Abhilfe gegen Cross-Site-Scripting und Clickjacking

Mit Content Security Policy sollen künftig Cross-Site-Scripting-Attacken und andere Angriffe nicht mehr funktionieren. Als erster Browser unterstützt Firefox 4 das neue Konzept.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 6 Min.
Von
  • Daniel Bachfeld

Cross-Site-Scripting (XSS) ist zur Pest des Internet geworden, selbst Banken bekommen das Problem auf ihren Webseiten nicht in den Griff. XSS-Angriffe auf Browser könnten jedoch bald der Vergangenheit angehören, zumindest bei Firefox-Anwendern: Die neueste Firefox-Version 4 der Mozilla Foundation unterstützt Content Security Policy (CSP). Damit können Web-Administratoren dem Browser durch Senden des speziellen HTTP-Headers X-Content-Security-Policy mitteilen, welchen Domains er als Quelle vertrauenswürdigen JavaScript-Codes akzeptieren soll.

Ist CSP aktiv, wird in HTML-Dokumenten eingebetteter JavaScript-Code standardmäßig nicht mehr ausgeführt. Dabei ist es unerheblich, ob der Code bereits im Original-HTML-Dokument enthalten ist oder während eines Angriffs eingeschleust wurde – er wird schlicht vom Browser ignoriert. Typische XSS-Angriffe über präparierte URLs mit eingebettetem JavaScript laufen mit CSP deshalb ebenfalls ins Leere. Allerdings funktionieren mit aktiviertem CSP leider auch keine JavaScript-gesteuerten Events mehr, wie Click und Rollover.

Ersatzweise darf das geladene HTML-Dokument aber JavaScripte als js-Datei aus erlaubten Quellen nachladen. Etwa mit der Angabe X-Content-Security-Policy: allow ‘self’ erreicht man, dass der Browser nur Code akzeptiert, der vom eigenen Server geladen wird. Daneben lässt sich aber eine Liste weiterer erlaubter Domains im CSP-Header angeben. Mit CSP funktionieren leider auch mit JavaScript verknüpfte HTML-Events wie onclick und andere nicht mehr.

Wer CSP serverseitig unterstützen will, muss daher einige Umbauarbeiten in seinen Seiten in Kauf nehmen. Erste Erfahrungen mit der neuen Option hat bereits der Kurznachrichtendienst Twitter für die Domain mobile.twitter.com gesammelt. Der aufwendigste Schritt bei der Einführung war das Trennen von HTML- und JavaScript-Code. Eingebetteter JavaScripte (Inline Code) musste in eigene Dateien ausgelagert werden und über Script-Tags wieder nachgeladen werden. Die mit HTML-Events verknüpften JavaScript-Funktionen muss man im Code zuvor über die Funktion addEventListener zur Liste möglicher Ereignisse hinzufügen.

Twitter hat in seiner Policy mehrere Server definiert, von denen der Browser Inhalte nachladen darf.

Die Twitter-Entwickler stießen bei ihre Anpassungen und Tests auf mehrere Firefox-Plug-ins, bei denen die CSP-Optionen einen Alarm auslösten, weil sie versuchten, Code in das HTML-Dokument zu schreiben. Daneben waren die Entwickler überrascht, dass offenbar viele ISPs JavaScript in ausgelieferte HTML-Dokumente einschleusen, um Image-Tags auf ihre Caching-Server zu verbiegen. Zudem mussten sie einige JavaScript-Bibliotheken anpassen. Insgesamt ist Twitter mit der Einführung von CSP auf mobile.twitter.com zufrieden und den Schutz nach und nach auf der gesamten Plattform einführen.

JavaScript kann aber nicht nur in HTML-Seiten eingebettet sein, sondern mitunter auch in präparierten Bildern und anderen Objekten versteckt sein. Via MIME-Sniffing erkannte etwa früher der Internet Explorer Code in Bitmaps und führte diesen aus. Deshalb ist CSP nicht nur auf das Nachladen von Skript-Code beschränkt, sondern lässt sich auf auf Bilder, Stylesheets, Frames, Fonts und weitere Objekte erweitern. Praktischerweise löst CSP auf diese Weise teilweise die Clickjacking-Problematik.

Mit der Übermittlung des Parameters frame-ancestor im Header signalisiert ein Webserver dem Firefox-Browser, dass er eine aufgerufene Seite nicht in einem Iframe öffnen darf. Damit können Klickbetrüger Anwendern keine durchsichtigen IFrames mehr unterschieben, auf denen er ungewollt unsichtbare Elemente anklickt. Anders als die von Microsoft präferierte Anti-Clickjacking-Lösung mit dem Header X-Frame-Options (XFO) erlaubt CSP jedoch die Angabe einer Domain-Liste und ist somit wesentlich flexibler. Zusätzlich lässt sich im neuen Header angeben, ob ein Browser weitere Inhalte via HTTP oder HTTPS nachladen soll.

Wogegen CSP jedoch nur begrenzt hilft, ist persistentes XSS. Zwar kann ein Angreifer nicht mehr einfach JavaScript-Code etwa durch Kommentare in HTML-Seiten einschleusen. Gelingt es ihm jedoch, seinen Code auf irgendeinem Weg in die Datenbank oder die Daten einzuschmuggeln, in denen der legitime JavaScript-Code hinterlegt ist, greift CSP nicht mehr. Glücklicherweise sind derartige Fälle von persistentem XSS nicht allzu häufig. Gegen Cross-Site-Request-Forgery-Angriffe (CSRF) hilft CSP indes gar nicht. Webadmins sollen solche Attacken jedoch über das Senden des Origin-Headers wirkungslos machen können.

CSP soll vollständig rückwärtskompatibel sein. Sendet die Website keinen CSP-Header, fällt Firefox einfach auf die herkömmliche Same Origin Policy zurück. Browser ohne CSP-Unterstützung ignorieren den zusätzlichen Header einfach. Brendan Sterne von der Mozilla Foundation, der Kopf hinter CSP, hat eine Testseite zur Verfügung gestellt, um die Arbeitsweise mit verschieden CSP-Parametern und Optionen zu demonstrieren. Admin können via CSP auch eine URI definieren, an die eine Meldung bei Verletzung der Policy geschickt wird. Das hilft nicht nur beim Aufdecken von Angriffen, sondern auch beim Beseitigen von Fehlern bei der Umstellung.

Anhand der CSP-Demo können Entwickler nachvollziehen, wie sich die Restriktionen auf das Nachladen von Objekten auswirken.

Neben Firefox sollen auf der Client-Seite auch Thunderbird 3.3 und SeaMonkey 2.1 demnächst CSP unterstützen. Was fehlt, sind nun weitere Browser und mehr Betreiber von Webservern, die das neue Konzept adaptieren. Bislang haben die anderen Browserhersteller eigene Anti-XSS-Funktionen in ihre Browser eingebaut und bei Anti-Clickjacking auf den X-Frame-Options-Header gesetzt. Letzteres hat sich auf Seiten der Webseitenbetreiber aber nicht durchgesetzt. Bleibt zu hoffen, dass CSP nun besser aufgenommen wird. Hilfe bei der Umstellung etwa für das eigene Content-Management-System bieten fertige Plug-ins, etwa für WordPress, Drupal und das Webframework Django. (dab )

(dab)