Cross-Site Request Forgery
Erklärung der Sicherheitslücke
Cross-Site Request Forgery oder CSRF (CWE-352) ist ein Angriff, der auftritt, wenn die Webanwendung nicht ausreichend überprüft oder nicht ausreichend überprüfen kann, ob eine wohlgeformte, gültige und konsistente HTTP-Anfrage absichtlich vom Benutzer bereitgestellt worden ist, als die Anfrage übermittelt wurde.
Ein CSRF-Angriff funktioniert, weil Browseranfragen automatisch alle Cookies, einschließlich Sitzungscookies, einbeziehen. Wenn der Benutzer gegenüber der Site authentifiziert ist, kann die Site daher nicht zwischen legitimen und gefälschten Anfragen unterscheiden.
Der Fehler tritt auf, wenn die Anwendung keinen Mechanismus zur Unterscheidung zwischen legitimen und gefälschten Anfragen hat.
Empfohlene Sicherheitskontrollen
Gemäß den Empfehlungen von OWASP und MITRE gibt es einige Ansätze zur Eindämmung von CSRF-Angriffen. Jeder dieser Ansätze eignet sich für bestimmte Arten von Webanwendungen.Die am häufigsten verwendete und empfohlene Lösung ist das Synchronizer Token Pattern. Mithilfe dieser Sicherheitskontrolle werden serverseitig CSRF-Tokens generiert.
Sie können einmal pro Benutzersitzung oder für jede Anfrage generiert werden. Per-Anfrage-Token sind sicherer als Pro-Sitzung-Token, da die Zeitspanne, in der ein Angreifer die gestohlenen Tokens benutzen kann begrenzt ist. Dies kann jedoch zu Bedenken hinsichtlich der Benutzerfreundlichkeit führen. Beispielsweise wird die Funktion des Browsers mit der Schaltfläche „Zurück“ häufig dadurch beeinträchtigt, dass die vorherige Seite möglicherweise ein Token enthält, der nicht mehr gültig ist. Die Interaktion mit dieser vorherigen Seite führt zu einem Fehlalarm CSRF-Sicherheitsereignis auf dem Server. Bei der sitzungsspezifischen Token-Implementierung wird der Wert nach der ersten Generierung eines Tokens in der Sitzung gespeichert und für jede nachfolgende Anfrage verwendet, bis die Sitzung abläuft.
Wenn vom Client eine HTTP-Anfrage ausgegeben wird, muss die serverseitige Komponente die Existenz und Gültigkeit des Tokens in der Anfrage im Vergleich zu dem in der Benutzersitzung gefundenen Token überprüfen. Wenn das Token in der Anfrage nicht gefunden wurde oder der angegebene Wert nicht mit dem Wert in der Benutzersitzung übereinstimmt, sollte die Anfrage abgebrochen, die Benutzersitzung beendet und das Ereignis als möglicher laufender CSRF-Angriff protokolliert werden.
CSRF-Token verhindern CSRF-Angriffe, da Angreifer ohne Kenntnis des richtigen CSRF-Tokens keine gültigen HTTP-Anfragen an das Backend im Server erstellen können.
Eine weitere Sicherheitskontrolle ist die Validierung des Ursprungs der HTTP-Anfrage über Standard-HTTP-Anfrageheader. Es gibt zwei Schritte zur Abhilfe, die beide auf der Untersuchung eines HTTP-Anforderungsheaderwerts basieren:
- Bestimmen des Ursprungs der Anfrage (Quellursprung), was über Origin- oder Referer-Header erreicht werden kann.
- Bestimmen des Ursprungs, an den die Anfrage geht (Zielursprung).
Wenn auf der Serverseite verifiziert ist , dass beide übereinstimmen, wird die Anfrage als legitim akzeptiert (d. h., es handelt sich um dieselbe Ursprungsanfrage). Ist dies nicht der Fall, wird die Anfrage verworfen (was bedeutet, dass die Anfrage domänenübergreifend erstellt worden ist). Solche Header gelten als zuverlässig und vertrauenswürdig, da sie nicht programmgesteuert geändert werden können (z.B unter Verwendung von JavaScript mit einer XSS-Schwachstelle)
So kann die Benutzung eines verbotenen Headers vermieden werden, und die Festlegung findet lediglich im Browser statt.
So funktioniert der Schutz von Waratek
Waratek bietet Schutz vor CSRF-Angriffen über zwei verschiedene Funktionen in der ARMR-HTTP-Regel:
-
csrf(synchronized-tokens)
-
csrf(same-origin)
Benutzer können eine dieser Funktionen oder beide aktivieren. OWASP empfiehlt die Verwendung beider Sicherheitskontrollen, jedoch sind nicht beide Arten von Sicherheitskontrollen in allen Anwendungsumgebungen verwendbar.
Die CSRF Synchronizer Token Pattern (STP)-Regel
Im Allgemeinen betrachted stoppt die CSRF-STP-Regel die Verarbeitung des JSP/Servlets, wenn die empfangene HTTP-Anfrage fehlt oder ein falsches CSRF-Token enthält.
Die CSRF-STP-Regel aktiviert den Synchronizer-Token-Pattern-Schutz, der Waratek anweist, CSRF-Tokens in bestimmte HTML-Elemente einzufügen.
Die zu verwendbaren HTML-Elemente sind:
<form> Elemente, in denen das Token als verstecktes Eingabefeld eingefügt wird.
<a> Elemente, in denen das Token in die durch sein href-Attribut angegebene URL eingefügt wird.
<frame>- und <iframe>-Elemente, in die das Token in die durch ihre src-Attribute angegebene URL eingefügt wird.
Durch die Aktivierung der Standard-CSRF-STP-Regel wird sichergestellt, dass alle HTTP-POST-Anfragen geschützt werden, indem das in den Anfragen vorhandene CSRF-Token validiert wird. HTTP-POST-Anfragen sind die wichtigsten zu schützenden Anfragetypen, da sie in der Regel den Status ändern, HTTP-GET-Anfragen hingegen normalerweise nicht.
- Aktivieren Sie den Schutz für HTTP-GET-Anfragen
Standardmäßig sind nur HTTP-POST-Anfragen geschützt. Wenn auch Schutz für HTTP-GET-Anfragen erforderlich ist, verwenden Sie die Methodenoption:
csrf(synchronized-tokens, options: {method: [GET, POST]}). - Bestimmte HTTP-Endpunkte vom Schutz ausschließen bzw. auf die Whitelist setzen
Standardmäßig sind alle HTTP-Endpunkte geschützt. Wenn der Schutz für bestimmte HTTP-Endpunkte deaktiviert werden muss, verwenden Sie die Ausschlussoption: csrf(synchronized-tokens, options: {exclude: ["/myApplication/safe.jsp"]}). - AJAX-Anfragen vom Schutz ausschließen
AJAX-Anfragen werden von der CSRF-STP-Regel nicht unterstützt, da das CSRF-Token nicht in clientseitigen Javascript-Code eingefügt werden kann, da die Ajax Anfragen dynamisch generiert werden. AJAX-Anfragen tragen normalerweise den X-Requested-With-Header. Wenn die Anwendung AJAX-Anfragen verwendet, kann die Ajax-Option verwendet werden, um die Validierung für diese Anfragen zu deaktivieren:
csrf(synchronized-tokens, options: {ajax: no-validate}). - Verwenden Sie für jede HTTP-Methode (POST / GET) ein anderes CSRF-Token.
Standardmäßig wird ein CSRF-Token für POST-Anfragen und ein anderes CSRF-Token für GET-Anfragen verwendet. Dies hat den Vorteil, dass das CSRF-Token für POST-Anfragen geschützt wird, falls das CSRF-Token für GET-Anfragen verloren geht. Die token-type-Option kann verwendet werden, um dies zu deaktivieren und stattdessen ein einzelnes Token sowohl für POST- als auch für GET-Anfragen zu verwenden:
csrf(synchronized-tokens, options: {method: [GET, POST], token-type: shared}). - Umbenennung des in den HTTP-Anfragen verwendeten CSRF-Token
Standardmäßig lautet der Name des von Waratek verwendeten CSRF-Tokens „_X-CSRF-TOKEN“. In dem seltenen Fall, dass dieser Name von einem anderen HTTP-Parameter verwendet wird, verwenden Sie die Option token-name, um den HTTP-Parameter umzubenennen, den Waratek für das CSRF-Tokens verwendet:
csrf(synchronized-tokens, options: {token-name: "custom-name"}).
Die CSRF Same-Origins-ARMR-Regel
Im Allgemeinen betrachtet prüft die CSRF-Same-Origins-Regel, ob die empfangene HTTP-Anfrage von einem anderen Quellursprung als dem Zielursprung stammt. Der Quellursprung wird durch die Header „Origin“, „Referer“ oder „X-Forwarded-For“ bestimmt. Der Zielursprung wird durch die Host- oder X-Forwarded-Host-Header oder durch die in der ARMR-Regel konfigurierten Hosts bestimmt.
Wenn die Ursprungsvalidierung fehlschlägt, entfernt die Regel alle HTTP-Parameter, Cookies und Payloads aus der HTTP-Anfrage und macht sie unschädlich. Wenn keiner der Origin-Header vorhanden ist, kann die Origin-Validierung nicht durchgeführt werden und die Regel blockiert die HTTP-Anfrage gemäß den OWASP-Empfehlungen. Wenn Sie die Standard-CSRF-Same-Origins-Regel aktivieren, werden alle HTTP-POST-Anfragen durch die Validierung der standardmäßigen Origin-HTTP-Antwortheader geschützt, die in den Anfragen vorhanden sein sollten. Im Folgenden finden Sie ein Beispiel für die standardmäßige CSRF-Same-Origins-Regel:
app("CSRF Same-Origins"):
requires(version: ARMR/2.8)
http("Deny HTTP requests with invalid origin header (for all HTTP endpoints)"):
csrf(same-origin)
request()
protect(message: "HTTP origin validation failed", severity: 7)
endhttp
endapp
Wenn Schutz für bestimmte HTTP-Endpunkte erforderlich ist, müssen die spezifischen relativen URIs der HTTP-Endpunkte in der Anforderungsdeklaration der CSRF-ARMR-Regel angegeben werden.
Zum Beispiel:
app("CSRF Same-Origins"):
requires(version: ARMR/2.8)
http("Deny HTTP requests with invalid origin header (for specific HTTP endpoints)"):
csrf(same-origin)
request(paths: ["/path/to/vulnerablePage.jsp", "/path/to/vulnerableServlet"])
protect(message: "HTTP origin validation failed", severity: 7)
endhttp
endapp
Beschreibung des Schutzes
Wenn die CSRF-STP-Regel im Schutzmodus aktiviert ist und ein CSRF-Angriff identifiziert wird, wird die böswillige HTTP-Anfrage beendet und eine HTTP 403-Antwort an den Client zurückgegeben.
Wenn die CSRF-Same-Origins-Regel im Schutzmodus aktiviert ist und ein CSRF-Angriff identifiziert wird, wird die bösartige HTTP-Anfrage nicht beendet, sondern alle ihre HTTP-Parameter und Cookies gelten als bösartig und werden daher aus der Anfrage entfernt, wodurch sie sicher wird.
Anwendbarkeit der Regel
Die CSRF Synchronizer Token Pattern (STP)-Regel
Die CSRF-STP-Regel ist anwendbar und kann in den folgenden Fällen sicher aktiviert werden:
- In herkömmlichen Webanwendungen, bei denen die HTTP-Antwort der Anwendung eine HTML-Seite ist.
- In Webanwendungen, die die Servlet-API zur Verarbeitung von HTTP-Anfragen, -Antworten und zur Sitzungsverwaltung verwenden.
- In Webanwendungen, die CSRF-Schutz für Seiten und Ressourcen erfordern, auf die nur über die HTTP-Methoden GET und POST zugegriffen werden kann. Beispielsweise werden <form>-Tags, die PUT-Anfragen auslösen, nicht unterstützt.
- Wobei das in <iframe>-HTML-Elementen vorhandene srcdoc-Attribut nicht vor CSRF-Angriffen geschützt ist.
Beachten Sie, dass CSRF-Angriffe nur dann sinnvoll sind, wenn den HTTP-Anfragen eine HTTP-Sitzung zugeordnet worden sind. Daher werden zustandslose Anwendungen, wie etwa einige RESTful-APIs und nicht authentifizierte HTTP-Anfragen, die keine gültige HTTP-Sitzungs-ID enthalten, nicht durch die CSRF-STP-Regel geschützt.
Standardmäßig werden nur POST-HTTP-Anfragen von der CSRF-STP-Regel validiert, wenn in der Regel keine Methode konfiguriert ist. Benutzer haben die Möglichkeit, die CSRF-STP-Regel zu konfigurieren, um auch den Schutz für GET-HTTP-Anfragen zu aktivieren.
Benutzer sollten die CSRF-STP-Regel nicht aktivieren, wenn die Webanwendung:
keine HTML-Antworten über die Servlet-API bereitstellt.
- Verwendet nicht die Standard-J2EE-Servlet-APIs:
- javax.servlet.http.HttpServletRequest
- javax.servlet.http.HttpServletResponse
- javax.servlet.http.HttpSession
Die Aktivierung der CSRF-STP-Regel könnte in diesen Fällen dazu führen, dass Waratek entweder keinen Schutz bietet oder die normale Anwendungsfunktionalität beeinträchtigt.
Die CSRF-Same-Origins-Regel
Die CSRF-Same-Origins-Regel hängt vom Vorhandensein der Origin- oder Referer-Header in den HTTP-Anfragen ab. Obwohl diese Header in den meisten Fällen in den HTTP-Anfragen enthalten sind, gibt es nur wenige Anwendungsfälle, in denen sie nicht enthalten sind. Im Folgenden sind die wichtigsten Anwendungsfälle aufgeführt:
- Ältere Browser unterstützen den Origin-Header nicht.
- Internet Explorer 11 fügt den Origin-Header nicht zu einer CORS-Anfrage über Websites einer vertrauenswürdigen Zone hinweg hinzu.
- HTTP-Anfragen, die nach 302-Redirect-Cross-Origin-Anfragen auftreten, enthalten nicht den Origin-Header.
- Es ist bekannt, dass Load Balancer, Proxys und eingebettete Netzwerkgeräte die Referrer- oder Origin-Header entfernen oder ändern.
- Browser enthalten den Origin-Header normalerweise nicht in mit Lesezeichen versehenen Links.
Bei Anwendungen, bei denen der Quellursprung auch bei nicht böswilligen Anfragen nicht mit dem Zielursprung übereinstimmt, kann der Regelparameter „hosts“ verwendet werden, um bekannte sichere Ursprünge auf die Whitelist zu setzen.
Zum Beispiel:
app("CSRF Same-Origins"):
requires(version: ARMR/2.8)
http("Deny HTTP requests with invalid origin header (with whitelisted hosts)"):
csrf(same-origin, options: {hosts: ["account.example.org", "login.example.com"]})
request()
protect(message: "HTTP origin validation failed", severity: 7)
endhttp
endapp
Nur POST-HTTP-Anfragen werden durch die CSRF Same-Origins-ARMR-Regel validiert.
Empfohlene Vorgehensweise
Waratek empfiehlt, die XSS-Sicherheitsregel auch im Blockierungsmodus zu aktivieren, um vor XSS-Angriffen geschützt zu sein. Wenn die Anwendung anfällig für XSS-Angriffe ist, wäre es möglich, die CSRF-Tokens über XSS-Angriffe zu stehlen. Dies würde es Angreifern ermöglichen, den CSRF-Schutz zu umgehen.
Da die CSRF-STP-Regel möglicherweise einige Konfigurationen erfordert, wird Benutzern empfohlen, zunächst die CSRF-Same-Origins-Regel als erste Verteidigungsebene gegen CSRF zu aktivieren. Erwägen Sie dann, die CSRF-STP-Regel nur in relevanten Anwendungen zu aktivieren, zunächst im Überwachungs-/Erkennungsmodus und später im Blockierungsmodus, nachdem die Regel ordnungsgemäß konfiguriert wurde.
Da die CSRF-Same-Origins-Regel vom Vorhandensein des Origin-HTTP-Headers abhängt, wird empfohlen, die CSRF-Same-Origins-Regel erst zu aktivieren, nachdem sichergestellt wurde, dass alle Benutzer eine aktuelle Browserversion verwenden.
Es wird außerdem empfohlen, dass Benutzer die CSRF-Same-Origins-Regel nur für die anfälligen HTTP-Endpunkte aktivieren, die von ihren Schwachstellenscannern gemeldet werden.