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.
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.
Im Entwickler Magazin 5.15 ist ein Artikel über die Spuren, die wir im Internet hinterlassen, und was man damit anstellen kann, erschienen.
Update 13. April 2016:
Der Artikel ist jetzt auch
online verfügbar.
Ende des Updates
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.
Im windows.developer 9.15 ist ein Artikel zur Sicherheit von AngularJS erschienen.
AngularJS? Das ist doch nur JavaScript, völlig harmlos!
Was kann da schon groß passieren?
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.