Trotz der Tatsache, dass in der zuletzt veröffentlichten Liste der Schwachstellen von OWASP Top 10 2017 CSRF-Angriffen die Einstufung „Gelöscht, aber nicht vergessen“ vorgenommen wurde, haben wir entschieden, dass es nicht überflüssig ist, erneut daran zu denken, wie man sich gegen CSRF-Angriffe verteidigt, wenn man sich auf diese stützt die gleichen Regeln von OWASP zur Verfügung gestellt.
CSRF-Token verwendenDie Verwendung eines Tokens (sowohl zustandslose als auch statusbezogene Methoden) ist die primäre und beliebteste Schutzmethode. Das Token muss für jede Benutzersitzung eindeutig sein und von einem kryptografisch robusten Pseudozufallszahlengenerator generiert werden. OWASP empfiehlt außerdem die Verwendung der Algorithmen AES256-GCM und SHA256 / 512 zur Verschlüsselung bei Verwendung von HMAC.
Es gibt verschiedene Möglichkeiten, mit Token zu arbeiten: Synchronizer-Token, verschlüsselungsbasiertes Token-Muster, HMAC-basiertes Token
Synchronizer-TokenBei Verwendung des Synchronizer-Token-Ansatzes (Statefull-Methode) bedeutet dies, dass bei jeder Anforderung ein Token gesendet wird, was einige Änderungen auf der Serverseite mit sich bringt. Wenn das Token nicht gültig ist, lehnt der Server die Anforderung ab.
Wenn Sie eine Anforderung an den Server senden, wird empfohlen, den Anforderungsparametern anstelle des Headers ein Token hinzuzufügen. Wenn Sie dennoch ein Token in den Anforderungsheader einfügen, stellen Sie sicher, dass es nicht auf dem Server angemeldet ist. Das empfangene Token kann
clientseitig in einem versteckten Feld gespeichert werden
:<form action="/post.php" method="post"> <input type="hidden" name="CSRFToken" value="l5824xNMAYFesBxing975yR8HPJlHZ"> ... </form>
in den Überschriften: POST /page HTTP/1.1 Accept: application/json, application/xml, text/json, text/x-json, text/javascript, text/xml User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36 Content-Type: application/json Host: example.com X-CSRF-TOKEN: l5824xNMAYFesBxing975yR8HPJlHZ
oder in Keksen POST /page HTTP/1.1 Host: example.com Set-Cookie: CSRFToken=l5824xNMAYFesBxing975yR8HPJlHZ; Content-Type: application/x-www-form-urlencoded
OWASP empfiehlt, das Token in den Headern zu speichern. Dies erklärt, dass der Angreifer die Anforderung aufgrund der Browser auch dann nicht fälschen kann, wenn das Token geöffnet oder abgelaufen ist.
Um die Sicherheitsstufe des vorgeschlagenen Verfahrens zu erhöhen, wird außerdem vorgeschlagen, für jede Anforderung einen zufälligen Token-Parameternamen und / oder das Token selbst zu generieren. Bei diesem Ansatz ist die Zeit, in der der Angreifer das gestohlene Token verwenden kann, minimal. Dies kann jedoch zu Usability-Problemen führen. Wenn Sie beispielsweise auf die Schaltfläche "Zurück" klicken, wird möglicherweise ein ungültiges Token an den Server gesendet, das auf der vorherigen Seite enthalten war.
Das Senden eines Tokens mithilfe einer GET-Anforderung wird nicht empfohlen, da mit dieser Methode das Token angezeigt werden kann: Im Browserverlauf werden Protokolldateien und Referrer-Header angezeigt.
Verschlüsselungsbasiertes TokenDieser Ansatz ist zustandslos, da er die Verschlüsselung / Entschlüsselung zur Validierung des Tokens verwendet und daher keine Speicherung des Tokens auf der Serverseite erfordert.
Der Server generiert ein Token, das aus einer Sitzungskennung und einem Zeitstempel besteht (um einen Wiederholungsangriff zu verhindern). Für die Verschlüsselung wird empfohlen, den Verschlüsselungsalgorithmus AES256 im Blockverschlüsselungsmodus GSM / GSM-SIV zu verwenden. Von der Verwendung des EZB-Modus wird dringend abgeraten. Das vom Server verschlüsselte Token wird auf dieselbe Weise an den Client zurückgesendet wie im Fall von "Synchronizer Token" im ausgeblendeten Formularfeld oder im Antwortheader / -parameter. Nach Erhalt des Tokens muss der Server es entschlüsseln, anschließend die Sitzungskennung und den Zeitstempel mit der aktuellen Uhrzeit überprüfen und sicherstellen, dass die festgelegte Lebensdauer des Tokens nicht überschritten wird.
Wenn die Überprüfung der Sitzungskennung erfolgreich ist, die Zeitübersicht jedoch nicht, kann die Anforderung als gültig betrachtet werden. In allen anderen Fällen wird empfohlen, die Anfrage abzulehnen und zu registrieren, um besser zu verstehen, wie auf solche Anfragen reagiert werden soll.
HMAC-basiertes Token
Es ist auch keine Tokenspeicherung erforderlich. Das Funktionsprinzip ähnelt dem verschlüsselungsbasierten Token, außer dass anstelle der Verschlüsselung des Tokens die HMAC-Funktion (Hash-basierter Nachrichtenauthentifizierungscode) zum Generieren des Tokens verwendet wird (es wird empfohlen, SHA256 oder einen stärkeren Algorithmus zu verwenden). In diesem Fall ist das Token das Ergebnis der HMAC-Funktion der Benutzersitzungs-ID + Zeitstempel.
Token-AutomatisierungDas Hauptproblem bei der Abwehr von CSRF-Angriffen besteht darin, dass Entwickler häufig einfach vergessen, Funktionen für die Arbeit mit Token hinzuzufügen. Um solche Probleme zu vermeiden, lohnt es sich, diesen Prozess zu automatisieren:
• Schreiben Sie einen Wrapper, der Anfragen über das Formular-Tag oder bei Verwendung von Ajax automatisch ein Token hinzufügt. Beispielsweise geht Spring Security bei jeder Verwendung des <form: form> -Tags ähnlich vor.
• Schreiben Sie einen Hook, der den Datenverkehr abfängt und allen anfälligen Ressourcen Token hinzufügt. Da es ziemlich schwierig ist zu analysieren, welche Anforderung die Statusänderung ausführt, und ein Token erforderlich ist, wird empfohlen, Token in alle POST-Antworten aufzunehmen, es lohnt sich jedoch, die Leistungskosten zu berücksichtigen
• Beim Rendern einer Seite wird automatisch ein Token hinzugefügt. Dieser Ansatz wird von CSRF Guard verwendet: Token werden zu allen href- und src-Attributen, ausgeblendeten Feldern und in allen Formen hinzugefügt
Bevor Sie versuchen, ein eigenes System zur automatischen Token-Generierung zu erstellen, sollten Sie klären, ob das von Ihnen verwendete Framework standardmäßig Schutz vor CSRF-Angriffen bietet. Das gleiche Django-Framework implementiert beispielsweise den Schutz vor CSRF.
Login CSRFMit CSRF im Anmeldeformular kann sich ein Angreifer anmelden,
als Opfer verkleidet. Solche Schwachstellen waren Giganten wie PayPal und Google ausgesetzt.
Sie können sich mit CSRF im Anmeldeformular befassen, indem Sie Vorbereitungen erstellen, die vor der Authentifizierung des Benutzers erstellt werden, und indem Sie Token in das Anmeldeformular aufnehmen.
Samesite-CookieSameSite Cookie ist ein in RFC6265bis beschriebenes Attribut, mit dem CSRF-Angriffen entgegengewirkt werden soll. Es funktioniert wie folgt. Eine der Schutzmethoden besteht darin, die Herkunfts- und Referenzkopfzeilen zu überprüfen, anhand derer Sie nachvollziehen können, woher die Anforderung stammt. Für diesen Ansatz ist jedoch die Implementierung eines Überprüfungsmechanismus erforderlich. Mit dem SameSite-Attribut schränken wir das Senden von Cookies bei einer Anfrage von externen Ressourcen ein. Dieses Attribut hat mehrere mögliche Werte: Strict, Lax und None.
Die Verwendung des strengen Werts bedeutet, dass der Browser keine Cookies von Quellen sendet, die nicht mit dem Domainnamen der aktuellen Ressource übereinstimmen.
Der Wert lax ermöglicht es, keine Cookies von externen Ressourcen zu blockieren, deren Übergang auf sichere Weise - unter Verwendung des HTTPS-Protokolls - durchgeführt wurde. Lax schafft ein Gleichgewicht zwischen Benutzerfreundlichkeit und Sicherheit.
Das Setzen eines Attributs ist ziemlich einfach:
Set-Cookie: JSESSIONID=xxxxx; SameSite=Strict Set-Cookie: JSESSIONID=xxxxx; SameSite=Lax
Zum Zeitpunkt des Schreibens sieht die Unterstützung des Attributs durch Browser folgendermaßen aus:
Es ist wichtig, sich daran zu erinnern, dass dieses Attribut als zusätzliche Schutzmaßnahme und nicht als Möglichkeit verwendet werden sollte, auf die Verwendung des CSRF-Tokens zu verzichten.
Header überprüfenWie oben erwähnt, überprüft eine der Schutzmethoden den Verweiser- und den Ursprungswert des Anforderungsheaders.
Das Wesentliche dieser Überprüfung ist die Überprüfung der Header-Werte auf der Serverseite. Wenn sie mit der Ressource übereinstimmen, wird die Anforderung als korrekt betrachtet, andernfalls wird sie abgelehnt. Wenn der Origin-Header fehlt, müssen Sie sicherstellen, dass der Referrer-Wert mit der aktuellen Ressource übereinstimmt. OWASP empfiehlt, Anfragen abzulehnen, die keine Origin- oder Referrer-Header enthalten. Sie können auch alle derartigen Anforderungen protokollieren, um sie später zu analysieren und zu entscheiden, wie Sie mit ihnen umgehen möchten.
Es wird jedoch kompliziert, wenn sich Ihre Anwendung hinter einem Proxyserver befindet, da die URL im Header unterschiedlich sein wird. In diesem Fall gibt es mehrere Möglichkeiten:
• Konfigurieren Sie Ihre Anwendung so, dass Sie immer den Ursprung der Anforderung kennen. Das Problem bei diesem Ansatz besteht darin, den richtigen Wert festzulegen, wenn Ihre Anwendung in mehreren Umgebungen bereitgestellt wird (z. B. dev, QA, Production), was zu einem Supportproblem führt
• Verwenden Sie den Host-Header. Mit diesem Header können Sie die Quelle der Anforderung unabhängig von der Umgebung ermitteln.
• Verwenden Sie den X-Forwarded-Host-Header, in dem die vom Proxy-Server empfangenen ursprünglichen Header gespeichert werden
Alle beschriebenen Methoden funktionieren nur, wenn die Header origin und referer vorhanden sind. Es gibt jedoch Fälle, in denen diese Header fehlen. In einigen Fällen sind diese Header nicht in der Anforderung enthalten:
• IE 11 enthält nicht den Origin-Header für vertrauenswürdige Sites. Es bleibt nur der Referer-Header übrig.
• Im Falle einer Weiterleitung ist Origin nicht in der Anforderung enthalten, da davon ausgegangen wird, dass es vertrauliche Informationen enthält, die nicht an eine andere Quelle gesendet werden sollten
• Origin-Header ist für alle standortübergreifenden Anforderungen aktiviert, die meisten Browser fügen ihn jedoch nur für POST / DELETE / PUT-Anforderungen hinzu
In der Regel fällt eine geringe Menge an Datenverkehr in die beschriebenen Kategorien, aber häufig möchten Sie nicht einmal diesen kleinen Teil der Benutzer verlieren. Daher wird es als gültig angesehen, eine Anfrage mit einem Nullwert für Herkunft / Verweis oder mit einem Wert zu stellen, der der Liste der vertrauenswürdigen Domänen entspricht.
Double Submit Cookie
Dieser Ansatz ist recht einfach zu implementieren und erfordert keine Speicherung des Tokens auf der Serverseite (zustandslos). Das Wesentliche der Methode ist das Senden des Tokens im Anforderungsparameter und in Cookies durch den Benutzer. Bei jeder Anforderung, die eine Statusänderung erfordert, überprüfen wir den Wert des Tokens in Cookies und in der Anforderung. Wenn die Überprüfung der Sitzungskennung erfolgreich ist, die Zeitübersicht jedoch nicht, wird die Anforderung möglicherweise als gültig angesehen