Cross-Site Request Forgery

*** Nothing contained in this article is intended to teach or encourage the use of security tools or methodologies for illegal or unethical purposes.

The Open Web Application Security Project(OWASP) is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security.

The OWASP Top 10 is a powerful awareness document for web application security. It represents a broad consensus about the most critical security risks to web applications. Cross-Site Request Forgery is mostly exploited one of the tenth attack along with SQL Injection and XSS in OWASP list. A cross site request forgery (CSRF) vulnerability occurs when a user’s web browser is instructed by a malicious webpage to send a request to a vulnerable web site, resulting in the vulnerable web site performing actions not intended by the user. Attacker can hijack the session without knowing session tokens. Let’s illustrate this with a scenario in Figure 1:

  • Victim logs into bank website.
  • After victim logged into bank website, a cookie is setted to user. Cookie is setted to be able recognize user by webpage, every time user visits a page in bank’s website area.
  • Then from example because of the clicking an ad, victim visits the attacker’s website (e.g. sponsored ad from an untrusted organization).
  • Attacker’s page includes form with same fields as the bank’s “Transfer Money” form.
  • Form fields are pre-filled to transfer money from your account to attacker’s account.
  • Attacker’s page includes Javascript that submits form to your bank.
  • When form gets submitted, browser includes your cookies for the bank site, including the session token.
  • Bank validates the session and completes the transaction by transfering money to attacker’s account.
  • The form can be in an iframe that is invisible, so victim would never know the attack is occurred.
Fig 1. CSRF Example

Some online guidance says CSRF can not be exploited if developer force to submit all sensitive requests over POST request while denying GET requests. The thinking is you can only automatically force the user’s browser to send GET requests, via the IMG tag for instance, and not POST. But, this is not the case. JavaScript is fully capable of sending POST requests via form submissions. It’s not to say that sensitive requests should not be restricted to POST for other valid security reasons, just not CSRF protection.

In fact, the best defense against CSRF attacks is unpredictable tokens. To do that every form must contain an additional authentication token as a hidden field. Token must be unpredictable to be able to attacker can’t guess it. First, server provides valid token in forms in its pages. When form posted server checks whether token is the one that server provide for form. If it is not then server reject form because it didn’t use the proper one. For example, it can be session identifier encrypted with server secret key[1].

We’ll use Damn Vulnerable Web Application(DVWA) which is is a PHP/MySQL web application that is damn vulnerable. We will use this application to simulate the CSRF attack:

Figure 2. Change Password

First I reached the CSRF page which has Change Password form. After that, I filled text boxes and checked the post with Burp Suite. I saw that the page uses GET request to send new password informations and here it is the problem. It sends the request but it didn’t contain any extra information to represent the user. Web page can not understand whether the user is legitimate or not. So, CSRF attack occurs in this page. You can see the request below in Figure 2 inside red rectangle area.

Figure 3. Source Code of Fake Link Page
Figure 4. Fake Link Page

Because our password informations carried with GET request we don’t need to prepare same fake change password page all we need to do prepare a link and make user click on it. I prepared this fake link in Figure 3 and you can see how the page look like in Figure 4.

If victim click this link: attack will be succeeded. Since this link will change the password from “password” to “12345”.

If page use POST request instead of GET, this time we need to change the Fake Link Page because we needed from victims to click to actual submit button, in a way.

Have fun.

Leave a comment

Your email address will not be published. Required fields are marked *