# Cross-Site Request Forgery (CSRF, XSRF)

In this type of attack an adversary tries to execute malicious code in a web application through the browser session of a trusted (i.e. logged in) user. This is basically done by tricking the user to do a web request (i.e. click on a link) that the adversary has configured. According to the [CSRF entry on Wikipedia](https://en.wikipedia.org/wiki/Cross-site_request_forgery) this attack is sometimes also called _one-click attack_ or _session riding_.

## A practical example

For example let us assume there is a website https://chitterchatter.net where people can send each other short messages, but only if they are logged in and only to users who have allowed the senders to send messages.

Now everyone can easily go to https://chitterchatter.net and see the start page. It might look differently for logged in users than for anonymous visitors. But if users go to https://chitterchatter.net/login, and provide their credentials, a user session is established (with an appropriate session cookie stored in the user's browser). Now the user sees other users and can send messages to them. For example https://chitterchatter.net/send_message?to=Betty&text=hi would send a message "hi" from our logged in user (let's say: Alice) to Betty. This will also only work if at some point Betty used https://chitterchatter.net/approve?user=Alice to allow Alice to send messages.

So far so good. But now our adversary, mysertiously named Eve, wants to send spam messages with Alice's account. Eve does not have Alice's credentials, and also no other account on this plattform. So Eve could try just calling https://chitterchatter.net/send_message?to=Betty&text=spamspamspam (or also replace the `to` parameter in this query with any other username), but it won't work. She will get a HTTP 403 Forbidden response from the server, because she is not logged in.

So Eve wants that actually Alice will make this request, while she is logged in on the plattform, without realising that she made the request. The only thing Eve needs to do for that is to get Alice to click on some link which has the target https://chitterchatter.net/send_message?to=Betty&text=spamspamspam and hope that Alice is already logged in on chitterchatter.net when she clicks on the link.

This is a very basic form of an CSRF attack. The name Cross-Site Request Forgery comes from the way how Eve can make Alice or Alice's Browser to follow this link. Eve has to trick Alice into clicking on this link somewhere else. So Eve could for example go to another plattform, e.g. a chitterchatter fan forum, where she nows that Alices is hanging out all the time and reading and following a lot of what is going on there. On this forum then Eve just creates a post with the follwing content:

> Check out this super awesome [demo of the new feature](https://chitterchatter.net/send_message?to=Betty&text=spamspamspam) we've built into the chitterchatter platform.

Alice is of course monitoring this forum closely because she is always super curious about new chitterchatter features. And of course she has to click on this link. And of course she is already logged into chitterchatter in another browser tab, because she's exchanging chitchats with her chitterchatter friends all the time.

So what does Alice's browser do? Exactly what it is expected to do: it goes to the link, which is a link to send a message to Betty (in this case a lot of _spam_). And it also sends the session cookie to the server, which it has stored from the session in the other browser tab.

Eve used another site to execute something as Alice on the actual target site. Therefore the term Cross-Site Request Forgery. Of course this could also happen by placing a link on chitterchatter itself. So no different site would need to be crossed, but the principal is the same.

And while the _other site_ can be another website, it also can be, and nowadays very often is, just a link placed in an e-mail.

Of course this scenario here is a highly constructed and hypothetical one. Few spammers and phishers would invest a lot of time to find out about Alice's communication habits to exploit this vulnerability. But this attack does not cost much, because it can also be easily automated and delegated to botnets. And it can be scaled easily by using popular sites and crappy mailservices. On the other hand, highly targeted social-engineering attacks under the right circumstances can even trick careful site administrators into following the wrong link just once.

**Questions:**
* in the chitterchatter example, how dramatic is it, that the site is vulnerable to this type of attack?
* what else could Eve do in the above example?
* how could chitterchatter prevent this attack?
* can you imagine more complex or dangerous CSRF attack scenarios?

On reflectoring.io there is an article [Complete Guide to CSRF/XSRF (Cross-Site Request Forgery)](https://reflectoring.io/complete-guide-to-csrf/?ref=fuffsec.com) with a nice visualisation of just about the thing we went through above. Here's the direct link to the image: https://reflectoring.io/images/posts/csrf/csrf-intro_hua1478ce17fadc128f4bcdf5651ad3b7f_65290_731x0_resize_box_3.png

## Your hacking challenge

We now leave the chitterchatter.net example and will try to hack the DVWA's CSRF challenge. Go to your local DVWA home page and then to the CSRF section in the menu. There you find a change password form. Your mission is now to find out what this form does, how it works, an how you could exploit it with a CSRF attack.

In this exercise you do not have another user to trick into clicking onto a link, because you will act as this user yourself. So we can also skip the part where you send the link in an e-mail or place it on some other website. Just craft the link you would like to send to the user (maybe use a text editor on the side to write and save the link). Then open a new browser tab, insert the link and hit enter. This emulates another user - who is already logged into the web application (in our case the DVWA) - clicking on this link in an e-mail.

Make sure to start with the low security setting first, if you are still on a higher level from a previous challenge. When you've solved the low security level, then head up to medium.

## Commonality, severity and context

CSRF attacks often are combined with other attack vectors, especially XSS attacks. While a plain XSS attack relies on the user's trust that a site is working securely, a plain CSRF attack relies in a website's trust that a user will only send secure requests.

Another variant than in the above example is, that an attacker tries to clone a website's interface and lure the user to their manipulated clone. There the user might encounter a form that is already familiar to them from the actual website. If there are no other protections on the actual website, the attacker can use this to send a manipulated request to the actual website, when the user clicks on the submit button. This is not to be confused with a phising form. In this case the attacker might not at all be interested in whatever the users enters in the form, but only to get the user's browser to send the request.

Especially dangerous (and lucrative for attackers) are requests to change passwords or e-mail addresses of user accounts, if they are not well protected against CSRF attacks. In the CSRF exercise in the DVWA you will find such an example.

**OWASP Top 10**:
* in 2017 report: dropped from the top 10 because: "as many frameworks include CSRF defenses, it was found in only 5% of applications."
* in 8th position in the 2013 Top 10 and in 5th position in the 2010 Top 10. The 2013 report states:
> "We believe this is because CSRF has been in the OWASP Top 10 for 6 years, and organizations and framework developers have focused on it enough to significantly reduce the number of CSRF vulnerabilities in real world applications."
* Categorisation in 2013 report:
* Exploitability: AVERAGE
* Prevalence: COMMON
* Detectability: EASY
* Impact: MODERATE

## Countermeasures

* using (good) CSRF tokens (e.g. by using an established framework's CSRF protection)
* not disabling SOP by allowing any CORS requests to everyone
* also make sure that your side is secure against XSS, because this would provide a lot more options to an attacker to circumvent any CSRF protection in place
* let the users authenticate again, at least for critical requests (e.g. ask again for credentials when changing password or e-mail address)

## Further resources & references

* https://en.wikipedia.org/wiki/Cross-site_request_forgery
* https://en.wikipedia.org/wiki/Same-origin_policy
* https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
* [CSRF @ owasp.org](https://owasp.org/www-community/attacks/csrf)
* [CSRF-FAQ @ cgisecurity.com](https://www.cgisecurity.com/csrf-faq.html)
* [OWASP Top 10](https://owasp.org/www-project-top-ten/)