What is CSRF
Cross site request forgery (CSRF), also known as XSRF, Sea Surf or Session Riding, is an attack vector that tricks a web browser into executing an unwanted action in an application to which a user is logged in.
A successful CSRF attack can be devastating for both the business and user. It can result in damaged client relationships, unauthorized fund transfers, changed passwords and data theft—including stolen session cookies.
CSRFs are typically conducted using malicious social engineering, such as an email or link that tricks the victim into sending a forged request to a server. As the unsuspecting user is authenticated by their application at the time of the attack, it’s impossible to distinguish a legitimate request from a forged one.
CSRF example
Before executing an assault, a perpetrator typically studies an application in order to make a forged request appear as legitimate as possible.
For example, a typical GET request for a $100 bank transfer might look like:
GET http://netbank.com/transfer.do?acct=PersonB&amount=$100 HTTP/1.1
A hacker can modify this script so it results in a $100 transfer to their own account. Now the malicious request might look like:
GET http://netbank.com/transfer.do?acct=AttackerA&amount=$100 HTTP/1.1
A bad actor can embed the request into an innocent looking hyperlink:
<a href="http://netbank.com/transfer.do?acct=AttackerA&amount=$100">Read more!</a>
Next, he can distribute the hyperlink via email to a large number of bank customers. Those who click on the link while logged into their bank account will unintentionally initiate the $100 transfer.
Note that if the bank’s website is only using POST requests, it’s impossible to frame malicious requests using a <a> href tag. However, the attack could be delivered in a <form> tag with automatic execution of the embedded JavaScript.
This is how such a form may look like:
<body onload="document.forms[0].submit()">
<form action="http://netbank.com/transfer.do" method="POST">
<input type="hidden" name="acct" value="AttackerA"/>
<input type="hidden" name="amount" value="$100"/>
<input type="submit" value="View my pictures!"/>
</form>
</body>
Methods of CSRF mitigation
A number of effective methods exist for both prevention and mitigation of CSRF attacks. From a user’s perspective, prevention is a matter of safeguarding login credentials and denying unauthorized actors access to applications.
Best practices include:
- Logging off web applications when not in use
- Securing usernames and passwords
- Not allowing browsers to remember passwords
- Avoiding simultaneously browsing while logged into an application
For web applications, multiple solutions exist to block malicious traffic and prevent attacks. Among the most common mitigation methods is to generate unique random tokens for every session request or ID. These are subsequently checked and verified by the server. Session requests having either duplicate tokens or missing values are blocked. Alternatively, a request that doesn’t match its session ID token is prevented from reaching an application.
Double submission of cookies is another well-known method to block CSRF. Similar to using unique tokens, random tokens are assigned to both a cookie and a request parameter. The server then verifies that the tokens match before granting access to the application.
While effective, tokens can be exposed at a number of points, including in browser history, HTTP log files, network appliances logging the first line of an HTTP request and referrer headers, if the protected site links to an external URL. These potential weak spots make tokens a less than full-proof solution.
Using custom rules to prevent CSRF attacks
The highly individual nature of CSRF attacks hinders the development of a one-size-fits-all solution. However, custom security policies can be employed to secure against possible CSRF scenarios.
IncapRules, the Imperva cloud proprietary custom rules engine, lets customers create their own security policies. The policies are generated using an intuitive syntax and can be modified on the fly, augmenting our default web application firewall configuration.
Using IncapRules, you can create a policy that filters requests to sensitive pages and functions based on your HTTP referrer header content. Doing so allows requests to be executed from a short list of secure domains.
This method completely counters the social engineering aspect of CSRF attacks. It prevents execution of malicious requests outside of a security perimeter, regardless of content.
Alternatively, you can run the rule in ‘Alert Only’ mode to track possible exploit attempts, or present CAPTCHAs that alert unwary users.
