17acef57b4
chore: add pre-commit hooks chore: add pre-commit hooks chore: add pre-commit hooks chore: add pre-commit hooks
23 lines
1.5 KiB
Plaintext
23 lines
1.5 KiB
Plaintext
=== Automatic support from frameworks
|
|
|
|
Most frameworks now have default support for preventing CSRF. For example with Angular an interceptor reads a token
|
|
from a cookie by default XSRF-TOKEN and sets it as an HTTP header, X-XSRF-TOKEN. Since only code that runs on your domain
|
|
could read the cookie, the backend can be certain that the HTTP request came from your client application and not an attacker.
|
|
|
|
In order for this to work the backend server sets the token in a cookie. As the value of the cookie should be read
|
|
by Angular (JavaScript) this cookie should not be marked with the http-only flag. On every request towards the server
|
|
Angular will put the token in the X-XSRF-TOKEN as a HTTP header. The server can validate whether those two tokens
|
|
match and this will ensure the server the request is running on the same domain.
|
|
|
|
*Important: DEFINE A SEPARATE COOKIE, DO NOT REUSE THE SESSION COOKIE*
|
|
|
|
Remember the session cookie should always be defined with http-only flag.
|
|
|
|
== Custom headers not safe
|
|
|
|
Another defense can be to add a custom request header to each call. This will work if all the interactions
|
|
with the server are performed with JavaScript. On the server side you only need to check the presence of this header
|
|
if this header is not present deny the request.
|
|
Some frameworks offer this implementation by default however researcher Alex Infuhr found out that this can be bypassed
|
|
as well. You can read about: https://insert-script.blogspot.com/2018/05/adobe-reader-pdf-client-side-request.html[Adobe Reader PDF - Client Side Request Injection]
|