Cross-site request forgery: Difference between revisions
| Line 13: | Line 13: | ||
==Defense== | ==Defense== | ||
To protect against CSRF, the website <code>shopping.com</code> should do the following: | To protect against CSRF, the website <code>shopping.com</code> should do the following: | ||
# While the user is browsing <code>shopping.com</code>, | # While the user is browsing <code>shopping.com</code>, the backend sets a CORS cookie using an HTTP header in a response. | ||
#: <code>XSRF-TOKEN:UKL7smHAK4xENQj5pYbi</code> | #: <code>XSRF-TOKEN:UKL7smHAK4xENQj5pYbi</code> | ||
#* This cookie will be different for each session. | #* This cookie will be different for each session. | ||
| Line 20: | Line 20: | ||
# Before processing the order, the backend will check the XSRF header to make sure that it matches what was sent originally. | # Before processing the order, the backend will check the XSRF header to make sure that it matches what was sent originally. | ||
#* I.e. it checks that the (XSRF header or hidden field) matches the (sent cookie or save session token). | #* I.e. it checks that the (XSRF header or hidden field) matches the (sent cookie or save session token). | ||
;Notes | |||
* Typically, the server will update the CSRF cookie every request. | |||
* If using a header, the defense is call ''cookie-to-header''. | |||
* Using a hidden form field is called ''double submit cookie'' and does not require JavaScript. | |||
===Defense Explanation=== | ===Defense Explanation=== | ||