However, browsers don’t allow reading across sites; for example, this website can’t read content on pages you may have open in other tabs. However, form submissions across sites or domains are allowed. It’s through that security loophole that the CSRF attack is possible in the first place. At the heart of the CSRF vulnerability is a “confused deputy problem” which happens when a web browser isn’t able to properly validate a web app user that is logged in.
The CSRF attacks are usually conducted by using malicious social engineering tricks and techniques, such as an email or link that tricks the victim into sending a forged request to a server. As the victim is authenticated by their vulnerable target application at the time of attack, then its impossible to distinguish a legitimate request from a forged one.
The targets of CSRF attacks include web applications like social media, in-browser email clients, online banking and web interfaces for network devices. The CSRF vulnerabilities can vary a lot in severity, for example an attacker could change the settings or posts something on behalf of victim, but in critical conditions it could also lead to password change, account takeover, and so on.
How CSRF Attack Works :
In CSRF attack the forged web requests are sent form a malicious site that the victim visits to the target site or web application that the attacker believes the victim is logged in or validated against. At here the malicious site is controlled by the attacker. The malicious requests are routed to the target site via the victim’s browser, which is authenticated against the target site. Now here the vulnerability lies in the affected web application/target site, not the victim’s browser or the site hosting the CSRF exploit.
For example lets say there is a banking web application by which we can transfer funds to different accounts, where the user needs to be log-in in order to transfer funds. Now the CSRF attack is executed within below steps :
1. First the user/victim will log into banking application to transfer funds.
2. Then visits the attackers controlled malicious site while he still logged in to the banking application.
3. At this point the attacker believing that the victim is logged in into his bank account. Now the attacker embedded some javascript in his malicious website to send the forged request to the banking application on the behalf of victim. The forged request might contains the fund transfer requests to the attackers bank account from victim account.
4. Now the banking application automatically validates the transaction without re-authenticating, because the victim is logged-in and the request appears to be coming from the user.
Now lets see an example of CSRF attack. The code for below example can be downloaded from here :
https://github.com/sec-artdotnet/CSRF/tree/master/csrf_basics
https://github.com/sec-artdotnet/CSRF/tree/master/csrf_basics
For example lets assume we are logged into the below online banking page where we can transfer money from our account.
When we put the amount and account number and click on submit button, it will process our transaction request.
Now there is also a malicious page called csrf.php, which send the forged request to bank application with altered amount and account number. The code for csrf.php is :
<html>
<body onload="document.getElementById('xsrf').submit();">
<form id="xsrf" method="GET" action="transfer.php">
<input name="amount" type="hidden" value="1000">
<input name="AcNo" type="hidden" value="999999999">
<input name="action" type="hidden" value="Change">
</form>
</body>
</html>
Now as we can see the above form is auto-submitting from, and when we open that page then it will immediately send the request to transfer.php file.
The above example is simple demonstration of csrf attack, but not an accurate one, because there is no sign-in mechanism. You can also try the above example on your system. Just download the code from below link :
https://github.com/sec-artdotnet/CSRF
Put the above code on root directory in your web server (for example xampp) and open the bank.php in your browser.
Prevention from CSRF Attacks :
The most common method to prevent Cross-Site Request Forgery (CSRF) attacks is to append CSRF tokens to each request and associate them with the user’s session. Such tokens should at a minimum be unique per user session, but can also be unique per request. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from a source other than the user.
Conclusion :
The CSRF attack could be very dangerous for users if its not prevented. Now in next posts we will try to exploit All CSRF exercises in Test Web applications (DVWA, Bewapp, Webgoat).
For more web security related stuff : http://www.sec-art.net/p/web-security.html
The above example is simple demonstration of csrf attack, but not an accurate one, because there is no sign-in mechanism. You can also try the above example on your system. Just download the code from below link :
https://github.com/sec-artdotnet/CSRF
Put the above code on root directory in your web server (for example xampp) and open the bank.php in your browser.
Prevention from CSRF Attacks :
The most common method to prevent Cross-Site Request Forgery (CSRF) attacks is to append CSRF tokens to each request and associate them with the user’s session. Such tokens should at a minimum be unique per user session, but can also be unique per request. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from a source other than the user.
Conclusion :
The CSRF attack could be very dangerous for users if its not prevented. Now in next posts we will try to exploit All CSRF exercises in Test Web applications (DVWA, Bewapp, Webgoat).
For more web security related stuff : http://www.sec-art.net/p/web-security.html