Days already gone when developers used to just code from the requirements perspective of the web application and then wait for testing results to emanate so that they can fix the bugs and finally deploy the application. Ever since the growth of web-based projects, fixing bugs and security vulnerabilities have been a horrendous task for developers. These days, a developer also needs to know about security vulnerabilities that can create havoc with their applications or websites. Today, I am going to talk about an attack known as Cross Site Request Forgery or CSRF.
However, Cross Site Request Forgery is one such most exploiting and dangerous attack apart from Cross-Site Scripting and SQL Injection. CSRF is one of the top 10 vulnerabilities as described by OWASP. CSRF (pronounce it as ‘sea-surf) also has an alternative name XSRF, session-riding or click-jacking.
In CSRF attack, a nasty website instructs a legitimate users’ browser to send a request to the trusted site, as if the request from the user is part of an ongoing interaction with the trusted site. The beauty of CSRF attack is it targets just the state-changing events or requests and not rely on stealing of data. The reason is, the attacker has no way to view the response to the forged request. HTTP being a stateless protocol, it can make the request to a site without any particular sequence from any location and the web application can never know from where this request came from.
One more thing that should keep in your mind is Cross Site Request Forgery is not an attack on the authentication. On the contrary, the user needs to be logged in to make this attack successful. So, encounter yourself with the best internet security tips!
Anatomy of a Cross Site Request Forgery or CSRF Attack
Consider the link http://www.youtube.com/results?search_query=obama. The link instructs YouTube to find videos of Obama. Such links are legitimate and the user can make out what the link does just by viewing anything that is written after the ‘?’. This is called as Query String – a perfectly harmless and valid thing.
However, consider another example of a link: http://www.mybank.com/withdraw?acc=myaccount&amount=1000000&transfer=myfriend . Considering that the user is authentic, an attacker can trick so that the user unknowingly transfers a few bucks from his account to the attacker’s account. For this, the attacker can use an image embedded with the link and send it to the victim either by posting it on some chat forum where the user is active or by sending a message.
<img src=”http://www.mybank.com/withdraw?acc=myaccount&amount=1000000&transfer=attacker”>
Stored and Reflected CSRF Attacks
CSRF attacks can be categorized into two: Stored and Reflected.
Recent CSRF Attacks
A recent CSRF Vulnerability was found in Lenovo’s Solution Centre by an independent security firm. This vulnerability allowed any attackers to exploit the system if a user opens a malicious website or a specially crafted URL for attacking purpose while the Solution Centre is running in the back end.
Another recent CSRF Vulnerability was found in Google’s Android Studio which is the official Android IDE for fixing security bugs. The flaw allowed attackers to get access to the local file system of the built-in web server of the IDE if the developer visits a nasty site.
Prominent sites like Gmail (in 2007) and Facebook (in 2015) also had to face the wrath of Cross-Site Forgery attacks.
Defending Against CSRF Attacks
As a programmer, you might be afraid after looking at the anatomy of a CSRF attack. Well, there are ways to prevent your web-apps against such types of attacks:
Using an undisclosed cookie: By using an undisclosed or secret cookie, one can prevent CSRF attack. However, this is not a fool proof method as cookies are transferring as normal requests.
Only allowing HTTP POST: This technique denies the use of image tags and as a result, links embedded inside images won’t work. However, the attacker can modify the attacks by using web forms or fake submit buttons.
Adding a Secret that is not Automatically Submit: Adding a secret token to all sensitive requests, a programmer can nullify the attack and the attacker cannot spoof the request. However, it is easily exploitable if your application has an XSS hole.
Generate random cryptographic tokens: One of the simplest and efficient way to prevent CSRF is to generate an unpredictable string or a token during the initial connection with the web application and embed it along with the query string. So the next time a request comes, the server can validate the token and hence approve the action the user wants to commit. If the value of the token does not match, then the server can deny the request and log such entries for further analysis. This technique is also referred to as Synchronizer Token Pattern.
A few other possibilities to add tokens
So, storing a single token for a particular session and add it to all the forms and URL’s of your website as shown in below examples:
Hidden Field: <input name = “secrettoken” value = “<some random value>” type = “hidden” />
Use and Throw URL
Create a URL which you can use only once, like /bankwithdrawal/<some random value>
Form Token
This can be embedded in your web-forms, like /bankwithdrawal?accountauth=<some random value>
Make sure that the token is not displayed in the Referrer Header: Use hidden fields.
Use Unique Names for each Secret Token
One way is to use combination of <HashFunction, SessionID, SecretToken>
2-factor authentication
So, for sensitive transaction two-factor authentication can be made by sending some random number on the user’s mobile or email.
Restrict the attackers to store attacks on your website
This can be achieved by properly encoding (e.g. Base-64) all the input on the way it comes out. As a result, all the URLs and requests will be unclear directly even by the interpreters.
CSRF Discoverer plugin on Google Chrome
This nifty plugin on Google Chrome can help developers to quickly discover all the forms that can possibly be exploited using CSRF.
Implementing CSRF Guard in Java Applications
OWASP CSRF Guard is a library that can mitigate the risk of CSRF Attacks. To know more about it, go to the site:
http://www.owasp.org/index.php/Category%3aOWASP_CSRFGuard_Project
Conclusion
So, this is all about Cross Site Request Forgery or CSRF or cross site request forgery attack. In this article, I am covering every necessary aspects of the attack. Maybe it was helpful for you. However, if you have any better idea, you can share with us. It will surely be very helpful of everyone. I am expecting all of your suggestion though. Until then, explore the cyber security tips!