Cross-Site-Scripting - XSS-Attacken verhindern

Worauf Website-Betreiber vorbereitet sein sollten

• Home
• Magazin
• Know How
• Projekte & Strategie

XSS: Drei Buchstaben beschreiben eine Bedrohung, mit der sich viele Website-Betreiber – auch namhafte – immer wieder konfrontiert sehen. Sie stehen als Abkürzung für das so genannte Cross-Site-Scripting. Dabei handelt es sich um eine Form der HTML Injection, bei der Angreifer bestehende Sicherheitslücken in der Programmierung ausnutzen, um eigenen Code in Websites oder in Online-Applikationen einzuschleusen und dort zur Ausführung zu bringen. Sie können so ohne Wissen des Internet-Nutzers, der die per XSS manipulierte, ursprünglich vertrauenswürdige Website aufruft, dessen sensible Daten stehlen oder gar physischen Zugriff auf dessen PC oder Internet-fähiges Endgerät erlangen.

XSS-Attacken: reflexive, persistente und DOM-basierte Angriffe

Bei den XSS-Attacken wird von den Angreifern in der Regel JavaScript, ActiveScript oder Visual Basic Script als Skript-Sprache verwendet. Dabei gilt es zwischen drei unterschiedlichen Angriffsarten zu unterscheiden, über die Cross-Site-Scripting stattfinden kann. Bei reflexiven XSS-Angriffen wird der Schadcode beim Abruf einer Website nur temporär eingeschleust. Angreifer machen sich hier meist die Parameter-Übergabe bei dynamischen Websites zunutze, die in der Regel über HTTP-GET oder HTTP-POST erfolgt. So kann der Angreifer durch Manipulation der HTTP-GET- beziehungsweise HTTP-POST-Parameter in der URL Einfluss auf die Inhalte einer dynamischen Website nehmen und so kontrolliert Schadcode ausgeben lassen.

Bei der persistenten XSS-Angriffsmethode wird der Schadcode hingegen dauerhaft in einer Website platziert. Der Code wird hierzu vom Angreifer in der Datenbank der Website gespeichert und von dort aus dann durch die Seite beim Abruf geladen sowie Client-seitig ausgeführt. Hierzu bedient er sich einfach der von vielen Website-Betreibern verwendeten Web-Applikationen, mit denen diese ihren Nutzern ermöglichen eigene Inhalte in Datenbanken einzuspeisen beziehungsweise auf der Website zu veröffentlichen. Als Beispiele seien hier Gästebücher, Foren und Kommentarfunktionen genannt. Schreibt der Angreifer seinen Schadcode beispielsweise direkt in ein Kommentar über ein System, das die Eingaben der Nutzer nicht prüft, wird der im Kommentar enthaltene Code in der Datenbank gespeichert und auf der Website veröffentlicht. Beim Abruf durch andere Nutzer wird der Schadcode dann von deren Browsern interpretiert und schließlich ausgeführt.

Deutlich seltener ist die dritte Form des Cross-Site-Scripting: Die DOM-basierten Angriffe. Sie setzen Schwachstellen meist nicht nur bei einer Website, sondern auch auf Nutzer-Seite zum Beispiel im Browser voraus, der Sonderzeichen in URLs gar nicht oder nicht richtig verarbeiten kann. Die DOM-basierten Angriffe adressieren statische HTML-Seiten, die mit JavaScript arbeiten. Auch hier kommen wieder manipulierte URLs ins Spiel.

Maßnahmen gegen XSS

Doch was können Website-Betreiber gegen XSS ausrichten? Das Wichtigste ist, dass diese alle Eingaben, die von ihren Nutzern getätigt werden – einschließlich der GET- und POST-Parameter in URLs – Server-seitig stets auf Plausibilität überprüfen. Bei PHP können bestimmten Sonderzeichen, die für die HTML-basierte Integration von Schadcodes benötigt werden, ein Backslash vorangestellt oder alle HTML-Metazeichen entschärft werden, in dem sie in den jeweiligen Entity-Code transformiert werden. In Foren, Gästebüchern oder ähnlichen Applikationen, die Nutzern das Veröffentlichen eigener Inhalte auf Websites ermöglichen, kann HTML entweder gänzlich deaktiviert oder stattdessen auf andere Auszeichnungssprachen wie BBCode zurückgegriffen werden. Die Integration von Schadcode über HTML wird damit unterbunden.

Mit der Content Security Policy (CSP) bietet sich Website-Betreibern eine weitere Möglichkeit, um Nutzer wirkungsvoll vor der Mehrheit der XSS-Attacken zu schützen. Mit ihr können sie Browsern durch Bereitstellung des HTTP-Headers "X-Content-Security-Policy" mitteilen, welche Domains sie als Quelle vertrauenswürdiger JavaScript-Codes akzeptieren sollen. Browser, die CSP unterstützen und bei denen diese Funktion aktiviert ist, ignorieren JavaScript-Codes auf HTML-Seiten standardmäßig. Stattdessen werden JavaScript-Codes in Form von js-Dateien, die ausschließlich aus den im HTTP-Header genannten, legitimen Quellen stammen, nachgeladen und ausgeführt.

Der Einsatz von CSP ist zwar mit einigem Aufwand verbunden, doch er lohnt sich. Nicht nur, dass die meisten XSS-Attacken wirkungsvoll verhindert werden können, wenn Nutzer einen CSP-fähigen Browser verwenden, sondern das Verfahren lässt sich auch auf Bilder, Stylesheets, Frames, Fonts und weitere Objekte ausweiten, in denen JavaScript eingebettet sein kann. Für viele Content-Management-Systeme sind bereits fertige Plug-ins verfügbar, die Website-Betreiber bei der Umstellung auf CSP unterstützen. Allerdings unterstützen noch nicht alle Browser die neue Policy.

Kommentare

Bitte beachten Sie unsere Informationen zum Datenschutz.

Weitere Artikel zum Thema