Testen der Anfälligkeit des Typs "CSRF"

Bei einem Cross-Site-Request-Forgery -Angriff (CSRF) wird die allgemein anerkannte Funktionslogik von Internetbrowsern für die Verwaltung der Benutzersitzung auf geöffneten Seiten verwendet. Der Standard ist, dass der Benutzer nur eine aktive Sitzung in der Web-App haben kann, die er derzeit verwendet. Jede neu geöffnete Registerkarte im Browser verwendet automatisch Cookies eines bereits angemeldeten Benutzers. Der Angreifer nutzt diese Tatsache am häufigsten, indem er seinem Opfer einen speziell vorbereiteten Link zusendert, wenn er auf der Seite, auf der das Opfer eine aktive Sitzung abhält, auf die Aktion (z. B. Passwortänderungen) klickt.

Der Schutz vor diesem Angriffstyp besteht in der Regel darin, einen speziellen eindeutigen und unvorhersehbaren Parameter pro Sitzung hinzuzufügen, der als Variable zu sensiblen Anforderungen eingefügt wird (z. B. Kennwort ändern, einen neuen Benutzer hinzufügen) und dessen Richtigkeit vom Server überprüft wird. Ein Angreifer, der den Wert dieses Tokens nicht kannte, kann keine Anforderung generieren, die der Server nicht ablehnt, weil das AntiCSRF-Token nicht kompatibil ist.

In einer der von mir untersuchten Anwendungen entdeckte ich die Möglichkeit, mehrere CSRF-Angriffedurchzuführen. Ein Beispiel ist die Vorbereitung einer entsprechenden erstellten Seite, sobald ein angemeldeter Benutzer eine Passwort-Änderungsanforderung in seinem Namen stellt. Im Folgenden wird der Code dieser Seite zusammen mit den ausgewählten Parametern für die Zuordnung des neuen Kennworts angezeigt. Beachten Sie, dass in der ausgewählten Zeile im folgenden Ausdruck der Code angegeben ist, der das Feld des Formulartyps inputdefiniert, in dem das neue Kennwort definiert wurde.

Eine automatisch gesendete Anforderung, die Sitzungen eines Benutzers verwendet, der die ersetzte Seite eingeben hat, sieht wie folgt aus:

Als Antwort bestätigt die App, dass das Kennwort geändert wurde, was im folgenden Screenshot zu sehen ist: