CSRF - TairinySimeonato/WebAuditing GitHub Wiki

What is a CSRF?

CSRF is when a attacker forces the victim's authenticated browser to send a forged request to a vulnerable aplication. This way, the vulnerable application "thinks" that the attacker's request is actually a legit request from the victim. Since the attacker is not able to see the response of that malicious request, CSRF is not used to steal sensitive data, unless the application has a wildcard CORS policy. However, the attacker still can transfer funds, change user email, and if the account is an admin one, CSRF can compromise the whole application. CSRF causes a state change in the server. An attacker can abuse a CSRF to send malicious controlled data to a site, which can be stored on the vulnerable website. When it happens, the severity increases substantially as the victim is more likely to access the webpage with CRSF and the victim is authenticated automatically in the web application. CSRF can occur via invisible img tags (GET) and forms (POST) and (GET).

CSRF mitigation for users

  • Log out the account after finish browsing the page
  • Use multiple browsers (one for sensitive data sites, one for browse freely)

CSRF mitigation for developers

  • Application should have more actions accepting POST requests instead of GET
  • Check and validate the Referer header
  • Disconnect after period of inactivity - session timeout
  • Confirmation pages, where the user has to interact with the application to execute an action
  • CAPTCHA
  • Forms should contain unique and random CSRF tokens

CSRF relies on:

  • how the browser handles session related information
  • Attack must know the vulnerable URLs
  • Existence of HTML tags that are able to access HTTP(S) (img tag)
  • Application of session management

GET accessible URLs

There are three ways to originate a GET Request:

  1. User accessing the actual website
  2. User typing the URL directly in the browser
  3. User clicking a link that redirects to the URL

The application cannot distinguish how the GET request was originated! A link could be hidden in a email message, be hosted in a malicious link where the user is tempt. If the user access this link, since the user is authenticated by the webpage, the browser sends a GET request with a session ID cookie. This is will cause a valid action performed on the page and the user is not aware of it.

With an IMG tag, this process is even simpler. If an attacker messages the victim a URL with the following HTML code:

<html><body>
...
<img src="https://test.com" width="0" height="0">
...
</body></html>

The first thing that happens is the browser will try to show the image (but it is invisible). However, the presence of a URL in a <img src> makes the GET request anyway.

Besides <img src> tag, other HTML tags can lead to automatic HTTP request execution, such as:

  • <a href = url>
  • <form action = url>
  • <link href = url>
  • <script src = url>
  • <embed src = url>

The browser cannot recognize that the img src tag is composed by a reliable image.

CSRF on DVWA

  • Low Security

Look at the page source, we can see this piece of code:

<form action="# method="GET">
			New password:<br />
			<input type="password" AUTOCOMPLETE="off" name="password_new"<br />
			Confirm new password:<br />
			<input type="password" AUTOCOMPLETE="off" name="password_conf" <br />
			<br />
			<input type="submit" value="Change" name="Change">

		</form>

Now, all an attacker needs to do change this form, save it as a HTML file (example: csrf.html) and send it to victim.

<form action="http://host/DVWA-master/vulnerabilities/csrf/" method="GET">
			New password:<br />
			<input type="password" name="password_new" value="hacker123"><br />
			Confirm new password:<br />
			<input type="password" name="password_conf" value="hacker123"><br />
			<br />
			<input type="submit" value="Change" name="Change">

		</form>

Now, after the victim access this page and submits this request, the new value of the password will be hacker123

Resources

⚠️ **GitHub.com Fallback** ⚠️