Cross Site Request Forgery

24th January 2019

I was recently asked to explain what a CSRF attack is, and how one would take place. This is what I understand a CSRF attack to be, and how one would take place in plain english.

The typical explanation of a cross-site request forgery is to imagine that an attacker controls a website. You have a tab in your browser, which has your bank open, and open a new tab to visit the attacker-controlled website. The attacker's website contains links which point to the bank, for example "/money/transfer?to=attacker". As your browser assumes that it is you making the selection, clicking on the attacker site (so cross-site) makes your browser respond using your credentials (request forgery!)

The main buzz-word of cross-site request forgery is that it negates the Same Origin Policy. As cross-site request forgery uses a request which triggers the action using the users context, the containment of same origin policy is completely ignored.

It is therefore important to ensure that user input is verifiably from the user activating a form submission. Meaning that an automated trigger must rely on some unique information within the page, which will be covered by the same origin policy.

There are a number of ways to protect against CSRF, listed on OWASP. The most common solution I have seen is to include a "number-once" as a hidden field in each and every field. This is a one-time randomly generated number which ensures that form submission is done by an entity able to view the page (often see as csrf-token, token, nonce, weirdly named after the issue). The only bad part of this implemention is that no-one checked whether a number once, or "nonce" had any other meanings before they implemented it.