CSRF or Cross-Site Request Forgery is a website vulnerability where an attacker can cause an action to happen in a victim’s session on another website. One of the things that makes CSRF so much of a risk is that it doesn’t even require user interaction, all that’s needed is for the victim to view a webpage with the exploit in it.
Tip: CSRF is generally pronounced either letter by letter or as “sea surf”.
How does a CSRF attack work?
The attack involves the attacker creating a website that has a method of making a request on another website. This could require user interaction, such as getting them to press a button, but it could also be interactionless. In JavaScript there are ways to cause an action to happen automatically. For example, a zero by zero pixel image won’t be visible to the user but can be configured so its “src” makes a request to another website.
JavaScript is a client-side language, this means that JavaScript code is run in the browser rather than on the webserver. Thanks to this fact, the computer that makes the CSRF request is actually that of the victim. Unfortunately, this means that the request is made with all the permissions that the user has. Once the attacking website has tricked the victim into making the CSRF request, the request is essentially indistinguishable from the user making the request normally.
CSRF is an example of a “confused deputy attack” against the web browser as the browser is tricked into using its permissions by an attacker without those privileges. These permissions are your session and authentication tokens to the target website. Your browser automatically includes these details in any request it makes.
CSRF attacks are somewhat complex to arrange. First of all, the target website needs to have a form or URL that has side effects such as deleting your account. The attacker then needs to craft a request to perform the desired action. Finally, the attacker needs to get the victim to load a webpage with the exploit in it while they’re signed into the target website.
To prevent CSRF issues the best thing you can do is include a CSRF token. A CSRF token is a randomly generated string that is set as a cookie, the value needs to be included with every response alongside a request header which includes the value. While a CSRF attack can include the cookie, it no way to be able to determine the value of the CSRF token to set the header and so the attack will be rejected.
