This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing for Bypassing Authentication Schema (OTG-AUTHN-004)"

From OWASP
Jump to: navigation, search
Line 1: Line 1:
 +
[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>
 
{{Template:OWASP Testing Guide v2}}
 
{{Template:OWASP Testing Guide v2}}
  
Line 121: Line 122:
 
'''Put a reference to the PHPBB 2.0.13 vulnerability -Roxberry'''
 
'''Put a reference to the PHPBB 2.0.13 vulnerability -Roxberry'''
 
'''Whitepapers'''<br>
 
'''Whitepapers'''<br>
−
David Endler - Session ID Brute Force Exploitation and Prediction -  
+
David Endler: "Session ID Brute Force Exploitation and Prediction" - http://www.cgisecurity.com/lib/SessionIDs.pdf
−
http://www.cgisecurity.com/lib/SessionIDs.pdf
 
  
 
<br>
 
<br>
Line 128: Line 128:
 
* WebScarab: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
 
* WebScarab: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
 
* WebGoat: http://www.owasp.org/index.php/OWASP_WebGoat_Project
 
* WebGoat: http://www.owasp.org/index.php/OWASP_WebGoat_Project
 +
 +
  
 
{{Category:OWASP Testing Project AoC}}
 
{{Category:OWASP Testing Project AoC}}
−
{{Template:Stub}}
 

Revision as of 21:16, 15 November 2006

[Up]
OWASP Testing Guide v2 Table of Contents

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.

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.

Description of the Issue

Problems related to Authentication Schema could be found at different stages of software development life cycle (SDLC), like design, development and deployment phase.

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.

Problems in the development phase are for example the incorrect implementation of input validation functionalities, or not following the security best practices for the specific language.

In addition, there are issues during application setup (installation and configuration activities) due to a lack in required technical skills, or due to poor documentation available.

Black Box testing and example

There are several methods to bypass the authentication schema in use by a web application:

  • Direct page request
  • Parameter Modification
  • Session ID Prediction
  • Sql Injection


Direct page request

Several web applications implement access control only inside the login page, otherwise if a user requests directly a different page in the designed protected area, the authentication schema could be bypassed.


Basm-directreq.jpg


Parameter Modification

Another problem related to authentication design is to let the application verify a succesful login upon fixed value parameters. Therefore a user could modify these parameters to gain access to the protected areas without providing valid credentials. 

http://www.site.com/page.asp?authenticated=no 
raven@blackbox /home $nc www.site.com 80                    
GET /page.asp?authenticated=yes HTTP/1.0                    
                                                            
HTTP/1.1 200 OK                                             
Date: Sat, 11 Nov 2006 10:22:44 GMT                         
Server: Apache                                              
Connection: close                                           
Content-Type: text/html; charset=iso-8859-1                 
                                                            
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">          
<HTML><HEAD>                                                
</HEAD><BODY>                                               
<H1>You Are Auhtenticated</H1>                              
</BODY></HTML>


Basm-parammod.jpg


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.

In the following figure values inside cookies increase linearly, so could be easy for an attacker to guess a valid session ID.


Basm-sessid.jpg


In the following figure values inside cookies change only partially, so it's possible to restrict a bruteforce attack to the defined fields shown below.


Basm-sessid2.jpg


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.


Basm-sqlinj.jpg


The following figure shows that with simple sql injection, it is possible to bypass the authentication form.


Basm-sqlinj2.gif


Gray Box testing and example

This should be rewritten from the point of view of a tester not an attacker - Roxberry
In the case an attacker has been able to retrieve the application source code by exploiting a previosly discovered vulnerability (e.g. directory traversal), or from a web repository (Open Source Applications), 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 unserialize() function parse user supplied cookie and set values inside $row array. At line 10 user md5 password hash stored inside the backend database is compared to the one supplied. 

1.  if ( isset($HTTP_COOKIE_VARS[$cookiename . '_sid']) ||
2.  {
3.  $sessiondata = isset( $HTTP_COOKIE_VARS[$cookiename . '_data'] ) ?
4. 
5.  unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename . '_data'])) : array();
6. 
7.  $sessionmethod = SESSION_METHOD_COOKIE;
8.  }
9. 
10. if( md5($password) == $row['user_password'] && $row['user_active'] )
11. 
12. {
13. $autologin = ( isset($HTTP_POST_VARS['autologin']) ) ? TRUE : 0;
14. }

In PHP a comparison between a string value and a boolean value (1 - "TRUE") is always "TRUE", so supplying the following string (important part is "b:1") to the userialize() function is possible to bypass the authentication control: 

a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}


References

Put a reference to the PHPBB 2.0.13 vulnerability -Roxberry Whitepapers
David Endler: "Session ID Brute Force Exploitation and Prediction" - http://www.cgisecurity.com/lib/SessionIDs.pdf


Tools


OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents

Retrieved from "https://wiki.owasp.org/index.php?title=Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004)&oldid=12813"