XSS vs. CSRF Angriffe – Was sind die Unterschiede?

Client-seitige Angriffe sind schwer zu beheben, da sie das Vertrauen zwischen einem Webserver und den Benutzern, die auf die Website zugreifen, missbrauchen. Zwei dieser clientseitigen Angriffe sind Cross-Site Scripting (XSS) und Cross-Site Request Forgery (CSRF). Bei ihnen werden bösartige Skripte in ein Zielsystem eingeschleust, um den Tech-Stack tiefergehend auszunutzen oder Benutzerdaten zu stehlen. In diesem Artikel erörtern wir XSS- und CSRF-Angriffe und erfahren mehr über typische Angriffsmechanismen, Präventionstechniken und die Unterschiede bei der Durchführung dieser Angriffe. 

Was sind XSS und CSRF?

Sowohl bei CSRF als auch bei XSS handelt es sich um clientseitige Angriffe, die die Same-Origin-Policy missbrauchen und das Vertrauen zwischen der Webanwendung und dem Benutzer bzw. Opfer ausnutzen.

XSS- und Cross-Site-Scripting-Angriffe ermöglichen es einem Angreifer, die Interaktionen von legitimen Benutzern mit einer angreifbaren Anwendung zu beeinträchtigen.

Was ist XSS?

XSS-Schwachstellen treten in Webanwendungen auf, die Benutzereingaben akzeptieren und diese ohne Kodierung oder Validierung als Antwort verwenden. Die böswilligen Benutzer erstellen bösartigen Code und übermitteln ihn über das Eingabeformular. Der Zielserver übernimmt dieses Skript, fügt es in seine Antwort ein und der Client-Browser führt es am Ende aus. Da der Browser dem Webserver vertraut, gewährt er dem bösartigen Skript Zugriff auf Cookies, das Sitzungs-Token und andere lokal gespeicherte sensible Client-Informationen.

XSS ist ein bekannter Angriffsvektor, und die Auswirkungen eines erfolgreichen Angriffs variieren typischerweise für verschiedene Szenarien, darunter:

• Offenlegung von Benutzerdateien
• Installation von Malware/Trojanischen Pferden
• Offenlegung von Onlinebanking-Informationen
• Änderung von HTML/DOM-Inhalten
• Umleitung von Benutzern auf unbekannte Websites

XSS-Angriffsarten

XSS-Angriffe werden hauptsächlich in drei Typen eingeteilt:

Gespeicherte XSS-Angriffe/persistente XSS/Typ-I-XSS

Bei einem Stored XSS-Angriff wird der injizierte bösartige Code dauerhaft in verschiedenen Komponenten der anfälligen Webanwendung gespeichert, z. B. in der Datenbank, im Kommentarfeld, im Besucherprotokoll, im Nachrichtenforum usw. Jedes Mal, wenn ein Client die infizierte Website besucht oder eine Anfrage an den Webserver stellt, führt die Anfrage das bösartige Skript im Browser des Benutzers aus.

Blindes XSS

Eine hybride Form des XSS-Angriffs, bei der das Skript des Angreifers gespeichert wird und die Benutzer von der Backend-Anwendung reflektiert werden.

Reflektiertes/nicht-persistentes XSS

Beim reflektierten Cross-Site-Scripting wird das bösartige Skript vom Webserver reflektiert, z. B. in einem Suchergebnis, einer Fehlermeldung oder einer anderen Webserver-Antwort, die eine Benutzereingabe enthält.

Das Skript wird dem Opfer über einen externen Weg zugestellt, z. B. über eine andere Website oder eine E-Mail-Nachricht. Wenn das Opfer ein Formular ausfüllt, die Website des Hackers aufruft oder auf einen verdächtigen Link klickt, wird das bösartige Skript an die Website gesendet und dann im Browser des Clients ausgeführt.

DOM-basiertes XSS

Beim DOM-basierten Cross-Site-Scripting wird das bösartige Skript ausgeführt, indem die Document Object Model-Umgebung des Opferbrowsers verändert wird. Bei diesem Angriff wird die HTTP-Antwort des Webservers nicht geändert, sondern die Ausführung des clientseitigen Codes aufgrund von DOM-Modifikationen verändert.

Was ist CSRF?

Cross-Site Request Forgery (CSRF), auch bekannt als Session Riding oder One-Click-Attacke, ist ein Cyberangriff auf Webanwendungen, bei dem die Opfer unwissentlich Aktionen im Namen des Angreifers durchführen. CSRF-Angriffe nutzen eine Sicherheitslücke in Webanwendungen aus, die nicht zwischen einer bösartigen und einer legitimen Anfrage innerhalb einer authentifizierten Benutzersitzung unterscheiden können. 

Angreifer starten CSRF-Angriffe in der Regel mit Social-Engineering-Techniken, um das Opfer dazu zu bringen, eine Seite zu laden oder auf einen Link zu klicken, der eine bösartige Anfrage enthält. Der Link sendet eine bösartige Anfrage vom Browser des authentifizierten Benutzers an die Ziel-Website. 

Bei den meisten Websites enthalten die Browseranfragen von Natur aus Sitzungsinformationen wie Sitzungscookies, ein gültiges Token oder Anmeldedaten, die die Website mit dem Benutzer verknüpft. Wenn sich der authentifizierte Benutzer bereits in einer aktiven Sitzung mit der Ziel-Website befindet, behandelt die Website die neue bösartige Anfrage als gültige Anfrage des Benutzers und führt sie aus.

CSRF-Angriffsarten

Eine Webanwendung ist anfällig für Cross-Site Request Forgery, wenn sie nicht zwischen einer unzulässigen und einer gültigen Anfrage unterscheiden kann. Der Angriff ist nur dann erfolgreich, wenn sich der authentifizierte Benutzer in einer aktiven Sitzung mit der Webanwendung befindet.

Login CSRF-Angriff

Mit einer besonderen Form des CSRF-Angriffs, dem so genannten Login-CSRF-Angriff, können sich Angreifer Zugang zu den vertraulichen und sensiblen Daten des Opferbenutzers verschaffen. Bei diesem Angriff wird ein ahnungsloser Benutzer gezwungen, sich bei einem Konto anzumelden, das der Hacker kontrolliert. Das Opfer wird dann dazu verleitet, persönliche und sensible Daten wie E-Mail-Adressen und Kreditkarteninformationen in das Konto einzugeben. 

Gespeicherter CSRF-Angriff

Ein CSRF-Angriffsbündel kann auch auf der anfälligen Website gespeichert werden. Der Angreifer kann einen Gespeicherte CSRF-Angriff durchführen, indem er entweder einen erweiterten XSS-Angriff durchführt oder ein IFRAME- oder IMG-Tag in einem Feld speichert, das HTML akzeptiert. Das Speichern des Angriffs auf der Website erhöht den Schweregrad und die Wahrscheinlichkeit des Angriffs, da der Benutzer des Opfers nun sicher ist, dass er die CSRF-geladene Seite sieht, und er würde sich natürlich auch gegenüber der Seite authentifizieren.

Unterschiede zwischen CSRF und XSS

Sowohl bei CSRF als auch bei XSS handelt es sich um clientseitige Angriffe, die die Same-Origin-Policy missbrauchen und die Vertrauensbeziehung zwischen der Webanwendung und einem ahnungslosen Benutzer ausnutzen.

Es gibt jedoch einige grundlegende Unterschiede zwischen XSS- und CSRF-Angriffen, darunter

• XSS-Angriffe folgen einem Zwei-Wege-Angriffsmuster, das es dem Angreifer ermöglicht, ein bösartiges Skript auszuführen, auf die Antwort zuzugreifen und anschließend sensible Daten an ein Ziel seiner Wahl zu senden. Im Gegensatz dazu ist CSRF ein einseitiger Angriffsmechanismus, bei dem der Angreifer nur die HTTP-Anfrage initiieren, aber nicht die Antwort als Gegenleistung für die initiierte Anfrage abrufen kann.
• CSRF-Angriffe setzen voraus, dass sich der authentifizierte Benutzer in einer aktiven Sitzung befindet, während dies bei XSS-Angriffen nicht der Fall ist. Bei einem XSS-Angriff können Nutzdaten gespeichert und übermittelt werden, sobald sich der Benutzer anmeldet.
• CSRF-Angriffe haben eine begrenzte Reichweite, die sich auf die Aktionen beschränkt, die der Benutzer durchführen kann, z. B. das Klicken auf einen bösartigen Link oder den Besuch der Website des Hackers. Im Gegensatz dazu bietet ein XSS-Angriff die Möglichkeit, bösartige Skripte auszuführen, um eine beliebige Aktivität nach Wahl des Angreifers auszuführen, was die Reichweite des Angriffs vergrößert. 
• Bei XSS-Angriffen wird der bösartige Code innerhalb der Website gespeichert, während bei CSRF-Angriffen der bösartige Code auf Websites von Drittanbietern gespeichert wird, auf die der Benutzer des Opfers zugreifen muss.

XSS-Beispiel

Das häufigste Beispiel für einen XSS-Angriff findet sich, wenn böswillige Benutzer die klassische 404-Fehlerseite angreifen und den bösartigen Code einspeisen. Lassen Sie uns dies anhand des folgenden Angriffsszenarios näher erläutern.

Angenommen, die 404-Fehlerseite, die den Benutzer über die fehlende/nicht vorhandene Seite informiert, läuft auf einem Code ähnlich wie:

<html>
<body>
<? php
print “Not found: ” . urldecode($_SERVER[“REQUEST_URI”]);
?>
</body>
</html>

Wenn der Benutzer auf eine nicht existierende Webseite klickt, die sich unter:

http://darwin.test/non_existent_file

Die folgende Antwort wird zurückgegeben:

Not found: /non_existent_file

Ein Angreifer kann diese Fehlerseite so manipulieren, dass sie bösartigen Code enthält, z. B:

http://darwin.test/<script>bad_payload_script</script>

Als Ergebnis wird als HTTP-Antwort nun genau die Fehlerseite mit dem bösartigen JavaScript-Code zurückgegeben.

Not found: /<script>bad_payload_script;</script>

Sobald der Angreifer erfolgreich bösartige Inhalte eingeschleust hat, führt der Browser des Benutzers das eingeschleuste Skript aus und gewährt dem Angreifer unbeabsichtigten Zugriff auf Sitzungsinformationen.

CSRF-Beispiel

Angreifer verwenden verschiedene anfällige HTTP-Methoden wie GET-, PUT-, DELETE- und POST-Anfragen, um CSRF-Angriffe durchzuführen. Ein Angreifer kann die Exploit-URL auch als gewöhnlichen Link inszenieren und diese HTTP-Methoden nutzen, um Parameterwerte zu übertragen und bösartige Aktionen auszuführen. Das folgende Beispiel zeigt einen typischen CSRF-Exploit, der mit der GET-HTTP-Methode durchgeführt wird.

Gehen wir von einem Szenario aus, in dem eine Bank-Webanwendung so konzipiert ist, dass sie Werte hauptsächlich über GET-Anfragen abruft. In einem solchen Fall würde eine Geldüberweisung einen ähnlichen Vorgang beinhalten, wie unten dargestellt:

GET http://darwin.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

Angenommen, die Angreifer wollen einen normalen Benutzer namens „Alice“ dazu bringen, 50.000 Dollar auf ein Konto für MARIA zu überweisen, können sie die Parameter für den Empfänger und den Betrag in der URL wie unten gezeigt ändern:   

http://darwin.com/transfer.do?acct=MARIA&amount=50000

Sie können dann Social-Engineering-Techniken einsetzen, um Alice dazu zu bringen, diese URL zu laden, wenn sie auf der Website ihrer Bank angemeldet ist. Der bösartige Link kann als unerwünschte E-Mail mit HTML-Inhalt oder als Skript-/Exploit-URL auf Seiten übermittelt werden, die Alice beim Online-Banking wahrscheinlich besuchen wird. Ein Beispiel für eine Exploit-URL, die als versteckter Iframe übermittelt wird, sieht etwa so aus:

<img src="http://darwin.com/transfer.do?acct=MARIA&amp;amount=50000" width="0" height="0" border="0">

Präventionsguide

Ultimativer Präventionsguide – Gängiste Cyber Threats

Dieses große, ständig wachsende E-Book zeigt Best Practices und Präventionstechniken, um Schwachstellen zu vermeiden und Ihre Webanwendungen zu sichern.

Download

XSS und CSRF – FAQs

Was ist der Unterschied zwischen Cross-Site-Scripting und Javascript-Injection?

XSS ist ein clientseitiger Angriff, bei dem der Hacker bösartige Skripte in einen Webserver einschleust, die vom Browser des ahnungslosen Benutzers ausgeführt werden.

Bei der Javascript-Injektion hingegen handelt es sich um einen serverseitigen Angriff, bei dem der Hacker bösartige Skripte an den Server sendet, die vom Interpreter ausgeführt werden, als ob sie Teil des Quellcodes wären.

Was sind einige wirksame CSRF-Präventionsmechanismen?

Einige Möglichkeiten zur Verhinderung von CSRF-Angriffen sind:

• Verwendung eines Synchronisierungs-Token-Musters
• Verwendung von Double-Submit-Cookies
• Verwendung von HTTP-Standard-Headern zur Überprüfung des Ursprungs von Anfragen
• UI-basierte Verifizierung wie CAPTCHA-basierte Autorisierung und MFA 
• Verwendung von SameSite Cookies für die Verwaltung der Herkunft von Anfragen
• Verwendung von CSRF-Tokens

Was sind einige wirksame XSS-Präventionsmechanismen?

Einige häufig eingesetzte wirksame XSS-Präventionstechniken sind:

• Durchsetzung von Sicherheitsrichtlinien für Inhalte
• Validierung und Filterung von Benutzereingaben
• Verschlüsselung von Ausgabedaten
• Verwendung benutzerdefinierter Antwort-Header (Content-Type & X-Content-Type-Options), um die Interpretation von Browser-Antworten zu steuern
• HTML-Eingaben säubern

Können CSRF-Tokens XSS verhindern?

Reflektierte XSS-Angriffe können meist durch die Verwendung eines praktischen CSRF-Tokens verhindert werden. Wenn ein Webserver eingereichte CSRF-Tokens angemessen validiert und Anfragen ohne gültiges Token zurückweist, verhindert diese Praxis, dass Angreifer Sicherheitslücken in reflektierten XSS-Anwendungen ausnutzen.

Bei anderen Formen von XSS-Angriffen sind CSRF-Tokens jedoch bekanntermaßen weniger hilfreich bei der Verhinderung eines solchen Angriffs. In Fällen, in denen eine gespeicherte XSS-Schwachstelle in der Anwendung vorhanden ist, können Angreifer Benutzer dazu verleiten, bösartige Aktionen auszuführen, selbst wenn diese Aktionen durch CSRF geschützt sind. 

Angreifer können auch ein Skript erstellen, das die geschützte Seite anfordert, um ein gültiges Authentifizierungs-Token offenzulegen, das ausgenutzt werden kann, um tiefer gehende Angriffe auf Systemebene und unerwünschte Aktionen zu orchestrieren.