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
(References)
(Bypassing authentication schema methods)
Line 19: Line 19:
 
== Black Box testing and example ==
 
== Black Box testing and example ==
 
There are several methods to bypass the authentication schema in use by a web application:
 
There are several methods to bypass the authentication schema in use by a web application:
 +
* Direct page request
 +
* Parameter Modification
 +
* Session ID Prediction
 +
* Session Fixation
 +
* Sql Injection
 +
 +
<br>
 +
== Black Box testing and example ==
 +
There are several methods to bypass the authentication schema in use by a web
 +
 +
application:
 
* Direct page request
 
* Direct page request
 
* Parameter Modification
 
* Parameter Modification
Line 30: Line 41:
 
'''Direct page request'''
 
'''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.
+
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.
  
 
[[Image:basm-directreq.jpg]]
 
[[Image:basm-directreq.jpg]]
Line 38: Line 53:
  
  
Another problem related to authentication design is to let the application verify a succesful login upon fixed value parameters.
+
Another problem related to authentication design is to let the application verify a  
  
Therefore a user could modify these parameters to gain access to the protected areas without providing valid credentials.
+
succesful login upon fixed value parameters.
 +
 
 +
Therefore a user could modify these parameters to gain access to the protected areas  
 +
 
 +
without providing valid credentials.
 
<pre>http://www.site.com/page.asp?authenticated=no </pre>
 
<pre>http://www.site.com/page.asp?authenticated=no </pre>
  
Line 63: Line 82:
 
'''Session Issues'''
 
'''Session Issues'''
 
* Session ID Prediction
 
* 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 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.
  
 
[[Image:basm-sessid.jpg]]
 
[[Image: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.
  
 
[[Image:basm-sessid2.jpg]]
 
[[Image:basm-sessid2.jpg]]
Line 71: Line 104:
  
 
'''Sql Injection (HTML Form Authentication)'''
 
'''Sql Injection (HTML Form Authentication)'''
 +
SQL Injection is a widely known range of techniques. We are not going to describe
  
 +
this technique into detail, because it's possible to find many dedicated paragraphs
 +
 +
in Owasp Testing Guide for either common and advanced readers.
  
 
[[Image:basm-sqlinj.jpg]]
 
[[Image:basm-sqlinj.jpg]]
 +
 +
The following figure shows that with simple sql injection it's possible to bypass
 +
 +
the authentication form.
 +
The Example is obfuscated because it's part of OWASP WebGoat suite, and to let the
 +
 +
reader experiment by himself without knowing the solution.
  
 
[[Image:basm-sqlinj2.gif]]
 
[[Image:basm-sqlinj2.gif]]

Revision as of 15:19, 11 November 2006

OWASP Testing Guide v2 Table of Contents

Brief Summary


While most most application require authentication for gaining access to private information or tasks, not every authentication method is able to provide adequate security level.

Negligence, ignorance or simple understatement of the security threats often result in authentication schemes that can be easily 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 compulsory authentication tampering with requests and tricking the application into thinking that we're already authenticated either by modifying the given URL parameter or by manipulating 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 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
  • Session Fixation
  • Sql Injection


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
  • Session Fixation
  • Sql Injection


Bypassing authentication schema methods

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 Issues

  • 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 range of techniques. We are not going to describe

this technique into detail, because it's possible to find many dedicated paragraphs

in Owasp Testing Guide for either common and advanced readers.

Basm-sqlinj.jpg

The following figure shows that with simple sql injection it's possible to bypass

the authentication form. The Example is obfuscated because it's part of OWASP WebGoat suite, and to let the

reader experiment by himself without knowing the solution.

Basm-sqlinj2.gif


Gray Box testing and example

Testing for Topic X vulnerabilities:
...
Result Expected:
...

References

Whitepapers
...
Tools


OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents OWASP Testing Guide v2 Table of Contents

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.