Zahnlücken

Und geben wir es zu, auch uns als ASP.NET-Entwicklern wird es ein wenig mulmig, wenn wir von einer eklatanten Lücke in ASP.NET lesen. Beim Internet Explorer ist man das ja gewöhnt, aber das .NET Framework war doch bisher recht verschont geblieben, sieht man einmal von Slammer, dem netten MSDE-Wurm, ab. Die erste Lücke, die in letzter Zeit offenkundig wurde, war das JPEG-Leck im GDI+. Die Liste an betroffenen Systemen liest sich gewaltig. Allerdings behebt immerhin Servicepack 2 für Windows XP das Problem und für alle Probleme gibt es Updates. Wer also auf seinem Webserver das GDI einsetzt, um Grafiken zu generieren, ist gut beraten, sich abzusichern.
Das zweite aktuelle Leck ist fast noch ein schlimmeres Kaliber, zumindest für ASP.NET-Entwickler. Die Forms-Authentication oder zu Deutsch formulargestützte Authentifizierung hat ein Leck, über das der böswillige Nutzer eindringen kann. Dazu muss er nur in der URL auf das gesicherte Skript den Backslash mit einem Slash vertauschen bzw. für den Internet Explorer einfach %5 statt des Slash verwenden. Zuerst gemeldet wurde die Lücke auf der Mailing-Liste NTBugTraq. Von dort gelangte Sie über Blogs in die Welt. Hier finden Sie beispielsweise auch ein Testskript. Microsoft hat darauf reagiert und verrät die Umgehungsmöglichkeit per URL-Filter.
Nun ist die Frage: Wer ist schuld an den Sicherheitslecks? Gerde für die Forms Authentication hätte das seit 2001 kostenlos zur Verfügung stehende Microsoft-Tool URLScan2 auch diese Lücke in den meisten Fällen stopfen können. Sind es also die armen Administratoren, die einfach besser aufpassen müssten? Das stimmt sicherlich teilweise, da viele Angreifer lieber populäre und gut dokumentierte Lücken verwenden, statt neue ausfindig zu machen. Ein Teil der Verantwortung liegt allerdings auch bei Microsoft. Im Moment gleicht das Spiel ein wenig dem Wettlauf von Hase und Igel – und Microsoft ist dabei kein besonders beeindruckender Hase. Zu guter Letzt sind auch wir Entwickler gefordert: Zum einen müssen wir sicher programmieren, zum anderen auch prüfen, was auf unseren Servern passiert. Denn wie die aktuelle Top-20-Studie der größten Sicherheitslücken beweist, ist unser Umfeld mit IIS, ASP.NET, Webbrowser etc. das Gefährdetste überhaupt.


Ein Beitrag aus meiner Kolumne für das dot.net-Magazin, erschienen im Software & Support Verlag.