...
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)
...
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
| Codeblock | ||||
|---|---|---|---|---|
| ||||
<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
| Codeblock | ||
|---|---|---|
| ||
public function login(...) {}
/views/login.hbs |
...