Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unintended actions on a web application in which they are currently authenticated. With a little social engineering help (like sending a link via email or chat), an attacker may force the users of a web application to execute actions of the attacker’s choosing. A successful CSRF exploit can compromise end user data and operation when it targets a normal user. If the targeted end user is the administrator account, a CSRF attack can compromise the entire web application.
For simplicity’s sake, consider GET-accessible URLs (though the discussion applies as well to POST requests). If victim has already authenticated themselves, submitting another request causes the cookie to be automatically sent with it. The figure below illustrates the user accessing an application on www.example.com.
The GET request could be sent by the user in several different ways:
The link can be embedded in an email message, appear in a malicious site to which the user is lured, or appear in content hosted by a third-party (such as another site or HTML email) and point to a resource of the application. If the user clicks on the link, since they are already authenticated by the web application on site, the browser will issue a GET request to the web application, accompanied by authentication information (the session ID cookie). This results in a valid operation being performed on the web application that the user does not expect; for example, a funds transfer on a web banking application.
By using a tag such as img, as specified in point 4 above, it is not even necessary that the user follows a particular link. Suppose the attacker sends the user an email inducing them to visit a URL referring to a page containing the following (oversimplified) HTML.
<html>
<body>
...
<img src="<https://www.company.example/action>" width="0" height="0">
...
</body>
</html>
When the browser displays this page, it will try to display the specified zero-dimension (thus, invisible) image from https://www.company.example as well. This results in a request being automatically sent to the web application hosted on site.
⚠️ It is not important that the image URL does not refer to a proper image, as its presence will trigger the request action specified in the src field anyway.
To manually test for CSRF vulnerabilities, first, ensure that Burp is correctly configured with your browser.
Burp Proxy “Intercept” tab must be off:
Visit the web application you are testing in your browser. Ensure you are authenticated to the web application you are testing.
Alter the value in the field/s you wish to change, in this case "Email" but don’t click on “Update” button!
