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
(Black Box testing and example)
m (Change heading formatting)
 
(55 intermediate revisions by 12 users not shown)
Line 1: Line 1:
{{Template:OWASP Testing Guide v2}}
+
{{Template:OWASP Testing Guide v4}}
  
== Brief Summary ==
+
== Summary ==
<br>
 
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.<br><br>
 
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.<br><br>
 
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.
 
<br>
 
 
 
== Description of the Issue ==
 
<br>
 
Problems related to Authentication Schema could be found at different stages of software development life cycle (SDLC), like design, development and deployment phase.<br><br>
 
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.<br><br>
 
'''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.<br><br>
 
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.
 
 
 
<br>
 
  
== Black Box testing and example ==
+
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.
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:
+
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.
* Direct page request
 
* Parameter Modification
 
* Session ID Prediction
 
* Sql Injection
 
  
<br>
 
=== Bypassing authentication schema methods ===
 
  
'''Direct page request'''
+
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 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 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.
  
Several web applications implement access control only inside the login page,
 
  
otherwise if a user requests directly a different page     in the designed protected
+
== How to Test ==
 +
=== 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]])
 +
* Parameter modification
 +
* Session ID prediction
 +
* SQL injection
  
area, the authentication schema could be bypassed.
+
<br>
 
+
====Direct page request====
[[Image:basm-directreq.jpg]]
 
  
 +
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.
  
'''Parameter Modification'''
 
  
 +
<center>[[Image:basm-directreq.jpg]]</center>
  
Another problem related to authentication design is to let the application verify a
 
  
succesful login upon fixed value parameters.
+
====Parameter Modification====
  
Therefore a user could modify these parameters to gain access to the protected areas  
+
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.
  
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 69: Line 46:
 
Connection: close                                           
 
Connection: close                                           
 
Content-Type: text/html; charset=iso-8859-1                 
 
Content-Type: text/html; charset=iso-8859-1                 
                                                           
+
 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">           
 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">           
 
<HTML><HEAD>                                                 
 
<HTML><HEAD>                                                 
 
</HEAD><BODY>                                               
 
</HEAD><BODY>                                               
<H1>You Are Auhtenticated</H1>                               
+
<H1>You Are Authenticated</H1>                               
</BODY></HTML></pre>
+
</BODY></HTML>
 +
</pre>
 +
 
 +
<center>[[Image:basm-parammod.jpg]]</center>
 +
 
 +
 
 +
====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.
 +
 
 +
 
 +
In the following figure, values inside cookies increase linearly, so it could be easy for an attacker to guess a valid session ID.
 +
 
 +
 
 +
<center>[[Image:basm-sessid.jpg]]</center>
 +
 
 +
 
 +
In the following figure, values inside cookies change only partially, so it's possible to restrict a brute force attack to the defined fields shown below.
 +
 
  
[[Image:basm-parammod.jpg]]
+
<center>[[Image:basm-sessid2.jpg]]</center>
  
  
'''Session Issues'''
+
====SQL Injection (HTML Form Authentication)====
* Session ID Prediction
 
Many web applications manage authentication using session identification
 
  
values(SESSION ID). Therefore if Session ID generation is predictable a malicious
+
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.
  
user could be able to find a valid session ID and gain unauthorized access to the
 
  
application, impersonating  a previously authenticated user.
+
<center>[[Image:basm-sqlinj.jpg]]</center>
  
In the following figure values inside cookies increase linearly, so could be easy
 
  
for an attacker to guess a valid session ID.
+
The following figure shows that with a simple SQL injection attack, it is sometimes possible to bypass the authentication form.
  
[[Image:basm-sessid.jpg]]
 
  
In the following figure values inside cookies change only partially, so it's
+
<center>[[Image:basm-sqlinj2.gif]]</center>
  
possible to restrict a bruteforce attack to the defined fields shown below.
 
  
[[Image:basm-sessid2.jpg]]
+
=== 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.
  
'''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 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 back end database is compared to the one supplied.
  
in Owasp Testing Guide for either common and advanced readers.
+
<pre>
 +
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. }
 +
</pre>
  
[[Image:basm-sqlinj.jpg]]
 
  
The following figure shows that with simple sql injection it's possible to bypass  
+
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:
  
the authentication form.
+
a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}
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]]
+
==Tools==
 +
* [[OWASP WebScarab Project|WebScarab]]
 +
* [[OWASP WebGoat Project|WebGoat]]
 +
* [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy (ZAP)]
  
<br>
 
  
== Gray Box testing and example ==
 
'''Testing for Topic X vulnerabilities:'''<br>
 
...<br>
 
'''Result Expected:'''<br>
 
...<br><br>
 
 
== References ==
 
== References ==
 
'''Whitepapers'''<br>
 
'''Whitepapers'''<br>
...<br>
+
* Mark Roxberry: "PHPBB 2.0.13 vulnerability"
'''Tools'''<br>
+
* David Endler: "Session ID Brute Force Exploitation and Prediction" - http://www.cgisecurity.com/lib/SessionIDs.pdf
* WebScarab: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
 
* WebGoat: http://www.owasp.org/index.php/OWASP_WebGoat_Project
 
 
 
{{Category:OWASP Testing Project AoC}}
 
[[OWASP Testing Guide v2 Table of Contents]]
 
{{Template:Stub}}
 

Latest revision as of 14:44, 5 August 2014

This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project

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.


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:

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


How to Test

Black Box testing

There are several methods of bypassing the authentication schema that is used by a web application:

  • Direct page request (forced browsing)
  • Parameter modification
  • Session ID prediction
  • SQL injection


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.


Basm-directreq.jpg


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.

http://www.site.com/page.asp?authenticated=no 
[email protected] /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 Authenticated</H1>                              
</BODY></HTML>
Basm-parammod.jpg


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.


In the following figure, values inside cookies increase linearly, so it 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 brute force attack to the defined fields shown below.


Basm-sessid2.jpg


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.


Basm-sqlinj.jpg


The following figure shows that with a simple SQL injection attack, it is sometimes possible to bypass the authentication form.


Basm-sqlinj2.gif


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.


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 back end 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 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";}


Tools


References

Whitepapers