Security Csrf Prevention


// Security - Cross Site Request Forgery - Prevention:

Preventing CSRF usually requires the inclusion of an unpredictable token in each 
HTTP request. Such tokens should, at a minimum, be unique per user session.

1. The preferred option is to include the unique token in a hidden field. This 
   causes the value to be sent in the body of the HTTP request, avoiding its 
   inclusion in the URL, which is more prone to exposure.

2. The unique token can also be included in the URL itself, or a URL parameter. 
   However, such placement runs a greater risk that the URL will be exposed to 
   an attacker, thus compromising the secret token.  OWASP’s CSRF Guard can 
   automatically include such tokens in Java EE, .NET, or PHP apps. OWASP’s 
   ESAPI includes methods developers can use to prevent CSRF vulnerabilities.

3. Requiring the user to reauthenticate, or prove they are a user (e.g., via a 
   CAPTCHA) can also protect against CSRF.

The CSRF token is probably stored inside the server-side session, and is only 
sent to the browser as a hidden form field, the attacker does not have this 
token so he cannot put it into the script.

// CSRF Prevention:

1. State changing web operations should be accompanied by a secret  that isn’t 
   sent automatically like Cookies. These secrets are called CSRF tokens.

2. CSRF tokens are typically included in the DOM.

3. The tokens should be unique per user per session.

4. The server should validate the token upon each state changing request

5. This would prevent malicious websites from performing state changing 
   operations on benign domains. 

6. Custom headers with secrets are also an effective way to prevent CSRF 
   because they are not automatically sent by your browser.

Sometimes, it is possible to store the CSRF attack on the vulnerable site 
itself. Such vulnerabilities are called Stored CSRF flaws. This can be 
accomplished by simply storing an IMG or IFRAME tag in a field that accepts 
HTML, or by a more complex cross-site scripting attack. If the attack can store 
a CSRF attack in the site, the severity of the attack is amplified. In 
particular, the likelihood is increased because the victim is more likely to 
view the page containing the attack than some random page on the Internet. The 
likelihood is also increased because the victim is sure to be authenticated to 
the site already.

CSRF attacks are also known by a number of other names, including XSRF, 
"Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. 
Microsoft refers to this type of attack as a One-Click attack in their threat 
modeling process and many places in their online documentation.

Cross-Site Scripting is not necessary for CSRF to work. However, any cross-site 
scripting vulnerability can be used to defeat token, Double-Submit cookie, 
referer and origin based CSRF defenses. This is because an XSS payload can 
simply read any page on the site using a XMLHttpRequest and obtain the generated 
token from the response, and include that token with a forged request. This 
technique is exactly how the MySpace (Samy) worm defeated MySpace's anti CSRF 
defenses in 2005, which enabled the worm to propagate. XSS cannot defeat 
challenge-response defenses such as Captcha, re-authentication or one-time 
passwords. It is imperative that no XSS vulnerabilities are present to ensure 
that CSRF defenses can't be circumvented. 

Approaches to prevent CSRF:

1. Embed a CSRF Token as a hidden form field.  The CSRF token should be unique 
   per session.  It should be included as a hidden field in a POST request.  
   Avoid including the CSRF token as part of a GET request because it is leaked 
   through the referrer header, in the server log, and browser history.

2. Viewstate (ASP.NET): ASP.NET has an option to maintain your ViewState. The 
   ViewState indicates the status of a page when submitted to the server. The 
   status is defined through a hidden field placed on each page with a 
   <form runat="server"> control. Viewstate can be used as a CSRF defense, as 
   it is difficult for an attacker to forge a valid Viewstate. It is not 
   impossible to forge a valid Viewstate since it is feasible that parameter 
   values could be obtained or guessed by the attacker. However, if the current 
   session ID is added to the ViewState, it then makes each Viewstate unique, 
   and thus immune to CSRF.

3. Double Submit Cookies: Double submitting cookies 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 are equal.  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. The site should then require every sensitive submission to include 
   this random value as a hidden form value (or other request parameter) and 
   also as a cookie value. An 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 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 submit a form unless he is 
   able to guess the random CSRF value.  Direct Web Remoting (DWR) Java library 
   version 2.0 has CSRF protection built in as it implements the double cookie 
   submission transparently.  I think that this depends on us using the 
   HttpOnly flag.

4. Encrypted Token Pattern: The Encrypted Token Pattern leverages an encryption, 
   rather than comparison, method of Token-validation. After successful 
   authentication, the server generates a unique Token comprised of the user's 
   ID, a timestamp value and a nonce, using a unique key available only on the 
   server. This Token is returned to the client and embedded in a hidden field. 
   Subsequent AJAX requests include this Token in the request-header, in a 
   similar manner to the Double-Submit pattern. Non-AJAX form-based requests 
   will implicitly persist the Token in its hidden field, although I recommend 
   persisting this data in a custom HTTP header in such cases. On receipt of 
   this request, the server reads and decrypts the Token value with the same 
   key used to create the Token.

   On successful Token-decryption, the server has access to parsed values, 
   ideally in the form of claims. These claims are processed by comparing the 
   UserId claim to any potentially stored UserId (in a Cookie or Session 
   variable, if the site already contains a means of authentication). The 
   Timestamp is validated against the current time, preventing replay attacks. 
   Alternatively, in the case of a CSRF attack, the server will be unable to 
   decrypt the poisoned Token, and can block and log the attack.

   This pattern exists primarily to allow developers and architects protect 
   against CSRF without session-dependency. It also addresses some of the 
   shortfalls in other stateless approaches, such as the need to store data in 
   a Cookie, circumnavigating the Cookie-subdomain and HTTPONLY issues.

CSRF can be prevented in a number of ways. Using a Synchronizer Token is one 
way that an application can rely upon the Same-Origin Policy to prevent CSRF by 
maintaining a secret token to authenticate requests. This section details other 
ways that an application can prevent CSRF by relying upon similar rules that 
CSRF exploits can never break.

1. Checking The Referer Header

2. Checking The Origin Header: The Origin HTTP Header standard was introduced 
   as a method of defending against CSRF and other Cross-Domain attacks. Unlike 
   the referer, the origin will be present in HTTP request that originates from 
   an HTTPS url.  If the origin header is present, then it should be checked for 

3. Challenge-Response: Challenge-Response is another defense option for CSRF. 
   The following are some examples of challenge-response options:

   b. Re-Authentication (password)
   c. One-time Token

   While challenge-response is a very strong defense to CSRF (assuming proper 
   implementation), it does impact user experience. For applications in need of 
   high security, tokens (transparent) and challenge-response should be used on 
   high risk functions.

All requests that create, update or delete data or have side-effects require 
protection against CSRF.  The most reliable method is to include an anti-CSRF 
token as a hidden input with every application action. This token should be 
included in all forms built by the genuine application and validated to be 
present and correct before form data is accepted and acted upon.  Use the POST 
method for requests requiring protection to avoid disclosing the token value in 
Referer headers.

The OWASP CSRFGuard Project also provides an anti-CSRF token mechanism 
implemented as a filter and set of JSP tags applicable to a wide range of J2EE 
applications. Download it at:

The “csrf-magic” library can provide anti-CSRF tokens for many PHP applications. 
Download it at:
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License