A Cross-site request forgery (CSRF) is:
A common example is an <img> tag embedded in a malicious page with the src pointing to the attack’s target. For instance:
<!-- This is embedded in another domain's site -->
<img src="http://target.site.com/add-user?user=name&grant=admin">
The above <img> tag will send a http get request to target.site.com every time the page that contains it is loaded.
If the user had previously logged in to target.site.com and the site used a session cookie to keep the session active, this cookie will be sent as well.
If the target site does not implement any CSRF mitigation techniques, the request will be handled as a valid request on behalf of the user.
If the user was logged in and the cookie were storing session information, the request will also be authenticated and made in the name of the user.
This request can be used to:
This is then important to verify that the request was made:
This cross-origin http request is performed via:
and:
This problem exists because any HTTP requests can be sent from any other origins.
Any fetch HTML element (image, video, …) or a HTML form will create a HTTP request
Sites can prevent such attacks:
If session data are not stored as cookies, CSRF attacks are not possible.
A CSRF token is a random, hard-to-guess string aimed at protecting a form from a CSRF attack
Steps:
The CSRF token is sent generally as an header called X-CSRF
The token may be stored:
<meta name="csrf-param" content="authenticity_token">
<meta name="csrf-token" content="glRwabjUEr/jI4ms0oM1jdxb0iG/iS3R0BEMWHTQsZbzNToWyd4PKbJ40Oexn5tno0Yt6c5zEBlHWmMZ3GOzKw==">
The token should not be stored:
The origin is the cornerstone of the web security and you can:
The Origin HTTP headers can be checked against the value obtained when the session was created.
The Referer header may also be used.
The browser add it automatically but for server-side or native apps, the Origin header should be sent with an identifying URL as the value. Example:
curl -c cookie.txt \
-d [email protected] \
-d password=123 \
-H "Origin: https://mywebsite.com" \
https://api-host.com/api/create-session/
curl -b cookie.txt \
-d '{"posts": [{"title": "Hello World"}]}' \
-H "Content-Type: application/json" \
-H "Origin: https://mywebsite.com" \
https://api-host.com/api/posts
The cors setting can also prevent this kind of attack. It allows only request from some origin
Example with access-control-allow-origin
Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: http://example.com
On this site for instance, we allows that the fetching of resources from https://jsfiddle.net/ because it's where you can try our code live and this code sometimes fetch some resources such a json or csv file.
Access-Control-Allow-Origin: https://jsfiddle.net
Use same site cookie to prevent sending along the cookie.
This method mitigates CSRF exploit against the the Oauth redirection URI
The client send pass a nonce parameter (called state in oauth) and the client validate that the the value coming from the response matches the one it sent.
This is mostly used in the two way authentication code flow method where the client gets a code via a redirection url and needs to ask an authorization point to transform it as authentication token.