What is CSRF ?
“Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the website trusts.” – Wikipedia
CSRF is at 8th position in OWASP top 10 bug list. Usage of frameworks like Django, ROR reduces the risk of CSRF to a large extent but it is still there. Also, it is carried out from user’s IP address, website’s logs will have no evidence.
Examples of CSRF:
CSRF comes in all shape and sizes. Dangerous one can take over an account, minor one can destroy your session or log you out.
Every request that change state on server should have CSRF protection.
It can be an email change or addition of user details like a bank account.
Suppose a user is withdrawing money from their bank account, if the bank is not so smart and using GET for the transaction purpose. The URL will look like something similar to this:
http://stupidbank.com/withdraw.php?account=112345&amount=1000
If an attacker can trick a user to click on link with his account number , attacker’s link can be http://stupidbank.com/withdraw.php?account=12345&amount=3000
One way to do this would be by using the URL as the source for an image tag. An HTML page with
<img src=”http://stupidbank.com/withdraw.php?account=12345&amount=3000″>
can do the work, the victim will never know what happened as the page will show nothing(distorted image) as there’s no image at that URL but the browser will send a request anyway to get the image and bang !
In this case, an attacker might be able to change the account number and amount.
I hope there is no bank in the world were an attack would be as easy as a CSRF but it is certainly true for many systems out there. You can logout user from almost every website like this
<img src=”http://smartwebsite.com/logout.php”>, this will hardly harm anyone but this can be used to exploit other bugs. Here’s an example https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/
So use POST ?
let’s look at another example, stupid website’s dashboard setting
<form action=”http://xyz.com/profile.php” method=”POST”>
<input type=”text” name=”fname” value=”manish”>
<input type=”text” name=”lname” value=”bhattacharya”>
<input type=”email” name=”email” value=”user@test.com”>
</form>
pretty neat ! Haan
what if I tell you a HTML page with following form will change user’s email to attacker’s email and later using forgot password attacker can take over user’s account.
<form action=”http://xyz.com/profile.php” method=”POST” name=”manish”>
<input type=”text” name=”fname” value=”manish”>
<input type=”text” name=”lname” value=”bhattacharya”>
<input type=”email” name=”email” value=“attacker@test.com”>
</form>
document.manish.submit();
FAQs
Why Same-origin policy isn’t enough to prevent CSRF attacks?
Because the Same-origin Policy only applies to reading data and not writing it.
Why using a secret cookie or using the token in the cookie won’t help ?
Remember that all cookies, even the secret ones, will be submitted with every request.
Where do we need CSRF protection ?
With every HTTP request that change state.
CSRF can be avoided by using a long random token with forms(requests), the token should get verified on the server side.
Bonus
- Try to submit forms without the token. Sometimes there’s token with the form but the token is getting validated on server-side, which is almost similar to having no CSRF protection.
- Make sure token is long,random and unpredictable.
- Also, check if the token is same before and after log out. The token should be different for different sessions.
- Django uses double cookie submit method (it match token value from POST with value in a cookie )to protect against CSRF. So don not use |safe, as it will escape HTML that can lead to XSS which can further leak the csrf_token value from the cookie. (alert(document.cookie)). Also with public forms like forgot password should better use captcha than relying on CSRF middleware as an attacker can have access to his cookie and parameter , all he need is the email of a user to bombard his mail with forgot password emails.
- Check security page of ROR http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf (they don’t consider CSRF with public forms).
If you have any questions,suggestions or comment reach out at my twitter @umenmactech
Further reading:
https://en.wikipedia.org/wiki/Cross-site_request_forgery
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29
If you want to start your bug bounty career please visit Bug Bounty resources.
Thanks
Manish Bhattacharya
http://manishbhattacharya.com/
what I'm breaking... 