Testing for Bypassing Authentication Schema (OTG-AUTHN-004) - Revision history

Andrew Muller: Change heading formatting

2014-08-05T14:44:46Z

Change heading formatting

Andrew Muller: Andrew Muller moved page Testing for Bypassing Authentication Schema (OWASP-AT-005) to Testing for Bypassing Authentication Schema (OTG-AUTHN-004): Align with Common Numbering

2014-08-05T13:26:01Z

Andrew Muller moved page Testing for Bypassing Authentication Schema (OWASP-AT-005) to Testing for Bypassing Authentication Schema (OTG-AUTHN-004): Align with Common Numbering

Jane O'Connor: Added Andrew's changes.

2014-08-01T19:43:16Z

Added Andrew's changes.

Jane O'Connor: Final edit

2014-05-14T17:49:39Z

Final edit

Lvsteche: Minor corrections/rewrites.

2014-03-22T08:11:03Z

Minor corrections/rewrites.

Mmeucci at 14:46, 9 October 2012

2012-10-09T14:46:32Z

MediaWiki spam cleanup: Reverting to last version not containing links to www.textlanooumonv.com

2009-05-27T18:29:24Z

Reverting to last version not containing links to www.textlanooumonv.com

Deleted user at 16:22, 22 May 2009

2009-05-22T16:22:29Z

KirstenS: /* Description of the Issue */

2009-02-03T19:42:53Z

‎Description of the Issue

KirstenS: /* Brief Summary */

2009-02-03T19:42:23Z

‎Brief Summary

@@ Line 16: / Line 16: @@
 == How to Test ==
-== Black Box testing ==
+=== Black Box testing ===
 There are several methods of bypassing the authentication schema that is used by a web application:
 * Direct page request ([[Forced_browsing|forced browsing]])
@@ Line 24: / Line 24: @@
 <br>
-'''Direct page request'''
+====Direct page request====
 If a web application implements access control only on the log in page, the authentication schema could be bypassed.  For example, if a user directly requests a different page via forced browsing, that page may not check the credentials of the user before granting access. Attempt to directly access a protected page through the address bar in your browser to test using this method.
@@ Line 32: / Line 32: @@
-'''Parameter Modification'''
+====Parameter Modification====
 Another problem related to authentication design is when the application verifies a successful log in on the basis of a fixed value parameters. A user could modify these parameters to gain access to the protected areas without providing valid credentials. In the example below, the "authenticated" parameter is changed to a value of "yes", which allows the user to gain access.  In this example, the parameter is in the URL, but a proxy could also be used to modify the parameter, especially when the parameters are sent as form elements in a POST request or when the parameters are stored in a cookie.
@@ Line 57: / Line 57: @@
-'''Session ID Prediction'''
+====Session ID Prediction====
 Many web applications manage authentication by using session identifiers (session IDs). Therefore, if session ID generation is predictable, a malicious user could be able to find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.
@@ Line 74: / Line 74: @@
-'''SQL Injection (HTML Form Authentication)'''
+====SQL Injection (HTML Form Authentication)====
 SQL Injection is a widely known attack technique. This section is not going to describe this technique in detail as there are several sections in this guide that explain injection techniques beyond the scope of this section.
@@ Line 88: / Line 88: @@
-== Gray Box Testing ==
+=== Gray Box Testing ===
 If an attacker has been able to retrieve the application source code by exploiting a previously discovered vulnerability (e.g., directory traversal), or from a web repository (Open Source Applications), it could be possible to perform refined attacks against the implementation of the authentication process.
@@ Line 116: / Line 116: @@
   a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}
@@ Line 122: / Line 128: @@
 * Mark Roxberry: "PHPBB 2.0.13 vulnerability"
 * David Endler: "Session ID Brute Force Exploitation and Prediction" - http://www.cgisecurity.com/lib/SessionIDs.pdf

@@ Line 1: / Line 1: @@
 {{Template:OWASP Testing Guide v4}}
-== Brief Summary ==
+== Summary ==
 While most applications require authentication to gain access to private information or to execute tasks, not every authentication method is able to provide adequate security. Negligence, ignorance, or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the log in page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.
@@ Line 8: / Line 8: @@
 In addition, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that the user is already authenticated.  This can be accomplished either by modifying the given URL parameter, by manipulating the form, or by counterfeiting sessions.
 Problems related to the authentication schema can be found at different stages of the software development life cycle (SDLC), like the design, development, and deployment phases:
@@ Line 17: / Line 15: @@
 == Black Box testing ==
 There are several methods of bypassing the authentication schema that is used by a web application:
@@ Line 125: / Line 124: @@
 <br>
-'''Tools'''<br>
+==Tools==
 * [[OWASP WebScarab Project|WebScarab]]
 * [[OWASP WebGoat Project|WebGoat]]

@@ Line 3: / Line 3: @@
 == Brief Summary ==
-While most applications require authentication for gaining access to private information or to execute tasks, not every authentication method is able to provide adequate security.
+While most applications require authentication to gain access to private information or to execute tasks, not every authentication method is able to provide adequate security. Negligence, ignorance, or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the log in page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.
-In addition to this, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that the user is already authenticated.  This can be accomplished either by modifying the given URL parameter, by manipulating the form or by counterfeiting sessions.
+In addition, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that the user is already authenticated.  This can be accomplished either by modifying the given URL parameter, by manipulating the form, or by counterfeiting sessions.
 == Description of the Issue ==
-Problems related to the authentication schema could be found at different stages of the software development life cycle (SDLC), like design, development, and deployment phase:
+Problems related to the authentication schema can be found at different stages of the software development life cycle (SDLC), like the design, development, and deployment phases:
-* In the design phase errors could include a wrong definition of application sections to be protected, the choice of not applying strong encryption protocols for securing the transmission of credentials, and many more.
+* In the design phase errors can include a wrong definition of application sections to be protected, the choice of not applying strong encryption protocols for securing the transmission of credentials, and many more.
-* In the development phase errors could include for example the incorrect implementation of input validation functionalities, or not following the security best practices for the specific language.
+* In the development phase errors can include the incorrect implementation of input validation functionality or not following the security best practices for the specific language.
-* In the application deployment phase, there may be issues during the application setup (installation and configuration activities) due to a lack in required technical skills, or due to the lack of good documentation being available.
+* In the application deployment phase, there may be issues during the application setup (installation and configuration activities) due to a lack in required technical skills or due to the lack of good documentation.
-== Black Box testing and example ==
-There are several methods to bypass the authentication schema in use by a web application:
+== Black Box testing ==
 * Direct page request ([[Forced_browsing|forced browsing]])
 * Parameter modification
@@ Line 26: / Line 27: @@
 '''Direct page request'''
-If a web application implements access control only on the login page, the authentication schema could be bypassed.  For example, if a user directly requests a different page via forced browsing, that page may not check the credentials of the user before granting access. Attempt to directly access a protected page through the address bar in your browser to test using this method.
+If a web application implements access control only on the log in page, the authentication schema could be bypassed.  For example, if a user directly requests a different page via forced browsing, that page may not check the credentials of the user before granting access. Attempt to directly access a protected page through the address bar in your browser to test using this method.
@@ Line 34: / Line 35: @@
 '''Parameter Modification'''
-Another problem related to authentication design is when the application verifies a successful login on the basis of a fixed value parameters. A user could modify these parameters to gain access to the protected areas without providing valid credentials. In the example below, the "authenticated" parameter is changed to a value of "yes", which allows the user to gain access.  In this example, the parameter is in the URL, but a proxy could also be used to modify the parameter, especially when the parameters are sent as form elements in a POST request or when the parameters are stored in a cookie.
+Another problem related to authentication design is when the application verifies a successful log in on the basis of a fixed value parameters. A user could modify these parameters to gain access to the protected areas without providing valid credentials. In the example below, the "authenticated" parameter is changed to a value of "yes", which allows the user to gain access.  In this example, the parameter is in the URL, but a proxy could also be used to modify the parameter, especially when the parameters are sent as form elements in a POST request or when the parameters are stored in a cookie.
 <pre>http://www.site.com/page.asp?authenticated=no </pre>
@@ Line 59: / Line 60: @@
 '''Session ID Prediction'''
-Many web applications manage authentication using session identifiers (session IDs). Therefore, if session ID generation is predictable, a malicious user could be able to find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.
+Many web applications manage authentication by using session identifiers (session IDs). Therefore, if session ID generation is predictable, a malicious user could be able to find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.
 In the following figure, values inside cookies increase linearly, so it could be easy for an attacker to guess a valid session ID.
@@ Line 71: / Line 73: @@
 <center>[[Image:basm-sessid2.jpg]]</center>
 '''SQL Injection (HTML Form Authentication)'''
-SQL Injection is a widely known attack technique. We are not going to describe this technique in detail in this section; there are several sections in this guide that explain injection techniques beyond the scope of this section.
+SQL Injection is a widely known attack technique. This section is not going to describe this technique in detail as there are several sections in this guide that explain injection techniques beyond the scope of this section.
@@ Line 87: / Line 88: @@
 <center>[[Image:basm-sqlinj2.gif]]</center>
-== Gray Box Testing And Example ==
 If an attacker has been able to retrieve the application source code by exploiting a previously discovered vulnerability (e.g., directory traversal), or from a web repository (Open Source Applications), it could be possible to perform refined attacks against the implementation of the authentication process.
-In the following example (PHPBB 2.0.13 - Authentication Bypass Vulnerability), at line 5, the unserialize() function parses a user supplied cookie and sets values inside the $row array. At line 10, the user's md5 password hash stored inside the backend database is compared to the one supplied.
 <pre>
 .  if ( isset($HTTP_COOKIE_VARS[$cookiename . '_sid']) ||
@@ Line 106: / Line 112: @@
 . }
 </pre>
 In PHP, a comparison between a string value and a boolean value (1 - "TRUE") is always "TRUE", so by supplying the following string (the important part is "b:1") to the unserialize() function, it is possible to bypass the authentication control:
-a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}
+ a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}
 == References ==

@@ Line 7: / Line 7: @@
 Negligence, ignorance, or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the login page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.
-In addition to this, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that we're already authenticated.  This can be accomplished either by modifying the given URL parameter or by manipulating the form or by counterfeiting sessions.
+In addition to this, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that the user is already authenticated.  This can be accomplished either by modifying the given URL parameter, by manipulating the form or by counterfeiting sessions.
 == Description of the Issue ==
-Problems related to Authentication Schema could be found at different stages of the software development life cycle (SDLC), like design, development, and deployment phase.
+Problems related to the authentication schema could be found at different stages of the software development life cycle (SDLC), like design, development, and deployment phase:
+* In the design phase errors could include a wrong definition of application sections to be protected, the choice of not applying strong encryption protocols for securing the transmission of credentials, and many more.
-Examples of design errors include a wrong definition of application parts to be protected, the choice of not applying strong encryption protocols for securing authentication data exchange, and many more.
+* In the development phase errors could include for example the incorrect implementation of input validation functionalities, or not following the security best practices for the specific language.
+* In the application deployment phase, there may be issues during the application setup (installation and configuration activities) due to a lack in required technical skills, or due to the lack of good documentation being available.
 == Black Box testing and example ==
 There are several methods to bypass the authentication schema in use by a web application:
-* Direct page request (forced browsing)
+* Direct page request ([[Forced_browsing|forced browsing]])
-* Parameter Modification
+* Parameter modification
-* Session ID Prediction
+* Session ID prediction
-* SQL Injection
+* SQL injection
 <br>
@@ Line 37: / Line 34: @@
 '''Parameter Modification'''
-Another problem related to authentication design is when the application verifies a successful login on the basis of a fixed value parameters. A user could modify these parameters to gain access to the protected areas without providing valid credentials. In the example below, the "authenticated" parameter is changed to a value of "yes", which allows the user to gain access.  In this example, the parameter is in the URL, but a proxy could also be used to modify the parameter, especially when the parameters are sent as form elements in a POST request.
+Another problem related to authentication design is when the application verifies a successful login on the basis of a fixed value parameters. A user could modify these parameters to gain access to the protected areas without providing valid credentials. In the example below, the "authenticated" parameter is changed to a value of "yes", which allows the user to gain access.  In this example, the parameter is in the URL, but a proxy could also be used to modify the parameter, especially when the parameters are sent as form elements in a POST request or when the parameters are stored in a cookie.
 <pre>http://www.site.com/page.asp?authenticated=no </pre>
@@ Line 53: / Line 50: @@
 <HTML><HEAD>
 </HEAD><BODY>
-<H1>You Are Auhtenticated</H1>
+<H1>You Are Authenticated</H1>
 </BODY></HTML>
 </pre>
@@ Line 62: / Line 59: @@
 '''Session ID Prediction'''
-Many web applications manage authentication using session identification values (SESSION ID). Therefore, if session ID generation is predictable, a malicious user could be able to find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.
+Many web applications manage authentication using session identifiers (session IDs). Therefore, if session ID generation is predictable, a malicious user could be able to find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.
 In the following figure, values inside cookies increase linearly, so it could be easy for an attacker to guess a valid session ID.

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

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

← Older revision	Revision as of 13:26, 5 August 2014
(No difference)

← Older revision		Revision as of 18:29, 27 May 2009
Line 1:		Line 1:
−	~~http://www.textlanooumonv.com~~
	{{Template:OWASP Testing Guide v3}}		{{Template:OWASP Testing Guide v3}}

← Older revision		Revision as of 16:22, 22 May 2009
Line 1:		Line 1:
		+	http://www.textlanooumonv.com
	{{Template:OWASP Testing Guide v3}}		{{Template:OWASP Testing Guide v3}}