Wir hatten ja schon festgestellt, dass die
einfachste Lösung
zum Verhindern von XSS, das Verbieten von HTML und damit JavaScript als
Benutzereingabe, heutzutage sehr oft nicht mehr möglich ist.
Dass die Benutzer aber manuell HTML-Code eingeben kann man meist auch nicht
erwarten, welcher normale Benutzer "spricht" schon HTML? Oder eine andere
Auszeichnungssprache wie BBCode? Womit diese Lösung ebenfalls
ausscheidet.
Unser Tool, unsere Daten, also alles ganz harmlos?
Am einfachsten verhindern Sie Cross-Site Scripting, indem Sie gar kein HTML
und damit JavaScript als Benutzereingabe akzeptieren. Wenn die Eingabe nur
aus reinem Klartext bestehen darf, kann sie beim Finden des ersten
HTML-Tags verworfen werden. Denn dann versucht jemand einen Angriff, und
der wird sofort abgewehrt, fertig, aus. Sie sollten nicht mal den Versuch
machen, den enthaltenen Code aus der Eingabe zu löschen. Denn die
Eingabe dient einzig und allein dazu, Schadcode in die Seiten Ihrer
Webanwendung einzuschleusen. Es gibt darin nichts, was aus irgend einem
Grund gerettet werden müsste.
Diese ebenso einfache wie effektive Lösung ist heutzutage nicht mehr
immer möglich. In Zeiten des Web 2.0 mit seinem "User generated
content" ist HTML-Code, zum Beispiel Auszeichnungs- oder
Formatierungsanweisungen, oft ein erwünschter Teil der Eingabe. Und
damit wird es deutlich schwieriger, erwünschte und unerwünschte
Inhalte auseinander zu halten.
Microsoft hat gestern
außer der Reihe
ein Update für den Internet Explorer veröffentlicht. Laut dem
zugehörigen Security Bulletin
MS15-093
wird die Schwachstelle mit der CVE-ID
CVE-2015-2502
bereits für Angriffe ausgenutzt. Was aber zu erwarten war, denn warum
sonst sollte Microsoft das Update außer der Reihe
veröffentlichen?
Damit sind wir
in diesem Jahr
bei 14 0-Day-Exploits angekommen. Ungeschlagener Spitzenreiter ist nach
wie vor der Flash Player mit bisher sieben Exploits. Außerdem gab es
drei für Microsoft Office, mit dem heutigen ebenfalls drei für
den Internet Exlorer und einen für Java.
Nachdem Sie alle möglicherweise für XSS anfälligen
Parameter der Webanwendung
ermittelt
und eine möglicherweise vorhandene Schutzfunktion
erkannt
haben, kann die Suche nach XSS-Schwachstellen los gehen.
Je nachdem, wo ein Parameter ausgegeben wird, müssen Sie andere Tests
verwenden. Oder genauer: Sie müssen Ihren Test so an die Umgebung
anpassen, dass er auch ausgeführt werden kann. Und nicht schon deshalb
fehl schlägt, weil der Browser ihn gar nicht als ausführbar
akzeptiert.
Auch am August-Patchday hat Microsoft mal wieder 0-Day-Schwachstellen
behoben, die bereits für Angriffe ausgenutzt werden: Eine Remote Code
Execution in Microsoft Office und eine Privilegieneskalation im Mount
Manager, die wohl auch zum Einschleusen von Code genutzt werden kann, sofern
der Angreifer einen USB-Stick anschließen (lassen) kann.
Damit sind wir bei 13 0-Day-Exploits
in diesem Jahr
angekommen. Ungeschlagener Spitzenreiter ist der Flash Player mit bisher
sieben Exploits. Außerdem gab es drei für Microsoft Office,
zwei für den Internet Exlorer und einen für Java.
Nachdem Sie alle möglicherweise für XSS anfälligen Parameter der
Webanwendung
ermittelt haben,
kann die Suche nach XSS-Schwachstellen eigentlich los gehen. Es sind nur
noch ein paar Vorbemerkungen nötig.
Joshua J. Drake von den Zimperium zLabs hat
mehrere Schwachstellen
in der Multimedia-Bibliothek
Stagefright
von Android entdeckt, die die Ausführung beliebigen Codes erlauben. Und
von Trend Micro wurde darin
eine Schwachstelle
entdeckt, über die das Gerät nahezu komplett lahm gelegt werden kann.