„Session Fixation“-Angriffe funktionieren so: Ein Angreifer startet eine Verbindung mit dem Webserver und erhält damit eine Session-ID. Diese schiebt er (beispielsweise per XSS) einem Opfer zu, das sich auf dem Webserver authentifiziert. Die Session des Angreifers ist nun authentifiziert, der Angreifer kann mit den Rechten des Opfers auf das System zugreifen. Elegant.

Und ebenso elegant zu vermeiden: Die Authentifizierungsroutine erstellt für die authentifizierte Session eine neue Session-ID und verwirft die bisherige Session. Um genau dieses nicht ständig neu programmieren zu müssen, verwenden Entwickler Frameworks.

Bisher wiegten ich die Nutzer von bewährten Java-Frameworks in Sicherheit. Auf eine Programmierumgebung, die täglich eingesetzt wird von Hunderten erfahrenen Kollegen, sollte ja Verlass sein und sie sollte keine gefährlichen Hintertürchen öffnen. Ganz anders als bei den risikofreudigen PHP-Kollegen, die jede Funktion immer wieder neu erfinden.

Doch ein Artikel in der iX bereitete nun einer trügerischen Sicherheit ein Ende: Session Fixation ist mitnichten ein reines PHP-Problem. Einige der beliebtesten Java-Servlet-Container sind anfällig für diese Schwachstelle. Schockiert vernimmt der Programmierer die Namen bekannter Java-Frameworks wie Tomcat, JBoss und JOnAS. Und bei richtiger Interpretation der CWE-Liste (Common Weakness Enumeration) implementieren wohl auch ASP (Active Server Pages) und .net von Microsoft die Anmeldung falsch.

Eine Blamage für die Java-Gilde. Immerhin war diese Schwachstelle bereits 2004, also vor sechs Jahren, in den OWASP Top Ten erwähnt, wie sie zu beheben ist ebenso. Die CWE-Liste beschreibt Problem und auch Lösung in klaren Worten: „Invalidate any existing session identifiers prior to authorizing a new user session“. So einfach könnte es sein.

Die entscheidende Frage ist: Wie kann es geschehen, dass wichtige Komponenten, die tagtäglich zum Einsatz kommen, solch gravierende Fehler aufweisen? Die für mich naheliegendste Erklärung wäre, dass wahrscheinlich ehemalige PHP-Programmierer die Java-Frameworks entwickelt haben. Doch das wäre nicht fair. Gleichgültig wer die Entwickler der Framework-Bausteine sind: Sie sollten sich bewusst machen, dass es nicht nur darum geht, neue Features einzubauen, sondern dass die Ergebnisse auch sicher sind.

Übrigens: Ob Ihr Framework den Fehler enthält, können sie beispielsweise mit dem Firefox Add-On Live HTTP Headers oder etwas einfacher mit CookieSafe prüfen. Wenn die ID im Session-Cookie nach der Anmeldung die gleiche ist wie vorher, dann ist Ihre Anwendung anfällig. Gegenmaßnahmen für die Java-Frameworks beschreibt besagter Artikel.