Double Submit Cookies Patterns
Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user’s web browser to perform an unwanted action on a trusted site for which the user is currently authenticated. The impact of a successful CSRF attack is limited to the capabilities exposed by the vulnerable application. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the user's context. In effect, CSRF attacks are used by an attacker to make a target system perform a function via the target's browser without knowledge of the target user, at least until the unauthorized transaction has been committed.
Impacts of successful CSRF exploits vary greatly based on the privileges of each victim. When targeting a normal user, a successful CSRF attack can compromise end-user data and their associated functions. If the targeted end user is an administrator account, a CSRF attack can compromise the entire web application. Sites that are more likely to be attacked by CSRF are community websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). Utilizing social engineering, an attacker can embed malicious HTML or JavaScript code into an email or website to request a specific 'task URL'. The task then executes with or without the user's knowledge, either directly or by utilizing a Cross-Site Scripting flaw.
There are numerous ways you can specifically defend against CSRF. We recommend using one of the following (in ADDITION to the check recommended above):
1. Synchronizer (i.e.,CSRF) Tokens (requires session state)
2. Double Cookie Defense
3. Encrypted Token Pattern
4. Custom Header - e.g., X-Requested-With: XMLHttpRequest
These are listed in order of strength of the defense. So use the strongest defense that makes sense in your situation.
Double Submit Cookies Patterns
If storing the CSRF token in session is problematic, an alternative defense is a use of a double submit cookie. A double submits cookie is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match.
When a user authenticates to a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine separate from the session id. The site does not have to save this value in any way, thus avoiding the server-side state. The site then requires that every transaction request include this random value as a hidden form value (or another request parameter). A cross-origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can force a victim to send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the request parameter or form value must be the same, the attacker will be unable to successfully force the submission of a request with the random CSRF value.
As an example, the Direct Web Remoting (DWR) Java library version 2.0 has CSRF protection built in that implements the double cookie submission transparently.
When the UI and the function service reside in different hosts, the Double Submit Cookie guard turns difficult to implement because the UI body and the Set-Cookie response header will be generated as part of different requests to different processes. The Set-Cookie response header would need to be induced by a request from the client javascript. In that case, making sure that both the UI and the service request came from a client serviced by the same UI origin appears as difficult as the original issue.
I'm going to show how to use the double submit cookies patterns to prevent the CSRF attacks.
Same as the earlier blog, in here I have changed only cookie values and check whether both cookie values are same.
You can download the source code from my GitHub: https://github.com/chathurangasineth/Double-Submit-Cookies-Patterns
Comments
Post a Comment