Testing for CSRF (OTG-SESS-005) - Revision history

D0ubl3 h3lix: Corrected yehg.net links

2019-03-28T05:06:16Z

Corrected yehg.net links

Tony Hsu HsiangChih: /* Gray Box Testing */

2016-04-12T23:29:10Z

‎Gray Box Testing

Christina Schelin: Goodness.

2015-03-13T20:17:58Z

Goodness.

Andrew Muller at 14:22, 31 July 2014

2014-07-31T14:22:53Z

Andrew Muller: Andrew Muller moved page Testing for CSRF (OWASP-SM-005) to Testing for CSRF (OTG-SESS-005): Align with Common Numbering

2014-07-31T14:19:05Z

Andrew Muller moved page Testing for CSRF (OWASP-SM-005) to Testing for CSRF (OTG-SESS-005): Align with Common Numbering

Jane O'Connor: Final edit

2014-05-17T16:57:00Z

Final edit

Show changes

David Fern at 14:04, 6 November 2012

2012-11-06T14:04:51Z

Mmeucci at 14:49, 9 October 2012

2012-10-09T14:49:39Z

Rick.mitchell: Minor correction.

2012-05-31T13:57:10Z

Minor correction.

D0ubl3 h3lix: /* References */

2010-08-14T23:19:41Z

‎References

@@ Line 164: / Line 164: @@
 * WebScarab Spider http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
 * CSRF Tester http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project
-* Cross Site Requester http://yehg.net/lab/pr0js/pentest/cross_site_request_forgery.php (via img)
+* Cross Site Requester https://1337.yehg.net/cross_site_request_forgery.php (via img)
-* Cross Frame Loader http://yehg.net/lab/pr0js/pentest/cross_site_framing.php (via iframe)
+* Cross Frame Loader https://1337.yehg.net/cross_site_framing.php (via iframe)
 * Pinata-csrf-tool http://code.google.com/p/pinata-csrf-tool/
@@ Line 175: / Line 175: @@
 * Oldest known post - http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan
 * Cross-site Request Forgery FAQ - http://www.cgisecurity.com/articles/csrf-faq.shtml
-* A Most-Neglected Fact About Cross Site Request Forgery (CSRF) - [http://yehg.net/lab/pr0js/view.php/A_Most-Neglected_Fact_About_CSRF.pdf  http://yehg.net/lab/pr0js/view.php/A_Most-Neglected_Fact_About_CSRF.pdf ]
+* A Most-Neglected Fact About Cross Site Request Forgery (CSRF) - http://yehg.net/lab/pr0js/view.php/A_Most-Neglected_Fact_About_CSRF.pdf
 ==Remediation==

← Older revision		Revision as of 23:29, 12 April 2016
Line 141:		Line 141:
	Resources accessible via HTTP GET requests are easily vulnerable, though POST requests can be automated via Javascript and are vulnerable as well; therefore, the use of POST alone is not enough to correct the occurrence of CSRF vulnerabilities.		Resources accessible via HTTP GET requests are easily vulnerable, though POST requests can be automated via Javascript and are vulnerable as well; therefore, the use of POST alone is not enough to correct the occurrence of CSRF vulnerabilities.

		+	In case of POST, the following sample can be used.
		+	* Step 1. Create a HTML as below
		+	* Step 2. Update the HTML to malicious site
		+	* Step 3. Send the link http://maliciousSite/CSRF.html to victim to click it.
		+
		+	<pre>
		+
		+	<html>
		+	<body onload='document.CSRF.submit()'>
		+
		+	<form action='http://tagetWebsite/Authenticate.jsp' method='POST' name='CSRF'>
		+	<input type='hidden' name='name' value='Hacked'>
		+	<input type='hidden' name='password' value='Hacked'>
		+	</form>
		+
		+	</body>
		+	</html>
		+
		+	</pre>

	==Tools==		==Tools==

@@ Line 3: / Line 3: @@
 ==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 or 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.
+[[CSRF]] is an attack that 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 or 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.
 CSRF relies on the following:
-) Web browser behavior regarding the handling of session-related information such as cookies and http authentication information;<br>
+# Web browser behavior regarding the handling of session-related information such as cookies and http authentication information
-) Knowledge by the attacker of valid web application URLs;<br>
+# Knowledge by the attacker of valid web application URLs
-) Application session management relying only on information which is known by the browser;<br>
+# Application session management relying only on information which is known by the browser
-) Existence of HTML tags whose presence cause immediate access to an http[s] resource; for example the image tag ''img''.<br>
+# Existence of HTML tags whose presence cause immediate access to an http[s] resource; for example the image tag ''img''
 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) "Known by the browser” refers to information such as cookies, or http-based authentication information (such as Basic Authentication; and not form-based authentication), which are stored by the browser and subsequently present 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:
@@ Line 37: / Line 29: @@
 * 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 and 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:
@@ Line 55: / Line 45: @@
 </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:
@@ Line 65: / Line 53: @@
 * 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
@@ Line 79: / Line 64: @@
 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 and session information is stored in a cookie.
 Let's suppose the 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

@@ Line 1: / Line 1: @@
 {{Template:OWASP Testing Guide v4}}
-==Brief Summary==
+==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 or 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.
 CSRF relies on the following:
@@ Line 159: / Line 132: @@
-'''Countermeasures.'''
 The following countermeasures are divided among recommendations to users and to developers.
@@ Line 187: / Line 204: @@
 *Automatic log out 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==
+===Description of CSRF Vulnerabilities===
-For a black box test the tester must know URLs in the restricted (authenticated) area. If they possess valid credentials, they can assume both roles – the attacker and the victim. In this case, testers know the URLs to be tested just by browsing around the application.
+See the OWASP article on [[CSRF]] Vulnerabilities.
-Otherwise, if testers don’t have valid credentials available, they 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.
+===How to Avoid CSRF Vulnerabilities===
-* let ''u'' the URL being tested; for example, u = http://www.example.com/action
+===How to Review Code for CSRF Vulnerabilities===
-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. "Client side values” 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).
+===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.

@@ Line 176: / Line 176: @@
 ==References==
 '''Whitepapers'''<br>
 * 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

← Older revision	Revision as of 14:19, 31 July 2014
(No difference)

← Older revision		Revision as of 14:49, 9 October 2012
Line 1:		Line 1:
−	{{Template:OWASP Testing Guide v3}}	+	{{Template:OWASP Testing Guide v4}}

	==Brief Summary==		==Brief Summary==

@@ Line 172: / Line 172: @@
 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.
+Resources accessible via HTTP GET requests are easily vulnerable, though POST requests can be automated via Javascript and are vulnerable as well; therefore, the use of POST alone is not enough to correct the occurrence of CSRF vulnerabilities.
 ==References==