OWASP - User contributions [en]

Category:OWASP CSRFGuard Project

2009-10-23T15:37:16Z

Paul Petefish:

==Overview==

Just when developers are starting to run in circles over [[Cross Site Scripting]], the [http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 'sleeping giant'] awakes for yet another web-catastrophe. [[Cross-Site Request Forgery]] (CSRF) is an attack whereby the victim is tricked into loading information from or submitting information to a web application for which they are currently authenticated. The problem is that the web application has no means of verifying the integrity of the request. The OWASP CSRFGuard Project attempts to address this issue through the use of unique request tokens.

[http://www.owasp.org/index.php/How_CSRFGuard_Works Click here] for more information regarding the design and implementation of CSRFGuard.

==License==

CSRFGuard is offered under the [http://www.gnu.org/copyleft/lesser.html LGPL]. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.

== News ==

'''13:35, 13 June 2008 (EDT) OWASP CSRFGuard 2.2 Beta Released!'''

In my spare time, I had been working on several minor updates to the OWASP CSRFGuard 2.0 release. Several of these updates address bugs that were identified in the previous release. Currently, I am spending a significant amount of time working on internal Aspect Security projects and have not had enough time to complete the release as I had wanted. One particular area that needs work is the inclusion of automated JUnit test cases. Instead of leaving the source lay untouched on my laptop, I've decided to make it available for people to test. Although this release is officially "Beta", it is very stable and '''developers are encouraged to consider testing and upgrading to the latest version'''. The reason for this push is that there are a couple of bugs that were never caught in 2.0. More information regarding the updates to 2.2 Beta can be found [http://www.owasp.org/index.php/CSRFGuard_2.2_ChangeLog here].

== Downloads ==

=== Version 1===

[http://www.owasp.org/index.php/Image:CSRF_Guard.zip Click here] to download the latest version of the OWASP CSRFGuard 1.x series.

=== Version 2===

[http://www.owasp.org/index.php/Image:OWASP-CSRFGuard-2.0.jar Click here] to download the latest OWASP CSRFGuard 2.0 binary.

[http://www.owasp.org/index.php/Image:OWASP_CSRFGuard-2.0-src.zip Click here] to download the latest OWASP CSRFGuard 2.0 source, binary, and sample configuration files '''(Recommended)'''.

[http://www.owasp.org/images/c/c9/CSRF_DangerDetectionDefenses.ppt Click here] to download the author's presentation at the 2007 OWASP conference in San Jose about the dangers of CSRF and a brief description of both CSRF Guard and CSRF Tester.

=== Version 2.2 Beta ===

[http://www.owasp.org/index.php/Image:OWASP-CSRFGuard-2.2-dist.jar Click here] to download the latest OWASP CSRFGuard 2.2 binary.

[http://www.owasp.org/index.php/Image:OWASP-CSRFGuard-2.2-src.zip Click here] to download the latest OWASP CSRFGuard 2.2 bundle which consists of source, binary, and sample configuration files. This includes the CSRFGuard properties file, ant build/deploy script, as well as the JSP tag definition '''(Recommended)'''.

[http://www.owasp.org/index.php/Image:OWASP-CSRFGuard-TestApp-2.2-src.zip Click here] to download a sample web application that makes use of OWASP CSRFGuard 2.2. This version comes with the CSRFGuard binary in WEB-INF/lib but it is not guaranteed to be the latest version. Replace it with the download above. The WebContent folder contains several JSP files that were used during testing. One file, "tags.jsp", shows how to use the custom JSP tag to insert the token.

[http://www.owasp.org/index.php/CSRFGuard_2.2_ChangeLog Click here] for a detailed change list of the latest version.

[http://www.owasp.org/index.php/CSRFGuard_2.2_Configuration_Manual Click here] for the OWASP CSRFGuard configuration manual.

[http://www.owasp.org/index.php/CSRFGuard_2.2_Installation Click here] for OWASP CSRFGuard installation instructions.

[http://www.owasp.org/index.php/CSRFGuard_2.2_Tag_Usage Click here] for OWASP CSRFGuard tag library usage instructions.

== Installation Instructions ==

[[CSRFGuard 1.x Installation|Click here]] to view the installation instructions of the OWASP CSRFGuard 1.0 series.

[http://www.owasp.org/index.php/CSRFGuard_2.0_Installation Click here] to view the installation instructions of the OWASP CSRFGuard 2.0 series.

== Road Map ==

[https://www.owasp.org/index.php/CSRF_Guard_2.2_Roadmap Click here] to view the road map for the latest development version of CSRFGuard. Please feel free to add your own change requests or send me patches/diffs!

==CSRF Testing Tool==

Check out the [http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRF Tester] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

==CSRF Prevention Cheat Sheet ==

Please see the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet OWASP CSRF Prevention Cheat Sheet] for more information on prevention.

==Feedback and Participation ==

We hope you find CSRFGuard useful. Please contribute back to the project by sending your comments, questions, and suggestions to OWASP. Thanks!

==Similar Projects==

There are a small number of other projects that implement the unique random request token concept similar to that of CSRFGuard. They are as follows:

:*http://www.owasp.org/index.php/PHP_CSRF_Guard
:*http://www.thespanner.co.uk/2007/10/19/jsck/
:*http://www.owasp.org/index.php/.Net_CSRF_Guard

==Donations==

The Open Web Application Security Project is purely an open-source community driven effort. As such, all projects and research efforts are contributed and maintained with an individual's ''spare time.'' If you have found this or any other project useful, please support OWASP with a [https://www.owasp.org/index.php/Contributions donation].

==Project Sponsors==

The OWASP CSRFGuard project is lead by Eric Sheridan (eric dot sheridan at owasp dot org) and sponsored by [http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif].

[[Category:OWASP_Validation_Project]]
[[Category:Java]]
[[Category:OWASP_Project|CSRFGuard Project]]
[[Category:OWASP_Java_Project]]

Category:OWASP CSRFTester Project

2009-10-23T15:36:14Z

Paul Petefish:

Testing for CSRF (OTG-SESS-005)

2009-10-23T15:26:09Z

Paul Petefish:

{{Template:OWASP Testing Guide v3}}

==Brief Summary==

[[CSRF]] is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is the administrator account, a CSRF attack can compromise the entire web application.

==Related Security Activities==

===Description of CSRF Vulnerabilities===

See the OWASP article on [[CSRF]] Vulnerabilities.

===How to Avoid CSRF Vulnerabilities===

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Guide to CSRF |Avoid CSRF]] Vulnerabilities.

===How to Review Code for CSRF Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues |Review Code for CSRF]] Vulnerabilities.

===How to Prevent CSRF Vulnerabilites===

See the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet OWASP CSRF Prevention Cheat Sheet] for prevention measures.

[[Category:Security Focus Area]]
__NOTOC__

==Description of the Issue==

CSRF relies on the following:

1) Web browser behavior regarding the handling of session-related information such as cookies and http authentication information;<br>
2) Knowledge of valid web application URLs on the side of the attacker;<br>
3) Application session management relying only on information which is known by the browser;<br>
4) Existence of HTML tags whose presence cause immediate access to an http[s] resource; for example the image tag ''img''.<br>

Points 1, 2, and 3 are essential for the vulnerability to be present, while point 4 is accessory and facilitates the actual exploitation, but is not strictly required.

Point 1) Browsers automatically send information which is used to identify a user session. Suppose ''site'' is a site hosting a web application, and the user ''victim'' has just authenticated himself to ''site''. In response, ''site'' sends ''victim'' a cookie which identifies requests sent by ''victim'' as belonging to ''victim’s'' authenticated session. Basically, once the browser receives the cookie set by ''site'', it will automatically send it along with any further requests directed to ''site''.

Point 2) If the application does not make use of session-related information in URLs, then it means that the application URLs, their parameters, and legitimate values may be identified (either by code analysis or by accessing the application and taking note of forms and URLs embedded in the HTML/JavaScript).

Point 3) By “known by the browser”, we mean information such as cookies, or http-based authentication information (such as Basic Authentication; NOT form-based authentication), which are stored by the browser and subsequently resent at each request directed towards an application area requesting that authentication. The vulnerabilities discussed next apply to applications which rely entirely on this kind of information to identify a user session.

Suppose, for simplicity's sake, to refer to GET-accessible URLs (though the discussion applies as well to POST requests). If ''victim'' has already authenticated himself, submitting another request causes the cookie to be automatically sent with it (see picture, where the user accesses an application on www.example.com).

<center>[[Image:session_riding.GIF]]</center>

The GET request could be originated in several different ways:

* by the user, who is using the actual web application;
* by the user, who types the URL directly in the browser;
* by the user, who follows a link (external to the application) pointing to the URL.

These invocations are indistinguishable by the application. In particular, the third may be quite dangerous. There are a number of techniques (and of vulnerabilities) which can disguise the real properties of a link. The link can be embedded in an email message, or appear in a malicious web site where the user is lured, i.e., the link appears in content hosted elsewhere (another web site, an HTML email message, etc.) and points to a resource of the application. If the user clicks on the link, since it was already authenticated by the web application on ''site'', the browser will issue a GET request to the web application, accompanied by authentication information (the session id cookie). This results in a valid operation performed on the web application – probably not what the user expects to happen! Think of a malicious link causing a fund transfer on a web banking application to appreciate the implications...

By using a tag such as ''img'', as specified in point 4 above, it is not even necessary that the user follows a particular link. Suppose the attacker sends the user an email inducing him to visit an URL referring to a page containing the following (oversimplified) HTML:

<pre>
<html><body>

...

<img src=”https://www.company.example/action” width=”0” height=”0”>

...

</body></html>
</pre>

What the browser will do when it displays this page is that it will try to display the specified zero-width (i.e., invisible) image as well. This results in a request being automatically sent to the web application hosted on ''site''. It is not important that the image URL does not refer to a proper image, its presence will trigger the request specified in the ''src'' field anyway; this happens provided that image download is not disabled in the browsers, which is a typical configuration since disabling images would cripple most web applications beyond usability.

The problem here is a consequence of the following facts:

* there are HTML tags whose appearance in a page result in automatic http request execution (''img'' being one of those);
* the browser has no way to tell that the resource referenced by ''img ''is not actually an image and is in fact not legitimate;
* image loading happens regardless of the location of the alleged image, i.e., the form and the image itself need not be located in the same host, not even in the same domain. While this is a very handy feature, it makes difficult to compartmentalize applications.

It is the fact that HTML content unrelated to the web application may refer components in the application, and the fact that the browser automatically composes a valid request towards the application, that allows such kind of attacks. As no standards are defined right now, there is no way to prohibit this behavior unless it is made impossible for the attacker to specify valid application URLs. This means that valid URLs must contain information related to the user session, which is supposedly not known to the attacker and therefore make the identification of such URLs impossible.

The problem might be even worse, since in integrated mail/browser environments simply displaying an email message containing the image would result in the execution of the request to the web application with the associated browser cookie.

Things may be obfuscated further, by referencing seemingly valid image URLs such as

<img src=”https://[attacker]/picture.gif” width=”0” height=”0”>

where [attacker] is a site controlled by the attacker, and by utilizing a redirect mechanism on http://[attacker]/picture.gif to http://[thirdparty]/action.

Cookies are not the only example involved in this kind of vulnerability. Web applications whose session information is entirely supplied by the browser are vulnerable too. This includes applications relying on HTTP authentication mechanisms alone, since the authentication information is known by the browser and is sent automatically upon each request. This DOES NOT include form-based authentication, which occurs just once and generates some form of session-related information (of course, in this case, such information is expressed simply as a cookie and can we fall back to one of the previous cases).

'''Sample scenario.'''

Let’s suppose that the victim is logged on to a firewall web management application. To log in, a user has to authenticate himself; subsequently, session information is stored in a cookie.

Let's suppose our firewall web management application has a function that allows an authenticated user to delete a rule specified by its positional number, or all the rules of the configuration if the user enters ‘*’ (quite a dangerous feature, but it will make the example more interesting). The delete page is shown next. Let’s suppose that the form – for the sake of simplicity – issues a GET request, which will be of the form

https://[target]/fwmgt/delete?rule=1

(to delete rule number one)

https://[target]/fwmgt/delete?rule=*

(to delete all rules).

The example is purposely quite naive, but shows in a simple way the dangers of CSRF.

<center>[[image:Session Riding Firewall Management.gif]]</center>

Therefore, if we enter the value ‘*’ and press the Delete button, the following GET request is submitted.

https://www.company.example/fwmgt/delete?rule=*

with the effect of deleting all firewall rules (and ending up in a possibly inconvenient situation...).

<center>[[image:Session Riding Firewall Management 2.gif]]</center>

Now, this is not the only possible scenario. The user might have accomplished the same results by manually submitting the URL https://[target]/fwmgt/delete?rule=*

or by following a link pointing, directly or via a redirection, to the above URL. Or, again, by accessing an HTML page with an embedded ''img'' tag pointing to the same URL.

In all of these cases, if the user is currently logged in the firewall management application, the request will succeed and will modify the configuration of the firewall.

One can imagine attacks targeting sensitive applications and making automatic auction bids, money transfers, orders, changing the configuration of critical software components, etc.

An interesting thing is that these vulnerabilities may be exercised behind a firewall; i.e., it is sufficient that the link being attacked be reachable by the victim (not directly by the attacker). In particular, it can be any Intranet web server; for example, the firewall management station mentioned before, which is unlikely to be exposed to the Internet. Imagine a CSRF attack targeting an application monitoring a nuclear power plant... Sounds far fetched? Probably, but it is a possibility.

Self-vulnerable applications, i.e., applications that are used both as attack vector and target (such as web mail applications), make things worse. If such an application is vulnerable, the user is obviously logged in when he reads a message containing a CSRF attack, that can target the web mail application and have it perform actions such as deleting messages, sending messages appearing as sent by the user, etc.

'''Countermeasures.'''

The following countermeasures are divided among recommendations to users and to developers.

<u>Users</u>

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating actions are:

* Logoff immediately after using a web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf freely the Internet; if you have to do both things at the same machine, do them with separate browsers.

Integrated HTML-enabled mail/browser, newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

<u>Developers</u>

Add session-related information to the URL. What makes the attack possible is the fact that the session is uniquely identified by the cookie, which is automatically sent by the browser. Having other session-specific information being generated at the URL level makes it difficult to the attacker to know the structure of URLs to attack.

Other countermeasures, while they do not resolve the issue, contribute to make it harder to exploit.

Use POST instead of GET. While POST requests may be simulated by means of JavaScript, they make it more complex to mount an attack. The same is true with intermediate confirmation pages (such as: “Are you sure you really want to do this?” type of pages). They can be bypassed by an attacker, although they will make their work a bit more complex. Therefore, do not rely solely on these measures to protect your application. Automatic logout mechanisms somewhat mitigate the exposure to these vulnerabilities, though it ultimately depends on the context (a user who works all day long on a vulnerable web banking application is obviously more at risk than a user who uses the same application occasionally).

==Black Box testing and example==

To test black box, you need to know URLs in the restricted (authenticated) area. If you possess valid credentials, you can assume both roles – the attacker and the victim. In this case, you know the URLs to be tested just by browsing around the application.

Otherwise, if you don’t have valid credentials available, you have to organize a real attack, and so induce a legitimate, logged in user into following an appropriate link. This may involve a substantial level of social engineering.

Either way, a test case can be constructed as follows:

* let ''u'' the URL being tested; for example, u = http://www.example.com/action
* build an html page containing the http request referencing URL u (specifying all relevant parameters; in the case of http GET this is straightforward, while to a POST request you need to resort to some Javascript);
* make sure that the valid user is logged on the application;
* induce him into following the link pointing to the to-be-tested URL (social engineering involved if you cannot impersonate the user yourself);
* observe the result, i.e. check if the web server executed the request.

==Gray Box testing and example==

Audit the application to ascertain if its session management is vulnerable. If session management relies only on client side values (information available to the browser), then the application is vulnerable. By “client side values” we mean cookies and HTTP authentication credentials (Basic Authentication and other forms of HTTP authentication; NOT form-based authentication, which is an application-level authentication). For an application to not be vulnerable, it must include session-related information in the URL, in a form of unidentifiable or unpredictable by the user ([3] uses the term ''secret'' to refer to this piece of information).

Resources accessible via HTTP GET requests are easily vulnerable, though POST requests can be automatized via Javascript and are vulnerable as well; therefore, the use of POST alone is not enough to correct the occurrence of CSRF vulnerabilities.

==References==
'''Whitepapers'''<br>
* This issue seems to get rediscovered from time to time, under different names. A history of these vulnerabilities has been reconstructed in: http://www.webappsec.org/lists/websecurity/archive/2005-05/msg00003.html
* Peter W: "Cross-Site Request Forgeries" - http://www.tux.org/~peterw/csrf.txt
* Thomas Schreiber: "Session Riding" - http://www.securenet.de/papers/Session_Riding.pdf
* Oldest known post - http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan
* Cross-site Request Forgery FAQ - http://www.cgisecurity.com/articles/csrf-faq.shtml

'''Tools'''<br>
* Currently there are no automated tools that can be used to test for the presence of CSRF vulnerabilities. However, you may use your favorite spider/crawler tools to acquire knowledge about the application structure and to identify the URLs to test.

Cross-Site Request Forgery (CSRF)

2009-10-23T15:23:40Z

Paul Petefish:

{{Template:Attack}}

[[Category:OWASP ASDR Project]]
<br>

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Overview==
CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.

==Related Security Activities==

===How to Review Code for CSRF Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues |Reviewing code for CSRF]] Vulnerabilities.

===How to Test for CSRF Vulnerabilities===

See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for CSRF (OWASP-SM-005) |Test for CSRF]] Vulnerabilities.

===How to Prevent CSRF Vulnerabilites===

See the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet OWASP CSRF Prevention Cheat Sheet] for prevention measures.

==Description==
Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.

For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request.

In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website.

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.

Synonyms: 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.

===Prevention measures that do '''NOT''' work===
;Using a secret cookie
:Remember that all cookies, even the ''secret'' ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

;Only accepting POST requests
:Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.


==Examples==

===How does the attack work?===
There are numerous ways in which an end-user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using bank.com. The request generated by Alice will look similar to the following:

POST <nowiki>http://bank.com/transfer.do</nowiki> HTTP/1.1
...
...
...
Content-Length: 19;

acct=BOB&amount=100

However, Maria notices that the same web application will execute the same transfer using URL parameters as follows:

GET <nowiki>http://bank.com/transfer.do?acct=BOB&amount=100</nowiki> HTTP/1.1

Maria now decides to exploit this web application vulnerability using Alice as her victim. Maria first constructs the following URL which will transfer $100,000 from Alice's account to her account:

<nowiki>http://bank.com/transfer.do?acct=MARIA&amount=100000</nowiki>

Now that her malicious request is generated, Maria must trick Alice into submitting the request. The most basic method is to send Alice an HTML email containing the following:

<nowiki><a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a></nowiki>

Assuming Alice is authenticated with the application when she clicks the link, the transfer of $100,000 to Maria's account will occur. However, Maria realizes that if Alice clicks the link, then Alice will notice that a transfer has occurred. Therefore, Maria decides to hide the attack in a zero-byte image:

<nowiki><img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="1" height="1" border="0"></nowiki>

If this image tag were included in the email, Alice would only see a little box indicating that the browser could not render the image. However, the browser ''will still'' submit the request to bank.com without any visual indication that the transfer has taken place.


==Related [[Attacks]]==
* [[Cross-site Scripting (XSS)]]


==Related [[Controls]]==
* Add a per-request nonce to URL and all forms in addition to the standard session. This is also referred to as "form keys". Many frameworks (ex, Drupal.org 4.7.4+) either have or are starting to include this type of protection "built-in" to every form so the programmer does not need to code this protection manually.
* TBD: Add a per-session nonce to URL and all forms
* TBD: Add a hash(session id, function name, server-side secret) to URL and all forms
* TBD: .NET - add session identifier to ViewState with MAC
* Checking HTTP referrer details can help mitigate the attack but does certainly not provide a bullet proof solution. By ensuring the HTTP posts have come from the original site means that the attacks from other sites will not function. However, if the CSRF attack was used in combination with XSS on the original site then this mechanism will not provide any protection. Furthermore, it is increasingly common for firewalls or browser plugins/settings to strip the referrer header, in which case legitimate requests would be denied.
* "Although cross-site request forgery is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session." -http://en.wikipedia.org/wiki/Cross-site_request_forgery#_note-1
* [[Tokenizing]]

==References==
* [http://www.cgisecurity.com/articles/csrf-faq.shtml The Cross-Site Request Forgery (CSRF/XSRF) FAQ]
: ''quote: "This paper serves as a living document for Cross-Site Request Forgery issues. This document will serve as a repository of information from existing papers, talks, and mailing list postings and will be updated as new information is discovered."''

* [[Testing for CSRF (OWASP-SM-005)|Testing for CSRF]]
: CSRF (aka Session riding) paper from the OWASP Testing Guide project (need to integrate)

* [http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 CSRF Vulnerability: A 'Sleeping Giant']
: Overview Paper

* [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf Client Side Protection against Session Riding]
: Martin Johns and Justus Winter's interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection - [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf PDF paper]

* [[:Category:OWASP_CSRFGuard_Project|OWASP CSRF Guard]]
: J2EE, .NET, and PHP Filters which append a unique request token to each form and link in the HTML response in order to provide universal coverage against CSRF throughout your entire application.

* [[:Category:OWASP CSRFTester Project|OWASP CSRF Tester]]
: The OWASP CSRFTester gives developers the ability to test their applications for CSRF flaws.

[[Category:Exploitation of Authentication]]
[[Category:Embedded Malicious Code]]
[[Category:Spoofing]]
[[Category: Attack]]

Cross-Site Request Forgery (CSRF)

2009-10-23T15:20:03Z

Paul Petefish:

{{Template:Attack}}

[[Category:OWASP ASDR Project]]
<br>

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Overview==
CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.

==Related Security Activities==

===How to Review Code for CSRF Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues |Reviewing code for CSRF]] Vulnerabilities.

===How to Test for CSRF Vulnerabilities===

See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for CSRF (OWASP-SM-005) |Test for CSRF]] Vulnerabilities.

==Description==
Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.

For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request.

In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website.

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.

Synonyms: 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.

===Prevention measures that do '''NOT''' work===
;Using a secret cookie
:Remember that all cookies, even the ''secret'' ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

;Only accepting POST requests
:Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.


==Examples==

===How does the attack work?===
There are numerous ways in which an end-user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using bank.com. The request generated by Alice will look similar to the following:

POST <nowiki>http://bank.com/transfer.do</nowiki> HTTP/1.1
...
...
...
Content-Length: 19;

acct=BOB&amount=100

However, Maria notices that the same web application will execute the same transfer using URL parameters as follows:

GET <nowiki>http://bank.com/transfer.do?acct=BOB&amount=100</nowiki> HTTP/1.1

Maria now decides to exploit this web application vulnerability using Alice as her victim. Maria first constructs the following URL which will transfer $100,000 from Alice's account to her account:

<nowiki>http://bank.com/transfer.do?acct=MARIA&amount=100000</nowiki>

Now that her malicious request is generated, Maria must trick Alice into submitting the request. The most basic method is to send Alice an HTML email containing the following:

<nowiki><a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a></nowiki>

Assuming Alice is authenticated with the application when she clicks the link, the transfer of $100,000 to Maria's account will occur. However, Maria realizes that if Alice clicks the link, then Alice will notice that a transfer has occurred. Therefore, Maria decides to hide the attack in a zero-byte image:

<nowiki><img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="1" height="1" border="0"></nowiki>

If this image tag were included in the email, Alice would only see a little box indicating that the browser could not render the image. However, the browser ''will still'' submit the request to bank.com without any visual indication that the transfer has taken place.


==Related [[Attacks]]==
* [[Cross-site Scripting (XSS)]]


==Related [[Controls]]==
* Add a per-request nonce to URL and all forms in addition to the standard session. This is also referred to as "form keys". Many frameworks (ex, Drupal.org 4.7.4+) either have or are starting to include this type of protection "built-in" to every form so the programmer does not need to code this protection manually.
* TBD: Add a per-session nonce to URL and all forms
* TBD: Add a hash(session id, function name, server-side secret) to URL and all forms
* TBD: .NET - add session identifier to ViewState with MAC
* Checking HTTP referrer details can help mitigate the attack but does certainly not provide a bullet proof solution. By ensuring the HTTP posts have come from the original site means that the attacks from other sites will not function. However, if the CSRF attack was used in combination with XSS on the original site then this mechanism will not provide any protection. Furthermore, it is increasingly common for firewalls or browser plugins/settings to strip the referrer header, in which case legitimate requests would be denied.
* "Although cross-site request forgery is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session." -http://en.wikipedia.org/wiki/Cross-site_request_forgery#_note-1
* [[Tokenizing]]

==References==
* [http://www.cgisecurity.com/articles/csrf-faq.shtml The Cross-Site Request Forgery (CSRF/XSRF) FAQ]
: ''quote: "This paper serves as a living document for Cross-Site Request Forgery issues. This document will serve as a repository of information from existing papers, talks, and mailing list postings and will be updated as new information is discovered."''

* [[Testing for CSRF (OWASP-SM-005)|Testing for CSRF]]
: CSRF (aka Session riding) paper from the OWASP Testing Guide project (need to integrate)

* [http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 CSRF Vulnerability: A 'Sleeping Giant']
: Overview Paper

* [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf Client Side Protection against Session Riding]
: Martin Johns and Justus Winter's interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection - [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf PDF paper]

* [[:Category:OWASP_CSRFGuard_Project|OWASP CSRF Guard]]
: J2EE, .NET, and PHP Filters which append a unique request token to each form and link in the HTML response in order to provide universal coverage against CSRF throughout your entire application.

* [[:Category:OWASP CSRFTester Project|OWASP CSRF Tester]]
: The OWASP CSRFTester gives developers the ability to test their applications for CSRF flaws.

* [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet OWASP CSRF Prevention Cheat Sheet]
: The CSRF Prevention Cheat Sheet discusses in-depth prevention measures.

[[Category:Exploitation of Authentication]]
[[Category:Embedded Malicious Code]]
[[Category:Spoofing]]
[[Category: Attack]]

Category:OWASP CSRFGuard Project

2009-10-23T15:04:06Z

Paul Petefish:

==Overview==

Just when developers are starting to run in circles over [[Cross Site Scripting]], the [http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 'sleeping giant'] awakes for yet another web-catastrophe. [[Cross-Site Request Forgery]] (CSRF) is an attack whereby the victim is tricked into loading information from or submitting information to a web application for which they are currently authenticated. The problem is that the web application has no means of verifying the integrity of the request. The OWASP CSRFGuard Project attempts to address this issue through the use of unique request tokens.

[http://www.owasp.org/index.php/How_CSRFGuard_Works Click here] for more information regarding the design and implementation of CSRFGuard.

==License==

CSRFGuard is offered under the [http://www.gnu.org/copyleft/lesser.html LGPL]. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.

== News ==

'''13:35, 13 June 2008 (EDT) OWASP CSRFGuard 2.2 Beta Released!'''

In my spare time, I had been working on several minor updates to the OWASP CSRFGuard 2.0 release. Several of these updates address bugs that were identified in the previous release. Currently, I am spending a significant amount of time working on internal Aspect Security projects and have not had enough time to complete the release as I had wanted. One particular area that needs work is the inclusion of automated JUnit test cases. Instead of leaving the source lay untouched on my laptop, I've decided to make it available for people to test. Although this release is officially "Beta", it is very stable and '''developers are encouraged to consider testing and upgrading to the latest version'''. The reason for this push is that there are a couple of bugs that were never caught in 2.0. More information regarding the updates to 2.2 Beta can be found [http://www.owasp.org/index.php/CSRFGuard_2.2_ChangeLog here].

== Downloads ==

=== Version 1===

[http://www.owasp.org/index.php/Image:CSRF_Guard.zip Click here] to download the latest version of the OWASP CSRFGuard 1.x series.

=== Version 2===

[http://www.owasp.org/index.php/Image:OWASP-CSRFGuard-2.0.jar Click here] to download the latest OWASP CSRFGuard 2.0 binary.

[http://www.owasp.org/index.php/Image:OWASP_CSRFGuard-2.0-src.zip Click here] to download the latest OWASP CSRFGuard 2.0 source, binary, and sample configuration files '''(Recommended)'''.

[http://www.owasp.org/images/c/c9/CSRF_DangerDetectionDefenses.ppt Click here] to download the author's presentation at the 2007 OWASP conference in San Jose about the dangers of CSRF and a brief description of both CSRF Guard and CSRF Tester.

=== Version 2.2 Beta ===

[http://www.owasp.org/index.php/Image:OWASP-CSRFGuard-2.2-dist.jar Click here] to download the latest OWASP CSRFGuard 2.2 binary.

[http://www.owasp.org/index.php/Image:OWASP-CSRFGuard-2.2-src.zip Click here] to download the latest OWASP CSRFGuard 2.2 bundle which consists of source, binary, and sample configuration files. This includes the CSRFGuard properties file, ant build/deploy script, as well as the JSP tag definition '''(Recommended)'''.

[http://www.owasp.org/index.php/Image:OWASP-CSRFGuard-TestApp-2.2-src.zip Click here] to download a sample web application that makes use of OWASP CSRFGuard 2.2. This version comes with the CSRFGuard binary in WEB-INF/lib but it is not guaranteed to be the latest version. Replace it with the download above. The WebContent folder contains several JSP files that were used during testing. One file, "tags.jsp", shows how to use the custom JSP tag to insert the token.

[http://www.owasp.org/index.php/CSRFGuard_2.2_ChangeLog Click here] for a detailed change list of the latest version.

[http://www.owasp.org/index.php/CSRFGuard_2.2_Configuration_Manual Click here] for the OWASP CSRFGuard configuration manual.

[http://www.owasp.org/index.php/CSRFGuard_2.2_Installation Click here] for OWASP CSRFGuard installation instructions.

[http://www.owasp.org/index.php/CSRFGuard_2.2_Tag_Usage Click here] for OWASP CSRFGuard tag library usage instructions.

== Installation Instructions ==

[[CSRFGuard 1.x Installation|Click here]] to view the installation instructions of the OWASP CSRFGuard 1.0 series.

[http://www.owasp.org/index.php/CSRFGuard_2.0_Installation Click here] to view the installation instructions of the OWASP CSRFGuard 2.0 series.

== Road Map ==

[https://www.owasp.org/index.php/CSRF_Guard_2.2_Roadmap Click here] to view the road map for the latest development version of CSRFGuard. Please feel free to add your own change requests or send me patches/diffs!

==CSRF Testing Tool==

Check out the [http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRF Tester] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

==CSRF Prevention Cheat Sheet ==

Please see the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet] for more information on prevention.

==Feedback and Participation ==

We hope you find CSRFGuard useful. Please contribute back to the project by sending your comments, questions, and suggestions to OWASP. Thanks!

==Similar Projects==

There are a small number of other projects that implement the unique random request token concept similar to that of CSRFGuard. They are as follows:

:*http://www.owasp.org/index.php/PHP_CSRF_Guard
:*http://www.thespanner.co.uk/2007/10/19/jsck/
:*http://www.owasp.org/index.php/.Net_CSRF_Guard

==Donations==

The Open Web Application Security Project is purely an open-source community driven effort. As such, all projects and research efforts are contributed and maintained with an individual's ''spare time.'' If you have found this or any other project useful, please support OWASP with a [https://www.owasp.org/index.php/Contributions donation].

==Project Sponsors==

The OWASP CSRFGuard project is lead by Eric Sheridan (eric dot sheridan at owasp dot org) and sponsored by [http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif].

[[Category:OWASP_Validation_Project]]
[[Category:Java]]
[[Category:OWASP_Project|CSRFGuard Project]]
[[Category:OWASP_Java_Project]]

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-20T15:15:53Z

Paul Petefish:

= Introduction =

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 that the user is currently authenticated to. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the user's context.

A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is an administrator account, a CSRF attack can compromise the entire Web application. The sites that are more likely to be attacked are community Websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). This attack can happen even if the user is logged into a Web site using strong encryption (HTTPS).

Utilizing social engineering, an attacker will 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.

In affect, CSRF attacks are used by an attacker to make a target system perform a function (funds Transfer, form submission etc.) via the target's browser without knowledge of the target user, at least until the unauthorized function has been committed.

For more information on CSRF, please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

= Prevention =

== Token Based ==

The most common defense for CSRF is to append challenge tokens to each sensitive request. These challenge tokens must be associated with the user's session. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user. The following describes how to incorporate challenge tokens:

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user), the application should include a hidden input tag query parameter with a name such as CSRFToken. It is important to note that the CSRFToken should not be included in the URL or in URL parameters as it may be leaked. The CSRFToken should have a value that is a randomly generated such as a 256-bit hash that has been base 64 encoded.

<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTVi
MGYwMGEwOA==">
…
</form>

For each request, this token only needs to be randomly generated once. After the initial random generation, the token value is stored in a session specific table mapping request names to validation tokens. When a request is performed by the user, before the request is executed the submitted CSRFToken has it's value verified by comparing the provided token to the value stored in the mapping table for this request. If there is no value in the table for this request name, or if the value provided does not match the value in the table exactly, then the request should be aborted and the event can be logged as a potential security incident.

The request name should be different for each request. The CSRFToken must be strictly protected. For example, an application that does not use SSL or passes the token through a URL parameter will result in the CSRFToken being leaked.

=== 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.

To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (This property must be set in the Page.Init event)

protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }

The following keys the Viewstate to an individual using a unique value of your choice.

(Page.ViewStateUserKey)

This must be applied in Page_Init because the key has to be provided to ASP.NET before Viewstate is loaded. This option has been available since ASP.NET 1.1.

However, there are [http://keepitlocked.net/archive/2008/05/29/viewstateuserkey-doesn-t-prevent-cross-site-request-forgery.aspx limitations] on this mechanism. Such as, ViewState MACs are only checked on POSTback, so any other application requests not using postbacks will happily allow CSRF.

=== Double Submit Cookies ===

Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request. First as a traditional header value, and again as a hidden form value.

When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. 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 the form, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.

[http://directwebremoting.org Direct Web Remoting (DWR)] Java library version 2.0 has CSRF protection built in as it implements the double cookie submission transparently.

=== Prevention Frameworks ===

There are CSRF prevention modules available for J2EE, .Net, and PHP.

[[:Category:OWASP_CSRFGuard_Project | OWASP CSRF Guard (For Java)]]

The OWASP CSRFGuard Project makes use of a unique per-session token verification pattern using a JavaEE filter to mitigate the risk of CSRF attacks. When an HttpSession is first instantiated, CSRFGuard will generate a cryptographically random token using the SecureRandom class to be stored in the session.

CSRFGuard is a "reference implementation". Developers are encouraged to leverage more tightly integrated solutions for performance (ex: speed of parsing HTML) and technical (ex: AJAX requests) challenges.

'''Similar Projects'''

CSRFGuard has been implemented in other languages besides Java. They are:

*[[PHP CSRF Guard]]
*[[.Net CSRF Guard]]

== Challenge-Response ==

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

*CAPTCHA
*Re-Authentication (password)
*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.

= Prevention Measures That Do NOT Work =

'''Using a Secret Cookie'''

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

'''Only Accepting POST Requests'''

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in an attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks the form will do something else.

'''Checking Referer Header'''

An attacker can easily block the sending of the Referer header, and the HTTP RFC’s make it clear that this header is optional. Browsers also omit the Referer header when they are being used over SSL.

'''Multi-Step Transactions'''

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacker can predict or deduce each step of the completed transaction, then CSRF is possible.

'''URL Rewriting'''

This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user’s credential is exposed over the URL.

= Client/User Prevention =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating include:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf the Internet freely (tabbed browsing).

Integrated HTML-enabled mail/browser and newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= No Cross-Site Scripting (XSS) Vulnerabilities =

Cross-Site Scripting is not necessary for CSRF to work. However, Cross-Site Scripting flaws can be used to defeat most token based CSRF defenses, since a malicious XSS script can simply read the site generated token from the response, and include that token with a forged request. This technique is exactly how the [http://en.wikipedia.org/wiki/Samy_(XSS) 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 re-authentication or one-time passwords. It is imperative that no XSS vulnerabilities are present to ensure that CSRF defenses can't be circumvented. Please see the OWASP [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | XSS Prevention Cheat Sheet]] for detailed guidance on how to prevent XSS flaws.

= Related Articles =

'''Cross-Site Request Forgery (CSRF)'''

For more information on CSRF please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

'''How to Review Code for CSRF Vulnerabilities'''

See the [[:Category:OWASP_Code_Review_Project | OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues]].

'''How to Test for CSRF Vulnerabilities'''

See the [[:Category:OWASP_Testing_Project | OWASP Testing Guide]] article on how to [[Testing_for_CSRF_(OWASP-SM-005) | Test for CSRF Vulnerabilities]].

'''CSRF Testing Tool'''

Check out the [[:Category:OWASP_CSRFTester_Project | OWASP CSRF Tester]] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

'''Other Articles in the OWASP Prevention Cheat Sheet Series'''

* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]
* [[SQL Injection Prevention Cheat Sheet]]
* [[Transport Layer Protection Cheat Sheet]]

= References =

[http://www.isecpartners.com/files/XSRF_Paper_0.pdf Cross Site Reference Forgery: An introduction to a common web application weakness]

[http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf Cross-Site Request Forgeries: Exploitation and Prevention]

= Authors and Primary Editors =

Paul Petefish - paulpetefish@solutionary.com

Eric Sheridan - eric.sheridan@aspectsecurity.com

Dave Wichers - dave.wichers@aspectsecurity.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-20T13:57:06Z

Paul Petefish:

= Introduction =

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 that the user is currently authenticated to. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the user's context.

A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is an administrator account, a CSRF attack can compromise the entire Web application. The sites that are more likely to be attacked are community Websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). This attack can happen even if the user is logged into a Web site using strong encryption (HTTPS).

Utilizing social engineering, an attacker will 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.

In affect, CSRF attacks are used by an attacker to make a target system perform a function (funds Transfer, form submission etc.) via the target's browser without knowledge of the target user, at least until the unauthorized function has been committed.

For more information on CSRF, please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

= Prevention =

== Token Based ==

The most common defense for CSRF is to append challenge tokens to each sensitive request. These challenge tokens must be associated with the user's session. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user. The following describes how to incorporate challenge tokens:

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user), the application should include a hidden input tag query parameter with a name such as CSRFToken. It is important to note that the CSRFToken should not be included in the URL or in URL parameters as it may be leaked. The CSRFToken should have a value that is a randomly generated such as a 256-bit hash that has been base 64 encoded.

<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTVi
MGYwMGEwOA==">
…
</form>

For each request, this token only needs to be randomly generated once. After the initial random generation, the token value is stored in a session specific table mapping request names to validation tokens. When a request is performed by the user, before the request is executed the submitted CSRFToken has it's value verified by comparing the provided token to the value stored in the mapping table for this request. If there is no value in the table for this request name, or if the value provided does not match the value in the table exactly, then the request should be aborted and the event can be logged as a potential security incident.

The request name should be different for each request. The CSRFToken must be strictly protected. For example, an application that does not use SSL or passes the token through a URL parameter will result in the CSRFToken being leaked.

=== 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.

To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (This property must be set in the Page.Init event)

protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }

The following keys the Viewstate to an individual using a unique value of your choice.

(Page.ViewStateUserKey)

This must be applied in Page_Init because the key has to be provided to ASP.NET before Viewstate is loaded. This option has been available since ASP.NET 1.1.

However, there are [http://keepitlocked.net/archive/2008/05/29/viewstateuserkey-doesn-t-prevent-cross-site-request-forgery.aspx limitations] on this mechanism. Such as, ViewState MACs are only checked on POSTback, so any other application requests not using postbacks will happily allow CSRF.

=== Prevention Frameworks ===

There are CSRF prevention modules available for J2EE, .Net, and PHP.

[[:Category:OWASP_CSRFGuard_Project | OWASP CSRF Guard (For Java)]]

The OWASP CSRFGuard Project makes use of a unique per-session token verification pattern using a JavaEE filter to mitigate the risk of CSRF attacks. When an HttpSession is first instantiated, CSRFGuard will generate a cryptographically random token using the SecureRandom class to be stored in the session.

CSRFGuard is a "reference implementation". Developers are encouraged to leverage more tightly integrated solutions for performance (ex: speed of parsing HTML) and technical (ex: AJAX requests) challenges.

'''Similar Projects'''

CSRFGuard has been implemented in other languages besides Java. They are:

*[[PHP CSRF Guard]]
*[[.Net CSRF Guard]]

== Challenge-Response ==

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

*CAPTCHA
*Re-Authentication (password)
*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.

== Double Submit Cookies ==

Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request. First as a traditional header value, and again as a hidden form value.

When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. 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 the form, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.

[http://directwebremoting.org Direct Web Remoting (DWR)] Java library version 2.0 has CSRF protection built in as it implements the double cookie submission transparently.

= Prevention Measures That Do NOT Work =

'''Using a Secret Cookie'''

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

'''Only Accepting POST Requests'''

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in an attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks the form will do something else.

'''Checking Referer Header'''

An attacker can easily block the sending of the Referer header, and the HTTP RFC’s make it clear that this header is optional. Browsers also omit the Referer header when they are being used over SSL.

'''Multi-Step Transactions'''

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacker can predict or deduce each step of the completed transaction, then CSRF is possible.

'''URL Rewriting'''

This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user’s credential is exposed over the URL.

= Client/User Prevention =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating include:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf the Internet freely (tabbed browsing).

Integrated HTML-enabled mail/browser and newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= No Cross-Site Scripting (XSS) Vulnerabilities =

Cross-Site Scripting is not necessary for CSRF to work. However, Cross-Site Scripting flaws can be used to defeat most token based CSRF defenses, since a malicious XSS script can simply read the site generated token from the response, and include that token with a forged request. This technique is exactly how the [http://en.wikipedia.org/wiki/Samy_(XSS) 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 re-authentication or one-time passwords. It is imperative that no XSS vulnerabilities are present to ensure that CSRF defenses can't be circumvented. Please see the OWASP [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | XSS Prevention Cheat Sheet]] for detailed guidance on how to prevent XSS flaws.

= Related Articles =

'''Cross-Site Request Forgery (CSRF)'''

For more information on CSRF please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

'''How to Review Code for CSRF Vulnerabilities'''

See the [[:Category:OWASP_Code_Review_Project | OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues]].

'''How to Test for CSRF Vulnerabilities'''

See the [[:Category:OWASP_Testing_Project | OWASP Testing Guide]] article on how to [[Testing_for_CSRF_(OWASP-SM-005) | Test for CSRF Vulnerabilities]].

'''CSRF Testing Tool'''

Check out the [[:Category:OWASP_CSRFTester_Project | OWASP CSRF Tester]] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

'''Other Articles in the OWASP Prevention Cheat Sheet Series'''

* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]
* [[SQL Injection Prevention Cheat Sheet]]
* [[Transport Layer Protection Cheat Sheet]]

= References =

[http://www.isecpartners.com/files/XSRF_Paper_0.pdf Cross Site Reference Forgery: An introduction to a common web application weakness]

[http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf Cross-Site Request Forgeries: Exploitation and Prevention]

= Authors and Primary Editors =

Paul Petefish - paulpetefish@solutionary.com

Eric Sheridan - eric.sheridan@aspectsecurity.com

Dave Wichers - dave.wichers@aspectsecurity.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-20T13:52:54Z

Paul Petefish:

= Introduction =

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 that the user is currently authenticated to. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the user's context.

A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is an administrator account, a CSRF attack can compromise the entire Web application. The sites that are more likely to be attacked are community Websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). This attack can happen even if the user is logged into a Web site using strong encryption (HTTPS).

Utilizing social engineering, an attacker will 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.

In affect, CSRF attacks are used by an attacker to make a target system perform a function (funds Transfer, form submission etc.) via the target's browser without knowledge of the target user, at least until the unauthorized function has been committed.

For more information on CSRF, please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

= Prevention =

== Token Based ==

The most common defense for CSRF is to append challenge tokens to each sensitive request. These challenge tokens must be associated with the user's session. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user. The following describes how to incorporate challenge tokens:

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user), the application should include a hidden input tag query parameter with a name such as CSRFToken. It is important to note that the CSRFToken should not be included in the URL or in URL parameters as it may be leaked. The CSRFToken should have a value that is a randomly generated such as a 256-bit hash that has been base 64 encoded.

<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTVi
MGYwMGEwOA==">
…
</form>

For each request, this token only needs to be randomly generated once. After the initial random generation, the token value is stored in a session specific table mapping request names to validation tokens. When a request is performed by the user, before the request is executed the submitted CSRFToken has it's value verified by comparing the provided token to the value stored in the mapping table for this request. If there is no value in the table for this request name, or if the value provided does not match the value in the table exactly, then the request should be aborted and the event can be logged as a potential security incident.

The request name should be different for each request. The CSRFToken must be strictly protected. For example, an application that does not use SSL or passes the token through a URL parameter will result in the CSRFToken being leaked.

=== 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.

To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (This property must be set in the Page.Init event)

protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }

The following keys the Viewstate to an individual using a unique value of your choice.

(Page.ViewStateUserKey)

This must be applied in Page_Init because the key has to be provided to ASP.NET before Viewstate is loaded. This option has been available since ASP.NET 1.1.

However, there are [http://keepitlocked.net/archive/2008/05/29/viewstateuserkey-doesn-t-prevent-cross-site-request-forgery.aspx limitations] on this mechanism. Such as, ViewState MACs are only checked on POSTback, so any other application requests not using postbacks will happily allow CSRF.

=== Prevention Frameworks ===

There are CSRF prevention modules available for J2EE, .Net, and PHP.

[[:Category:OWASP_CSRFGuard_Project | OWASP CSRF Guard (For Java)]]

The OWASP CSRFGuard Project makes use of a unique per-session token verification pattern using a JavaEE filter to mitigate the risk of CSRF attacks. When an HttpSession is first instantiated, CSRFGuard will generate a cryptographically random token using the SecureRandom class to be stored in the session.

CSRFGuard is a "reference implementation". Developers are encouraged to leverage more tightly integrated solutions for performance (ex: speed of parsing HTML) and technical (ex: AJAX requests) challenges.

'''Similar Projects'''

CSRFGuard has been implemented in other languages besides Java. They are:

*[[PHP CSRF Guard]]
*[[.Net CSRF Guard]]

== Challenge-Response ==

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

*CAPTCHA
*Re-Authentication (password)
*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.

== Double Submit Cookies ==

Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request. First as a traditional header value, and again as a hidden form value.

When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. 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 the form, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.

[http://directwebremoting.org Direct Web Remoting (DWR)] version 2.0 has CSRF protection built in as it implements the double cookie submission transparently.

= Prevention Measures That Do NOT Work =

'''Using a Secret Cookie'''

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

'''Only Accepting POST Requests'''

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in an attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks the form will do something else.

'''Checking Referer Header'''

An attacker can easily block the sending of the Referer header, and the HTTP RFC’s make it clear that this header is optional. Browsers also omit the Referer header when they are being used over SSL.

'''Multi-Step Transactions'''

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacker can predict or deduce each step of the completed transaction, then CSRF is possible.

'''URL Rewriting'''

This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user’s credential is exposed over the URL.

= Client/User Prevention =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating include:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf the Internet freely (tabbed browsing).

Integrated HTML-enabled mail/browser and newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= No Cross-Site Scripting (XSS) Vulnerabilities =

Cross-Site Scripting is not necessary for CSRF to work. However, Cross-Site Scripting flaws can be used to defeat most token based CSRF defenses, since a malicious XSS script can simply read the site generated token from the response, and include that token with a forged request. This technique is exactly how the [http://en.wikipedia.org/wiki/Samy_(XSS) 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 re-authentication or one-time passwords. It is imperative that no XSS vulnerabilities are present to ensure that CSRF defenses can't be circumvented. Please see the OWASP [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | XSS Prevention Cheat Sheet]] for detailed guidance on how to prevent XSS flaws.

= Related Articles =

'''Cross-Site Request Forgery (CSRF)'''

For more information on CSRF please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

'''How to Review Code for CSRF Vulnerabilities'''

See the [[:Category:OWASP_Code_Review_Project | OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues]].

'''How to Test for CSRF Vulnerabilities'''

See the [[:Category:OWASP_Testing_Project | OWASP Testing Guide]] article on how to [[Testing_for_CSRF_(OWASP-SM-005) | Test for CSRF Vulnerabilities]].

'''CSRF Testing Tool'''

Check out the [[:Category:OWASP_CSRFTester_Project | OWASP CSRF Tester]] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

'''Other Articles in the OWASP Prevention Cheat Sheet Series'''

* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]
* [[SQL Injection Prevention Cheat Sheet]]
* [[Transport Layer Protection Cheat Sheet]]

= References =

[http://www.isecpartners.com/files/XSRF_Paper_0.pdf Cross Site Reference Forgery: An introduction to a common web application weakness]

[http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf Cross-Site Request Forgeries: Exploitation and Prevention]

= Authors and Primary Editors =

Paul Petefish - paulpetefish@solutionary.com

Eric Sheridan - eric.sheridan@aspectsecurity.com

Dave Wichers - dave.wichers@aspectsecurity.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-20T13:34:42Z

Paul Petefish:

= Introduction =

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 that the user is currently authenticated to. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the user's context.

A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is an administrator account, a CSRF attack can compromise the entire Web application. The sites that are more likely to be attacked are community Websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). This attack can happen even if the user is logged into a Web site using strong encryption (HTTPS).

Utilizing social engineering, an attacker will 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.

In affect, CSRF attacks are used by an attacker to make a target system perform a function (funds Transfer, form submission etc.) via the target's browser without knowledge of the target user, at least until the unauthorized function has been committed.

For more information on CSRF, please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

= Prevention =

== Token Based ==

The most common defense for CSRF is to append challenge tokens to each sensitive request. These challenge tokens must be associated with the user's session. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user. The following describes how to incorporate challenge tokens:

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user), the application should include a hidden input tag query parameter with a name such as CSRFToken. It is important to note that the CSRFToken should not be included in the URL or in URL parameters as it may be leaked. The CSRFToken should have a value that is a randomly generated such as a 256-bit hash that has been base 64 encoded.

<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTVi
MGYwMGEwOA==">
…
</form>

For each request, this token only needs to be randomly generated once. After the initial random generation, the token value is stored in a session specific table mapping request names to validation tokens. When a request is performed by the user, before the request is executed the submitted CSRFToken has it's value verified by comparing the provided token to the value stored in the mapping table for this request. If there is no value in the table for this request name, or if the value provided does not match the value in the table exactly, then the request should be aborted and the event can be logged as a potential security incident.

The request name should be different for each request. The CSRFToken must be strictly protected. For example, an application that does not use SSL or passes the token through a URL parameter will result in the CSRFToken being leaked.

=== 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.

To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (This property must be set in the Page.Init event)

protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }

The following keys the Viewstate to an individual using a unique value of your choice.

(Page.ViewStateUserKey)

This must be applied in Page_Init because the key has to be provided to ASP.NET before Viewstate is loaded. This option has been available since ASP.NET 1.1.

=== Prevention Frameworks ===

There are CSRF prevention modules available for J2EE, .Net, and PHP.

[[:Category:OWASP_CSRFGuard_Project | OWASP CSRF Guard (For Java)]]

The OWASP CSRFGuard Project makes use of a unique per-session token verification pattern using a JavaEE filter to mitigate the risk of CSRF attacks. When an HttpSession is first instantiated, CSRFGuard will generate a cryptographically random token using the SecureRandom class to be stored in the session.

CSRFGuard is a "reference implementation". Developers are encouraged to leverage more tightly integrated solutions for performance (ex: speed of parsing HTML) and technical (ex: AJAX requests) challenges.

'''Similar Projects'''

CSRFGuard has been implemented in other languages besides Java. They are:

*[[PHP CSRF Guard]]
*[[.Net CSRF Guard]]

== Challenge-Response ==

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

*CAPTCHA
*Re-Authentication (password)
*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.

== Double Submit Cookies ==

Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request. First as a traditional header value, and again as a hidden form value.

When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. 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 the form, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.

[http://directwebremoting.org Direct Web Remoting (DWR)] version 2.0 has CSRF protection built in as it implements the double cookie submission transparently.

= Prevention Measures That Do NOT Work =

'''Using a Secret Cookie'''

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

'''Only Accepting POST Requests'''

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in an attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks the form will do something else.

'''Checking Referer Header'''

An attacker can easily block the sending of the Referer header, and the HTTP RFC’s make it clear that this header is optional. Browsers also omit the Referer header when they are being used over SSL.

'''Multi-Step Transactions'''

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacker can predict or deduce each step of the completed transaction, then CSRF is possible.

'''URL Rewriting'''

This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user’s credential is exposed over the URL.

= Client/User Prevention =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating include:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf the Internet freely (tabbed browsing).

Integrated HTML-enabled mail/browser and newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= No Cross-Site Scripting (XSS) Vulnerabilities =

Cross-Site Scripting is not necessary for CSRF to work. However, Cross-Site Scripting flaws can be used to defeat most token based CSRF defenses, since a malicious XSS script can simply read the site generated token from the response, and include that token with a forged request. This technique is exactly how the [http://en.wikipedia.org/wiki/Samy_(XSS) 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 re-authentication or one-time passwords. It is imperative that no XSS vulnerabilities are present to ensure that CSRF defenses can't be circumvented. Please see the OWASP [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | XSS Prevention Cheat Sheet]] for detailed guidance on how to prevent XSS flaws.

= Related Articles =

'''Cross-Site Request Forgery (CSRF)'''

For more information on CSRF please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

'''How to Review Code for CSRF Vulnerabilities'''

See the [[:Category:OWASP_Code_Review_Project | OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues]].

'''How to Test for CSRF Vulnerabilities'''

See the [[:Category:OWASP_Testing_Project | OWASP Testing Guide]] article on how to [[Testing_for_CSRF_(OWASP-SM-005) | Test for CSRF Vulnerabilities]].

'''CSRF Testing Tool'''

Check out the [[:Category:OWASP_CSRFTester_Project | OWASP CSRF Tester]] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

'''Other Articles in the OWASP Prevention Cheat Sheet Series'''

* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]
* [[SQL Injection Prevention Cheat Sheet]]
* [[Transport Layer Protection Cheat Sheet]]

= References =

[http://www.isecpartners.com/files/XSRF_Paper_0.pdf Cross Site Reference Forgery: An introduction to a common web application weakness]

[http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf Cross-Site Request Forgeries: Exploitation and Prevention]

= Authors and Primary Editors =

Paul Petefish - paulpetefish@solutionary.com

Eric Sheridan - eric.sheridan@aspectsecurity.com

Dave Wichers - dave.wichers@aspectsecurity.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-20T13:16:43Z

Paul Petefish:

= Introduction =

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 that the user is currently authenticated to. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the user's context.

A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is an administrator account, a CSRF attack can compromise the entire Web application. The sites that are more likely to be attacked are community Websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). This attack can happen even if the user is logged into a Web site using strong encryption (HTTPS).

Utilizing social engineering, an attacker will 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.

In affect, CSRF attacks are used by an attacker to make a target system perform a function (funds Transfer, form submission etc.) via the target's browser without knowledge of the target user, at least until the unauthorized function has been committed.

For more information on CSRF, please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

= Prevention =

== Token Based ==

The most common defense for CSRF is to append challenge tokens to each sensitive request. These challenge tokens must be associated with the user's session. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user. The following describes how to incorporate challenge tokens:

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user), the application should include a hidden input tag query parameter with a name such as CSRFToken. It is important to note that the CSRFToken should not be included in the URL or in URL parameters as it may be leaked. The CSRFToken should have a value that is a randomly generated such as a 256-bit hash that has been base 64 encoded.

<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTVi
MGYwMGEwOA==">
…
</form>

For each request, this token only needs to be randomly generated once. After the initial random generation, the token value is stored in a session specific table mapping request names to validation tokens. When a request is performed by the user, before the request is executed the submitted CSRFToken has it's value verified by comparing the provided token to the value stored in the mapping table for this request. If there is no value in the table for this request name, or if the value provided does not match the value in the table exactly, then the request should be aborted and the event can be logged as a potential security incident.

The request name should be different for each request. The CSRFToken must be strictly protected. For example, an application that does not use SSL or passes the token through a URL parameter will result in the CSRFToken being leaked.

=== 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.

To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (This property must be set in the Page.Init event)

protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }

The following keys the Viewstate to an individual using a unique value of your choice.

(Page.ViewStateUserKey)

This must be applied in Page_Init because the key has to be provided to ASP.NET before Viewstate is loaded. This option has been available since ASP.NET 1.1.

=== Prevention Frameworks ===

There are CSRF prevention modules available for J2EE, .Net, and PHP.

[[:Category:OWASP_CSRFGuard_Project | OWASP CSRF Guard (For Java)]]

The OWASP CSRFGuard Project makes use of a unique per-session token verification pattern using a JavaEE filter to mitigate the risk of CSRF attacks. When an HttpSession is first instantiated, CSRFGuard will generate a cryptographically random token using the SecureRandom class to be stored in the session.

CSRFGuard is a "reference implementation". Developers are encouraged to leverage more tightly integrated solutions for performance (ex: speed of parsing HTML) and technical (ex: AJAX requests) challenges.

'''Similar Projects'''

CSRFGuard has been implemented in other languages besides Java. They are:

*[[PHP CSRF Guard]]
*[[.Net CSRF Guard]]

== Challenge-Response ==

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

*CAPTCHA
*Re-Authentication (password)
*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.

== Double Submit Cookies ==

Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request. First as a traditional header value, and again as a hidden form value.

When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. 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 the form, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.

[http://directwebremoting.org Direct Web Remoting (DWR)] version 2.0 has CSRF protection built in as it implements the double cookie submission transparently.

= Prevention Measures That Do NOT Work =

'''Using a Secret Cookie'''

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

'''Only Accepting POST Requests'''

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in an attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks the form will do something else.

'''Checking Referer Header'''

An attacker can easily block the sending of the Referer header, and the HTTP RFC’s make it clear that this header is optional. Browsers also omit the Referer header when they are being used over SSL.

'''Multi-Step Transactions'''

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacker can predict or deduce each step of the completed transaction, then CSRF is possible.

'''URL Rewriting'''

This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user’s credential is exposed over the URL.

= Client/User Prevention =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating include:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf the Internet freely (tabbed browsing).

Integrated HTML-enabled mail/browser and newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= No Cross-Site Scripting (XSS) Vulnerabilities =

Cross-Site Scripting is not necessary for CSRF to work. However, Cross-Site Scripting flaws can be used to defeat most token based CSRF defenses, since a malicious XSS script can simply read the site generated token from the response, and include that token with a forged request. This technique is exactly how the [http://en.wikipedia.org/wiki/Samy_(XSS) 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 re-authentication or one-time passwords. It is imperative that no XSS vulnerabilities are present to ensure that CSRF defenses can't be circumvented. Please see the OWASP [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | XSS Prevention Cheat Sheet]] for detailed guidance on how to prevent XSS flaws.

= Related Articles =

'''Cross-Site Request Forgery (CSRF)'''

For more information on CSRF please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

'''How to Review Code for CSRF Vulnerabilities'''

See the [[:Category:OWASP_Code_Review_Project | OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues]].

'''How to Test for CSRF Vulnerabilities'''

See the [[:Category:OWASP_Testing_Project | OWASP Testing Guide]] article on how to [[Testing_for_CSRF_(OWASP-SM-005) | Test for CSRF Vulnerabilities]].

'''CSRF Testing Tool'''

Check out the [[:Category:OWASP_CSRFTester_Project | OWASP CSRF Tester]] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

'''Other Articles in the OWASP Prevention Cheat Sheet Series'''

* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]
* [[SQL Injection Prevention Cheat Sheet]]
* [[Transport Layer Protection Cheat Sheet]]

= References =

[http://www.isecpartners.com/files/XSRF_Paper_0.pdf Cross Site Reference Forgery] - An introduction to a common web application weakness

= Authors and Primary Editors =

Paul Petefish - paulpetefish@solutionary.com

Eric Sheridan - eric.sheridan@aspectsecurity.com

Dave Wichers - dave.wichers@aspectsecurity.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-20T11:51:14Z

Paul Petefish:

= Introduction =

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 that the user is currently authenticated to. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the user's context.

A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is an administrator account, a CSRF attack can compromise the entire Web application. The sites that are more likely to be attacked are community Websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). This attack can happen even if the user is logged into a Web site using strong encryption (HTTPS).

Utilizing social engineering, an attacker will 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.

In affect, CSRF attacks are used by an attacker to make a target system perform a function (funds Transfer, form submission etc.) via the target's browser without knowledge of the target user, at least until the unauthorized function has been committed.

For more information on CSRF, please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

= Prevention =

== Token Based ==

The most common defense for CSRF is to append challenge tokens to each sensitive request. These challenge tokens must be associated with the user's session. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user. The following describes how to incorporate challenge tokens:

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user), the application should include a hidden input tag query parameter with a name such as CSRFToken. It is important to note that the CSRFToken should not be included in the URL or in URL parameters as it may be leaked. The CSRFToken should have a value that is a randomly generated such as a 256-bit hash that has been base 64 encoded.

<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTVi
MGYwMGEwOA==">
…
</form>

For each request, this token only needs to be randomly generated once. After the initial random generation, the token value is stored in a session specific table mapping request names to validation tokens. When a request is performed by the user, before the request is executed the submitted CSRFToken has it's value verified by comparing the provided token to the value stored in the mapping table for this request. If there is no value in the table for this request name, or if the value provided does not match the value in the table exactly, then the request should be aborted and the event can be logged as a potential security incident.

The request name should be different for each request. The CSRFToken must be strictly protected. For example, an application that does not use SSL or passes the token through a URL parameter will result in the CSRFToken being leaked.

=== 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 though, since it is feasible that parameter values could be obtained or guessed by the attacker. However, if you add the current session ID to the ViewState, then it makes each Viewstate unique, and thus immune to CSRF.

To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (Note that you must set this property in the Page.Init event)

protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }

Keys the Viewstate to an individual using a unique value of your choice.

(Page.ViewStateUserKey)

This must be applied in Page_Init because the key has to be provided to ASP.NET before Viewstate is loaded. This option has been available since ASP.NET 1.1.

=== Prevention Frameworks ===

There are CSRF prevention modules available for J2EE, .Net, and PHP.

[[:Category:OWASP_CSRFGuard_Project | OWASP CSRF Guard (For Java)]]

The OWASP CSRFGuard Project makes use of a unique per-session token verification pattern using a JavaEE filter to mitigate the risk of CSRF attacks. When an HttpSession is first instantiated, CSRFGuard will generate a cryptographically random token using the SecureRandom class to be stored in the session.

CSRFGuard is a "reference implementation". Developers are encouraged to leverage more tightly integrated solutions for performance (ex: speed of parsing HTML) and technical (ex: AJAX requests) challenges.

'''Similar Projects'''

CSRFGuard has been implemented in other languages besides Java. They are:

*[[PHP CSRF Guard]]
*[[.Net CSRF Guard]]

== Challenge-Response ==

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

*CAPTCHA
*Re-Authentication (password)
*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.

== Double Submit Cookies (DWR) ==

Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request: first as a traditional header value, and again as a hidden form value.

When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. 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 the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.

If you are using Ajax or a significant amount of scripting then this solution is a simple fix once solution.

If you are using DWR version 2 then this CSRF protection is built in. DWR implements the double cookie submission pattern transparently.

= Prevention Measures That Do NOT Work =

'''Using a Secret Cookie'''

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

'''Only Accepting POST Requests'''

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.

'''Checking Referer Header'''

An attacker can easily block the sending of the Referer header, and the HTTP RFC’s make it clear the this header is optional. Browsers also omit the referer header when they are being used over SSL.

'''Multi-Step Transactions'''

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacked can predict or deduce each step of the completed transaction, then CSRF is possible.

'''URL Rewriting'''

This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user’s credential is exposed over the URL.

= Client/User Prevention =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating actions are:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf freely the Internet; if you have to do both things at the same machine, do them with separate browsers.

Integrated HTML-enabled mail/browser, newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= No Cross-Site Scripting (XSS) Vulnerabilities =

Cross-Site Scripting is not necessary for CSRF to work. However, Cross-Site Scripting flaws can be used to defeat most token based CSRF defenses, since a malicious XSS script can simply read the site generated token from the response, and include that token with a forged request. This technique is exactly how the [http://en.wikipedia.org/wiki/Samy_(XSS) 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 re-authentication or one-time passwords. It is imperative that no XSS vulnerabilities are present to ensure that CSRF defenses can't be circumvented. Please see the OWASP [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | XSS Prevention Cheat Sheet]] for detailed guidance on how to prevent XSS flaws.

= Related Articles =

'''Cross-Site Request Forgery (CSRF)'''

For more information on CSRF please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

'''How to Review Code for CSRF Vulnerabilities'''

See the [[:Category:OWASP_Code_Review_Project | OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues]].

'''How to Test for CSRF Vulnerabilities'''

See the [[:Category:OWASP_Testing_Project | OWASP Testing Guide]] article on how to [[Testing_for_CSRF_(OWASP-SM-005) | Test for CSRF Vulnerabilities]].

'''CSRF Testing Tool'''

Check out the [[:Category:OWASP_CSRFTester_Project | OWASP CSRF Tester]] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

'''Other Articles in the OWASP Prevention Cheat Sheet Series'''

* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]
* [[SQL Injection Prevention Cheat Sheet]]
* [[Transport Layer Protection Cheat Sheet]]

= References =

[http://www.isecpartners.com/files/XSRF_Paper_0.pdf Cross Site Reference Forgery] - An introduction to a common web application weakness

= Authors and Primary Editors =

Paul Petefish - paulpetefish@solutionary.com

Eric Sheridan - eric.sheridan@aspectsecurity.com

Dave Wichers - dave.wichers@aspectsecurity.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-15T15:25:04Z

Paul Petefish:

= Introduction =

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 that the user is currently authenticated to. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the users’ context.

A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is an administrator account, a CSRF attack can compromise the entire Web application. The sites that are more likely to be attacked are community Websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). This attack can happen even if the user is logged into a Web site using strong encryption (HTTPS).

Utilizing social engineering, an attacker will 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 users knowledge, either directly or by utilizing a Cross-site Scripting Flaw.

In effect, CSRF attacks are used by an attacker to make a target system perform a function (Funds Transfer, Form submission etc..) via the targets browser without knowledge of the target user, at least until the unauthorized function has been committed.

For more information on CSRF please see the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) OWASP Cross-Site Request Forgery (CSRF)] page.

= Prevention =

== Token Based ==

The most common defense of CSRF is to append challenge tokens to each sensitive request. These challenge tokens must be associated with the user's session. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user. The following describes how to incorporate challenge tokens.

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user) the application should include as a query parameter as an “Input” tag of type “hidden” with a name like: CSRFToken. It is important to note that the CSRFToken should not be included in the URL or in URL parameters as they may be leaked. The CSRFToken should have a value that is a randomly generated such as a 128-bit hash that has been base 64 encoded.

<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="MDZhMWUxNjRlNDlhZDBjNGYyNjg0ZWExODIzZjI0OTE=">
…
</form>

For each request this token need only be generated randomly once, after that the token value is stored in a session specific table mapping request names to validation tokens. When a request is performed by the user, before the request is executed the submitted CSRFToken has its value verified by comparing the provided token to the value stored in the mapping table for this request. If there is no value in the table for this request name, or if the value provided does not match the value in the table exactly then the Request Formulator is not the application, the request should be aborted and the event can be logged as a potential security incident.

The request name should be different for each request. The CSRFToken must be strictly protected, for example an application that does not use SSL or passes the token through a URL parameter, will result in the CSRFToken being leaked.

=== 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 though, since it is feasible that parameter values could be obtained or guessed by the attacker. However, if you add the current session ID to the ViewState, then it makes each Viewstate unique, and thus immune to CSRF.

To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (Note that you must set this property in the Page.Init event)

protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }

Keys the Viewstate to an individual using a unique value of your choice.

(Page.ViewStateUserKey)

This must be applied in Page_Init because the key has to be provided to ASP.NET before Viewstate is loaded. This option has been available since ASP.NET 1.1.

=== Prevention Frameworks ===

There are CSRF prevention modules available for J2EE, .Net, and PHP.

[http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project OWASP CSRF Guard]

The OWASP CSRFGuard Project makes use of a unique per-session token verification pattern using a JavaEE filter to mitigate the risk of CSRF attacks. When an HttpSession is first instantiated, CSRFGuard will generate a cryptographically random token using the SecureRandom class to be stored in the session.

CSRFGuard is a "reference implementation". Developers are encouraged to leverage more tightly integrated solutions for performance (ex: speed of parsing HTML) and technical (ex: AJAX requests) challenges.

'''Similar Projects'''

There are a small number of other projects that implement the unique random request token concept similar to that of CSRFGuard. They are as follows:

[http://www.owasp.org/index.php/PHP_CSRF_Guard http://www.owasp.org/index.php/PHP_CSRF_Guard]

[http://www.owasp.org/index.php/.Net_CSRF_Guard http://www.owasp.org/index.php/.Net_CSRF_Guard]

== Challenge-Response ==

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

*CAPTCHA
*Re-Authentication (password)
*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.

== Double Submit Cookies (DWR) ==

Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request: first as a traditional header value, and again as a hidden form value.

When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. 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 the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.

If you are using Ajax or a significant amount of scripting then this solution is a simple fix once solution.

If you are using DWR version 2 then this CSRF protection is built in. DWR implements the double cookie submission pattern transparently.

= Prevention Measures That Do NOT Work =

'''Using a Secret Cookie'''

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

'''Only Accepting POST Requests'''

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.

'''Checking Referer Header'''

An attacker can easily block the sending of the Referer header, and the HTTP RFC’s make it clear the this header is optional. Browsers also omit the referer header when they are being used over SSL.

'''Multi-Step Transactions'''

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacked can predict or deduce each step of the completed transaction, then CSRF is possible.

'''URL Rewriting'''

This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user’s credential is exposed over the URL.

= Client/User Prevention =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating actions are:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf freely the Internet; if you have to do both things at the same machine, do them with separate browsers.

Integrated HTML-enabled mail/browser, newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= No Cross-Site Scripting (XSS) Vulnerabilities =

Cross-Site Scripting is not necessary to for CSRF to work. However, any Cross-Site Scripting flaw can defeat most token based CSRF defenses that are available. XSS can not defeat challenge-response defenses such as re-authentication or one-time tokens. It is imperative that no XSS vulnerabilities are present to ensure that no CSRF vulnerabilities are present. Please see the [http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet XSS Prevention Cheat Sheet] for more information.

= Related Articles =

'''Cross-Site Request Forgery (CSRF)'''

For more information on CSRF please see the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) OWASP Cross-Site Request Forgery (CSRF)] page.

'''How to Review Code for CSRF Vulnerabilities'''

See the [http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project OWASP Code Review Guide] article on how to [http://www.owasp.org/index.php/Reviewing_code_for_Cross-Site_Request_Forgery_issues Reviewing Code for CSRF Vulnerabilities].

'''How to Test for CSRF Vulnerabilities'''

See the [http://www.owasp.org/index.php/Category:OWASP_Testing_Project OWASP Testing Guide] article on how to [http://www.owasp.org/index.php/Testing_for_CSRF_(OWASP-SM-005) Test for CSRF Vulnerabilities].

'''CSRF Testing Tool'''

Check out the [http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRF Tester] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

= References =

[https://www.isecpartners.com/files/XSRF_Paper_0.pdf Cross Site Reference Forgery]

An introduction to a common web application weakness

= Authors and Primary Editors =

Paul Petefish - paulpetefish@solutionary.com

Eric Sheridan - eric.sheridan@aspectsecurity.com

Dave Wichers - dave.wichers@aspectsecurity.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-15T15:21:30Z

Paul Petefish:

= Introduction =

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 that the user is currently authenticated to. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the users’ context.

A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is an administrator account, a CSRF attack can compromise the entire Web application. The sites that are more likely to be attacked are community Websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). This attack can happen even if the user is logged into a Web site using strong encryption (HTTPS).

Utilizing social engineering, an attacker will 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 users knowledge, either directly or by utilizing a Cross-site Scripting Flaw.

In effect, CSRF attacks are used by an attacker to make a target system perform a function (Funds Transfer, Form submission etc..) via the targets browser without knowledge of the target user, at least until the unauthorized function has been committed.

For more information on CSRF please see the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) OWASP Cross-Site Request Forgery (CSRF)] page.

= Prevention =

== Token Based ==

The most common defense of CSRF is to append challenge tokens to each sensitive request. These challenge tokens must be associated with the user's session. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user. The following describes how to incorporate challenge tokens.

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user) the application should include as a query parameter as an “Input” tag of type “hidden” with a name like: CSRFToken. It is important to note that the CSRFToken should not be included in the URL or in URL parameters as they may be leaked. The CSRFToken should have a value that is a randomly generated such as a 128-bit hash that has been base 64 encoded.

<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="MDZhMWUxNjRlNDlhZDBjNGYyNjg0ZWExODIzZjI0OTE=">
…
</form>

For each request this token need only be generated randomly once, after that the token value is stored in a session specific table mapping request names to validation tokens. When a request is performed by the user, before the request is executed the submitted CSRFToken has its value verified by comparing the provided token to the value stored in the mapping table for this request. If there is no value in the table for this request name, or if the value provided does not match the value in the table exactly then the Request Formulator is not the application, the request should be aborted and the event can be logged as a potential security incident.

The request name should be different for each request. The CSRFToken must be strictly protected, for example an application that does not use SSL or passes the token through a URL parameter, will result in the CSRFToken being leaked.

=== 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 though, since it is feasible that parameter values could be obtained or guessed by the attacker. However, if you add the current session ID to the ViewState, then it makes each Viewstate unique, and thus immune to CSRF.

To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (Note that you must set this property in the Page.Init event)

protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }

Keys the Viewstate to an individual using a unique value of your choice.

(Page.ViewStateUserKey)

This must be applied in Page_Init because the key has to be provided to ASP.NET before Viewstate is loaded. This option has been available since ASP.NET 1.1.

=== Prevention Frameworks ===

There are CSRF prevention modules available for J2EE, .Net, and PHP.

[http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project OWASP CSRF Guard]

The OWASP CSRFGuard Project makes use of a unique per-session token verification pattern using a JavaEE filter to mitigate the risk of CSRF attacks. When an HttpSession is first instantiated, CSRFGuard will generate a cryptographically random token using the SecureRandom class to be stored in the session.

CSRFGuard is a "reference implementation". Developers are encouraged to leverage more tightly integrated solutions for performance (ex: speed of parsing HTML) and technical (ex: AJAX requests) challenges.

'''Similar Projects'''

There are a small number of other projects that implement the unique random request token concept similar to that of CSRFGuard. They are as follows:

[http://www.owasp.org/index.php/PHP_CSRF_Guard http://www.owasp.org/index.php/PHP_CSRF_Guard]

[http://www.owasp.org/index.php/.Net_CSRF_Guard http://www.owasp.org/index.php/.Net_CSRF_Guard]

== Challenge-Response ==

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

*CAPTCHA
*Re-Authentication (password)
*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.

== Double Submit Cookies (DWR) ==

Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request: first as a traditional header value, and again as a hidden form value.

When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. 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 the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.

If you are using Ajax or a significant amount of scripting then this solution is a simple fix once solution.

If you are using DWR version 2 then this CSRF protection is built in. DWR implements the double cookie submission pattern transparently.

= Prevention Measures That Do NOT Work =

'''Using a Secret Cookie'''

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

'''Only Accepting POST Requests'''

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.

'''Checking Referer Header'''

An attacker can easily block the sending of the Referer header, and the HTTP RFC’s make it clear the this header is optional. Browsers also omit the referer header when they are being used over SSL.

'''Multi-Step Transactions'''

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacked can predict or deduce each step of the completed transaction, then CSRF is possible.

'''URL Rewriting'''

This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user’s credential is exposed over the URL.

= Client/User Prevention =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating actions are:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf freely the Internet; if you have to do both things at the same machine, do them with separate browsers.

Integrated HTML-enabled mail/browser, newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= Cross-Site Scripting (XSS) =

Cross-Site Scripting is not necessary to for CSRF to work. However, any Cross-Site Scripting flaw can defeat most token based CSRF defenses that are available. XSS can not defeat challenge-response defenses such as re-authentication or one-time tokens. It is imperative that no XSS vulnerabilities are present to ensure that no CSRF vulnerabilities are present. Please see the [http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet XSS Prevention Cheat Sheet] for more information.

= Related Articles =

'''Cross-Site Request Forgery (CSRF)'''

For more information on CSRF please see the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) OWASP Cross-Site Request Forgery (CSRF)] page.

'''How to Review Code for CSRF Vulnerabilities'''

See the [http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project OWASP Code Review Guide] article on how to [http://www.owasp.org/index.php/Reviewing_code_for_Cross-Site_Request_Forgery_issues Reviewing Code for CSRF Vulnerabilities].

'''How to Test for CSRF Vulnerabilities'''

See the [http://www.owasp.org/index.php/Category:OWASP_Testing_Project OWASP Testing Guide] article on how to [http://www.owasp.org/index.php/Testing_for_CSRF_(OWASP-SM-005) Test for CSRF Vulnerabilities].

'''CSRF Testing Tool'''

Check out the [http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRF Tester] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

= References =

[https://www.isecpartners.com/files/XSRF_Paper_0.pdf Cross Site Reference Forgery]

An introduction to a common web application weakness

= Authors and Primary Editors =

Paul Petefish - paulpetefish@solutionary.com

Eric Sheridan - eric.sheridan@aspectsecurity.com

Dave Wichers - dave.wichers@aspectsecurity.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-15T15:14:25Z

Paul Petefish:

= Introduction =

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 that the user is currently authenticated to. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the users’ context.

A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is an administrator account, a CSRF attack can compromise the entire Web application. The sites that are more likely to be attacked are community Websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). This attack can happen even if the user is logged into a Web site using strong encryption (HTTPS).

Utilizing social engineering, an attacker will 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 users knowledge, either directly or by utilizing a Cross-site Scripting Flaw.

In effect, CSRF attacks are used by an attacker to make a target system perform a function (Funds Transfer, Form submission etc..) via the targets browser without knowledge of the target user, at least until the unauthorized function has been committed.

For more information on CSRF please see the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) OWASP Cross-Site Request Forgery (CSRF)] page.

= Prevention =

== Token Based ==

The most common defense of CSRF is to append challenge tokens to each sensitive request. These challenge tokens must be associated with the user's session. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user. The following describes how to incorporate challenge tokens.

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user) the application should include as a query parameter as an “Input” tag of type “hidden” with a name like: CSRFToken. It is important to note that the CSRFToken should not be included in the URL or in URL parameters as they may be leaked. The CSRFToken should have a value that is a randomly generated such as a 128-bit hash that has been base 64 encoded.

<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="MDZhMWUxNjRlNDlhZDBjNGYyNjg0ZWExODIzZjI0OTE=">
…
</form>

For each request this token need only be generated randomly once, after that the token value is stored in a session specific table mapping request names to validation tokens. When a request is performed by the user, before the request is executed the submitted CSRFToken has its value verified by comparing the provided token to the value stored in the mapping table for this request. If there is no value in the table for this request name, or if the value provided does not match the value in the table exactly then the Request Formulator is not the application, the request should be aborted and the event can be logged as a potential security incident.

The request name should be different for each request. The CSRFToken must be strictly protected, for example an application that does not use SSL or passes the token through a URL parameter, will result in the CSRFToken being leaked.

=== 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 though, since it is feasible that parameter values could be obtained or guessed by the attacker. However, if you add the current session ID to the ViewState, then it makes each Viewstate unique, and thus immune to CSRF.

To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (Note that you must set this property in the Page.Init event)

protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }

Keys the Viewstate to an individual using a unique value of your choice.

(Page.ViewStateUserKey)

This must be applied in Page_Init because the key has to be provided to ASP.NET before Viewstate is loaded. This option has been available since ASP.NET 1.1.

=== Prevention Frameworks ===

There are CSRF prevention modules available for J2EE, .Net, and PHP.

[http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project OWASP CSRF Guard]

The OWASP CSRFGuard Project makes use of a unique per-session token verification pattern using a JavaEE filter to mitigate the risk of CSRF attacks. When an HttpSession is first instantiated, CSRFGuard will generate a cryptographically random token using the SecureRandom class to be stored in the session.

CSRFGuard is a "reference implementation". Developers are encouraged to leverage more tightly integrated solutions for performance (ex: speed of parsing HTML) and technical (ex: AJAX requests) challenges.

Similar Projects
There are a small number of other projects that implement the unique random request token concept similar to that of CSRFGuard. They are as follows:

[http://www.owasp.org/index.php/PHP_CSRF_Guard http://www.owasp.org/index.php/PHP_CSRF_Guard]

[http://www.owasp.org/index.php/.Net_CSRF_Guard http://www.owasp.org/index.php/.Net_CSRF_Guard]

== Challenge-Response ==

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

*CAPTCHA
*Re-Authentication (password and or username)
*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.

== Double Submit Cookies (DWR) ==

Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request: first as a traditional header value, and again as a hidden form value.

When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. 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 the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.

If you are using Ajax or a significant amount of scripting then this solution is a simple fix once solution.

If you are using DWR version 2 then this CSRF protection is built in. DWR implements the double cookie submission pattern transparently.

= Prevention Measures That Do NOT Work =

'''Using a Secret Cookie'''

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

'''Only Accepting POST Requests'''

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.

'''Checking Referer Header'''

An attacker can easily block the sending of the Referer header, and the HTTP RFC’s make it clear the this header is optional. Browsers also omit the referer header when they are being used over SSL.

'''Multi-Step Transactions'''

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacked can predict or deduce each step of the completed transaction, then CSRF is possible.

'''URL Rewriting'''

This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user’s credential is exposed over the URL.

= Client/User Prevention =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating actions are:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf freely the Internet; if you have to do both things at the same machine, do them with separate browsers.

Integrated HTML-enabled mail/browser, newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= Cross-Site Scripting (XSS) =

Cross-Site Scripting is not necessary to for CSRF to work. However, any Cross-Site Scripting flaw can defeat most token based CSRF defenses that are available. XSS can not defeat challenge-response defenses such as re-authentication or one-time tokens. It is imperative that no XSS vulnerabilities are present to ensure that no CSRF vulnerabilities are present. Please see the [http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet XSS Prevention Cheat Sheet] for more information.

= Related Articles =

'''Cross-Site Request Forgery (CSRF)'''

For more information on CSRF please see the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) OWASP Cross-Site Request Forgery (CSRF)] page.

'''How to Review Code for CSRF Vulnerabilities'''

See the [http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project OWASP Code Review Guide] article on how to [http://www.owasp.org/index.php/Reviewing_code_for_Cross-Site_Request_Forgery_issues Reviewing Code for CSRF Vulnerabilities].

'''How to Test for CSRF Vulnerabilities'''

See the [http://www.owasp.org/index.php/Category:OWASP_Testing_Project OWASP Testing Guide] article on how to [http://www.owasp.org/index.php/Testing_for_CSRF_(OWASP-SM-005) Test for CSRF Vulnerabilities].

'''CSRF Testing Tool'''

Check out the [http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRF Tester] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

= References =

[https://www.isecpartners.com/files/XSRF_Paper_0.pdf Cross Site Reference Forgery]

An introduction to a common web application weakness

= Authors and Primary Editors =

Paul Petefish - paulpetefish@solutionary.com

Eric Sheridan - eric.sheridan@aspectsecurity.com

Dave Wichers - dave.wichers@aspectsecurity.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-15T14:35:03Z

Paul Petefish:

= Introduction =

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 that the user is currently authenticated to. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the users’ context.

A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is an administrator account, a CSRF attack can compromise the entire Web application. The sites that are more likely to be attacked are community Websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). This attack can happen even if the user is logged into a Web site using strong encryption (HTTPS).

Utilizing social engineering, an attacker will 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 users knowledge, either directly or by utilizing a Cross-site Scripting Flaw.

In effect, CSRF attacks are used by an attacker to make a target system perform a function (Funds Transfer, Form submission etc..) via the targets browser without knowledge of the target user, at least until the unauthorized function has been committed.

For more information on CSRF please see the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) OWASP Cross-Site Request Forgery (CSRF)] page.

= Prevention =

== Token Based ==

The most common defense of CSRF is to append challenge tokens to each sensitive request. These challenge tokens must be associated with the user's session. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user. The following describes how to incorporate challenge tokens.

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user) the application should include as a query parameter as an “Input” tag of type “hidden” with a name like: CSRFToken. It is important to note that the CSRFToken should not be included in the URL or in URL parameters as they may be leaked. The CSRFToken should have a value that is a randomly generated such as a 128-bit hash that has been base 64 encoded. For each request this token need only be generated randomly once, after that the token value is stored in a session specific table mapping request names to validation tokens. When a request is performed by the user, before the request is executed the submitted CSRFToken has its value verified by comparing the provided token to the value stored in the mapping table for this request. If there is no value in the table for this request name, or if the value provided does not match the value in the table exactly then the Request Formulator is not the application, the request should be aborted and the event can be logged as a potential security incident.

The request name should be different for each request. The CSRFToken must be strictly protected, for example an application that does not use SSL or passes the token through a URL parameter, will result in the CSRFToken being leaked.

=== 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 though, since it is feasible that parameter values could be obtained or guessed by the attacker. However, if you add the current session ID to the ViewState, then it makes each Viewstate unique, and thus immune to CSRF.

To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (Note that you must set this property in the Page.Init event)

protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }

Keys the Viewstate to an individual using a unique value of your choice.

(Page.ViewStateUserKey)

This must be applied in Page_Init because the key has to be provided to ASP.NET before Viewstate is loaded. This option has been available since ASP.NET 1.1.

=== Prevention Frameworks ===

There are CSRF prevention modules available for J2EE, .Net, and PHP.

[http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project OWASP CSRF Guard]

The OWASP CSRFGuard Project makes use of a unique per-session token verification pattern using a JavaEE filter to mitigate the risk of CSRF attacks. When an HttpSession is first instantiated, CSRFGuard will generate a cryptographically random token using the SecureRandom class to be stored in the session.

CSRFGuard is a "reference implementation". Developers are encouraged to leverage more tightly integrated solutions for performance (ex: speed of parsing HTML) and technical (ex: AJAX requests) challenges.

Similar Projects
There are a small number of other projects that implement the unique random request token concept similar to that of CSRFGuard. They are as follows:

[http://www.owasp.org/index.php/PHP_CSRF_Guard http://www.owasp.org/index.php/PHP_CSRF_Guard]

[http://www.owasp.org/index.php/.Net_CSRF_Guard http://www.owasp.org/index.php/.Net_CSRF_Guard]

== Challenge-Response ==

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

*CAPTCHA
*Re-Authentication (password and or username)
*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.

== Double Submit Cookies (DWR) ==

Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request: first as a traditional header value, and again as a hidden form value.

When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. 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 the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.

If you are using Ajax or a significant amount of scripting then this solution is a simple fix once solution.

If you are using DWR version 2 then this CSRF protection is built in. DWR implements the double cookie submission pattern transparently.

= Prevention Measures That Do NOT Work =

'''Using a Secret Cookie'''

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

'''Only Accepting POST Requests'''

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.

'''Checking Referer Header'''

An attacker can easily block the sending of the Referer header, and the HTTP RFC’s make it clear the this header is optional. Browsers also omit the referer header when they are being used over SSL.

'''Multi-Step Transactions'''

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacked can predict or deduce each step of the completed transaction, then CSRF is possible.

'''URL Rewriting'''

This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user’s credential is exposed over the URL.

= Client/User Prevention =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating actions are:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf freely the Internet; if you have to do both things at the same machine, do them with separate browsers.

Integrated HTML-enabled mail/browser, newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= Cross-Site Scripting (XSS) =

Cross-Site Scripting is not necessary to for CSRF to work. However, any Cross-Site Scripting flaw can defeat most token based CSRF defenses that are available. XSS can not defeat challenge-response defenses such as re-authentication or one-time tokens. It is imperative that no XSS vulnerabilities are present to ensure that no CSRF vulnerabilities are present. Please see the [http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet XSS Prevention Cheat Sheet] for more information.

= Related Articles =

'''Cross-Site Request Forgery (CSRF)'''

For more information on CSRF please see the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) OWASP Cross-Site Request Forgery (CSRF)] page.

'''How to Review Code for CSRF Vulnerabilities'''

See the [http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project OWASP Code Review Guide] article on how to [http://www.owasp.org/index.php/Reviewing_code_for_Cross-Site_Request_Forgery_issues Reviewing Code for CSRF Vulnerabilities].

'''How to Test for CSRF Vulnerabilities'''

See the [http://www.owasp.org/index.php/Category:OWASP_Testing_Project OWASP Testing Guide] article on how to [http://www.owasp.org/index.php/Testing_for_CSRF_(OWASP-SM-005) Test for CSRF Vulnerabilities].

'''CSRF Testing Tool'''

Check out the [http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRF Tester] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

= References =

[https://www.isecpartners.com/files/XSRF_Paper_0.pdf Cross Site Reference Forgery]

An introduction to a common web application weakness

= Authors and Primary Editors =

Paul Petefish - paulpetefish@solutionary.com

Eric Sheridan - eric.sheridan@aspectsecurity.com

Dave Wichers - dave.wichers@aspectsecurity.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-14T22:35:39Z

Paul Petefish:

= Introduction =

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 that the user is currently authenticated to. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the users’ context.

A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is an administrator account, a CSRF attack can compromise the entire Web application. The sites that are more likely to be attacked are community Websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). This attack can happen even if the user is logged into a Web site using strong encryption (HTTPS).

Utilizing social engineering, an attacker will 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 users knowledge, either directly or by utilizing a Cross-site Scripting Flaw.

In effect, CSRF attacks are used by an attacker to make a target system perform a function (Funds Transfer, Form submission etc..) via the targets browser without knowledge of the target user, at least until the unauthorized function has been committed.

For more information on CSRF please see the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) OWASP Cross-Site Request Forgery (CSRF)] page.

= Prevention =

== Token Based ==

The most common defense of CSRF is to append challenge tokens to each sensitive request. These challenge tokens must be associated with the user's session. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user. The following describes how to incorporate challenge tokens.

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user) the application should include as a query parameter as an “Input” tag of type “hidden” with a name like: CSRFToken. It is important to note that the CSRFToken should not be included in the URL or in URL parameters as they may be leaked. The CSRFToken should have a value that is a randomly generated such as a 128-bit hash that has been base 64 encoded. For each request this token need only be generated randomly once, after that the token value is stored in a session specific table mapping request names to validation tokens. When a request is performed by the user, before the request is executed the submitted CSRFToken has its value verified by comparing the provided token to the value stored in the mapping table for this request. If there is no value in the table for this request name, or if the value provided does not match the value in the table exactly then the Request Formulator is not the application, the request should be aborted and the event can be logged as a potential security incident.

The request name should be different for each request. The CSRFToken must be strictly protected, for example an application that does not use SSL or passes the token through a URL parameter, will result in the CSRFToken being leaked.

=== 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 though, since it is feasible that parameter values could be obtained or guessed by the attacker. However, if you add the current session ID to the ViewState, then it makes each Viewstate unique, and thus immune to CSRF.

To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (Note that you must set this property in the Page.Init event)

protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }

Keys the Viewstate to an individual using a unique value of your choice.

(Page.ViewStateUserKey)

This must be applied in Page_Init because the key has to be provided to ASP.NET before Viewstate is loaded. This option has been available since ASP.NET 1.1.

=== Prevention Frameworks ===

There are CSRF prevention modules available for J2EE, .Net, and PHP.

[http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project OWASP CSRF Guard]

The OWASP CSRFGuard Project makes use of a unique per-session token verification pattern using a JavaEE filter to mitigate the risk of CSRF attacks. When an HttpSession is first instantiated, CSRFGuard will generate a cryptographically random token using the SecureRandom class to be stored in the session.

CSRFGuard is a "reference implementation". Developers are encouraged to leverage more tightly integrated solutions for performance (ex: speed of parsing HTML) and technical (ex: AJAX requests) challenges.

Similar Projects
There are a small number of other projects that implement the unique random request token concept similar to that of CSRFGuard. They are as follows:

[http://www.owasp.org/index.php/PHP_CSRF_Guard http://www.owasp.org/index.php/PHP_CSRF_Guard]

[http://www.owasp.org/index.php/.Net_CSRF_Guard http://www.owasp.org/index.php/.Net_CSRF_Guard]

== Challenge-Response ==

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

*CAPTCHA
*Re-Authentication (password and or username)
*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.

== Double Submit Cookies (DWR) ==

Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request: first as a traditional header value, and again as a hidden form value.

When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. 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 the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.

If you are using Ajax or a significant amount of scripting then this solution is a simple fix once solution.

If you are using DWR version 2 then this CSRF protection is built in. DWR implements the double cookie submission pattern transparently.

= Prevention Measures That Do NOT Work =

'''Using a Secret Cookie'''

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

'''Only Accepting POST Requests'''

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.

'''Checking Referer Header'''

An attacker can easily block the sending of the Referer header, and the HTTP RFC’s make it clear the this header is optional. Browsers also omit the referer header when they are being used over SSL.

'''Multi-Step Transactions'''

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacked can predict or deduce each step of the completed transaction, then CSRF is possible.

'''URL Rewriting'''

This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user’s credential is exposed over the URL.

= Client/User Prevention =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating actions are:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf freely the Internet; if you have to do both things at the same machine, do them with separate browsers.

Integrated HTML-enabled mail/browser, newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= Cross-Site Scripting (XSS) =

Cross-Site Scripting is not necessary to for CSRF to work. However, any Cross-Site Scripting flaw can defeat most token based CSRF defenses that are available. XSS can not defeat challenge-response defenses such as re-authentication or one-time tokens. It is imperative that no XSS vulnerabilities are present to ensure that no CSRF vulnerabilities are present. Please see the [http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet XSS Prevention Cheat Sheet] for more information.

= Related Articles =

'''Cross-Site Request Forgery (CSRF)'''

For more information on CSRF please see the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) OWASP Cross-Site Request Forgery (CSRF)] page.

'''How to Review Code for CSRF Vulnerabilities'''

See the [http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project OWASP Code Review Guide] article on how to [http://www.owasp.org/index.php/Reviewing_code_for_Cross-Site_Request_Forgery_issues Reviewing Code for CSRF Vulnerabilities].

'''How to Test for CSRF Vulnerabilities'''

See the [http://www.owasp.org/index.php/Category:OWASP_Testing_Project OWASP Testing Guide] article on how to [http://www.owasp.org/index.php/Testing_for_CSRF_(OWASP-SM-005) Test for CSRF Vulnerabilities].

'''CSRF Testing Tool'''

Check out the [http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRF Tester] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

= References =

[https://www.isecpartners.com/files/XSRF_Paper_0.pdf Cross Site Reference Forgery]

An introduction to a common web application weakness

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-14T21:42:10Z

Paul Petefish:

= Introduction =

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 that the user is currently authenticated to. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the users’ context.

A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is an administrator account, a CSRF attack can compromise the entire Web application. The sites that are more likely to be attacked are community Websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). This attack can happen even if the user is logged into a Web site using strong encryption (HTTPS).

Utilizing social engineering, an attacker will 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 users knowledge, either directly or by utilizing a Cross-site Scripting Flaw.

In effect, CSRF attacks are used by an attacker to make a target system perform a function (Funds Transfer, Form submission etc..) via the targets browser without knowledge of the target user, at least until the unauthorized function has been committed.

For more information on CSRF please see the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) OWASP Cross-Site Request Forgery (CSRF)] page.

= Prevention =

== Token Based ==

The most common defense of CSRF is to append challenge tokens to each sensitive request. These challenge tokens must be associated with the user's session. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user. The following describes how to incorporate challenge tokens.

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user) the application should include as a query parameter as an “Input” tag of type “hidden” with a name like: CSRFToken. It is important to note that the CSRFToken should not be included in the URL or in URL parameters as they may be leaked. The CSRFToken should have a value that is a randomly generated such as a 128-bit hash that has been base 64 encoded. For each request this token need only be generated randomly once, after that the token value is stored in a session specific table mapping request names to validation tokens. When a request is performed by the user, before the request is executed the submitted CSRFToken has its value verified by comparing the provided token to the value stored in the mapping table for this request. If there is no value in the table for this request name, or if the value provided does not match the value in the table exactly then the Request Formulator is not the application, the request should be aborted and the event can be logged as a potential security incident.

The request name should be different for each request. The CSRFToken must be strictly protected, for example an application that does not use SSL or passes the token through a URL parameter, will result in the CSRFToken being leaked.

=== 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 though, since it is feasible that parameter values could be obtained or guessed by the attacker. However, if you add the current session ID to the ViewState, then it makes each Viewstate unique, and thus immune to CSRF.

To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (Note that you must set this property in the Page.Init event)

protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }

Keys the Viewstate to an individual using a unique value of your choice.

(Page.ViewStateUserKey)

This must be applied in Page_Init because the key has to be provided to ASP.NET before Viewstate is loaded. This option has been available since ASP.NET 1.1.

=== Prevention Frameworks ===

There are CSRF prevention modules available for J2EE, .Net, and PHP.

[http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project OWASP CSRF Guard]

The OWASP CSRFGuard Project makes use of a unique per-session token verification pattern using a JavaEE filter to mitigate the risk of CSRF attacks. When an HttpSession is first instantiated, CSRFGuard will generate a cryptographically random token using the SecureRandom class to be stored in the session.

CSRFGuard is a "reference implementation". Developers are encouraged to leverage more tightly integrated solutions for performance (ex: speed of parsing HTML) and technical (ex: AJAX requests) challenges.

Similar Projects
There are a small number of other projects that implement the unique random request token concept similar to that of CSRFGuard. They are as follows:

[http://www.owasp.org/index.php/PHP_CSRF_Guard http://www.owasp.org/index.php/PHP_CSRF_Guard]

[http://www.owasp.org/index.php/.Net_CSRF_Guard http://www.owasp.org/index.php/.Net_CSRF_Guard]

== Challenge-Response ==

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

*CAPTCHA
*Re-Authentication (password and or username)
*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.

== Double Submit Cookies (DWR) ==

Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request: first as a traditional header value, and again as a hidden form value.

When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. 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 the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.

If you are using Ajax or a significant amount of scripting then this solution is a simple fix once solution.

If you are using DWR version 2 then this CSRF protection is built in. DWR implements the double cookie submission pattern transparently.

= Prevention Measures That Do NOT Work =

'''Using a Secret Cookie'''

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

'''Only Accepting POST Requests'''

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.

'''Checking Referer Header'''

An attacker can easily block the sending of the Referer header, and the HTTP RFC’s make it clear the this header is optional. Browsers also omit the referer header when they are being used over SSL.

'''Multi-Step Transactions'''

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacked can predict or deduce each step of the completed transaction, then CSRF is possible.

'''URL Rewriting'''

This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user’s credential is exposed over the URL.

= Client/User Prevention =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating actions are:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf freely the Internet; if you have to do both things at the same machine, do them with separate browsers.

Integrated HTML-enabled mail/browser, newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= Cross-Site Scripting (XSS) =

Cross-Site Scripting is not necessary to for CSRF to work. However, any Cross-Site Scripting flaw can defeat most token based CSRF defenses that are available. XSS can not defeat challenge-response defenses such as re-authentication or one-time tokens. It is imperative that no XSS vulnerabilities are present to ensure that no CSRF vulnerabilities are present. Please see the [http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet XSS Prevention Cheat Sheet] for more information.

= Related Articles =

'''How to Review Code for CSRF Vulnerabilities'''

See the [http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project OWASP Code Review Guide] article on how to [http://www.owasp.org/index.php/Reviewing_code_for_Cross-Site_Request_Forgery_issues Reviewing Code for CSRF Vulnerabilities].

'''How to Test for CSRF Vulnerabilities'''

See the [http://www.owasp.org/index.php/Category:OWASP_Testing_Project OWASP Testing Guide] article on how to [http://www.owasp.org/index.php/Testing_for_CSRF_(OWASP-SM-005) Test for CSRF Vulnerabilities].

'''CSRF Testing Tool'''

Check out the [http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRF Tester] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

= References =

[https://www.isecpartners.com/files/XSRF_Paper_0.pdf Cross Site Reference Forgery]

An introduction to a common web application weakness

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-14T21:11:30Z

Paul Petefish:

= Introduction =

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 that the user is currently authenticated to. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the users’ context.

A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is an administrator account, a CSRF attack can compromise the entire Web application. The sites that are more likely to be attacked are community Websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). This attack can happen even if the user is logged into a Web site using strong encryption (HTTPS).

Utilizing social engineering, an attacker will 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 users knowledge, either directly or by utilizing a Cross-site Scripting Flaw.

In effect, CSRF attacks are used by an attacker to make a target system perform a function (Funds Transfer, Form submission etc..) via the targets browser without knowledge of the target user, at least until the unauthorized function has been committed.

For more information on CSRF please see the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) OWASP Cross-Site Request Forgery (CSRF)] page.

= Prevention =

== Token Based ==

The most common defense of CSRF is to append challenge tokens to each sensitive request. These challenge tokens must be associated with the user's session. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user. The following describes how to incorporate challenge tokens.

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user) the application should include as a query parameter as an “Input” tag of type “hidden” with a name like: CSRFToken. It is important to note that the CSRFToken should not be included in the URL or in URL parameters as they may be leaked. The CSRFToken should have a value that is a randomly generated such as a 128-bit hash that has been base 64 encoded. For each request this token need only be generated randomly once, after that the token value is stored in a session specific table mapping request names to validation tokens. When a request is performed by the user, before the request is executed the submitted CSRFToken has its value verified by comparing the provided token to the value stored in the mapping table for this request. If there is no value in the table for this request name, or if the value provided does not match the value in the table exactly then the Request Formulator is not the application, the request should be aborted and the event can be logged as a potential security incident.

The request name should be different for each request. The CSRFToken must be strictly protected, for example an application that does not use SSL or passes the token through a URL parameter, will result in the CSRFToken being leaked.

=== .NET Viewstate ===

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 though, since it is feasible that parameter values could be obtained or guessed by the attacker. However, if you add the current session ID to the ViewState, then it makes each Viewstate unique, and thus immune to CSRF.

To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (Note that you must set this property in the Page.Init event)

protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }

Keys the Viewstate to an individual using a unique value of your choice.

(Page.ViewStateUserKey)

This must be applied in Page_Init because the key has to be provided to ASP.NET before Viewstate is loaded. This option has been available since ASP.NET 1.1.

=== Prevention Frameworks ===

There are CSRF prevention modules available for J2EE, .Net, and PHP.

[http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project OWASP CSRF Guard]

The OWASP CSRFGuard Project makes use of a unique per-session token verification pattern using a JavaEE filter to mitigate the risk of CSRF attacks. When an HttpSession is first instantiated, CSRFGuard will generate a cryptographically random token using the SecureRandom class to be stored in the session.

CSRFGuard is a "reference implementation". Developers are encouraged to leverage more tightly integrated solutions for performance (ex: speed of parsing HTML) and technical (ex: AJAX requests) challenges.

Similar Projects
There are a small number of other projects that implement the unique random request token concept similar to that of CSRFGuard. They are as follows:

[http://www.owasp.org/index.php/PHP_CSRF_Guard http://www.owasp.org/index.php/PHP_CSRF_Guard]

[http://www.owasp.org/index.php/.Net_CSRF_Guard http://www.owasp.org/index.php/.Net_CSRF_Guard]

== Challenge-Response ==

== Double Submit Cookies ==

= Prevention Measures That Do NOT Work =

'''Using a Secret Cookie'''

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

'''Only Accepting POST Requests'''

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.

'''Checking Referer Header'''

An attacker can easily block the sending of the Referer header, and the HTTP RFC’s make it clear the this header is optional. Browsers also omit the referer header when they are being used over SSL.

'''Multi-Step Transactions'''

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacked can predict or deduce each step of the completed transaction, then CSRF is possible.

'''URL Rewriting'''

This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user’s credential is exposed over the URL.

= Client/User Prevention =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating actions are:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf freely the Internet; if you have to do both things at the same machine, do them with separate browsers.

Integrated HTML-enabled mail/browser, newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= Cross-Site Scripting (XSS) =

Cross-Site Scripting is not necessary to for CSRF to work. However, any Cross-Site Scripting flaw can defeat most token based CSRF defenses that are available. XSS can not defeat challenge-response defenses such as re-authentication or RSA time tokens. It is imperative that no XSS vulnerabilities are present to ensure that no CSRF vulnerabilities are present. Please see the [http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet XSS Prevention Cheat Sheet] for more information.

= Related Articles =

'''How to Review Code for CSRF Vulnerabilities'''

See the [http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project OWASP Code Review Guide] article on how to [http://www.owasp.org/index.php/Reviewing_code_for_Cross-Site_Request_Forgery_issues Reviewing Code for CSRF Vulnerabilities].

'''How to Test for CSRF Vulnerabilities'''

See the [http://www.owasp.org/index.php/Category:OWASP_Testing_Project OWASP Testing Guide] article on how to [http://www.owasp.org/index.php/Testing_for_CSRF_(OWASP-SM-005) Test for CSRF Vulnerabilities].

'''CSRF Testing Tool'''

Check out the [http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRF Tester] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

= References =

[https://www.isecpartners.com/files/XSRF_Paper_0.pdf Cross Site Reference Forgery]

An introduction to a common web application weakness

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-14T20:42:03Z

Paul Petefish:

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-14T16:22:08Z

Paul Petefish:

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-14T16:15:21Z

Paul Petefish:

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-14T16:01:14Z

Paul Petefish:

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-14T16:00:18Z

Paul Petefish:

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-14T15:31:01Z

Paul Petefish:

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-14T15:00:09Z

Paul Petefish:

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-14T14:49:58Z

Paul Petefish:

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-14T14:49:01Z

Paul Petefish:

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-14T14:41:09Z

Paul Petefish:

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-14T14:37:27Z

Paul Petefish:

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-14T14:31:29Z

Paul Petefish:

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-14T14:28:34Z

Paul Petefish:

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2009-10-12T13:49:28Z

Paul Petefish: Created page with '= Introduction = 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 brow…'