Was ist CSRF?
„Eine Cross-Site-Request-Forgery (meist CSRF oder XSRF abgekürzt ist eine Website-übergreifende Anfragenfälschung) ist ein Angriff auf ein Computersystem, bei dem der Angreifer eine Transaktion in einer Webanwendung durchführt. Dies geschieht nicht direkt, der Angreifer bedient sich dazu eines Opfers, das bei einer Webanwendung bereits angemeldet sein muss.
Dem Webbrowser des Opfers wird ohne sein Wissen eine arglistige HTTP-Anfrage untergeschoben. Der Angreifer wählt die Anfrage so, dass bei Aufruf die Webanwendung die vom Angreifer gewünschte Aktion ausführt.“
Quelle: Wikipedia
Zur Abwehr eines Cross-Site-Request-Forgery (CSRF)-Angriffs ist das Synchronizer Token Pattern die empfohlene Abwehrmaßnahme.
Hierbei wird zusätzlich zur Session-basierten Authentifikation per Cookie (der auch von anderen Browser-Fenstern genutzt werden kann) eine Authentifikation über einen jeweils neu generierten zufälligen CSRF-Token realisiert. Dieser Token darf nicht als GET-Parameter über die URL einsehbar sein, da ein Angreifer ihn sonst leicht mitlesen und verwenden könnte.
Zum Beispiel könnten CSRF-Tokens durch Links in E-Mails, in Log-Dateien oder der Browser-History auftauchen. Statt dessen sollte er als verstecktes Eingabefeld eines Formulars über die HTTP-POST-Methode übertragen werden.
GET-Requests sollten also grundsätzlich nicht für Status-verändernde Aktionen, wie Löschvorgänge, verwendet werden. Dies entspricht auch den Bestimmungen des HTTP-Standards.
Statusändernde Anfragen
Brandbox unterscheidet zwei Anfrage-Arten. Executes und Requests. Executes sind typischerweise Statusändernde Requests. Beispiel:
delete
save
move
upload
CORS (Cross Origin Ressource Sharing) und SOP (Same-Origin-Policy)
Im Falle von Anwendungen (wie brandbox), die zum Beispiel als Single Page Javascript Application viele Ajax-Aufrufe verwenden, kann nicht für jeden Aufruf ein neuer Token generiert werden, da die Webseite nach dem erstmaligen Aufruf nicht mehr neu generiert wird.
In diesem Fall kann als Alternative zum Verhindern von CSRF der CSRF-Token auch
pro Session generiert werden,
als Cookie im Client gespeichert werden und
als Header-Eintrag bei jedem XMLHTTP-Aufruf mitgesendet werden. In diesem Fall ist aber auf eine strikte Einhaltung der Same-Origin-Policy (SOP) des Browsers zu achten. Wenn diese mit dem HTTP-Header-Eintrag
AccessControl-Allow-0rigin: *außer Kraft gesetzt wird, um das Cross Origin Resource Sharing (CORS) zu ermöglichen, kann der Token von einem Angreifer, beispielsweise bei Vorliegen einer Cross Site Scripting Schwachstelle, ausgelesen werden.
CSRF-Token generieren
<body ... data-csrf-token="{{csrfToken}}">
...
</body>
Auf diese Weise wird bei jedem Aufruf einer Seite ein neuer CSRF-Token generiert.
Erzwungene POST-Anfragen
Statusändernde Requests müssen gemäß den Bestimmungen des HTTP-Standards als POST-Request verarbeitet werden. Das macht brandbox automatisch, wenn eine Execute-Anfrage gestartet wird.
Serverseitig wird zusätzlich geprüft, ob eine POST-Anfrage statusändernd ist. Sie ist es nicht, sobald ein View für die Anfrage existiert.
Beispiel für eine Anfrage die validiert werden muss
public function login(...) {}
/views/login.hbs