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)"
(→Black Box testing and example: Added more instructions on "how" rather than "what") |
|||
| Line 22: | Line 22: | ||
== 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 | + | * Direct page request (forced browsing) |
* Parameter Modification | * Parameter Modification | ||
* Session ID Prediction | * Session ID Prediction | ||
| Line 30: | Line 30: | ||
'''Direct page request''' | '''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 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 38: | Line 38: | ||
'''Parameter Modification''' | '''Parameter Modification''' | ||
| − | Another problem related to authentication design is | + | Another problem related to authentication design is when the application verifies a succesful login based on 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. |
| − | |||
<pre>http://www.site.com/page.asp?authenticated=no </pre> | <pre>http://www.site.com/page.asp?authenticated=no </pre> | ||
| Line 55: | Line 54: | ||
<HTML><HEAD> | <HTML><HEAD> | ||
</HEAD><BODY> | </HEAD><BODY> | ||
| + | <H1>You Are Auhtenticated</H1> | ||
| + | </BODY></HTML></pre> | ||
| + | |||
| + | |||
| + | [[Image: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 find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user. | ||
| + | |||
| + | The tester can use a tool such as WebScarab to perform session ID analysis. In the following figure, cookies values increase linearly as each one is generated, making it easy for an attacker to guess a valid session ID. The guessed session ID can then be inserted into the cookie in the tester's browser. | ||
| + | |||
| + | |||
| + | [[Image:basm-sessid.jpg]] | ||
| + | |||
| + | |||
| + | In the following figure, cookies values change only partially, so it's possible to restrict a bruteforce attack to the fields shown below. | ||
| + | |||
| + | |||
| + | [[Image: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. | ||
| + | |||
| + | |||
| + | [[Image:basm-sqlinj.jpg]] | ||
| + | |||
| + | |||
| + | The following figure shows that with simple sql injection, it is possible to bypass the authentication form. | ||
| + | |||
| + | |||
| + | [[Image:basm-sqlinj2.gif]] | ||
| + | |||
<H1>You Are Auhtenticated</H1> | <H1>You Are Auhtenticated</H1> | ||
</BODY></HTML></pre> | </BODY></HTML></pre> | ||
Revision as of 21:22, 5 February 2007
[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 (forced browsing)
- Parameter Modification
- Session ID Prediction
- Sql Injection
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 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
Another problem related to authentication design is when the application verifies a succesful login based on 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.
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>
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 find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.
The tester can use a tool such as WebScarab to perform session ID analysis. In the following figure, cookies values increase linearly as each one is generated, making it easy for an attacker to guess a valid session ID. The guessed session ID can then be inserted into the cookie in the tester's browser.
In the following figure, cookies values change only partially, so it's possible to restrict a bruteforce attack to the fields shown below.
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.
The following figure shows that with simple sql injection, it is possible to bypass the authentication form.
You Are Auhtenticated
</BODY></HTML></pre>
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.
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.
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.
The following figure shows that with simple sql injection, it is possible to bypass the authentication form.
References
Whitepapers
- Mark Roxberry: "PHPBB 2.0.13 vulnerability"
- David Endler: "Session ID Brute Force Exploitation and Prediction" - http://www.cgisecurity.com/lib/SessionIDs.pdf
Tools
- WebScarab: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
- WebGoat: http://www.owasp.org/index.php/OWASP_WebGoat_Project
OWASP Testing Guide v2
Here is the OWASP Testing Guide v2 Table of Contents
