Sicherheit
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 08/2006,
Seite 118)
Bei gewöhnlichen Briefen schützt der Umschlag vor neugierigen Blicken und die Unterschrift beweist, wer ihn abgesendet hat. Wer den gleichen Effekt für E-Mails bewirken will, muss seine Mails verschlüsseln und signieren. dotnetpro zeigt, wie Sie dieses Ziel mit VB.NET 2.0 und den Collaboration Data Objects (CDO) erreichen.
(
dotnetpro 05/2006,
Seite 106)
Paranoide leben länger
Cross Site Scripting und SQL Injection sind bekannte Methoden, um Websites anzugreifen. Aber haben Sie auch schon von Cross Site Request Forgeries und XPath Injection gehört? Wer sich gegen Attacken aus dem Netz wappnen will, muss gleichermaßen mit alten Bekannten wie mit neuen Ansätzen der „Black Hats“ rechnen. dotnetpro rät: Im Zweifelsfall besser paranoid als offline.
(
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 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 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 3/2005,
Seite 106)
CAS (Code Access Security) ist eines der Sicherheits-Subsysteme von .NET. Die Code-Zugriffssicherheit steuert die Zugriffsrechte auf Ressourcen. Eine Entscheidung darüber, ob der Code auf die angeforderte Ressource zugreifen darf, obliegt der Common Language Runtime. Die CLR benötigt dazu jedoch ein komplexes Regelwerk. Dieses kann per Administrations-Tool, aber auch per Code beeinflusst werden.
(
dotnetpro 2/2005,
Seite 100)
Guten Webanwendungen muss ein Spagat gelingen: Einerseits sollen sie öffentlich zugänglich sein. Andererseits sollen die sicherheitskritischen Funktionen nur wenigen berechtigten Personen vorbehalten sein. dotnetpro erläutert die Grundlagen eines Sicherheitskonzepts fürs Web. Den Ausgangspunkt bildet das Szenario einer Intranet-Anwendung mit ASP.NET.
(
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 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 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.