Mehr Sicherheit mit ASP.Net

Unter Sicherheitsaspekten bietet ASP.NET eine deutliche Verbesserung im Vergleich zu früheren ASP-Modellen. Mit der neuen Plattform haben Entwickler die einfache Möglichkeit, Benutzereingaben im Programm zu validieren und auf integrierte Funktionen zuzugreifen, die eine Anwendung sperren. Zusätzlich bietet der .NET Support mit der Garbage Collection und Safe Strings Sicherheitsmechanismen, die gegen herkömmliche Angriffe in den meisten Fällen sehr wirksam sind. Eine richtig gesicherte .NET Anwendung ist nicht nur gegen Angriffe gestärkt, sie kann auch den entstehenden Schaden bei einem gelegentlichen Ausfall begrenzen.

Trotz dieser deutlichen Verbesserung kann ASP.NET, was die Sicherheit betrifft, sicherlich keine Wunder vollbringen. Nach Aussagen von Sicherheitsanalyst H.D. Moore, der im April auf der CanSecWest Conference drei nicht zu vernachlässigende Sicherheitsmängel in ASP.NETdrei nicht zu vernachlässigende Sicherheitsmängel in ASP.NET präsentierte, sind die tollen neuen Features keinen Pfifferling wert, solange sie von den Entwicklern nicht genutzt werden. Moore empfiehlt, die folgenden einfachen Sicherheitstipps zu befolgen, um ASP.NET Anwendungen sicherer zu machen.

Kontrollieren sie ihre Konfigurationsdaten
Als allgemeine Regel kann festgestellt werden, dass sie nichts im Internet platzieren sollten, was nicht auch von einem Hacker gesehen werden darf. Ausnahmen bilden hier alle Dateierweiterungen, die mit einem ISAPI-Handler verknüpft sind, der den Zugriff auf Dateien mit den folgenden Erweiterungen verhindert: .aspx, .cs, und .vb. Andererseits sind Dateien mit den Endungen .txt, .csv, und .xml nicht automatisch geschützt und können von jedem Besucher der Website angeschaut werden.

Bevor sie eine neue Anwendung programmieren, sollten sie sicherstellen, dass die Ablaufverfolgung und der Debugging-Support deaktiviert sind. Der customErrors-Tag in der web.config Datei sollte nicht auf „off“ stehen. Diese Sicherheitsmaßnahmen sind geeignet, um eventuelle Informationslecks zu vermeiden. So können keine Dateinamen oder -pfade und vielleicht sogar Quellcode nach außen gelangen, wenn in der Anwendung ein Fehler auftritt.

Weiterhin sollten sie ihre Projekt-Verzeichnisse aufräumen, bevor sie mit einer Anwendung in die Produktion gehen. Stellen sie sicher, dass beim Verteilen der neuen Anwendung alle Projektdateien von Visual Studio und temporäre Dateien aus dem Anwendungsverzeichnis entfernt wurden. Die .sln und .slo Dateien werden nicht vom ISAPI-Filter erfasst. Somit könnte aus dem Internet auf sie zugegriffen werden, wenn jemand den Namen ihres Projektes errät, was meistens nicht besonders schwer ist.

Vermeiden sie eine Session-Verwaltung ohne Cookies
Eines der krassen Probleme, das Moore während seines Tests von ASP.NET aufdeckte, war eine „Hijack“ Verwundbarkeit in Anwendungen, die das „cookie-less session management“-Schema verwenden. Dieses Schema bettet für jede Session eine ID in jede URL ein, so dass der Server den entsprechenden Client identifizieren kann. Das Problem hierbei ist, dass der Server bei Verwendung dieses Features im Falle einer bisher unbekannten, aber gültigen Session-ID eine neue Session erstellt, um fortzufahren. Ein gewiefter Angreifer kann diese Vorgehensweise ausnutzen, indem er einen legitimierten User mit einer URL versorgt, die eine bekannte, validierte Session-ID enthält. Diese kann der Angreifer nun verwenden, um Zugriff auf das System zu erlangen, nachdem der übertölpelte User authentifiziert wurde.

Dies ist eine heimtückische Attacke, so Moore, da die URL, die der User bekommt, zu keinem Zeitpunkt verdächtig aussieht, denn nur die Session-ID erscheint gefälscht . Moore empfiehlt Entwicklern, das „cookieless session management“ einfach nicht zu verwenden, bis Microsoft einen Patch für diesen Fehler anbietet.

Bleiben sie in der „Sandbox“
In der von .NET verwalteten Laufzeit-Umgebung erscheinen traditionelle Angriffe wie ein Buffer-Überlauf unmöglich. Moore weist jedoch auf ein Overflow-Problem hin, das er im StateServer ausmachen konnte. Bei diesem Beispiel wird das Unmögliche möglich. Es scheint, dass irgendwo im StateServer ein Aufruf existiert, der sich mit inkorrekten Speicheradressierungen an nicht verwalteten Programmcode richtet.

Laut Moore sollten sich Entwickler, wann immer es möglich ist, an die von .NET verwaltete „sandbox“ halten, da jeder Aufruf von nicht verwaltetem Code ähnliche Risiken mit sich bringt. Trotzdem brauchen sie als Programmierer manchmal die Funktionalität von eigenem Programmcode, was uns zu unserem nächsten Tipp bringt.

Validieren, validieren, validieren
Trotz all der schicken neuen Möglichkeiten gelten immer noch die gleichen alten Regeln, was die Validierung von Benutzereingaben betrifft. Entwickler sollten alle Möglichkeiten der leistungsfähigen Validator-Kontrollfunktion nutzen, indem sie das System.Web.UI.Validator-Interface erweitern, um Benutzereingaben zu „säubern“, bevor diese intern weiterverwendet werden. Wenn sie noch nie von den .NET-Validatoren gehört haben, sollten sie diesen Artikel unbedingt lesen.

Verwenden sie eine Typumwandlung
Sollten sie eine Web-Anwendung installieren müssen, die ihnen nicht vollständig sicher erscheint, sollten sie die in web.config verfügbaren Einstellungen nutzen, um diese Anwendung mit einem anderen Benutzerkonto zu starten und dann die Rechte dieses Kontos beschränken. Zusätzlich können sie den Internet Services Manager verwenden, um das Sicherheitslevel für eine Anwendung festzulegen, was etwas mehr an Sicherheit bringt. Wählen sie „Low Trust“, wird die Anwendung in einem separaten Speicherbereich gestartet. So sollte sie theoretisch nicht in der Lage sein, den Rest des Systems oder andere Web-Anwendungen nachteilig zu beeinflussen, sollten diese gefährdet sein oder aus irgendwelchen Gründen abstürzen.