Mit Cross-Site-Scripting – kurz XSS – wird das Ausnutzen von Si­cher­heits­lü­cken in Web­an­wen­dun­gen be­zeich­net. Schäd­li­che Skripte werden dabei in einen ver­trau­ens­wür­di­gen Kontext ein­ge­speist, aus dem heraus sie das System der Nutzer angreifen können. Skripte sind Programme, die mit Skript­spra­chen wie Ja­va­Script und haupt­säch­lich als Quell­text­da­tei pro­gram­miert werden. Bei harmlosen Varianten handelt es sich bei­spiels­wei­se um auf­pop­pen­de Will­kom­mens­grü­ße, die lediglich etwas lästig sind. Im schlimms­ten Fall erlangen Angreifer mithilfe solcher Skripte aber auch ver­trau­li­che In­for­ma­tio­nen oder Zugriff auf den Computer des ge­schä­dig­ten Users.

Die Gefahr des Cross-Site-Scrip­tin­gs besteht immer dann, wenn die jeweilige Web­an­wen­dung Be­nut­zer­da­ten ohne Über­prü­fung an den Web­brow­ser wei­ter­lei­tet. Über so­ge­nann­te XSS-Löcher gelangen die schäd­li­chen Skripte zu den be­trof­fe­nen Clients. Dort ma­ni­pu­lie­ren diese An­wen­dun­gen bei­spiels­wei­se ser­ver­sei­ti­ge Skripte wie Formulare zur Be­nut­zer­an­mel­dung. Während für den User alles nach einem ver­schlüs­sel­ten und anonymen An­mel­de­vor­gang aussieht, werden die Daten in Wahrheit un­ge­fil­tert wei­ter­ge­ge­ben.

Nicht alle XSS-Angriffe zielen al­ler­dings darauf ab, sensible Daten zu stehlen bzw. dem be­trof­fe­nen Client direkt zu schaden. Ebenso ver­brei­tet sind Skripte, die den je­wei­li­gen Client als Initiator von Phishing- und Malware-Angriffen zweck­ent­frem­den oder den Inhalt der Website negativ verändern – die ei­gent­li­chen Ver­ur­sa­cher bleiben dabei meist anonym.

Cross-Site-Scripting Beispiele: Welche Arten von XSS-Angriffen gibt es?

Um zu ver­an­schau­li­chen, was Cross-Site-Scripting konkret für Website-Betreiber und -Besucher bedeutet, folgt eine kurze Auf­lis­tung und Er­läu­te­rung der un­ter­schied­li­chen Arten von XSS.

Re­flek­tier­tes Cross-Site-Scripting/XSS

Über das Aufrufen einer ma­ni­pu­lier­ten URL oder das Absenden eines prä­pa­rier­ten Formulars wird das schäd­li­che Skript an den Webserver gesendet, der es ohne Über­prü­fung wieder an den Client zu­rück­gibt. Der Schadcode wird nicht auf dem Server ge­spei­chert und existiert nur temporär bei der Erzeugung der Website durch den ge­schä­dig­ten Client. Beliebte An­griffs­zie­le sind dy­na­mi­sche Websites oder Mail-An­wen­dun­gen.

Beispiel: Bei dieser XSS-Variante bringt der Angreifer sein Skript in einem prä­pa­rier­ten Link unter. Im Anschluss versucht er den Link – bevorzugt über E-Mails – wei­ter­zu­lei­ten. Der ent­hal­te­ne Schadcode wird nur ausgelöst, wenn der Benutzer den er­hal­te­nen Link aufruft. Tut er dies, wird ihm bei­spiels­wei­se ein imi­tier­ter An­mel­de­bild­schirm seines Online-Bankings prä­sen­tiert. Anstatt die ein­ge­ge­be­nen Daten an den Webserver der Bank zu senden, sorgt das Skript jedoch für eine Umleitung auf die Adresse, die der Angreifer zuvor bestimmt hat.

Per­sis­ten­tes Cross-Site-Scripting/XSS

Beim per­sis­ten­ten bzw. be­stän­di­gen XSS werden die schäd­li­chen Skripte auf dem Webserver ge­spei­chert und bei jedem Aufruf durch einen Client aus­ge­lie­fert. Zu diesem Zweck werden solche Web­an­wen­dun­gen für den Angriff aus­ge­wählt, die Be­nut­zer­da­ten ser­ver­sei­tig speichern und an­schlie­ßend ohne Über­prü­fung oder Codierung ausgeben. Besonders anfällig für diese Scripting-Art sind Blogs und Foren.

Beispiel: In einem Forum werden von Usern ge­schrie­be­ne Beiträge in einer Datenbank ge­spei­chert. Dabei werden diese oftmals weder überprüft noch ver­schlüs­selt hin­ter­legt. Diese Chance machen sich die Angreifer zunutze und fügen einem ganz normalen Forenpost ihr schäd­li­ches Skript hinzu. Nichts­ah­nen­de User erhalten den je­wei­li­gen Link zu dem Post per E-Mail oder gelangen zufällig zu dem ent­spre­chen­den Eintrag und führen das Skript mit dem Aufruf aus.

DOM-basiertes Cross-Site-Scripting/XSS

Diese An­griffs­art wird auch lokales XSS genannt. Über das Aufrufen einer ma­ni­pu­lier­ten URL wird der Schadcode durch eine Lücke in einem cli­ent­sei­ti­gen Skript ohne Über­prü­fung aus­ge­führt. Im Gegensatz zu per­sis­ten­tem und re­flek­tier­tem XSS ist der Webserver nicht an dem Prozess beteiligt. Ent­spre­chend sind auch statische Websites, welche die jeweilige Skript-Sprache un­ter­stüt­zen, durch diese Scripting-Variante gefährdet.

Beispiel: Das DOM-basierte setzt wie das re­flek­tier­te Cross-Site-Scripting voraus, dass zunächst ein Link vom Benutzer geöffnet wird. Nach dem Öffnen des Links wird das ent­hal­te­ne Skript direkt in ein cli­ent­sei­ti­ges Skript wie Ja­va­Script in­te­griert. Selbiges liest den Ar­gu­ment­wert der URL aus und startet dadurch die Website inklusive der schäd­li­chen Anwendung.

So schützen Sie sich vor XSS-Angriffen

Die negativen Folgen, die Cross-Site-Scripting für Website-Nutzer und -Betreiber hat, sind nicht zu un­ter­schät­zen: Als User riskieren Sie den Verlust Ihrer Daten oder fungieren unbemerkt als un­frei­wil­li­ger Komplize der Angreifer. Als Website-Betreiber sind sie für die Daten Ihrer Kunden bzw. Besucher ver­ant­wort­lich und können zudem direkt durch Angriffe getroffen werden: Schäd­li­che Inhalte und Ser­ver­ab­stür­ze mindern die Be­su­cher­zah­len, und auf lange Sicht reagieren Such­ma­schi­nen wie Google mit Ab­stra­fun­gen und po­ten­ti­el­le Kunden mit Miss­trau­en. Das führt letztlich auch zu fi­nan­zi­el­len Einbußen. Daher sollten Sie als Website-Betreiber, aber auch als Nutzer unbedingt Maßnahmen einleiten, um Cross-Site-Scripting zu ver­hin­dern.

Schutz­maß­nah­men für Internet-User

Die ein­fachs­te Mög­lich­keit, cli­ent­sei­ti­ges Cross-Site-Scripting zu ver­hin­dern, ist das Aus­schal­ten der Ja­va­Script-Un­ter­stüt­zung im Browser. Ist dieses so­ge­nann­te Active Scripting de­ak­ti­viert, haben DOM-basierte XSS, die auf Ja­va­Script abzielen, keine Wirkung, da die schäd­li­che Anwendung erst gar nicht gestartet wird. Für einige Browser exis­tie­ren außerdem Add-ons, die Sie vor XSS-Angriffen schützen können. So gibt es für Mozilla Firefox bei­spiels­wei­se die Er­wei­te­rung NoScript. In den Stan­dard­ein­stel­lun­gen sind alle aktiven Inhalte von Websites, wie z. B. Ja­va­Script, Java-Applets, Adobe Flash oder Microsoft Sil­ver­light, au­to­ma­tisch gesperrt. Auf Wunsch können Sie die Blo­ckie­rung temporär aufheben oder die jeweilige Seite auf die Whitelist setzen, wenn Sie sich sicher sind, dass jene zu 100 Prozent ver­trau­ens­wür­dig ist. Ein letzter Tipp, den Sie nicht nur in Zu­sam­men­hang mit den Gefahren des Cross-Site-Scrip­tin­gs unbedingt be­her­zi­gen sollten: Fremd­da­ten wie Links sollten Sie stets skeptisch gegenüber sein und vor der Ver­wen­dung gründlich unter die Lupe nehmen.

Das können Sie als Website-Betreiber gegen XSS-Attacken un­ter­neh­men

Damit Ihre Web­an­wen­dun­gen keine Basis für XSS-Angriffe bieten, müssen Sie zunächst alle ein­ge­hen­den Ein­ga­be­wer­te als unsicher be­trach­ten. Bevor diese also vom Webserver in Empfang genommen werden, sollten sie ent­spre­chend geprüft werden. Die sicherste Methode ist hier wieder – wie beim Browser-Add-on NoScript für Clients – das Anlegen einer Whitelist. Sofern es die Ka­pa­zi­tä­ten erlauben, die Eingaben auf Ihrer Website zu scannen und nur ver­trau­ens­wür­di­ge Inhalte zu­zu­las­sen, erzeugen Sie auf diese Weise einen ex­zel­len­ten Schutz gegen Cross-Site-Scripting.

Zu­sätz­lich zu den Ein­ga­be­da­ten sollte al­ler­dings auch die Da­ten­aus­ga­be ab­ge­si­chert werden. Hierzu ist es notwendig, dass die pro­ble­ma­ti­schen HTML-Me­ta­zei­chen durch ent­spre­chen­de Zei­chen­re­fe­ren­zen ersetzt werden; dadurch werden die Me­ta­zei­chen als normale Zeichen gewertet und po­ten­zi­ell ein­ge­schleus­te Skripte können nicht gestartet werden. Die meisten Pro­gram­mier- und Skript­spra­chen wie Perl, Ja­va­Script oder PHP besitzen zu diesem Zweck bereits vor­de­fi­nier­te Funk­tio­nen zur Zei­chener­set­zung bzw. -mas­kie­rung, die Sie be­den­ken­los verwenden können.

Einfache XSS-Attacken wehren Sie außerdem durch den Einsatz von Web-Ap­pli­ca­ti­on-Firewalls ab.

Cross-Site-Scripting bildet oftmals nur die Vorstufe für schwer­wie­gen­de­re Angriffe, die Sie mit einem um­fas­sen­den Schutz der ein- und aus­ge­hen­den Da­ten­ein­ga­be Ihres Web­ser­vers also schon in der Ent­ste­hung vereiteln können.

SSL-Zer­ti­fi­kat kaufen
Sichern Sie sich Ihr SSL-Zer­ti­fi­kat
  • Ver­schlüs­selt die Website-Kom­mu­ni­ka­ti­on
  • Ver­hin­dert Si­cher­heits­war­nun­gen
  • Ver­bes­sert die Google-Plat­zie­rung
Zum Hauptmenü