Saturday, 16 April 2016

Cross Site Request Forgery (CSRF) Mitigation Techniques



INTRODUCTION
In the post before this, I explain what cross siterequest forgery (CSRF) is all about and how it works. It was established that a successful CSRF attack can effectively bypass authentication mechanisms working in the background of an application and access to confidential information gained. Today, we shall discuss some mitigation techniques that can be employed by developers. I’ll start with the less effective to the much more effective ones.


CSRF MITIGATION TECHNIQUES

Use Of POST Instead of GET Parameters
To make it difficult for a hacker to carry out CSRF attack, developers should use POST parameters instead of GET parameters as the latter encourages CSRF through parameter manipulation while the former closes certain attack vectors such as use of image tags. Though this is only a basic step as it takes only a trivial effort from the attacker to bypass. Also, it may not be completely removing GET parameters may not be easy as this concept may make programming more difficult for the developer. The next mitigation technique is much more defensive and sophisticated.

Checking HTTP Referrer Header
Checking HTTP referrer header has proven to be a much more defensive measure against CSRF than the first method. By maintaining a white list of accepted referrers, the banking code snippet in the previous post could deduce that the request generated by clicking https://attack.com/steal.php was initiated due to a CSRF attack and refuse to perform the transaction. The sad news again is that; using modern browsers the referrer header can be configured to have arbitrary values or even empty values. Also, leaking of sensitive information to third parties while sending referrer header has discourage its use. Another problem is; when classifying requests with an empty referrer header as valid, it would become impossible to detect attacks against users who follow the recommendation and disable the transmission of the referrer header.

Use of Shared Secret or Token
CSRF only works when a cookie is used to store session ID. Cookie-based session management is much more popular and wide-spread for a number of reasons, some of which are even security-related. The best solution proposed so far is the use of a shared secret (or token) between the client and the server to identify the actual origin of a request. This can be adapted in the banking example in previous post by making the HTML form contain an additional hidden field. The token should be generated using the session ID and associated with the current session. Only request for financial transactions that contain the correct token are processed. The problem with the use of token is that considerable amount of work is involved as implementation requires detailed application-specific knowledge and considerable modification to existing source code.


CONCLUSION
CSRF is one of the top 10 security issues published by the Open Web Application Security Project (OWASP). It is a very serious security flaw even though it has been given less attention than Cross Site Scripting (XSS) and Structured Query Language Injection (SQLi) attack. Of the three mitigation techniques described above, the use of token is the best if one is ready to do some code review. Developers can also research for hybrid approaches such as proxy-based solutions that are deployed on the server side and do not require modification to existing code.

0 comments:

Post a Comment

Add a comment here

Advert