Artikel von Michael Willers
Als Abonnent haben Sie vollen Zugriff auf alle Artikel im Archiv.
Zum Download eines Artikels und/oder der zugehörigen Quelltexte, klicken Sie
den gewünschten Artikel einfach an.
(
dotnetpro 12/2005,
Seite 120)
Speichern und Lesen von Konfigurationsdaten mit DPAPI
Eine Frage führt immer wieder zu kontroversen Diskussionen unter Entwicklern: „Wie kann ich meine Konfigurationsdaten vor Missbrauch schützen?“ Neuerdings lautet die Antwort oft: „Nimm doch DPAPI“. Die Praxis befördert den unbedarften Entwickler jedoch unsanft auf den Boden der Tatsachen. Ein Erfahrungsbericht.
(
dotnetpro 11/2005,
Seite 94)
Custom Permissions installieren
Mit Custom Permissions können Sie im .NET Framework direkte Systemaufrufe absichern. Diese Berechtigungen müssen Sie aber auf jedem Client-Rechner zunächst in das Sicherheitsystem der CLR einbetten. dotnetpro zeigt, wie Sie Ihren Anwendungen den nötigen Passierschein mit auf den Weg geben.
(
dotnetpro 10/2005,
Seite 122)
Systemaufrufe mit Custom Permissions absichern.
Die CLR bietet Sicherheit. Was aber tun, wenn das auf Sicherheit getrimmte .NET-Programm Funktionen des Windows-APIs benötigt? Direkte Aufrufe von Systemfunktionen kann die CLR nicht überwachen. dotnetpro zeigt, wie Sie einen Torwächter installieren.
(
dotnetpro 9/2005,
Seite 112)
Du kommst hier nicht rein!
Die Situation ist bekannt: die neue .NET-Bibliothek ist fertig, das dazugehörige API sauber dokumentiert – und plötzlich kommt ein neugieriger Zeitgenosse daher und greift am API vorbei direkt auf die Funktionen zu. dotnetpro zeigt, wie sich dies verhindern lässt.
(
dotnetpro 7-8/2005,
Seite 106)
Den Zettel, auf dem das Passwort notiert ist, sollte man bekanntlich nicht achtlos ins Altpapier werfen, denn wer weiß, wer darin herumschnüffelt. In .NET 2.0 bietet die Klasse SecureString das Äquivalent zum Schredder. dotnetpro stellt diese und weitere Neuerungen im Bereich Security unter .NET 2.0 vor und zeigt, wo es noch Lücken gibt.
(
dotnetpro 6/2005,
Seite 122)
Mit Windows Server 2003 und Windows XP Service Pack 2 hält ein neues Feature Einzug in die Windows-Welt, das den Namen „Services without Components“ trägt. dotnetpro beleuchtet die Funktionsweise und erläutert den Nutzen dieses Features bei der Arbeit mit Transaktionen.
(
dotnetpro 6/2005,
Seite 116)
Nicht jede Anwendung darf alles. Mit einer CLR-Sicherheitsrichtlinie legen Sie fest, welche Rechte eine Anwendung erhält. Nur: Wie kommt diese CLR-Sicherheitsrichtlinie auf den Client? dotnetpro zeigt, wie Sie eigene CLR-Sicherheitsrichtlinien konzipieren und auf dem Zielrechner installieren.
(
dotnetpro 5/2005,
Seite 126)
Manche unter Ihnen werden schon einmal einen Windows-Dienst implementiert haben. Unter .NET ist das recht einfach geworden, denn dafür gibt es sogar eine eigene Projektvorlage. Wenn der Service aus Sicherheitsgründen einen eigenen Account erhält, findet sich in den Benutzereinstellungen die Option „Interact with desktop“. dotnetpro erklärt, was es damit auf sich hat. Ein Account für den Dienst
(
dotnetpro 5/2005,
Seite 131)
Trotz .NET und Common Language Runtime bleibt die „DLL-Hölle“ den Entwicklern wohl noch eine ganze Weile erhalten. Dabei ist ein XCOPY-Deployment schon unter Windows XP möglich – und zwar ganz ohne .NET. Ein wenig Handarbeit macht’s möglich. COM ohne Registry
(
dotnetpro 4/2005,
Seite 90)
Dass man nach Möglichkeit ohne Administratorrechte arbeiten sollte, dürfte sich herumgesprochen haben. Schlagwörter wie Non-Admin und Limited User Acess, auch LUA genannt, beginnen sich einzubürgern. Nur, was tun, wenn sich eine lebenswichtige Anwendung der Entziehungskur partout verweigert und darauf besteht, nur mit Adminrechten zu laufen?
(
dotnetpro 12/2004,
Seite 114)
Zugriffsrechte und Privilegien
Die Installation von Programmen ist eine unendliche Geschichte von Missverständnissen. Probleme gibt es oft dann, wenn Programme ohne Administratorrechte eingerichtet werden müssen. Denn nicht jeder Entwickler denkt daran, dass sein Werk auch auf Rechnern eingesetzt werden könnte, die zwischen verschiedenen Nutzerrechten unterscheiden.
(
dotnetpro 11/2004,
Seite 106)
Praxis!
In der letzten Kolumne haben wir uns ausführlich mit der Ursache für die allseits unbeliebte Fehlermeldung „Access Denied“ beschäftigt. Gemäß einem alten Werbespruch wollen auch wir „es jetzt anpacken“ und Abhilfe schaffen. Allerdings führt der Weg über C++. Das Resultat ist ein kleines Tool, mit dem sich ASP.NET-Anwendungen auch ohne Admin-Rechte entwanzen lassen.
(
dotnetpro 10/2004,
Seite 96)
Ohne Administratorrechte
Sie haben nur zwei Möglichkeiten, dies zu tun: Entweder haben Sie Administratorreche oder der ASP.NET-Prozess muss unter dem gleichen Account wie der im System angemeldete Benutzer laufen. Klingt kompliziert? Ist es auch. Schuld ist aber nicht ASP.NET sondern das Debugging-API der CLR ist’s. Aber alles der Reihe nach.
(
dotnetpro 9/2004,
Seite 104)
Least Privileges!
Melissa, Blaster und Sasser haben bleibenden Eindruck hinterlassen. Dabei hätte es gereicht, wenn Benutzer wirklich nur Benutzer und nicht Administratoren gewesen wären. Doch lassen sich einige Aufgaben unter Windows nicht mit einem Benutzer-Account ausführen. Dieser Beitrag gibt Tipps, wie man im täglichen Programmierer-Leben mit solchen Situationen fertig wird.
(
dotnetpro 9/2004,
Seite 114)
Scripting für alle
Auch das noch: Der Kunde will, dass seine Applikation scriptfähig ist, denn sie soll optimale Möglichkeiten für das Customizing bieten! Aber mit .NET ist das im Prinzip kein Problem. Mit wenigen Codezeilen schreiben Sie einen eigenen Scripting-Host. Spezielle Skriptspachen sind damit nicht mehr zwingend notwendig. dotnetpro gibt einen Überblick und zeigt Lösungsansätze auf.
(
dotnetpro 7/2004,
Seite 104)
Blindes Vertrauen
Sicherheit ist, wenn nichts geht. Da aber immer ein bisserl was gehen muss, schaltet man einfach auf Full Trust und alles ist paletti. Dann könnten allerdings Blaster und Konsorten kommen und eindrucksvoll zeigen, dass Full Trust unter .NET keine wirklich gute Idee ist. dotnetpro zeigt es Ihnen hier völlig gefahrlos.
(
dotnetpro 7/2004,
Seite 106)
Installation mit Klasse
„Einfach kopieren und fertig“, so lautet die Marketingbotschaft zu .NET aus Redmond. Es scheint, als würden Installationsprogramme nicht mehr gebraucht. Es kommt jedoch ganz auf den Einzelfall an. Bei serverseitigen Anwendungen etwa erweist sich der Windows Installer als unverzichtbares Werkzeug.
(
dotnetpro 6/2004,
Seite 110)
Input macht kaputt!
Da haben Sie das Programm getestet und gedebugged und dann kommt so ein mieser Hacker und führt es mit nur einer Eingabe aufs Glatteis. Der Grund: Ungeprüfte Eingaben sind die Hauptursache für erfolgreiche Hacker-Angriffe. dotnetpro zeigt gängige Angriffsmuster und Maßnahmen, die Abhilfe schaffen.
(
dotnetpro 5/2004,
Seite 98)
Bitte hier unterschreiben
Gibt es zwischen Strong Names und Zertifikaten einen Zusammenhang? In der Tat: Es gibt ihn und er ist viel unmittelbarer, als man zunächst glauben mag. Das Zertifikat sorgt dafür, dass Sie im Fall der Fälle den Verursacher der bösen Tat zumindest dem Namen nach kennen. Es bildet deshalb zusammen mit einem Strong Name ein ideales Team.
(
dotnetpro 4/2004,
Seite 96)
Ihr Friedrich Wilhelm
Seit Beginn des .NET-Zeitalters macht der Begriff Strong Name die Runde durch die Entwicklergemeinde und sorgt für Gesprächsstoff. dotnetpro bringt ein wenig Licht ins Dunkel und zeigt, was sich hinter einem Strong Name verbirgt. Nur so viel vorweg: Sicherheit spielt dabei eine grundlegende Rolle.
(
dotnetpro 4/2004,
Seite 100)
Bring your own transaction
„Just do me favour and bring me home“ heißt ein Refrain der Musikgruppe „Fury in the Slaughterhouse”. Dies ist auch das Motto dieses Artikels. COM+ oder .NET Enterprise Services tun Ihnen einen Gefallen: Beim Design der ersten großen Anwendung wünscht man sich Transaktionen auf Methodenebene herbei. Der Mechanismus „Bring your own transaction“ kann helfen.
(
dotnetpro 3/2004,
Seite 110)
Letzte Möglichkeit
Vom Girokonto abgebucht, aber aus dem Automaten kommt kein Geld. Wer so ein Horrorszenario bei seinen Anwendungen vermeiden will, setzt Transaktionen ein. Sie sorgen mit dem Ganz-oder-gar-nicht-Prinzip für eine komplette Ausführung. Was aber, wenn eines der beteiligten Objekte wie etwa die Registry gar keine Transaktionen unterstützt? Dann helfen der Compensating Resource Manager und dotnetpro weiter.
(
dotnetpro 12/2003,
Seite 108)
No Registry, just COM
.NET hat sich noch nicht in dem Maße durchgesetzt, dass es schon eine Alternative zur DLL-Hölle gäbe. Mit ein wenig Handarbeit entfliehen Sie dem DLL-Aufwand schon heute, indem Sie für clientseitiges XCOPY-Deployment gänzlich ohne .NET sorgen. dotnetpro zeigt eine Lösung.
(
dotnetpro 11/2003,
Seite 128)
Darf der das?
Im .NET Framework muss der Entwickler festlegen, auf welche Ressourcen eine Komponente in welchem Umfang zugreifen darf. Das ist insbesondere beim Einsatz unbekannter Komponenten sinnvoll, die aus dem Internet heruntergeladen wurden. dotnetpro zeigt, wie Sie Ihre wertvollen Ressourcen mithilfe maßgeschneiderter Berechtigungssätze schützen können.