“aber ob und wann” die Lücke geschlossen wird…
Sonntag, 29. Januar 2012, 13:45 Uhr | Autor: ich
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.)
Thema: Sicherheit, XSS | 2 Kommentare
