Let's talk about CSRF

Cross Site Request Forgery

Who discovered CSRF?

The following text comes from here

In 1998 Norm Hardy published a document explaining an application level trust issue he called consufed deputy. In 2000 a post from bugtraq explained how ZOPE was affected by a confused deputy web problem that we would define today as CSRF. Later in 2001 Peter Watkins posted an entry on the bugtraq mailing list coining the CSRF term in response to another thread titled The Dangers of Allowing Users to Post Images

What can be done with CSRF?

Most of the functionality allowed by the website can be performed by an attacker utilizing CSRF. This could include posting content to a message board, subscribing to an online newsletter, performing stock trades, using a shopping cart, or even sending a e-card...

What is a CSRF attack?

A cross site request forgery attack occurs when an attacker can trick the victim into using his/her credentials in an authenticated system to do something he/she did not orignally anticipated, this could happen in a secure bank appliction when an attacker can send a carefully crafted link to the victim which when opened would send him/her money without the victim being aware, though this is dangerous the real danger when an administrator accounts gets compromised the attack could compromise not just one account but the complete infrastructure. According to the OWASP Test Guide a succesful CSRF attack relies on the following:

1. Web browser behavior regarding the handling of session related information such as cookies, and http authentication information
2. Knowledge by the attacker of valid URLs
3. App session management relying only on information which is know by the browser
4. Existence of HTML tags whose presence cause an immediate access to an http[s] resource(most ususally a GET request). The most common one being the <img src=x /> element

The OWASP test guide does point that steps: 1,2,3 are essential for this attack while step: 4 only facilitates the attack but it is not neccesary for it to be exploitable.

Let's break those requirements down

1 - The browser will automatically send info to each request which is used to identify a session, once the browser recives a cookie set by the site, this cookie will be passed to every single request directed to the site.

2 - If the application does not use any user session details in its URLs then the values used by these URLs can be determined either by code analysis or by mapping the application, this entails using the given application as it is meant to be used by a normal user.

3 - Refers to information that is known by the browser; in other words: cookies, or http-based authentication, which are stored by the browser and sent in each subsequent request to the site.

If steps 1,2 and 3 are met we can began our attack - let's pretend our victim is using a banking web application that does not defend against CSRF, our victim logs into his bank to check his balance and leaves the browser open while he checks his email, our attacker knows the bank is vulnerable to CSRF and has crafted s malicious email with a link saying our victime has won donuts for life! Our victim loves donuts and cannot refuse this deal, so he clicks on the link - but nothing happens...weird, maybe the offer expired?? He continues on about his day, at one point he checks his bank account, he wants to get donuts anyways and wants to make sure there is enough money in his bank account....but it shows $0. He was sure he had enough for the donuts! He calls his bank and the bank tells him that he transfered all of his donut money to account xxx-xxx-xxx, he doesn't remeber doing this though - so what happened?!, let's look into it.