The typical method used by most developers to correctly fix this vulnerability is by generating and adding a secret token or nonce, called an anti CSRF token, to every sensitive request, which is then verified by the server for authenticity.
Let’s assume that we have a banking web application and see how it can be fixed by adding a secret token alongside other request parameters.
Assuming the user is logged into the banking web application, the server assigns his session with a unique anti-CSRF token, say ABC1234, to all sensitive forms and URLs.
Now to transfer 100 dollars to John the URL would become the following:
“https://bank.example.com/transfer/money?username=John&amount=100&toke n=ABC1234”
This token parameter’s value will be checked and validated by the server with respect to the session of the logged-in user, and if they mismatch then the transfer will be rejected. This idea makes use of the fact that a fairly long alphanumeric token will get very difficult for an attacker to either guess or to use brute force. For example, Facebook’s form and pages contain an anti-CSRF token with the name “fb_dtsg”.
To add anti-CSRF protection tokens automatically, there are many popular libraries that developers can use such as OWASP CSRFGuard to prevent CSRF attacks. Other techniques include inserting the token in request headers, checking the origin header, and so on.
