OWASP - User contributions [en]

Testing for Vulnerable Remember Password (OTG-AUTHN-005)

2013-12-08T11:31:06Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Summary ==

Browsers will sometimes ask a user if they wish to remember the password that they just entered. The browser will then store the password, and automatically enter it whenever the same authentication portal is visited. This is a convenience for the user.
 

== Description of the Issue ==
Whilst a convenience for the user, having the browser storing passwords is also a convenience for an attacker. 
If an attacker can gain access to the victim's browser (e.g. through a Cross Site Scripting attack, or through a shared computer), then they can retrieve the stored passwords. It is not uncommon for browsers to store these passwords in a fully retrievable manner, but even if the browser were to store the passwords encrypted and only retrievable through the use of a master password, an attacker could retrieve the password by visiting the target authentication portal web site, entering the victim's username, and letting the browser to enter the password. 

== How to test ==

* Enter a username and password in the target authentication portal and determine whether the browser asks the user whether they want the password remembered.
* View the authentication portal's HTML source code and look for the autocomplete="off" attribute in the password form field. The code for this will usually be along the following lines:
<pre>
<INPUT TYPE="password" AUTOCOMPLETE="off">
</pre>
* Also look for passwords being stored in a cookie. Examine the cookies stored by the application. Verify that the credentials are not stored in cleartext, but are hashed. Examine the hashing mechanism: if it is a common, well-known algorithm, check for its strength; in homegrown hash functions, attempt several usernames to check whether the hash function is easily guessable. Additionally, verify that the credentials are only sent during the login phase, and not sent together with every request to the application.
* Also look for other areas where a password may be entered, e.g. a Change Password form.
* Also consider other sensitive form fields (e.g. an answer to a secret question, used for Forgotten Password forms).

== Remediation ==

Any fields that contain sensitive information and passwords should be flagged in the HTML with AUTOCOMPLETE=”off”.

Testing for Weak lock out mechanism (OTG-AUTHN-003)

2013-12-03T02:12:18Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Summary ==

Account lockout mechanisms are used to mitigate against brute force password guessing attacks. Accounts are typically locked out after 3 to 5 unsuccessful login attempts and can only be unlocked after a predetermined period of time, via a self-service unlock mechanism, or intervention by an administrator. Account lockout mechanisms require a balance between protecting accounts from unauthorized access and protecting users from being denied authorized access. 
Note that this test should cover all aspects of authentication where lock out mechanisms would be appropriate, e.g. when the user is presented with security questions during forgotten password mechanisms (see [[Testing for Weak security question/answer (OTG-AUTHN-008)]]).

== Description of the Issue ==

Without a strong lock out mechanism, the application may be susceptible to brute force attacks. After a successful brute force attack, a malicious user could have access to:

* Confidential information / data;
** Private sections of a web application could disclose confidential documents, users' profile data, financial status, bank details, users' 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.

== Test objectives ==

Evaluate the account lockout mechanism's ability to mitigate brute force password guessing.

Evaluate the reactivation mechanism's resistance to unauthorized account re-activation.

== Black Box testing and example ==

Typically, to test the strength of lockout mechanisms, you will need access to an account that you are willing to lock out. 
 
To evaluate the account lockout mechanism's ability to mitigate brute force password guessing, attempt an invalid login by using the incorrect password a number of times, before using the correct password to verify that the account was locked out. An example test may be as follows:
# Attempt to login with an incorrect password 3 times.
# Successfully login with the correct password, thereby showing that the lockout mechanism doesn't trigger after 3 incorrect authentication attempts.
# Attempt to login with an incorrect password 4 times.
# Successfully login with the correct password, thereby showing that the lockout mechanism doesn't trigger after 4 incorrect authentication attempts.
# Attempt to login with an incorrect password 5 times.
# Attempt to login with the correct password. The application returns "Your account is locked out.", thereby confirming that the account is locked out after 5 incorrect authentication attempts.
# Attempt to login with the correct password 5 minutes later. The application returns "Your account is locked out.", thereby showing that the lockout mechanism does not automatically unlock after 5 minutes.
# Attempt to login with the correct password 10 minutes later. The application returns "Your account is locked out.", thereby showing that the lockout mechanism does not automatically unlock after 10 minutes.
# Successfully login with the correct password 15 minutes later, thereby showing that the lockout mechanism automatically unlocks after a 10 to 15 minute period.
 
A CAPTCHA may hinder brute force attacks, but they can come with their own set of weaknesses (see [[Testing_for_Captcha_(OWASP-AT-012)|Testing for CAPTCHA]]), and should not replace a lockout mechanism.

 
To evaluate the reactivation mechanism's resistance to unauthorized account reactivation, initiate the reactivation mechanism and look for weaknesses. Typical reactivation mechanisms may involve secret questions/answers, or an emailed reactivation link. The reactivation link should be a unique one-time link, to stop an attacker from guessing or replaying the link and performing brute force attacks in batches. Secret questions and answers should be strong (see [[Testing_for_Weak_security_question/answer_(OTG-AUTHN-008)|Testing for Weak Security Question/Answer]]). 
Note that a reactivation mechanism is simply for unlocking accounts. It is not the same as a password recovery mechanism. 
 
Factors to consider when implementing an account lockout mechanism:

# What is the risk of brute force password guessing against the application?
# Is a CAPTCHA sufficient to mitigate this risk?
# Number of unsuccessful login attempts before lockout. Too few, and valid users may trigger the lockout too often. Too few, and the more attempts an attacker can make to brute force the account. Depending on the application function, a range of 5 to 10 unsuccessful attempts is typical.
# How will accounts be unlocked?
## Manually by an administrator. This is the most secure lockout method, but may cause inconvenience to users and take up the administrator's "valuable" time.
## After a period of time. What is the lockout period? Is this sufficient for the application being protected? e.g. a 5 minute lockout period may be a good compromise between mitigating brute force attacks and inconveniencing valid users.
## Via a self-service mechanism. Is this mechanism secure?

== Gray Box testing and example ==

== Tools ==

== References ==

See the OWASP article on [[Brute_force_attack|Brute Force]] Attacks.

== Remediation ==

Apply account reactivation mechanisms depending on the risk level. In order from lowest to highest assurance:

# Time-based lockout and reactivation
# Self-service reactivation (sends reactivation email to registered email address)
# Manual administrator reactivation
# Manual administrator reactivation with positive user identification

Testing for Weak lock out mechanism (OTG-AUTHN-003)

2013-12-03T02:01:26Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Summary ==

Account lockout mechanisms are used to mitigate against brute force password guessing attacks. Accounts are typically locked out after 3 to 5 unsuccessful login attempts and can only be unlocked after a predetermined period of time, via a self-service unlock mechanism, or intervention by an administrator. Account lockout mechanisms require a balance between protecting accounts from unauthorized access and protecting users from being denied authorized access. 
Note that this test should cover all aspects of authentication where lock out mechanisms would be appropriate, e.g. when the user is presented with security questions during forgotten password mechanisms (see [[Testing for Weak security question/answer (OTG-AUTHN-008)]]).

== Description of the Issue ==

Without a strong lock out mechanism, the application may be susceptible to brute force attacks. After a successful brute force attack, a malicious user could have access to:

* Confidential information / data;
** Private sections of a web application could disclose confidential documents, users' profile data, financial status, bank details, users' 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.

== Test objectives ==

Evaluate the account lockout mechanism's ability to mitigate brute force password guessing.

Evaluate the reactivation mechanism's resistance to unauthorized account re-activation.

== Black Box testing and example ==

Typically, to test the strength of lockout mechanisms, you will need access to an account that you are willing to lock out. 
 
To evaluate the account lockout mechanism's ability to mitigate brute force password guessing, attempt an invalid login by using the incorrect password a number of times, before using the correct password to verify that the account was locked out. An example test may be as follows:
# Attempt to login with an incorrect password 3 times.
# Successfully login with the correct password, thereby showing that the lockout mechanism doesn't trigger after 3 incorrect authentication attempts.
# Attempt to login with an incorrect password 4 times.
# Successfully login with the correct password, thereby showing that the lockout mechanism doesn't trigger after 4 incorrect authentication attempts.
# Attempt to login with an incorrect password 5 times.
# Attempt to login with the correct password. The application returns "Your account is locked out.", thereby confirming that the account is locked out after 5 incorrect authentication attempts.
# Attempt to login with the correct password 5 minutes later. The application returns "Your account is locked out.", thereby showing that the lockout mechanism does not automatically unlock after 5 minutes.
# Attempt to login with the correct password 10 minutes later. The application returns "Your account is locked out.", thereby showing that the lockout mechanism does not automatically unlock after 10 minutes.
# Successfully login with the correct password 15 minutes later, thereby showing that the lockout mechanism automatically unlocks after a 10 to 15 minute period.
 
A CAPTCHA may hinder brute force attacks, but they can come with their own set of weaknesses (see [[Testing_for_Captcha_(OWASP-AT-012)|Testing for CAPTCHA]]), and should not replace a lockout mechanism.

 
To evaluate the reactivation mechanism's resistance to unauthorized account reactivation, initiate the reactivation mechanism and look for weaknesses. Typical reactivation mechanisms may involve secret questions/answers, or an emailed reactivation link. The reactivation link should be a unique one-time link, to stop an attacker from guessing or replaying the link and performing brute force attacks in batches. Secret questions and answers should be strong (see [[Testing_for_Weak_security_question/answer_(OTG-AUTHN-008)|Testing for Weak Security Question/Answer]]). 
Note that a reactivation mechanism is simply for unlocking accounts. It is not the same as a password recovery mechanism. 
 
Factors to consider when implementing an account lockout mechanism:

# What is the risk of brute force password guessing against the application?
# Is a CAPTCHA sufficient to mitigate this risk?
# Number of unsuccessful login attempts before lockout. Too few, and valid users may trigger the lockout too often. Too few, and the more attempts an attacker can make to brute force the account. Depending on the application function, a range of 5 to 10 unsuccessful attempts is typical.
# How will accounts be unlocked?
## Manually by an administrator. This is the most secure lockout method, but may cause inconvenience to users and take up the administrator's "valuable" time.
## After a period of time. What is the lockout period? Is this sufficient for the application being protected? e.g. a 5 minute lockout period may be a good compromise between mitigating brute force attacks and inconveniencing valid users.
## Via a self-service mechanism. Is this mechanism secure?

== Gray Box testing and example ==

== Tools ==

== References ==

See the OWASP article on [[Brute_force_attack|Brute Force]] Attacks.

== Remediation ==

Implement CAPTCHA with the account logon page.

Apply account reactivation mechanisms depending on the risk level. In order from lowest to highest assurance:

# Time-based lockout and reactivation
# Self-service reactivation (sends reactivation email to registered email address)
# Manual administrator reactivation
# Manual administrator reactivation with positive user identification

Testing for default credentials (OTG-AUTHN-002)

2013-12-03T00:08:09Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
Nowadays web applications often make use of popular open source or commercial software that can be installed on servers with minimal configuration or customization by the server administrator. Moreover, a lot of hardware appliances (i.e. network routers and database servers) offer web-based configuration or administrative interfaces. 
Often these applications, once installed, are not properly configured and the default credentials provided for initial authentication and configuration are never changed. 
These default credentials are well known by penetration testers and, unfortunately, also by malicious attackers, who can use them to gain access to various types of applications. 
Furthermore, in many situations, when a new account is created on an application, a default password (with some standard characteristics) is generated. If this password is predictable and the user does not change it on the first access, this can lead an attacker to gain unauthorized access to the application.
 
== Description of the Issue ==
 
The root cause of this problem can be identified as:
* Inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components, or leave the password as default for "ease of maintenance".
* Programmers who leave backdoors to easily access and test their application and later forget to remove them.
* Applications with built-in, non-removable default accounts with a pre-set username and password.
* Applications that do not force the user to change the default credential after the first login operation.

 
== Black Box testing and example ==
 
===Testing for default credentials of common applications===

In Blackbox testing the tester knows nothing about the application and its underlying infrastructure. In reality this is often not true, and some information about the application is known. We suppose that you have identified, through the use of the techniques described in this Testing Guide under the chapter Information Gathering, at least one or more common applications that may contain accessible administrative interfaces. 
When you have identified an application interface, for example a Cisco router web interface or a Weblogic administrator portal, check that the known usernames and passwords for these devices do not result in successful authentication. To do this you can consult the manufacturer’s documentation or, in a much simpler way, you can found common credentials using a search engine or by using one of the sites or tools listed in the Reference section. 
When facing applications to which we do not have a list of default and common user accounts (due to the fact for example that the application is not widely spread) we can attempt to guess valid default credentials. 
Note that the application being tested may have an account lockout policy enabled, and multiple password guess attempts with a known username may cause the account to be locked. If it is possible to lock the administrator account, it may be troublesome for the system administrator to reset it. 
Many applications have verbose error messages that inform the site users as to the validity of entered usernames. This information will be helpful when testing for default or guessable user accounts. Such functionality can be found, for example, on the login page, password reset and forgotten password page, and sign up page. Once you have found a default username you could also start guessing passwords for this account. 
More information about this procedure can be found in the section [[Testing for User Enumeration and Guessable User Account (OWASP-AT-002)|Testing for User Enumeration and Guessable User]] and in the section [[Testing for Weak password policy (OWASP-AT-008)|Testing for Weak password policy]]. 
Since these types of default credentials are often bound to administrative accounts you can proceed in this manner:
* Try the following usernames - "admin", "administrator", "root", "system", "guest", "operator", or "super". These are popular among system administrators and are often used. Additionally you could try "qa", "test", "test1", "testing" and similar names. Attempt any combination of the above in both the username and the password fields. If the application is vulnerable to username enumeration, and you successfully manage to identify any of the above usernames, attempt passwords in a similar manner. In addition try an empty password or one of the following "password", "pass123", "password123", "admin", or "guest" with the above accounts or any other enumerated accounts. Further permutations of the above can also be attempted. If these passwords fail, it may be worth using a common username and password list and attempting multiple requests against the application. This can, of course, be scripted to save time.
* Application administrative users are often named after the application or organization. This means if you are testing an application named "Obscurity", try using obscurity/obscurity or any other similar combination as the username and password.
* When performing a test for a customer, attempt using names of contacts you have received as usernames with any common passwords.
* Attempt using all the above usernames with blank passwords.
* Review the page source and javascript either through a proxy or by viewing the source. Look for any references to users and passwords in the source. For example "If username='admin' then starturl=/admin.asp else /index.asp" (for a successful login vs a failed login). Also, if you have a valid account, then login and view every request and response for a valid login vs an invalid login, such as additional hidden parameters, interesting GET request (login=yes), etc.
* Look for account names and passwords written in comments in the source code. Also look in backup directories, etc for source code that may contain comments of interest.

===Testing for default password of new accounts===

As mentioned previously, in other situations, when a new account is created on an application, a default password is generated. This password could have some standard characteristics making it predictable and if the user does not change it on the first access (this often happens if the user is not forced to change it), this can lead an attacker to gain unauthorized access to the application. 
Advice for testing default passwords on common application (about lockout policy and verbose error messages) still remain valid also for this test. 
The Following steps can be applied to test for these types of default credentials:
* Viewing the User Registration page may help determine the expected format and length of the application usernames and passwords. If a user registration page does not exist, determine if the organization uses a standard naming convention for user names such as their email address or the name before the "@" in the email.
* Try to extrapolate from the application how usernames are generated. For example, can a user create their own username or does the system create an account for the user based on some personal information or a predictable sequence? If the application does create its own accounts in a predictable sequence, such as user7811, try fuzzing all possible accounts recursively. If you can identify a different response from the application when using a valid username and a wrong password, then you can try a brute force attack on the valid username (or quickly try any of the identified common passwords above or in the reference section).
* Try to determine if the password is predictable by creating many new accounts in quick succession to compare and determine if the passwords are predictable. If predictable, then try to correlate these with the usernames, or any enumerated accounts, and use them as a basis for a brute force attack.
* If you have identified the correct naming convention for the user name, try to “brute force” passwords with some common predictable sequence like for example dates of birth.
* Attempt using all the above usernames with blank passwords or using the username also as password value.
 
===Result Expected===
Successful authentication to the application or system being tested.

 
== Gray Box testing and example ==
 
The following steps rely on an entirely Gray Box approach. If only some of this information is available to you, refer to black box testing to fill the gaps.
* Talk to the IT personnel to determine passwords they use for administrative access and how administration of the application is undertaken.
* Examine the user database for default credentials as described in the Black Box testing section. Also check for empty password fields.
* Examine the code for hard coded usernames and passwords.
* Check for configuration files that contain usernames and passwords.
* Examine the password policy and, if the application creates its own passwords for new users, check the policy in use for this procedure.
 
===Result Expected===
Successful authentication to the application or system being tested.
 
== References ==
'''Whitepapers''' 
* CIRT http://www.cirt.net/passwords
* Government Security - Default Logins and Passwords for Networked Devices http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
* Virus.org http://www.virus.org/default-password/ 

'''Tools''' 
* Burp Intruder: http://portswigger.net/intruder/
* THC Hydra: http://www.thc.org/thc-hydra/
* Brutus: http://www.hoobie.net/brutus/
* Nikto 2: http://www.cirt.net/nikto2

Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)

2013-12-02T23:16:54Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Testing for credentials transport means to verify that the user's authentication data are transferred via an encrypted channel to avoid being intercepted by malicious users. The analysis focuses simply on trying to understand if the data travels unencrypted from the web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. The HTTPS protocol is built on TLS/SSL to encrypt the data that is transmitted and to ensure that user is being sent towards the desired site. Clearly, the fact that traffic is encrypted does not necessarily mean that it's completely safe. The security also depends on the encryption algorithm used and the robustness of the keys that the application is using, but this particular topic will not be addressed in this section. For a more detailed discussion on testing the safety of TLS/SSL channels you can refer to the chapter [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]]. Here, the tester will just try to understand if the data that users put into web forms, for example, in order to log into a web site, are transmitted using secure protocols that protect them from an attacker or not. To do this we will consider various examples.
 

== Description of the Issue ==
Nowadays, the most common example of this issue is the login page of a web application. The tester should verify that user's credentials are transmitted via an encrypted channel. In order to log into a web site, usually, the user has to fill a simple form that transmits the inserted data with the POST method. What is less obvious is that this data can be passed using the HTTP protocol, that means in a non-secure way, or using HTTPS, which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe that the transmission is insecure), but then it actually sends data via HTTPS. This test is done to be sure that an attacker cannot retrieve sensitive information by simply sniffing the net with a sniffer tool.
 

== Black Box testing and example ==
In the following examples we will use WebScarab in order to capture packet headers and to inspect them. You can use any web proxy that you prefer.

'''Case study: Sending data with POST method through HTTP''' 

Suppose that the login page presents a form with fields User, Pass, and the Submit button to authenticate and give access to the application. If we look at the header of our request with WebScarab, we get something like this: 
<pre>
POST http://www.example.com/AuthenticationServlet HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com/index.jsp
Cookie: JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S!
Content-Type: application/x-www-form-urlencoded
Content-length: 64

delegated_service=218&User=test&Pass=test&Submit=SUBMIT
</pre>

From this example the tester can understand that the POST sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password by simply sniffing the net with a tool like Wireshark.

'''Case study: Sending data with POST method through HTTPS'''

Suppose that our web application uses the HTTPS protocol to encrypt data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, the header of our POST request would be similar to the following:

<pre>
POST https://www.example.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.example.com/cgi-bin/login.cgi
Cookie: language=English;
Content-Type: application/x-www-form-urlencoded
Content-length: 50

Command=Login&User=test&Pass=test
</pre>

We can see that the request is addressed to
''www.example.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
This ensures that our data are sent through an encrypted channel and that they are not readable by other people.

'''Case study: sending data with POST method via HTTPS on a page reachable via HTTP'''

Now, suppose to have a web page reachable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This situation occurs, for example, when we are on a portal of a big company that offers various information and services publicly available, without identification, but which has also a private section accessible from the home page through a login. So when we try to login, the header of our request will look like the following example:

<pre>
POST https://www.example.com:443/login.do HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com/homepage.do
Cookie: SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB6pLhjkW6F
Content-Type: application/x-www-form-urlencoded
Content-length: 45

User=test&Pass=test&portal=ExamplePortal
</pre>

We can see that our request is addressed to ''www.example.com:443/login.do'' using HTTPS. But if we have a look at the referer field in the header (the page from which we came), it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. Although we are sending data via HTTPS, this deployment can allow [http://www.thoughtcrime.org/software/sslstrip/ SSLStrip] attacks (a type of [http://en.wikipedia.org/wiki/Man-in-the-middle_attack Man-in-the-middle] attack)

'''Case study: Sending data with GET method through HTTPS'''

In this last example, suppose that the application transfers data using the GET method. This method should never be used in a form that transmits sensitive data such as username and password, because they are displayed in clear in the URL and this entails a whole set of security issues. So this example is purely demonstrative, but, in reality, it is strongly suggested to use the POST method instead. This is because when the GET method is used, the URL that it requests is easily available from, for example, the server logs exposing your sensitive data to information leakage.

<pre>
GET https://www.example.com/success.html?user=test&pass=test HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.example.com/form.html
If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT
If-None-Match: "43a01-5b-4868915f"
</pre>

You can see that the data is transferred in clear text in the URL and not in the body of the message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than HTTP, so the whole HTTP package is still encrypted and the URL is unreadable to an attacker. It is not a good practice to use the GET method in these cases, because the information contained in the URL can be stored in many servers such as proxy and web servers, leaking the privacy of the user's credentials.

== Gray Box testing and example ==
Talk with the developers of the application and try to understand if they are aware of differences between HTTP and HTTPS protocols and why they should use the HTTPS for sensitive information transmissions. 
Then, check with them if HTTPS is used in every sensitive transmission, like those in login pages, to prevent unauthorized users to read the data.

== References ==
'''Whitepapers''' 
* HTTP/1.1: Security Considerations - http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html
* [http://www.troyhunt.com/2011/01/ssl-is-not-about-encryption.html SSL is not about encryption] 
'''Tools''' 
* [[OWASP WebScarab Project|WebScarab]]

Testing for Browser cache weakness (OTG-AUTHN-006)

2013-11-25T11:30:38Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
In this phase we check that the application correctly instructs the browser to not remember sensitive data.
 

== Description of the Issue ==
Browsers can store information for purposes of caching and history. Caching is used to improve performance, so that previously displayed information doesn't need to be downloaded again. History mechanisms are used for user convenience, so the user can see exactly what they saw at the time when the resource was retrieved.
If sensitive information is displayed to the user (such as their address, credit card details, Social Security Number, or username), then this information could be stored for purposes of caching or history, and therefore retrievable through examining the browser's cache or by simply pressing the browser's "Back" button.
 

== Black Box testing and example ==
'''Browser History''' 
Technically, the "Back" button is a history, not a cache (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13). The cache and the history are two different entities, however, they share the same weakness that we are trying to prevent, that of presenting previously displayed sensitive information.
The first (and simplest) test consists of entering sensitive information into the application, logging out, and then hitting the "Back" button of the browser, to check whether previously displayed sensitive information can be accessed whilst unauthenticated.
If by pressing the "Back" button we can access previous pages but not access new ones, then it is not an authentication issue, but a browser history issue. If these pages contain sensitive data, it means that the application did not forbid the browser to store it.
Authentication does not necessarily need to be involved in the testing. For example, when a user enters their email address in order to sign up to a newsletter, this information could be retrievable if not properly handled.
The "Back" button can be stopped from showing sensitive data. This can be done by:
* Delivering the page over HTTPS.
* Setting Cache-Control: must-revalidate

'''Browser Cache''' 
Here we check that the application does not leak any sensitive data into the browser cache. In order to do that, we can use a proxy (such as WebScarab) and search through the server responses that belong to the session, checking that for every page that contains sensitive information the server instructed the browser not to cache any data. Such a directive can be issued in the HTTP response headers:
* Cache-Control: no-cache, no-store
* Expires: 0
* Pragma: no-cache
These directives are generally robust, although additional flags may be necessary for the Cache-Control header in order to better prevent persistently linked files on the filesystem. These include:
* Cache-Control: must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0

<pre>
HTTP/1.1:
Cache-Control: no-cache
</pre>

<pre>
HTTP/1.0:
Pragma: no-cache
Expires: <past date or illegal value (e.g., 0)>
</pre>

For instance, if we are testing an e-commerce application, we should look for all pages that contain a credit card number or some other financial information, and check that all those pages enforce the no-cache directive.
On the other hand, if we find pages that contain critical information but that fail to instruct the browser not to cache their content, we know that sensitive information will be stored on the disk, and we can double-check that simply by looking for it in the browser cache. The exact location where that information is stored depends on the client operating system and on the browser that has been used. Here are some examples:

* Mozilla Firefox:
** Unix/Linux: ~/.mozilla/firefox/<profile-id>/Cache/
** Windows: C:\Documents and Settings\<user_name>\Local Settings\Application Data\Mozilla\Firefox\Profiles\<profile-id>\Cache

* Internet Explorer:
** C:\Documents and Settings\<user_name>\Local Settings\Temporary Internet Files

== Gray Box testing and example ==
The methodology for testing is equivalent to the black box case, as in both scenarios we have full access to the server response headers and to the HTML code. However, with gray box testing, we may have access to account credentials that will allow us to test sensitive pages that are accessible only to authenticated users.
 

== References ==
'''Whitepapers''' 
* [http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html Caching in HTTP]

'''Tools''' 
* [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy]
* Firefox add-on [https://addons.mozilla.org/en-US/firefox/addon/cacheviewer2/?src=api CacheViewer2]

Testing for Browser cache weakness (OTG-AUTHN-006)

2013-11-25T11:17:36Z

Robert WInkel:

Testing for Browser cache weakness (OTG-AUTHN-006)

2013-11-25T11:16:02Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
In this phase we check that the application correctly instructs the browser to not remember sensitive data.
 

== Description of the Issue ==
Browsers can store information for purposes of caching and history. Caching is used to improve performance, so that previously displayed information doesn't need to be downloaded again. History mechanisms are used for user convenience, so the user can see exactly what they saw at the time when the resource was retrieved.
If sensitive information is displayed to the user (such as their address, credit card details, Social Security Number, or username), then this information could be stored for purposes of caching or history, and therefore retrievable through examining the browser's cache or by simply pressing the browser's "Back" button.
 

== Black Box testing and example ==
'''Browser History''' 
Technically, the "Back" button is a history, not a cache (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13). The cache and the history are two different entities, however, they share the same weakness that we are trying to prevent, that of presenting previously displayed sensitive information.
The first (and simplest) test consists of entering sensitive information into the application, logging out, and then hitting the "Back" button of the browser, to check whether previously displayed sensitive information can be accessed whilst unauthenticated.
If by pressing the "Back" button we can access previous pages but not access new ones, then it is not an authentication issue, but a browser history issue. If these pages contain sensitive data, it means that the application did not forbid the browser to store it.
Authentication does not necessarily need to be involved in the testing. For example, when a user enters their email address in order to sign up to a newsletter, this information could be retrievable if not properly handled.
The "Back" button can be stopped from showing sensitive data. This can be done by:
* Delivering the page over HTTPS.
* Setting Cache-Control: must-revalidate

'''Browser Cache''' 
Here we check that the application does not leak any sensitive data into the browser cache. In order to do that, we can use a proxy (such as WebScarab) and search through the server responses that belong to the session, checking that for every page that contains sensitive information the server instructed the browser not to cache any data. Such a directive can be issued in the HTTP response headers:
* Cache-Control: no-cache, no-store
* Expires: 0
* Pragma: no-cache
These directives are generally robust, although additional flags may be necessary for the Cache-Control header in order to better prevent persistently linked files on the filesystem. These include:
* Cache-Control: must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0

<pre>
HTTP/1.1:
Cache-Control: no-cache
</pre>

<pre>
HTTP/1.0:
Pragma: no-cache
Expires: <past date or illegal value (e.g., 0)>
</pre>

For instance, if we are testing an e-commerce application, we should look for all pages that contain a credit card number or some other financial information, and check that all those pages enforce the no-cache directive.
On the other hand, if we find pages that contain critical information but that fail to instruct the browser not to cache their content, we know that sensitive information will be stored on the disk, and we can double-check that simply by looking for it in the browser cache. The exact location where that information is stored depends on the client operating system and on the browser that has been used. Here are some examples:

* Mozilla Firefox:
** Unix/Linux: ~/.mozilla/firefox/<profile-id>/Cache/
** Windows: C:\Documents and Settings\<user_name>\Local Settings\Application Data\Mozilla\Firefox\Profiles\<profile-id>\Cache

* Internet Explorer:
** C:\Documents and Settings\<user_name>\Local Settings\Temporary Internet Files

== Gray Box testing and example ==
The methodology for testing is equivalent to the black box case, as in both scenarios we have full access to the server response headers and to the HTML code. However, with gray box testing, we may have access to account credentials that will allow us to test sensitive pages that are accessible only to authenticated users.
 

== References ==
'''Whitepapers''' 
* [http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html Caching in HTTP]
 

'''Tools''' 
* [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy]

Testing for Browser cache weakness (OTG-AUTHN-006)

2013-11-25T11:02:52Z

Robert WInkel:

Testing for Browser cache weakness (OTG-AUTHN-006)

2013-11-25T11:02:03Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
In this phase we check that the application correctly instructs the browser to not remember sensitive data.
 

== Description of the Issue ==
Browsers can store information for purposes of caching and history. Caching is used to improve performance, so that previously displayed information doesn't need to be downloaded again. History mechanisms are used for user convenience, so the user can see exactly what they saw at the time when the resource was retrieved.
If sensitive information is displayed to the user (such as their address, credit card details, Social Security Number, or username), then this information could be stored for purposes of caching or history, and therefore retrievable through examining the browser's cache or by simply pressing the browser's "Back" button.
 

== Black Box testing and example ==
'''Browser History''' 
Technically, the "Back" button is a history, not a cache (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13). The cache and the history are two different entities, however, they share the same weakness that we are trying to prevent, that of presenting previously displayed sensitive information.
The first (and simplest) test consists of entering sensitive information into the application, logging out, and then hitting the "Back" button of the browser, to check whether previously displayed sensitive information can be accessed whilst unauthenticated.
If by pressing the "Back" button we can access previous pages but not access new ones, then it is not an authentication issue, but a browser history issue. If these pages contain sensitive data, it means that the application did not forbid the browser to store it.
Authentication does not necessarily need to be involved in the testing. For example, when a user enters their email address in order to sign up to a newsletter, this information could be retrievable if not properly handled.
The "Back" button can be stopped from showing sensitive data. This can be done by:
* Delivering the page over HTTPS.
* Setting Cache-Control: must-revalidate
 

'''Browser Cache''' 
Here we check that the application does not leak any sensitive data into the browser cache. In order to do that, we can use a proxy (such as WebScarab) and search through the server responses that belong to the session, checking that for every page that contains sensitive information the server instructed the browser not to cache any data. Such a directive can be issued in the HTTP response headers:
* Cache-Control: no-cache, no-store
* Expires: 0
* Pragma: no-cache
These directives are generally robust, although additional flags may be necessary for the Cache-Control header in order to better prevent persistently linked files on the filesystem. These include:
* Cache-Control: must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0

<pre>
HTTP/1.1:
Cache-Control: no-cache
</pre>

<pre>
HTTP/1.0:
Pragma: no-cache
Expires: <past date or illegal value (e.g., 0)>
</pre>

For instance, if we are testing an e-commerce application, we should look for all pages that contain a credit card number or some other financial information, and check that all those pages enforce the no-cache directive.
On the other hand, if we find pages that contain critical information but that fail to instruct the browser not to cache their content, we know that sensitive information will be stored on the disk, and we can double-check that simply by looking for it in the browser cache. The exact location where that information is stored depends on the client operating system and on the browser that has been used. Here are some examples:

* Mozilla Firefox:
** Unix/Linux: ~/.mozilla/firefox/<profile-id>/Cache/
** Windows: C:\Documents and Settings\<user_name>\Local Settings\Application Data\Mozilla\Firefox\Profiles\<profile-id>\Cache

* Internet Explorer:
** C:\Documents and Settings\<user_name>\Local Settings\Temporary Internet Files

== Gray Box testing and example ==
The methodology for testing is equivalent to the black box case, as in both scenarios we have full access to the server response headers and to the HTML code. However, with gray box testing, we may have access to account credentials that will allow us to test sensitive pages that are accessible only to authenticated users.
 

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

'''Tools''' 
...

Testing for Browser cache weakness (OTG-AUTHN-006)

2013-11-25T11:01:00Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
In this phase we check that the application correctly instructs the browser to not remember sensitive data.
 

== Description of the Issue ==
Browsers can store information for purposes of caching and history. Caching is used to improve performance, so that previously displayed information doesn't need to be downloaded again. History mechanisms are used for user convenience, so the user can see exactly what they saw at the time when the resource was retrieved.
If sensitive information is displayed to the user (such as their address, credit card details, Social Security Number, or username), then this information could be stored for purposes of caching or history, and therefore retrievable through examining the browser's cache or by simply pressing the browser's "Back" button.
 

== Black Box testing and example ==
'''Browser History''' 
Technically, the "Back" button is a history, not a cache (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13). The cache and the history are two different entities, however, they share the same weakness that we are trying to prevent, that of presenting previously displayed sensitive information.
The first (and simplest) test consists of entering sensitive information into the application, logging out, and then hitting the "Back" button of the browser, to check whether previously displayed sensitive information can be accessed whilst unauthenticated.
If by pressing the "Back" button we can access previous pages but not access new ones, then it is not an authentication issue, but a browser history issue. If these pages contain sensitive data, it means that the application did not forbid the browser to store it.
Authentication does not necessarily need to be involved in the testing. For example, when a user enters their email address in order to sign up to a newsletter, this information could be retrievable if not properly handled.
The "Back" button can be stopped from showing sensitive data. This can be done by:
* Delivering the page over HTTPS.
* Setting Cache-Control: must-revalidate
 

'''Browser Cache''' 
Here we check that the application does not leak any sensitive data into the browser cache. In order to do that, we can use a proxy (such as WebScarab) and search through the server responses that belong to the session, checking that for every page that contains sensitive information the server instructed the browser not to cache any data. Such a directive can be issued in the HTTP response headers:
* Cache-Control: no-cache, no-store
* Expires: 0
* Pragma: no-cache
These directives are generally robust, although additional flags may be necessary for the Cache-Control header in order to better prevent persistently linked files on the filesystem. These include:
* Cache-Control: must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0
 
<pre>
HTTP/1.1:
Cache-Control: no-cache
</pre>

<pre>
HTTP/1.0:
Pragma: no-cache
Expires: <past date or illegal value (e.g., 0)>
</pre>

For instance, if we are testing an e-commerce application, we should look for all pages that contain a credit card number or some other financial information, and check that all those pages enforce the no-cache directive.
On the other hand, if we find pages that contain critical information but that fail to instruct the browser not to cache their content, we know that sensitive information will be stored on the disk, and we can double-check that simply by looking for it in the browser cache. The exact location where that information is stored depends on the client operating system and on the browser that has been used. Here are some examples:

* Mozilla Firefox:
** Unix/Linux: ~/.mozilla/firefox/<profile-id>/Cache/
** Windows: C:\Documents and Settings\<user_name>\Local Settings\Application Data\Mozilla\Firefox\Profiles\<profile-id>\Cache

* Internet Explorer:
** C:\Documents and Settings\<user_name>\Local Settings\Temporary Internet Files
 

== Gray Box testing and example ==
The methodology for testing is equivalent to the black box case, as in both scenarios we have full access to the server response headers and to the HTML code. However, with gray box testing, we may have access to account credentials that will allow us to test sensitive pages that are accessible only to authenticated users.
 

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

'''Tools''' 
...

Testing for Browser cache weakness (OTG-AUTHN-006)

2013-11-25T10:59:22Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

= Brief Summary ==
In this phase we check that the server correctly instructs the browser to not remember sensitive data.
 

== Description of the Issue ==
Browsers can store information for purposes of caching and history. Caching is used to improve performance, so that previously displayed information doesn't need to be downloaded again. History mechanisms are used for user convenience, so the user can see exactly what they saw at the time when the resource was retrieved.
If sensitive information is displayed to the user (such as their address, credit card details, Social Security Number, or username), then this information could be stored for purposes of caching or history, and therefore retrievable through examining the browser's cache or by simply pressing the browser's "Back" button.
 

== Black Box testing and example ==
'''Browser History''' 
Technically, the "Back" button is a history, not a cache (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13). The cache and the history are two different entities, however, they share the same weakness that we are trying to prevent, that of presenting previously displayed sensitive information.
The first (and simplest) test consists of entering sensitive information into the application, logging out, and then hitting the "Back" button of the browser, to check whether previously displayed sensitive information can be accessed whilst unauthenticated.
If by pressing the "Back" button we can access previous pages but not access new ones, then it is not an authentication issue, but a browser history issue. If these pages contain sensitive data, it means that the application did not forbid the browser to store it.
Authentication does not necessarily need to be involved in the testing. For example, when a user enters their email address in order to sign up to a newsletter, this information could be retrievable if not properly handled.
The "Back" button can be stopped from showing sensitive data. This can be done by:
* Delivering the page over HTTPS.
* Setting Cache-Control: must-revalidate
 

'''Browser Cache''' 
Here we check that the application does not leak any sensitive data into the browser cache. In order to do that, we can use a proxy (such as WebScarab) and search through the server responses that belong to the session, checking that for every page that contains sensitive information the server instructed the browser not to cache any data. Such a directive can be issued in the HTTP response headers:
* Cache-Control: no-cache, no-store
* Expires: 0
* Pragma: no-cache
These directives are generally robust, although additional flags may be necessary for the Cache-Control header in order to better prevent persistently linked files on the filesystem. These include:
* Cache-Control: must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0
 
<pre>
HTTP/1.1:
Cache-Control: no-cache
</pre>
<pre>
HTTP/1.0:
Pragma: no-cache
Expires: <past date or illegal value (e.g., 0)>
</pre>
 
For instance, if we are testing an e-commerce application, we should look for all pages that contain a credit card number or some other financial information, and check that all those pages enforce the no-cache directive.
On the other hand, if we find pages that contain critical information but that fail to instruct the browser not to cache their content, we know that sensitive information will be stored on the disk, and we can double-check that simply by looking for it in the browser cache. The exact location where that information is stored depends on the client operating system and on the browser that has been used. Here are some examples:

* Mozilla Firefox:
** Unix/Linux: ~/.mozilla/firefox/<profile-id>/Cache/
** Windows: C:\Documents and Settings\<user_name>\Local Settings\Application Data\Mozilla\Firefox\Profiles\<profile-id>\Cache

* Internet Explorer:
** C:\Documents and Settings\<user_name>\Local Settings\Temporary Internet Files
 

== Gray Box testing and example ==
The methodology for testing is equivalent to the black box case, as in both scenarios we have full access to the server response headers and to the HTML code. However, with gray box testing, we may have access to account credentials that will allow us to test sensitive pages that are accessible only to authenticated users.
 

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

'''Tools''' 
...

Testing for Browser cache weakness (OTG-AUTHN-006)

2013-11-25T09:48:24Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

Note: Currently, this is basically a replica of the browser cache portions of the "Testing for Logout and Browser Cache Management (OWASP-AT-007)" Test Case from OWASP v3.

== Brief Summary ==
In this phase we check that the server correctly instructs the browser to not cache sensitive data.
 

== Description of the Issue ==
...here: Short Description of the Issue: Topic and Explanation
 

== Black Box testing and example ==
'''The Browser "Back" Button''' 
The first (and simplest) test consists of logging out and then hitting the 'back' button of the browser, to check whether previously displayed sensitive information can be accessed whilst unauthenticated.
If by pressing the 'back' button we can access previous pages but not access new ones, then we are simply accessing the browser cache. If these pages contain sensitive data, it means that the application did not forbid the browser to cache it (by not setting the Cache-Control header).
Technically, the "back" button is a history, not a cache (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13). However, it is possible in practice to stop the "back" button from showing sensitive data. This can be done by:
* Deliver the page over HTTPS.
* Set Cache-Control: must-revalidate
 

'''Cached Pages''' 
Logging out from an application obviously does not clear the browser cache of any sensitive information that might have been stored. Therefore, another test that is to be performed is to check that our application does not leak any critical data into the browser cache. In order to do that, we can use a proxy (such as WebScarab) and search through the server responses that belong to our session, checking that for every page that contains sensitive information the server instructed the browser not to cache any data. Such a directive can be issued in the HTTP response headers:
* Cache-Control: no-cache, no-store
* Expires: 0
* Pragma: no-cache
These directives are generally robust, although additional flags may be necessary for the Cache-Control header in order to better prevent persistently linked files on the filesystem. These include:
* Cache-Control: must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0
 
<pre>
HTTP/1.1:
Cache-Control: no-cache
</pre>
<pre>
HTTP/1.0:
Pragma: no-cache
Expires: <past date or illegal value (e.g., 0)>
</pre>
 
For instance, if we are testing an e-commerce application, we should look for all pages that contain a credit card number or some other financial information, and check that all those pages enforce the no-cache directive.
On the other hand, if we find pages that contain critical information but that fail to instruct the browser not to cache their content, we know that sensitive information will be stored on the disk, and we can double-check that simply by looking for it in the browser cache. The exact location where that information is stored depends on the client operating system and on the browser that has been used. Here are some examples:

* Mozilla Firefox:
** Unix/Linux: ~/.mozilla/firefox/<profile-id>/Cache/
** Windows: C:\Documents and Settings\<user_name>\Local Settings\Application Data\Mozilla\Firefox\Profiles\<profile-id>\Cache

* Internet Explorer:
** C:\Documents and Settings\<user_name>\Local Settings\Temporary Internet Files
 

== Gray Box testing and example ==
The methodology for testing is equivalent to the black box case, as in both scenarios we have full access to the server response headers and to the HTML code. However, with gray box testing, we may have access to account credentials that will allow us to test sensitive pages that are accessible only to authenticated users.
 

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

'''Tools''' 
...

Testing for Browser cache weakness (OTG-AUTHN-006)

2013-11-25T09:45:01Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

Note: Currently, this is basically a replica of the browser cache portions of the "Testing for Logout and Browser Cache Management (OWASP-AT-007)" Test Case from OWASP v3.

== Brief Summary ==
In this phase we check that the server correctly instructs the browser to not cache sensitive data.
 

== Description of the Issue ==
...here: Short Description of the Issue: Topic and Explanation
 

== Black Box testing and example ==
'''The Browser "Back" Button''' 
The first (and simplest) test consists of logging out and then hitting the 'back' button of the browser, to check whether previously displayed sensitive information can be accessed whilst unauthenticated.
If by pressing the 'back' button we can access previous pages but not access new ones, then we are simply accessing the browser cache. If these pages contain sensitive data, it means that the application did not forbid the browser to cache it (by not setting the Cache-Control header).
Technically, the "back" button is a history, not a cache (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13). However, it is possible in practice to stop the "back" button from showing sensitive data. This can be done by:
* Deliver the page over HTTPS.
* Set Cache-Control: must-revalidate
 

'''Cached Pages''' 
Logging out from an application obviously does not clear the browser cache of any sensitive information that might have been stored. Therefore, another test that is to be performed is to check that our application does not leak any critical data into the browser cache. In order to do that, we can use a proxy (such as WebScarab) and search through the server responses that belong to our session, checking that for every page that contains sensitive information the server instructed the browser not to cache any data. Such a directive can be issued in the HTTP response headers. "Cache-Control: no-cache, no-store" coupled with "Expires: 0" and "Pragma: no-cache" is generally robust although additional flags may be necessary for the Cache-Control header in order to better prevent persistently linked files on the filesystem. These include: must-revalidate, pre-check=0, post-check=0, max-age=0, and s-maxage=0.
 
<pre>
HTTP/1.1:
Cache-Control: no-cache
</pre>
<pre>
HTTP/1.0:
Pragma: no-cache
Expires: <past date or illegal value (e.g., 0)>
</pre>
 
For instance, if we are testing an e-commerce application, we should look for all pages that contain a credit card number or some other financial information, and check that all those pages enforce the no-cache directive.
On the other hand, if we find pages that contain critical information but that fail to instruct the browser not to cache their content, we know that sensitive information will be stored on the disk, and we can double-check that simply by looking for it in the browser cache. The exact location where that information is stored depends on the client operating system and on the browser that has been used. Here are some examples:

* Mozilla Firefox:
** Unix/Linux: ~/.mozilla/firefox/<profile-id>/Cache/
** Windows: C:\Documents and Settings\<user_name>\Local Settings\Application Data\Mozilla\Firefox\Profiles\<profile-id>\Cache

* Internet Explorer:
** C:\Documents and Settings\<user_name>\Local Settings\Temporary Internet Files
 

== Gray Box testing and example ==
The methodology for testing is equivalent to the black box case, as in both scenarios we have full access to the server response headers and to the HTML code. However, with gray box testing, we may have access to account credentials that will allow us to test sensitive pages that are accessible only to authenticated users.
 

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

'''Tools''' 
...

Testing for Browser cache weakness (OTG-AUTHN-006)

2013-11-25T09:06:14Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

Note: Currently, this is basically a replica of the browser cache portions of the "Testing for Logout and Browser Cache Management (OWASP-AT-007)" Test Case from OWASP v3.

== Brief Summary ==
In this phase we check that the server correctly instructs the browser to not cache sensitive data.
 

== Description of the Issue ==
...here: Short Description of the Issue: Topic and Explanation
 

== Black Box testing and example ==
'''The Browser "Back" Button''' 
The first (and simplest) test consists of logging out and then hitting the 'back' button of the browser, to check whether previously entered sensitive information can be accessed whilst unauthenticated.
If by pressing the 'back' button we can access previous pages but not access new ones, then we are simply accessing the browser cache. If these pages contain sensitive data, it means that the application did not forbid the browser to cache it (by not setting the Cache-Control header).
 

'''Cached Pages''' 
Logging out from an application obviously does not clear the browser cache of any sensitive information that might have been stored. Therefore, another test that is to be performed is to check that our application does not leak any critical data into the browser cache. In order to do that, we can use a proxy (such as WebScarab) and search through the server responses that belong to our session, checking that for every page that contains sensitive information the server instructed the browser not to cache any data. Such a directive can be issued in the HTTP response headers. "Cache-Control: no-cache, no-store" coupled with "Expires: 0" and "Pragma: no-cache" is generally robust although additional flags may be necessary for the Cache-Control header in order to better prevent persistently linked files on the filesystem. These include: must-revalidate, pre-check=0, post-check=0, max-age=0, and s-maxage=0.
 
<pre>
HTTP/1.1:
Cache-Control: no-cache
</pre>
<pre>
HTTP/1.0:
Pragma: no-cache
Expires: <past date or illegal value (e.g., 0)>
</pre>
 
For instance, if we are testing an e-commerce application, we should look for all pages that contain a credit card number or some other financial information, and check that all those pages enforce the no-cache directive.
On the other hand, if we find pages that contain critical information but that fail to instruct the browser not to cache their content, we know that sensitive information will be stored on the disk, and we can double-check that simply by looking for it in the browser cache. The exact location where that information is stored depends on the client operating system and on the browser that has been used. Here are some examples:

* Mozilla Firefox:
** Unix/Linux: ~/.mozilla/firefox/<profile-id>/Cache/
** Windows: C:\Documents and Settings\<user_name>\Local Settings\Application Data\Mozilla\Firefox\Profiles\<profile-id>\Cache

* Internet Explorer:
** C:\Documents and Settings\<user_name>\Local Settings\Temporary Internet Files
 

== Gray Box testing and example ==
The methodology for testing is equivalent to the black box case, as in both scenarios we have full access to the server response headers and to the HTML code. However, with gray box testing, we may have access to account credentials that will allow us to test sensitive pages that are accessible only to authenticated users.
 

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

'''Tools''' 
...

Testing for Weak security question/answer (OTG-AUTHN-008)

2013-08-14T12:33:12Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords (see [[Testing for weak password change or reset functionalities (OWASP-AT-011)]]), or as extra security on top of the password.
 
They are typically generated upon account creation, and require the user to select from some pre-generated questions and supply an appropriate answer, or allow the user to generate their own question and answer pairs. Both methods are prone to insecurities.
 
Ideally, security questions should generate answers that are only known by the user, and not guessable or discoverable by anybody else. This is harder than it sounds.
 

== Description of the Issue ==
Security questions and answers rely on the secrecy of the answer. Answers should be of the form that are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that websites implement promote answers that are pseduo-private. Some examples are below.
 
'''Pre-generated questions:'''
 
The majority of pre-generated questions are fairly simplistic in nature and can lead to insecure answers. For example:
* The answers may be known to family members or close friends of the user, e.g. "What is your mother's maiden name?", "What is your date of birth?"
* The answers may be easily guessable, e.g. "What is your favorite color?", "What is your favorite baseball team?"
* The answers may be brute forcible, e.g. "What is the first name of your favorite high school teacher?" - the answer is probably on some easily downloadable lists of popular first names, and therefore a simple brute force attack can be scripted.
* The answers may be publicly discoverable, e.g. "What is your favorite movie?" - the answer may easily be found on the user's social media profile page.
 
'''Self-generated questions:'''
 
The problem with having users to generate their own questions is that it allows them to generate very insecure questions, or even bypass the whole point of having a security question in the first place. Here are some real world examples that illustrates this point:
 
* "What is 1+1?"
* "What is your username?"
* "My password is M3@t$p1N"
 
== Black Box testing and examples ==
'''Testing for weak pre-generated questions:'''
 
Generate the security questions, e.g. by creating a new account, going through the forgotten password functionality, or whatever the process is for that particular system. Try to generate as many questions as possible to get a good idea of the type of security questions that are answered. If any of the security questions fall in the categories described above, they are vulnerable to being attacked (guessed, brute-forced, available on social media, etc.). If within scope of the testing engagement, the vulnerability could be exploited by the tester as further proof.
 
'''Testing for weak self-generated questions:'''
 
Generate the security questions, e.g. by creating a new account, going through the forgotten password functionality, or whatever the process is for that particular system. If the system allows the user to generate their own security questions, it is vulnerable to having insecure questions created. If the system uses the self-generated security questions during the forgotten password functionality and if usernames can be enumerated (see [[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]), then it should be easy for the tester to enumerate a number of users' self-generated questions. It should be expected to find several weak self-generated passwords using this method.
 
'''Testing for brute-forcible answers:'''
 
Use the methods described in [[Testing for Weak lock out mechanism (OWASP-AT-004)]] to determine whether a number of incorrectly supplied security answers generates an appropriate lock out mechanism.
 
The first thing to take into consideration when trying to exploit security questions is how many questions need to be answered? The majority of applications only need the user to answer a single question, but some critical applications require the user to answer correctly to two or even more questions.
 
The next step is to assess the strength of the security questions. Could the answers be obtained by a simple Google search or with social engineering attack? As a penetration tester, here is a step-by-step walk-through of exploiting a security question scheme:
 
* Are there multiple questions offered? If so, focus on questions which have:
** a “public” answer; for example, something Google would find with a simple query
** a factual answer such as a “first school” or other facts which can be looked up
** few possible answers, such as “what make was your first car”. These questions would present the attacker with a short-list of answers to guess at, and based on statistics the attacker could rank answers from most to least likely
* Determine how many guesses you have (if possible)
** Does the password reset allow unlimited attempts?
** Is there a lockout period after X incorrect answers? Keep in mind that a lockout system can be a security problem in itself, as it can be exploited by an attacker to launch a Denial of Service against legitimate users
* Pick the appropriate question based on analysis from above point, and do research to determine the most likely answers
 
The key to successfully exploiting and bypassing a weak security question scheme is to find a question or set of questions which give the possibility of easily acquiring the answers. Always look for questions which can give you the greatest statistical chance of guessing the correct answer, if you are completely unsure of any of the answers. In the end, a security question scheme is only as strong as the weakest question.
 
== References ==
[http://www.schneier.com/essay-081.html The Curse of the Secret Question]

Testing for Weak security question/answer (OTG-AUTHN-008)

2013-08-14T12:02:59Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords (see [[Testing for weak password change or reset functionalities (OWASP-AT-011)]]), or as extra security on top of the password.
 
They are typically generated upon account creation, and require the user to select from some pre-generated questions and supply an appropriate answer, or allow the user to generate their own question and answer pairs. Both methods are prone to insecurities.
 
Ideally, security questions should generate answers that are only known by the user, and not guessable or discoverable by anybody else. This is harder than it sounds.
 

== Description of the Issue ==
Security questions and answers rely on the secrecy of the answer. Answers should be of the form that are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that websites implement promote answers that are pseduo-private. Some examples are below.
 
'''Pre-generated questions:'''
 
The majority of pre-generated questions are fairly simplistic in nature and can lead to insecure answers. For example:
* The answers may be known to family members or close friends of the user, e.g. "What is your mother's maiden name?", "What is your date of birth?"
* The answers may be easily guessable, e.g. "What is your favorite color?", "What is your favorite baseball team?"
* The answers may be brute forcible, e.g. "What is the first name of your favorite high school teacher?" - the answer is probably on some easily downloadable lists of popular first names, and therefore a simple brute force attack can be scripted.
* The answers may be publicly discoverable, e.g. "What is your favorite movie?" - the answer may easily be found on the user's social media profile page.
 
'''Self-generated questions:'''
 
The problem with having users to generate their own questions is that it allows them to generate very insecure questions, or even bypass the whole point of having a security question in the first place. Here are some real world examples that illustrates this point:
 
* "What is 1+1?"
* "What is your username?"
* "My password is M3@t$p1N"
 
== Black Box testing and examples ==
'''Testing for weak pre-generated questions:'''
 
Generate the security questions, e.g. by creating a new account, going through the forgotten password functionality, or whatever the process is for that particular system. Try to generate as many questions as possible to get a good idea of the type of security questions that are answered. If any of the security questions fall in the categories described above, they are vulnerable to being attacked (guessed, brute-forced, available on social media, etc.). If within scope of the testing engagement, the vulnerability could be exploited by the tester as further proof.
 
'''Testing for weak self-generated questions:'''
 
Generate the security questions, e.g. by creating a new account, going through the forgotten password functionality, or whatever the process is for that particular system. If the system allows the user to generate their own security questions, it is vulnerable to having insecure questions created. If the system uses the self-generated security questions during the forgotten password functionality and if usernames can be enumerated (see [[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]), then it should be easy for the tester to enumerate a number of users' self-generated questions. It should be expected to find several weak self-generated passwords using this method.
 
'''Testing for brute-forcible answers:'''
 
Use the methods described in [[Testing for Weak lock out mechanism (OWASP-AT-004)]] to determine whether a number of incorrectly supplied security answers generates an appropriate lock out mechanism.
 
The first thing to take into consideration when trying to exploit security questions is how many questions need to be answered? The majority of applications only need the user to answer a single question, but some critical applications require the user to answer correctly to two or even more questions.
 
The next step is to assess the strength of the security questions. Could the answers be obtained by a simple Google search or with social engineering attack? As a penetration tester, here is a step-by-step walk-through of exploiting a security question scheme:
 
* Are there multiple questions offered? If so, focus on questions which have:
** a “public” answer; for example, something Google would find with a simple query
** a factual answer such as a “first school” or other facts which can be looked up
** few possible answers, such as “what make was your first car”. These questions would present the attacker with a short-list of answers to guess at, and based on statistics the attacker could rank answers from most to least likely
* Determine how many guesses you have (if possible)
** Does the password reset allow unlimited attempts?
** Is there a lockout period after X incorrect answers? Keep in mind that a lockout system can be a security problem in itself, as it can be exploited by an attacker to launch a Denial of Service against legitimate users
* Pick the appropriate question based on analysis from above point, and do research to determine the most likely answers
 
The key to successfully exploiting and bypassing a weak security question scheme is to find a question or set of questions which give the possibility of easily acquiring the answers. Always look for questions which can give you the greatest statistical chance of guessing the correct answer, if you are completely unsure of any of the answers. In the end, a security question scheme is only as strong as the weakest question.
 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

Testing for Weak security question/answer (OTG-AUTHN-008)

2013-08-14T11:57:41Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords, or as extra security on top of password.
 
They are typically generated upon account creation, and require the user to select from some pre-generated questions and supply an appropriate answer, or allow the user to generate their own question and answer pairs. Both methods are prone to insecurities.
 
Ideally, security questions should generate answers that are only known by the user, and not guessable or discoverable by anybody else. This is harder than it sounds.
 

== Description of the Issue ==
Security questions and answers rely on the secrecy of the answer. Answers should be of the form that are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that websites implement promote answers that are pseduo-private. Some examples are below.
 
'''Pre-generated questions:'''
 
The majority of pre-generated questions are fairly simplistic in nature and can lead to insecure answers. For example:
* The answers may be known to family members or close friends of the user, e.g. "What is your mother's maiden name?", "What is your date of birth?"
* The answers may be easily guessable, e.g. "What is your favorite color?", "What is your favorite baseball team?"
* The answers may be brute forcible, e.g. "What is the first name of your favorite high school teacher?" - the answer is probably on some easily downloadable lists of popular first names, and therefore a simple brute force attack can be scripted.
* The answers may be publicly discoverable, e.g. "What is your favorite movie?" - the answer may easily be found on the user's social media profile page.
 
'''Self-generated questions:'''
 
The problem with having users to generate their own questions is that it allows them to generate very insecure questions, or even bypass the whole point of having a security question in the first place. Here are some real world examples that illustrates this point:
 
* "What is 1+1?"
* "What is your username?"
* "My password is M3@t$p1N"
 
== Black Box testing and examples ==
'''Testing for weak pre-generated questions:'''
 
Generate the security questions, e.g. by creating a new account, going through the forgotten password functionality, or whatever the process is for that particular system. Try to generate as many questions as possible to get a good idea of the type of security questions that are answered. If any of the security questions fall in the categories described above, they are vulnerable to being attacked (guessed, brute-forced, available on social media, etc.). If within scope of the testing engagement, the vulnerability could be exploited by the tester as further proof.
 
'''Testing for weak self-generated questions:'''
 
Generate the security questions, e.g. by creating a new account, going through the forgotten password functionality, or whatever the process is for that particular system. If the system allows the user to generate their own security questions, it is vulnerable to having insecure questions created. If the system uses the self-generated security questions during the forgotten password functionality and if usernames can be enumerated (see [[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]), then it should be easy for the tester to enumerate a number of users' self-generated questions. It should be expected to find several weak self-generated passwords using this method.
 
'''Testing for brute-forcible answers:'''
 
Use the methods described in [[Testing for Weak lock out mechanism (OWASP-AT-004)]] to determine whether a number of incorrectly supplied security answers generates an appropriate lock out mechanism.
 
The first thing to take into consideration when trying to exploit security questions is how many questions need to be answered? The majority of applications only need the user to answer a single question, but some critical applications require the user to answer correctly to two or even more questions.
 
The next step is to assess the strength of the security questions. Could the answers be obtained by a simple Google search or with social engineering attack? As a penetration tester, here is a step-by-step walk-through of exploiting a security question scheme:
 
* Are there multiple questions offered? If so, focus on questions which have:
** a “public” answer; for example, something Google would find with a simple query
** a factual answer such as a “first school” or other facts which can be looked up
** few possible answers, such as “what make was your first car”. These questions would present the attacker with a short-list of answers to guess at, and based on statistics the attacker could rank answers from most to least likely
* Determine how many guesses you have (if possible)
** Does the password reset allow unlimited attempts?
** Is there a lockout period after X incorrect answers? Keep in mind that a lockout system can be a security problem in itself, as it can be exploited by an attacker to launch a Denial of Service against legitimate users
* Pick the appropriate question based on analysis from above point, and do research to determine the most likely answers
 
The key to successfully exploiting and bypassing a weak security question scheme is to find a question or set of questions which give the possibility of easily acquiring the answers. Always look for questions which can give you the greatest statistical chance of guessing the correct answer, if you are completely unsure of any of the answers. In the end, a security question scheme is only as strong as the weakest question.
 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

Testing for Weak lock out mechanism (OTG-AUTHN-003)

2013-08-14T10:25:09Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
..here: we describe in "natural language" what we want to test.
 
Note that this test should cover all aspects of authentication where lock out mechanisms would be appropriate, e.g. when the user is presented with security questions during forgotten password mechanisms (see [[Testing for Weak security question/answer (OTG-AUTHN-008)]]).
 
== Description of the Issue ==
 
...here: Short Description of the Issue: Topic and Explanation
 
== Black Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

Testing for Weak security question/answer (OTG-AUTHN-008)

2013-08-14T10:19:50Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords, or as extra security on top of password.
 
They are typically generated upon account creation, and require the user to select from some pre-generated questions and supply an appropriate answer, or allow the user to generate their own question and answer pairs. Both methods are prone to insecurities.
 
Ideally, security questions should generate answers that are only known by the user, and not guessable or discoverable by anybody else. This is harder than it sounds.
 

== Description of the Issue ==
Security questions and answers rely on the secrecy of the answer. Answers should be of the form that are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that websites implement promote answers that are pseduo-private. Some examples are below.
 
'''Pre-generated questions:'''
 
The majority of pre-generated questions are fairly simplistic in nature and can lead to insecure answers. For example:
* The answers may be known to family members or close friends of the user, e.g. "What is your mother's maiden name?", "What is your date of birth?"
* The answers may be easily guessable, e.g. "What is your favorite color?", "What is your favorite baseball team?"
* The answers may be brute forcible, e.g. "What is the first name of your favorite high school teacher?" - the answer is probably on some easily downloadable lists of popular first names, and therefore a simple brute force attack can be scripted.
* The answers may be publicly discoverable, e.g. "What is your favorite movie?" - the answer may easily be found on the user's social media profile page.
 
'''Self-generated questions:'''
 
The problem with having users to generate their own questions is that it allows them to generate very insecure questions, or even bypass the whole point of having a security question in the first place. Here are some real world examples that illustrates this point:
 
* "What is 1+1?"
* "What is your username?"
* "My password is M3@t$p1N"
 
== Black Box testing and examples ==
'''Testing for weak pre-generated questions:'''
 
Generate the security questions, e.g. by creating a new account, going through the forgotten password functionality, or whatever the process is for that particular system. Try to generate as many questions as possible to get a good idea of the type of security questions that are answered. If any of the security questions fall in the categories described above, they are vulnerable to being attacked (guessed, brute-forced, available on social media, etc.). If within scope of the testing engagement, the vulnerability could be exploited by the tester as further proof.
 
'''Testing for weak self-generated questions:'''
 
Generate the security questions, e.g. by creating a new account, going through the forgotten password functionality, or whatever the process is for that particular system. If the system allows the user to generate their own security questions, it is vulnerable to having insecure questions created. If the system uses the self-generated security questions during the forgotten password functionality and if usernames can be enumerated (see [[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]), then it should be easy for the tester to enumerate a number of users' self-generated questions. It should be expected to find several weak self-generated passwords using this method.
 
'''Testing for brute-forcible answers:'''
 
Use the methods described in [[Testing for Weak lock out mechanism (OWASP-AT-004)]] to determine whether a number of incorrectly supplied security answers generates an appropriate lock out mechanism.
 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

Testing for Weak security question/answer (OTG-AUTHN-008)

2013-08-14T10:16:17Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords, or as extra security on top of password.
 
They are typically generated upon account creation, and require the user to select from some pre-generated questions and supply an appropriate answer, or allow the user to generate their own question and answer pairs. Both methods are prone to insecurities.
 
Ideally, security questions should generate answers that are only known by the user, and not guessable or discoverable by anybody else. This is harder than it sounds.
 

== Description of the Issue ==
Security questions and answers rely on the secrecy of the answer. Answers should be of the form that are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that websites implement promote answers that are pseduo-private. Some examples are below.
 
'''Pre-generated questions:'''
 
The majority of pre-generated questions are fairly simplistic in nature and can lead to insecure answers. For example:
* The answers may be known to family members or close friends of the user, e.g. "What is your mother's maiden name?", "What is your date of birth?"
* The answers may be easily guessable, e.g. "What is your favorite color?", "What is your favorite baseball team?"
* The answers may be brute forcible, e.g. "What is the first name of your favorite high school teacher?" - the answer is probably on some easily downloadable lists of popular first names, and therefore a simple brute force attack can be scripted.
* The answers may be publicly discoverable, e.g. "What is your favorite movie?" - the answer may easily be found on the user's social media profile page.
 
'''Self-generated questions:'''
 
The problem with having users to generate their own questions is that it allows them to generate very insecure questions, or even bypass the whole point of having a security question in the first place. Here are some real world examples that illustrates this point:
 
* "What is 1+1?"
* "What is your username?"
* "My password is M3@t$p1N"
 
== Black Box testing and example ==
'''Testing for weak pre-generated questions:'''
 
Generate the security questions, e.g. by creating a new account, going through the forgotten password functionality, or whatever the process is for that particular system. Try to generate as many questions as possible to get a good idea of the type of security questions that are answered. If any of the security questions fall in the categories described above, they are vulnerable to being attacked (guessed, brute-forced, available on social media, etc.). If within scope of the testing engagement, the vulnerability could be exploited by the tester as further proof.
 
'''Testing for weak self-generated questions:'''
 
Generate the security questions, e.g. by creating a new account, going through the forgotten password functionality, or whatever the process is for that particular system. If the system allows the user to generate their own security questions, it is vulnerable to having insecure questions created. If the system uses the self-generated security questions during the forgotten password functionality and if usernames can be enumerated (see [[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]), then it should be easy for the tester to enumerate a number of users' self-generated questions. It should be expected to find several weak self-generated passwords using this method.
 
'''Testing for brute-forcible answers:'''
 
Use the methods described in [[Testing for Weak lock out mechanism (OWASP-AT-004)]] to determine whether a number of incorrectly supplied security answers generates an appropriate lock out mechanism.
 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

Testing for Weak security question/answer (OTG-AUTHN-008)

2013-08-14T05:43:52Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords, or as extra security on top of password.
 
They are typically generated upon account creation, and require the user to select from some pre-generated questions and supply an appropriate answer, or allow the user to generate their own question and answer pairs. Both methods are prone to insecurities.
 
Ideally, security questions should generate answers that are only known by the user, and not guessable or discoverable by anybody else. This is harder than it sounds.
 

== Description of the Issue ==
Security questions and answers rely on the secrecy of the answer. Answers should be of the form that are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that websites implement promote answers that are pseduo-private. Some examples are below.
 
'''Pre-generated questions:'''
 
The majority of pre-generated questions are fairly simplistic in nature and can lead to insecure answers. For example:
* The answers may be known to family members or close friends of the user, e.g. "What is your mother's maiden name?", "What is your date of birth?"
* The answers may be easily guessable, e.g. "What is your favorite color?", "What is your favorite baseball team?"
* The answers may be brute forcible, e.g. "What is the first name of your favorite high school teacher?" - the answer is probably on some easily downloadable lists of popular first names, and therefore a simple brute force attack can be scripted.
* The answers may be publicly discoverable, e.g. "What is your favorite movie?" - the answer may easily be found on the user's social media profile page.
 
'''Self-generated questions:'''
 
The problem with having users to generate their own questions is that it allows them to generate very insecure questions, or even bypass the whole point of having a security question in the first place. Here are some real world examples that illustrates this point:
 
* "What is 1+1?"
* "What is your username?"
* "My password is M3@t$p1N"
 
== Black Box testing and example ==
'''Testing for weak pre-generated questions:'''
 
'''Testing for weak self-generated questions:'''
 
'''Testing for brute-forcible answers:'''
 
Use the methods described in [[Testing for Weak lock out mechanism (OWASP-AT-004)]] to determine whether a number of incorrectly supplied security answers generates an appropriate lock out mechanism.
 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

Testing for Weak security question/answer (OTG-AUTHN-008)

2013-08-14T05:42:14Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords, or as extra security on top of password.
 
They are typically generated upon account creation, and require the user to select from some pre-generated questions and supply an appropriate answer, or allow the user to generate their own question and answer pairs. Both methods are prone to insecurities.
 

== Description of the Issue ==
Security questions and answers rely on the secrecy of the answer. Answers should be of the form that are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that websites implement promote answers that are pseduo-private. Some examples are below.
 
'''Pre-generated questions:'''
 
The majority of pre-generated questions are fairly simplistic in nature and can lead to insecure answers. For example:
* The answers may be known to family members or close friends of the user, e.g. "What is your mother's maiden name?", "What is your date of birth?"
* The answers may be easily guessable, e.g. "What is your favorite color?", "What is your favorite baseball team?"
* The answers may be brute forcible, e.g. "What is the first name of your favorite high school teacher?" - the answer is probably on some easily downloadable lists of popular first names, and therefore a simple brute force attack can be scripted.
* The answers may be publicly discoverable, e.g. "What is your favorite movie?" - the answer may easily be found on the user's social media profile page.
 
'''Self-generated questions:'''
 
The problem with having users to generate their own questions is that it allows them to generate very insecure questions, or even bypass the whole point of having a security question in the first place. Here are some real world examples that illustrates this point:
 
* "What is 1+1?"
* "What is your username?"
* "My password is M3@t$p1N"
 
== Black Box testing and example ==
'''Testing for weak pre-generated questions:'''
 
'''Testing for weak self-generated questions:'''
 
'''Testing for brute-forcible answers:'''
 
Use the methods described in [[Testing for Weak lock out mechanism (OWASP-AT-004)]] to determine whether a number of incorrectly supplied security answers generates an appropriate lock out mechanism.
 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

Testing for Weak security question/answer (OTG-AUTHN-008)

2013-08-14T05:41:02Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords, or as extra security on top of password.
 
They are typically generated upon account creation, and require the user to select from some pre-generated questions and supply an appropriate answer, or allow the user to generate their own question and answer pairs. Both methods are prone to insecurities.
 

== Description of the Issue ==
Security questions and answers rely on the secrecy of the answer. Answers should be of the form that are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that websites implement promote answers that are pseduo-private. Some examples are below.
 
'''Pre-generated questions:'''
 
The majority of pre-generated questions are fairly simplistic in nature and can lead to insecure answers. For example:
* The answers may be known to family members or close friends of the user, e.g. "What is your mother's maiden name?", "What is your date of birth?"
* The answers may be easily guessable, e.g. "What is your favorite color?", "What is your favorite baseball team?"
* The answers may be brute forcible, e.g. "What is the first name of your favorite high school teacher?" - the answer is probably on some easily downloadable lists of popular first names, and therefore a simple brute force attack can be scripted.
* The answers may be publicly discoverable, e.g. "What is your favorite movie?" - the answer may easily be found on the user's social media profile page.
 
'''Self-generated questions:'''
 
The problem with having users to generate their own questions is that it allows them to generate very insecure questions, or even bypass the whole point of having a security question in the first place. Here are some real world examples that illustrates this point:
 
* "What is 1+1?"
* "What is your username?"
* "My password is M3@t$p1N"
 
== Black Box testing and example ==
'''Testing for weak pre-generated questions:'''
 
'''Testing for weak self-generated questions:'''
 
'''Testing for brute-forcible answers:'''
 
Use the methods described in [[Testing for Weak lock out mechanism (OWASP-AT-004)]] to determine whether a number of incorrectly supplied security answers generates an appropriate lock out mechanism.
 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

Testing for Weak security question/answer (OTG-AUTHN-008)

2013-08-14T05:36:22Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords, or as extra security on top of password.
 
They are typically generated upon account creation, and require the user to select from some pre-generated questions and supply an appropriate answer, or allow the user to generate their own question and answer pairs. Both methods are prone to insecurities.
 

== Description of the Issue ==
Security questions and answers rely on the secrecy of the answer. Answers should be of the form that are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that websites implement promote answers that are pseduo-private. Some examples are below.
 
'''Pre-generated questions:'''
 
The majority of pre-generated questions are fairly simplistic in nature and can lead to insecure answers. For example:
* The answers may be known to family members or close friends of the user, e.g. "What is your mother's maiden name?", "What is your date of birth?"
* The answers may be easily guessable, e.g. "What is your favorite color?", "What is your favorite baseball team?"
* The answers may be brute forcible, e.g. "What is the first name of your favorite high school teacher?" - the answer is probably on some easily downloadable lists of popular first names, and therefore a simple brute force attack can be scripted.
* The answers may be publicly discoverable, e.g. "What is your favorite movie?" - the answer may easily be found on the user's social media profile page.
 
'''Self-generated questions:'''
 
== Black Box testing and example ==
'''Testing for weak pre-generated questions:'''
 
'''Testing for weak self-generated questions:'''
 
'''Testing for brute-forcible answers:'''
 
Use the methods described in [[Testing for Weak lock out mechanism (OWASP-AT-004)]] to determine whether a number of incorrectly supplied security answers generates an appropriate lock out mechanism.
 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

Testing for Weak security question/answer (OTG-AUTHN-008)

2013-08-14T05:19:53Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords, or as extra security on top of password.
 
They are typically generated upon account creation, and require the user to select from some pre-generated questions and supply an appropriate answer, or allow the user to generate their own question and answer pairs. Both methods are prone to insecurities.
 

== Description of the Issue ==
Security questions and answers rely on the secrecy of the answer. Answers should be of the form that are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that websites offer promote answers that are pseduo-private. Some examples are below.
'''Pre-generated questions:''' 
The majority of pre-generated questions are fairly simplistic in nature and can generate insecure answers. For example:
* The answers may be known to family members or close friends of the user, e.g. "What is your mother's maiden name?"
* The answer may be easily guessable.
 
== Black Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

Testing for Weak security question/answer (OTG-AUTHN-008)

2013-08-14T05:06:46Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords, or as extra security on top of password.
They are typically generated upon account creation, and require the user to select from some pre-generated questions and supply an appropriate answer, or allow the user to generate their own question and answer pairs. Both methods are prone to insecurities.
 
== Description of the Issue ==
 
...here: Short Description of the Issue: Topic and Explanation
 
== Black Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

Testing for Weak security question/answer (OTG-AUTHN-008)

2013-08-14T05:01:10Z

Robert WInkel: Created page with "{{Template:OWASP Testing Guide v4}} == Brief Summary == == Description of the Issue == == Black Box testing and example == == Gray Box testing and example == == Referen..."

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

== Description of the Issue ==

== Black Box testing and example ==

== Gray Box testing and example ==

== References ==

Testing for User Enumeration and Guessable User Account (OWASP-AT-002)

2012-10-26T04:27:40Z

Robert WInkel:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
The scope of this test is to verify if it is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password.
Often, web applications reveal when a username exists on system, either as a consequence of a misconfiguration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong.
The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack.
 

== Description of the Issue ==
The tester should interact with the authentication mechanism of the application to understand if sending particular requests causes the application to answer in different manners. This issue exists because the information released from web application or web server when we provide a valid username is different than when we use an invalid one.

In some cases, we receive a message that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, we can enumerate the existing users by sending a username and an empty password.

== Black Box testing and example ==
In a black box testing, we know nothing about the specific application, username, application logic, error messages on login page, or password recovery facilities.
If the application is vulnerable, we receive a response message that reveals, directly or indirectly, some information useful for enumerating users.

===HTTP Response message===

'''Testing for Valid user/right password'''

Record the server answer when you submit a valid userID and valid password.

'''Result Expected:'''

Using WebScarab, notice the information retrieved from this successful authentication (HTTP 200 Response, length of the response).

'''Testing for valid user/wrong password''' 
Now, the tester should try to insert a valid userID and a wrong password and record the error message generated by the application.

'''Result Expected:''' 
From the browser we will expect message similar to the following one: 
[[Image:AuthenticationFailed.png]] 

or something like: 
[[Image:NoConfFound.jpg]] 

against any message that reveals the existence of user, for instance, message similar to: 
Login for User foo: invalid password

Using WebScarab, notice the information retrieved from this unsuccessful authentication attempt (HTTP 200 Response, length of the response).

'''Testing for a nonexistent username'''

Now, the tester should try to insert an invalid userID and a wrong password and record the server answer (you should be confident that the username is not valid in the application). Record the error message and the server answer.

'''Result Expected:'''

If we enter a nonexistent userID, we can receive a message similar to: 
[[Image:Userisnotactive.png]] 
or message like the following one: 
Login failed for User foo: invalid Account

Generally the application should respond with the same error message and length to the different wrong requests. If you notice that the responses are not the same, you should investigate and find out the key that creates a difference between the two responses. For example:
* Client request: Valid user/wrong password --> Server answer:'The password is not correct'
* Client request: Wrong user/wrong password --> Server answer:'User not recognized'
The above responses let the client understand that for the first request we have a valid user name. So we can interact with the application requesting a set of possible userIDs and observing the answer.

Looking at the second server response, we understand in the same way that we don't hold a valid username. So we can interact in the same manner and create a list of valid userID looking at the server answers.

===Other ways to enumerate users===

We can enumerate users in several ways, such as: 
'''- Analyzing the error code received on login pages''' 
Some web application release a specific error code or message that we can analyze.

'''- Analyzing URLs, and URLs redirections''' 
For example: 
http://www.foo.com/err.jsp?User=baduser&Error=0 
http://www.foo.com/err.jsp?User=gooduser&Error=2

As we can see above, when we provide a userID and password to the web application, we see a message indication that an error has occurred in the URL.
In the first case we has provided a bad userID and bad password. In the second, a good user and bad password, so we can identify a valid userID.

'''- URI Probing''' 
Sometimes a web server responds differently if it receives a request for an existing directory or not. For instance in some portals every user is associated with a directory. If we try to access an existing directory we could receive a web server error.
A very common error that we can receive from web server is: 
403 Forbidden error code
and 
404 Not found error code
 
Example 
http://www.foo.com/account1 - we receive from web server: 403 Forbidden
http://www.foo.com/account2 - we receive from web server: 404 file Not Found

In first case the user exists, but we cannot view the web page, in second case instead the user “account2” doesn’t exist.
Collecting this information we can enumerate the users.

'''- Analyzing Web page Titles''' 
We can receive useful information on Title of web page, where we can obtain a specific error code or messages that reveal if the problems are on username or password.
For instance, if we cannot authenticate to an application and receive a web page whose title is similar to:
Invalid user
Invalid authentication

'''- Analyzing message received from recovery facility''' 
When we use a recovery facility (i.e. a Forgotten Password function) a vulnerable application might return a message that reveals if a username exists or not.

For example, message similar to the following: 
Invalid username: e-mail address is not valid or the specified user was not found.

Valid username: Your password has been successfully sent to the email address you registered with.
 

'''- Friendly 404 Error Message''' 
When we request for a user within the directory that does not exist, we don't always receive 404 error code. Instead, we may receive “200 ok” with an image, in this case we can assume that when we receive the specific image the user doesn’t exist. This logic can be applied to other web server response; the trick is a good analysis of web server and web application messages.
 
 
===Guessing Users===
In some cases the userIDs are created with specific policies of administrator or company.
For example we can view a user with a userID created in sequential order: 
CN000100 
CN000101 
…. 
Sometimes the usernames are created with a REALM alias and then a sequential numbers: 
R1001 – user 001 for REALM1 
R2001 – user 001 for REALM2 
 
In the above sample we can create simple shell scripts that compose UserIDs and submit a request with tool like wget to automate a web query to discern valid userIDs.
To create a script we can also use Perl and CURL.

Other possibilities are:
- userIDs associated with credit card numbers, or in general numbers with a pattern.
- userIDs associated with real names, e.g. if Freddie Mercury has a userID of "fmercury", then you might guess Roger Taylor to have the userID of "rtaylor".

Again, we can guess a username from the information received from an LDAP query or from Google information gathering, for example, from a specific domain.
Google can help to find domain users through specific queries or through a simple shell script or tool.

 
'''Attention:''' by enumerating user accounts, you risk locking out accounts after a predefined number of failed probes (based on application policy). Also, sometimes, your IP address can be banned by dynamic rules on the application firewall or Intrusion Prevention System.

== Gray Box testing and example ==
'''Testing for Authentication error messages''' 
Verify that the application answers in the same manner for every client request that produces a failed authentication. For this issue the Black Box testing and Gray Box testing have the same concept based on the analysis of messages or error codes received from web application. 
'''Result Expected:''' 
The application should answer in the same manner for every failed attempt of authentication. 
For Example: 
Credentials submitted are not valid
 

== References ==
* Marco Mella, ''Sun Java Access & Identity Manager Users enumeration: http://www.aboutsecurity.net ''
* ''Username Enumeration Vulnerabilities: http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities ''

'''Tools''' 
* WebScarab: [[OWASP_WebScarab_Project]]
* CURL: http://curl.haxx.se/
* PERL: http://www.perl.org
* Sun Java Access & Identity Manager users enumeration tool: http://www.aboutsecurity.net

OWASP Testing Guide v4 Table of Contents

2012-10-26T01:29:57Z

Robert WInkel:

__NOTOC__

'''This is the DRAFT of the table of content of the New Testing Guide v4.''' 
 You can download the stable version v3[http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here] 

Back to the OWASP Testing Guide Project:
http://www.owasp.org/index.php/OWASP_Testing_Project

'''Updated: 22nd October 2012'''

[[ OWTGv4 Contributors list|'''Contributors List]]

----

The following is a DRAFT of the Toc based on the feedback already received.

== Table of Contents ==

==[[Testing Guide Foreword|Foreword by OWASP Chair]]==
[To review--> OWASP Chair]

==[[Testing Guide Frontispiece |1. Frontispiece]]==
[To review--> Mat]

'''[[Testing Guide Frontispiece|1.1 About the OWASP Testing Guide Project]]'''
[To review--> Mat]

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''
[To review--> ]

==[[Testing Guide Introduction|2. Introduction]]==

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

2.4 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation Security requirements test derivation],[https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_and_Non_Functional_Test_Requirements functional and non functional test requirements], and [https://www.owasp.org/index.php/Testing_Guide_Introduction#Test_Cases_Through_Use_and_Misuse_Cases test cases through use and misuse cases]

2.5 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Test_Data_Analysis_and_Reporting Security test data analysis and reporting: root cause identification and business/role case test data reporting]

==[[The OWASP Testing Framework|3. The OWASP Testing Framework]]==

'''3.1. Overview'''

'''3.2. Phase 1: Before Development Begins '''

'''3.3. Phase 2: During Definition and Design'''

'''3.4. Phase 3: During Development'''

'''3.5. Phase 4: During Deployment'''

'''3.6. Phase 5: Maintenance and Operations'''

'''3.7. A Typical SDLC Testing Workflow '''

==[[Web Application Penetration Testing |4. Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']] [To review--> Mat]

[[Testing Checklist| 4.1.1 Testing Checklist]] [To review at the end of brainstorming --> Mat]

[[Testing: Information Gathering|'''4.2 Information Gathering ''']] [To review--> contributor here]

[[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|4.2.1 Spiders, Robots and Crawlers (OWASP-IG-001)]]

[[Testing: Search engine discovery/reconnaissance (OWASP-IG-002)|4.2.2 Search Engine Discovery/Reconnaissance (OWASP-IG-002)]]

[[Testing: Identify application entry points (OWASP-IG-003)|4.2.3 Identify application entry points (OWASP-IG-003)]]

[[Testing for Web Application Fingerprint (OWASP-IG-004)|4.2.4 Testing for Web Application Fingerprint (OWASP-IG-004)]]

[[Testing for Application Discovery (OWASP-IG-005)|4.2.5 Application Discovery (OWASP-IG-005)]]

[[Testing for Error Code (OWASP-IG-006)|4.2.6 Analysis of Error Codes (OWASP-IG-006)]]

[[Testing for configuration management|'''4.3 Configuration and Deploy Management Testing ''']]

[[Testing for infrastructure configuration management (OWASP-CM-003)|4.3.1 Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)]]

[[Testing for application configuration management (OWASP-CM-004)|4.3.2 Testing for Application Configuration Management weakness (OWASP-CM-002)]]

[[Testing for file extensions handling (OWASP-CM-005)|4.3.3 Testing for File Extensions Handling (OWASP-CM-003)]]

[[Testing for Old, Backup and Unreferenced Files (OWASP-CM-006)|4.3.4 Old, Backup and Unreferenced Files (OWASP-CM-004) ]]

[[Testing for Admin Interfaces (OWASP-CM-007)|4.3.5 Infrastructure and Application Admin Interfaces (OWASP-CM-005)]]

[[Testing for HTTP Methods and XST (OWASP-CM-008)|4.3.6 Testing for Bad HTTP Methods (OWASP-CM-006)]][new - Abian Blome]

> Informative Error Messages [MAT NOTE: in info gathering] 

[[Testing for Database credentials/connection strings available|4.3.7 Testing for Database credentials/connection strings available (OWASP-CM-007)]]

[[Testing for Content Security Policy weakness|4.3.8 Testing for Content Security Policy weakness (OWASP-CM-008)]][New! - Simone Onofri]

[[Testing for Missing HSTS header|4.3.9 Testing for Missing HSTS header (OWASP-CM-009)]][New! Juan Manuel Bahamonde ]

[[Testing for RIA policy files weakness|4.3.10 Testing for RIA policy files weakness (OWASP-CM-010)]] [New!]

> Incorrect time[New! MAT NOTE: explain the test in detail please]

> Unpatched components and libraries (e.g. JavaScript libraries)[New! NOTE: tu discuss it]

> Test data in production systems (and vice versa)[New! MAT NOTE: this is not a particular test that could find a vulnerability] 

[[Testing for authentication|'''4.4 Authentication Testing ''']]

[[Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|4.4.1 Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)]] [Robert Winkel]

[[Testing for User Enumeration and Guessable User Account (OWASP-AT-002)|4.4.2 Testing for User Enumeration and Guessable User Account (OWASP-AT-002)]] [Robert Winkel]

[[Testing for default credentials (OWASP-AT-003)|4.4.3 Testing for default credentials (OWASP-AT-003)]]

[[Testing for Weak lock out mechanism (OWASP-AT-004)|4.4.4 Testing for Weak lock out mechanism (OWASP-AT-004)]] [New! - Robert Winkel]

> Account lockout DoS [New! - Robert Winkel - we can put it in the 4.4.4]

[[Testing for Bypassing Authentication Schema (OWASP-AT-005)|4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)]]

[[Testing for Vulnerable Remember Password (OWASP-AT-006)|4.4.6 Testing for vulnerable remember
password functionality (OWASP-AT-006)]] [Robert Winkel]

[[Testing for Browser cache weakness (OWASP-AT-007)|4.4.7 Testing for Browser cache weakness (OWASP-AT-007)]] [New! - Abian Blome]

[[Testing for Weak password policy (OWASP-AT-008)|4.4.8 Testing for Weak password policy (OWASP-AT-008)]] [New! - Robert Winkel]

[[Testing for Weak or unenforced username policy (OWASP-AT-009)|4.4.9 Testing for Weak or unenforced username policy (OWASP-AT-009)]] [New! - Robert Winkel]

> Weak security question/answer [New! - Robert Winkel - MAT Note: same as AT-006] 

[[Testing for failure to restrict access to authenticated resource(OWASP-AT-010)|4.4.10 Testing for failure to restrict access to authenticated resource (OWASP-AT-010)]] [New!] 

[[Testing for weak password change or reset functionalities (OWASP-AT-011)|4.4.11 Testing for weak password change or reset functionalities (OWASP-AT-011)]] [New! - Robert Winkel] 

[[Testing for Captcha (OWASP-AT-012)|4.4.12 Testing for CAPTCHA (OWASP-AT-012)]]

> Weaker authentication in alternative channel (e.g. mobile app, IVR, help desk) [New!: MAT Note: to explain better the kind of test to perform please] 

[[Testing for Session Management|'''4.5 Session Management Testing''']]

[[Testing for Session_Management_Schema (OWASP-SM-001)|4.5.1 Testing for Bypassing Session Management Schema (OWASP-SM-001)]]

[[Testing for cookies attributes (OWASP-SM-002)|4.5.2 Testing for Cookies attributes (Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity) (OWASP-SM-002)]]

[[Testing for Session Fixation (OWASP-SM-003)|4.5.3 Testing for Session Fixation (OWASP-SM-003)]]

[[Testing for Exposed Session Variables (OWASP-SM-004)|4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)]]

[[Testing for CSRF (OWASP-SM-005)|4.5.5 Testing for Cross Site Request Forgery (CSRF) (OWASP-SM-005)]]

> Weak Session Token (MAT NOTE included in 4.5.1)

[[Testing for Session token not restricted properly (OWASP-SM-006)|4.5.6 Testing for Session token not restricted properly (such as domain or path not set properly) (OWASP-SM-006)]] [New! - Abian Blome] 

> Session passed over http (NOTE: included in SM-004) [New!] 

[[Testing for logout functionality (OWASP-SM-007)|4.5.7 Testing for logout functionality (OWASP-SM-007)]]

>Session token not removed on server after logout [New!: NOTE included in the above test] 

> Logout function not properly implemented (NOTE:same above) 

> Persistent session token [New! NOTE: this is not a vulnerability if session time out is correctly performed] 

[[Testing for Session puzzling (OWASP-SM-008)|4.5.8 Testing for Session puzzling (OWASP-SM-008)]] [New! - Abian Blome]

> Missing user-viewable log of authentication events [NOTE: needs more details: which test perform?]

[[Testing for Authorization|'''4.6 Authorization Testing''']]

[[Testing for Path Traversal (OWASP-AZ-001)|4.6.1 Testing Directory traversal/file include (OWASP-AZ-001) [Juan Galiana] ]]

[[Testing for Bypassing Authorization Schema (OWASP-AZ-002)|4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)]]

[[Testing for Privilege escalation (OWASP-AZ-003)|4.6.3 Testing for Privilege Escalation (OWASP-AZ-003) [Irene Abezgauz]]]

[[Testing for Insecure Direct Object References (OWASP-AZ-004)|4.6.4 Testing for Insecure Direct Object References (OWASP-AZ-004) [Irene Abezgauz] ]]

[[Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)|4.6.5 Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005) [New!] ]]

> Server component has excessive privileges (e.g. indexing service, reporting interface, file generator)[New!] 
> Lack of enforcement of application entry points (including exposure of objects)[New!] 

[[Testing for business logic (OWASP-BL-001)|'''4.7 Business Logic Testing (OWASP-BL-001)''']] [To review--> contributor here]
Business Logic 

Business logic data validation[New!] NOTE MAT: to discuss this section 
Ability to forge requests[New!] 
Lack of integrity checks (e.g. overwriting updates) [New!] 
Lack of tamper evidence[New!] 
Use of untrusted time source[New!] 
Lack of limits to excessive rate (speed) of use[New!] 
Lack of limits to size of request[New!] 
Lack of limit to number of times a function can be used[New!] 
Bypass of correct sequence[New!] 
Missing user-viewable log of actvity[New!] 
Self-hosted payment cardholder data processing[New!] 
Lack of security incident reporting information[New!] 
Defenses against application mis-use[New!] 

[[Testing for Data Validation|'''4.8 Data Validation Testing''']]

[[Testing for Reflected Cross site scripting (OWASP-DV-001) |4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001) ]]

[[Testing for Stored Cross site scripting (OWASP-DV-002) |4.8.2 Testing for Stored Cross Site Scripting (OWASP-DV-002) ]]

[[Testing for HTTP Verb Tampering (OWASP-DV-003)|4.8.3 Testing for HTTP Verb Tampering [Brad Causey] ]]

[[Testing for HTTP Parameter pollution (OWASP-DV-004)|4.8.4 Testing for HTTP Parameter pollution [Luca Carettoni, Stefano Di Paola, Brad Causey] ]]

[[Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)|4.8.5 Testing for Unvalidated Redirects and Forwards [Brad Causey] ]]

[[Testing for SQL Injection (OWASP-DV-005)| 4.8.5 Testing for SQL Injection (OWASP-DV-005) Ismael Gonçalves]]

[[Testing for Oracle|4.8.5.1 Oracle Testing]]

[[Testing for MySQL|4.8.5.2 MySQL Testing]]

[[Testing for SQL Server|4.8.5.3 SQL Server Testing]]

[[Testing for MS Access |4.8.5.4 MS Access Testing]]

[[Testing for NoSQL injection|4.8.5.5 Testing for NoSQL injection [New!]]]

[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.5.5 Testing PostgreSQL (from OWASP BSP) ]]

[[Testing for LDAP Injection (OWASP-DV-006)|4.8.6 Testing for LDAP Injection (OWASP-DV-006)]]

[[Testing for ORM Injection (OWASP-DV-007)|4.8.7 Testing for ORM Injection (OWASP-DV-007)]]

[[Testing for XML Injection (OWASP-DV-008)|4.8.8 Testing for XML Injection (OWASP-DV-008)]]

[[Testing for SSI Injection (OWASP-DV-009)|4.8.9 Testing for SSI Injection (OWASP-DV-009)]]

[[Testing for XPath Injection (OWASP-DV-010)|4.8.10 Testing for XPath Injection (OWASP-DV-010)]]

[[Testing for IMAP/SMTP Injection (OWASP-DV-011)|4.8.11 IMAP/SMTP Injection (OWASP-DV-011)]]

[[Testing for Code Injection (OWASP-DV-012)|4.8.12 Testing for Code Injection (OWASP-DV-012)]]

[[Testing for Command Injection (OWASP-DV-013)|4.8.13 Testing for Command Injection (OWASP-DV-013) [Juan Galiana]]]

[[Testing for Buffer Overflow (OWASP-DV-014)|4.8.14 Testing for Buffer overflow (OWASP-DV-014)]]

[[Testing for Heap Overflow|4.8.14.1 Testing for Heap overflow]]

[[Testing for Stack Overflow|4.8.14.2 Testing for Stack overflow]]

[[Testing for Format String|4.8.14.3 Testing for Format string]]

[[Testing for Incubated Vulnerability (OWASP-DV-015)|4.8.15 Testing for incubated vulnerabilities (OWASP-DV-015)]]

[[Testing for HTTP Splitting/Smuggling (OWASP-DV-016)|4.8.16 Testing for HTTP Splitting/Smuggling (OWASP-DV-016) [Juan Galiana] ]]

> Regular expression DoS[New!] note: to understand better 

[[Data Encryption (New!)]]

[[Testing for Insecure encryption usage (OWASP-EN-001)| 4.9.1 Testing for Insecure encryption usage (OWASP-EN-001]]

[[Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)| 4.9.2 Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)]]

[[Testing for Padding Oracle (OWASP-EN-003)| 4.9.3 Testing for Padding Oracle (OWASP-EN-003) [Giorgio Fedon]]]

> [[Testing for Cacheable HTTPS Response | x.x.3 Testing for Cacheable HTTPS Response 
Cache directives insecure 
> Testing for Insecure Cryptographic Storage [put in x.x.1] 
[[Testing for Sensitive information sent via unencrypted channels | x.x.4 

[[Web Service (XML Interpreter)|'''4.10 Web Service Testing''']] [Tom Eston]

[[Scoping a Web Service Test (OWASP-WS-001)|4.10.1 Scoping a Web Service Test (OWASP-WS-001)]]

[[WS Information Gathering (OWASP-WS-002)|4.10.2 WS Information Gathering (OWASP-WS-002)]]

[[WS Authentication Testing (OWASP-WS-003)|4.10.3 WS Authentication Testing (OWASP-WS-003)]]

[[WS Management Interface Testing (OWASP-WS-004)|4.10.4 WS Management Interface Testing (OWASP-WS-004)]]

[[Weak XML Structure Testing (OWASP-WS-005)|4.10.5 Weak XML Structure Testing (OWASP-WS-005)]]

[[XML Content-Level Testing (OWASP-WS-006)|4.10.6 XML Content-Level Testing (OWASP-WS-006)]]

[[WS HTTP GET Parameters/REST Testing (OWASP-WS-007)|4.10.7 WS HTTP GET Parameters/REST Testing (OWASP-WS-007)]]

[[WS Naughty SOAP Attachment Testing (OWASP-WS-008)|4.10.8 WS Naughty SOAP Attachment Testing (OWASP-WS-008)]]

[[WS Replay/MiTM Testing (OWASP-WS-009)|4.10.9 WS Replay/MiTM Testing (OWASP-WS-009)]]

[[WS BEPL Testing (OWASP-WS-010)|4.10.10 WS BEPL Testing (OWASP-WS-010)]]

[[Client Side Testing|'''4.11 Client Side Testing''']] [New!]

[[Testing for DOM-based Cross site scripting (OWASP-DV-003)|4.11.1 Testing for DOM based Cross Site Scripting (OWASP-CS-001) [Stefano Di Paola]]

[[Testing for HTML5 (OWASP CS-002)|4.11.2 Testing for HTML5 (OWASP CS-002) [Juan Galiana] ]] 

[[Testing for Cross site flashing (OWASP-DV-004)|4.11.3 Testing for Cross Site Flashing (OWASP-CS-003)]]

[[Testing for Testing for ClickHijacking (OWASP-CS-004)|4.11.4 Testing for Testing for ClickHijacking (OWASP-CS-004) ]] 

==[[Writing Reports: value the real risk |5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]] [To review--> contributor here]

[[How to write the report of the testing |5.2 How to write the report of the testing]] [To review--> contributor here]

==[[Appendix A: Testing Tools |Appendix A: Testing Tools ]]==

* Black Box Testing Tools [To review--> Amro. We need only tools fo webapp testing]

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers [To review--> David Fern]
* Books [To review--> David Fern]
* Useful Websites [To review--> David Fern]

==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]==

* Fuzz Categories [To review--> contributor here]

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==

[To review--> contributor here]

----

[[Category:OWASP Testing Project]]

Testing for User Enumeration and Guessable User Account (OWASP-AT-002)

2012-10-26T01:28:15Z

Robert WInkel: moved Testing for user enumeration (OWASP-AT-002) to Testing for User Enumeration and Guessable User Account (OWASP-AT-002): Better title

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
The scope of this test is to verify if it is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password.
Often, web applications reveal when a username exists on system, either as a consequence of a misconfiguration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong.
The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack.
 

== Description of the Issue ==
The tester should interact with the authentication mechanism of the application to understand if sending particular requests causes the application to answer in different manners. This issue exists because the information released from web application or web server when we provide a valid username is different than when we use an invalid one.

In some cases, we receive a message that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, we can enumerate the existing users by sending a username and an empty password.

== Black Box testing and example ==
In a black box testing, we know nothing about the specific application, username, application logic, error messages on login page, or password recovery facilities.
If the application is vulnerable, we receive a response message that reveals, directly or indirectly, some information useful for enumerating users.

===HTTP Response message===

'''Testing for Valid user/right password'''

Record the server answer when you submit a valid userID and valid password.

'''Result Expected:'''

Using WebScarab, notice the information retrieved from this successful authentication (HTTP 200 Response, length of the response).

'''Testing for valid user/wrong password''' 
Now, the tester should try to insert a valid userID and a wrong password and record the error message generated by the application.

'''Result Expected:''' 
From the browser we will expect message similar to the following one: 
[[Image:AuthenticationFailed.png]] 

or something like: 
[[Image:NoConfFound.jpg]] 

against any message that reveals the existence of user, for instance, message similar to: 
Login for User foo: invalid password

Using WebScarab, notice the information retrieved from this unsuccessful authentication attempt (HTTP 200 Response, length of the response).

'''Testing for a nonexistent username'''

Now, the tester should try to insert an invalid userID and a wrong password and record the server answer (you should be confident that the username is not valid in the application). Record the error message and the server answer.

'''Result Expected:'''

If we enter a nonexistent userID, we can receive a message similar to: 
[[Image:Userisnotactive.png]] 
or message like the following one: 
Login failed for User foo: invalid Account

Generally the application should respond with the same error message and length to the different wrong requests. If you notice that the responses are not the same, you should investigate and find out the key that creates a difference between the two responses. For example:
* Client request: Valid user/wrong password --> Server answer:'The password is not correct'
* Client request: Wrong user/wrong password --> Server answer:'User not recognized'
The above responses let the client understand that for the first request we have a valid user name. So we can interact with the application requesting a set of possible userIDs and observing the answer.

Looking at the second server response, we understand in the same way that we don't hold a valid username. So we can interact in the same manner and create a list of valid userID looking at the server answers.

'''Other ways to enumerate users'''

We can enumerate users in several ways, such as: 
'''- Analyzing the error code received on login pages''' 
Some web application release a specific error code or message that we can analyze.

'''- Analyzing URLs, and URLs redirections''' 
For example: 
http://www.foo.com/err.jsp?User=baduser&Error=0 
http://www.foo.com/err.jsp?User=gooduser&Error=2

As we can see above, when we provide a userID and password to the web application, we see a message indication that an error has occurred in the URL.
In the first case we has provided a bad userID and bad password. In the second, a good user and bad password, so we can identify a valid userID.

'''- URI Probing''' 
Sometimes a web server responds differently if it receives a request for an existing directory or not. For instance in some portals every user is associated with a directory. If we try to access an existing directory we could receive a web server error.
A very common errors that we can receive from web server is: 
403 Forbidden error code
and 
404 Not found error code
 
Example 
http://www.foo.com/account1 - we receive from web server: 403 Forbidden
http://www.foo.com/account2 - we receive from web server: 404 file Not Found

In first case the user exists, but we cannot view the web page, in second case instead the user “account2” doesn’t exist.
Collecting this information we can enumerate the users.

'''- Analyzing Web page Titles''' 
We can receive useful information on Title of web page, where we can obtain a specific error code or messages that reveal if the problems are on username or password.
For instance, if we cannot authenticate to an application and receive a web page whose title is similar to:
Invalid user
Invalid authentication

'''- Analyzing message received from recovery facilities''' 
When we use a recovery facilities the applications that is vulnerable could return a message that reveals if a username exists or not.

For example, message similar to the following: 
Invalid username: e-mail address are not valid or The specified user was not found

Valid username: Your recovery password has been successfully sent
 

'''- Friendly 404 Error Message''' 
When we request for a user within the directory that does not exist, we don't always receive 404 error code. Instead, we may receive “200 ok” with an image, in this case we can assume that when we receive the specific image the user doesn’t exist. This logic can be applied to other web server response; the trick is a good analysis of web server and web application messages.
 
 
'''Guessing Users''' 
In some cases the userIDs are created with specific policies of administrator or company.
For example we can view a user with a userID created in sequential order: 
CN000100 
CN000101 
…. 
Sometimes the usernames are created with a REALM alias and then a sequential numbers: 
R1001 – user 001 for REALM1 
R2001 – user 001 for REALM2 
 
Other possibilities are userIDs associated with credit card numbers, or in general a numbers with a pattern.
In the above sample we can create simple shell scripts that compose UserIDs and submit a request with tool like wget to automate a web query to discern valid userIDs.
To create a script we can also use Perl and CURL.

Again, we can guess a username from the information received from an LDAP query or from google information gathering for example from a specific domain.
Google can help to find domain users through a specific queries or through a simple shell script or tool.

For other information on guessing userIDs see next section 4.5.3 Testing for Guessable (Dictionary) User Account.
 
'''Attention:''' by enumerating user accounts, you risk locking out accounts after a predefined number of failed probes (based on application policy). Also, sometimes, our IP address can be banned by dynamic rules on the application firewall.

== Gray Box testing and example ==
'''Testing for Authentication error messages''' 
Verify that the application answers in the same manner for every client request that produces a failed authentication. For this issue the Black Box testing and Gray Box testing have the same concept based on the analysis of messages or error codes received from web application. 
'''Result Expected:''' 
The application should answer in the same manner for every failed attempt of authentication. 
For Example: 
Credentials submitted are not valid
 

== References ==
* Marco Mella, ''Sun Java Access & Identity Manager Users enumeration: http://www.aboutsecurity.net ''
* ''Username Enumeration Vulnerabilities: http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities ''

'''Tools''' 
* WebScarab: [[OWASP_WebScarab_Project]]
* CURL: http://curl.haxx.se/
* PERL: http://www.perl.org
* Sun Java Access & Identity Manager users enumeration tool: http://www.aboutsecurity.net

Testing for user enumeration (OWASP-AT-002)

2012-10-26T01:28:15Z

Robert WInkel: moved Testing for user enumeration (OWASP-AT-002) to Testing for User Enumeration and Guessable User Account (OWASP-AT-002): Better title

#REDIRECT [[Testing for User Enumeration and Guessable User Account (OWASP-AT-002)]]

Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)

2012-10-26T01:04:10Z

Robert WInkel: moved Testing for credentials transport (OWASP-AT-001) to Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001): Better title

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Testing for credentials transport means to verify that the user's authentication data are transferred via an encrypted channel to avoid being intercepted by malicious users. The analysis focuses simply on trying to understand if the data travels unencrypted from the web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. The HTTPS protocol is built on TLS/SSL to encrypt the data that is transmitted and to ensure that user is being sent towards the desired site. Clearly, the fact that traffic is encrypted does not necessarily mean that it's completely safe. The security also depends on the encryption algorithm used and the robustness of the keys that the application is using, but this particular topic will not be addressed in this section. For a more detailed discussion on testing the safety of TLS/SSL channels you can refer to the chapter [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]]. Here, the tester will just try to understand if the data that users put into web forms, for example, in order to log into a web site, are transmitted using secure protocols that protect them from an attacker or not. To do this we will consider various examples.
 

== Description of the Issue ==
Nowadays, the most common example of this issue is the login page of a web application. The tester should verify that user's credentials are transmitted via an encrypted channel. In order to log into a web site, usually, the user has to fill a simple form that transmits the inserted data with the POST method. What is less obvious is that this data can be passed using the HTTP protocol, that means in a non-secure way, or using HTTPS, which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe that the transmission is insecure), but then it actually sends data via HTTPS. This test is done to be sure that an attacker cannot retrieve sensitive information by simply sniffing the net with a sniffer tool.
 

== Black Box testing and example ==
In the following examples we will use WebScarab in order to capture packet headers and to inspect them. You can use any web proxy that you prefer.

'''Case study: Sending data with POST method through HTTP''' 

Suppose that the login page presents a form with fields User, Pass, and the Submit button to authenticate and give access to the application. If we look at the header of our request with WebScarab, we get something like this: 
<pre>
POST http://www.example.com/AuthenticationServlet HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com/index.jsp
Cookie: JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S!
Content-Type: application/x-www-form-urlencoded
Content-length: 64

delegated_service=218&User=test&Pass=test&Submit=SUBMIT
</pre>

From this example the tester can understand that the POST sends the data to the page ''www.example.com/AuthenticationServlet'' simply using HTTP. So, in this case, data are transmitted without encryption and a malicious user could read our username and password by simply sniffing the net with a tool like Wireshark.

'''Case study: Sending data with POST method through HTTPS'''

Suppose that our web application uses the HTTPS protocol to encrypt data we are sending (or at least for those relating to the authentication). In this case, trying to access the login page and to authenticate, the header of our POST request would be similar to the following:

<pre>
POST https://www.example.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.example.com/cgi-bin/login.cgi
Cookie: language=English;
Content-Type: application/x-www-form-urlencoded
Content-length: 50

Command=Login&User=test&Pass=test
</pre>

We can see that the request is addressed to
''www.example.com:443/cgi-bin/login.cgi'' using the HTTPS protocol.
This ensures that our data are sent through an encrypted channel and that they are not readable by other people.

'''Case study: sending data with POST method via HTTPS on a page reachable via HTTP'''

Now, suppose to have a web page reachable via HTTP and that then only data sent from the authentication form are shipped via HTTPS. This means that our data is transmitted in a secure way through encryption. This situation occurs, for example, when we are on a portal of a big company that offers various information and services publicly available, without identification, but which has also a private section accessible from the home page through a login. So when we try to login, the header of our request will look like the following example:

<pre>
POST https://www.example.com:443/login.do HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com/homepage.do
Cookie: SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB6pLhjkW6F
Content-Type: application/x-www-form-urlencoded
Content-length: 45

User=test&Pass=test&portal=ExamplePortal
</pre>

We can see that our request is addressed to ''www.example.com:443/login.do'' using HTTPS. But if we have a look at the referer field in the header (the page from which we came), it is ''www.example.com/homepage.do'' and is accessible via simple HTTP. So, in this case, we have no lock inside our browser window that tells us that we are using a secure connection, but, in reality, we are sending data via HTTPS. This ensures us that no other people can read the data that we are sending.

'''Case study: Sending data with GET method through HTTPS'''

In this last example, suppose that the application transfers data using the GET method. This method should never be used in a form that transmits sensitive data such as username and password, because they are displayed in clear in the URL and this entails a whole set of security issues. So this example is purely demonstrative, but, in reality, it is strongly suggested to use the POST method instead. This is because when the GET method is used, the URL that it requests is easily available from, for example, the server logs exposing your sensitive data to information leakage.

<pre>
GET https://www.example.com/success.html?user=test&pass=test HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.example.com/form.html
If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT
If-None-Match: "43a01-5b-4868915f"
</pre>

You can see that the data is transferred in clear text in the URL and not in the body of the message as before. But we must consider that TLS/SSL is a level 5 protocol, a lower level than HTTP, so the whole HTTP package is still encrypted and the URL is unreadable to an attacker. It is not a good practice to use the GET method in these cases, because the information contained in the URL can be stored in many servers such as proxy and web servers, leaking the privacy of the user's credentials.

== Gray Box testing and example ==
Talk with the developers of the application and try to understand if they are aware of differences between HTTP and HTTPS protocols and why they should use the HTTPS for sensitive information transmissions. 
Then, check with them if HTTPS is used in every sensitive transmission, like those in login pages, to prevent unauthorized users to read the data.

== References ==
'''Whitepapers''' 
* HTTP/1.1: Security Considerations - http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html 
'''Tools''' 
* [[OWASP WebScarab Project|WebScarab]]

Testing for credentials transport (OWASP-AT-001)

2012-10-26T01:04:10Z

Robert WInkel: moved Testing for credentials transport (OWASP-AT-001) to Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001): Better title

#REDIRECT [[Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)]]

OWASP Testing Guide v4 Table of Contents

2012-10-26T01:02:07Z

Robert WInkel:

__NOTOC__

'''This is the DRAFT of the table of content of the New Testing Guide v4.''' 
 You can download the stable version v3[http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here] 

Back to the OWASP Testing Guide Project:
http://www.owasp.org/index.php/OWASP_Testing_Project

'''Updated: 22nd October 2012'''

[[ OWTGv4 Contributors list|'''Contributors List]]

----

The following is a DRAFT of the Toc based on the feedback already received.

== Table of Contents ==

==[[Testing Guide Foreword|Foreword by OWASP Chair]]==
[To review--> OWASP Chair]

==[[Testing Guide Frontispiece |1. Frontispiece]]==
[To review--> Mat]

'''[[Testing Guide Frontispiece|1.1 About the OWASP Testing Guide Project]]'''
[To review--> Mat]

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''
[To review--> ]

==[[Testing Guide Introduction|2. Introduction]]==

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

2.4 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation Security requirements test derivation],[https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_and_Non_Functional_Test_Requirements functional and non functional test requirements], and [https://www.owasp.org/index.php/Testing_Guide_Introduction#Test_Cases_Through_Use_and_Misuse_Cases test cases through use and misuse cases]

2.5 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Test_Data_Analysis_and_Reporting Security test data analysis and reporting: root cause identification and business/role case test data reporting]

==[[The OWASP Testing Framework|3. The OWASP Testing Framework]]==

'''3.1. Overview'''

'''3.2. Phase 1: Before Development Begins '''

'''3.3. Phase 2: During Definition and Design'''

'''3.4. Phase 3: During Development'''

'''3.5. Phase 4: During Deployment'''

'''3.6. Phase 5: Maintenance and Operations'''

'''3.7. A Typical SDLC Testing Workflow '''

==[[Web Application Penetration Testing |4. Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']] [To review--> Mat]

[[Testing Checklist| 4.1.1 Testing Checklist]] [To review at the end of brainstorming --> Mat]

[[Testing: Information Gathering|'''4.2 Information Gathering ''']] [To review--> contributor here]

[[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|4.2.1 Spiders, Robots and Crawlers (OWASP-IG-001)]]

[[Testing: Search engine discovery/reconnaissance (OWASP-IG-002)|4.2.2 Search Engine Discovery/Reconnaissance (OWASP-IG-002)]]

[[Testing: Identify application entry points (OWASP-IG-003)|4.2.3 Identify application entry points (OWASP-IG-003)]]

[[Testing for Web Application Fingerprint (OWASP-IG-004)|4.2.4 Testing for Web Application Fingerprint (OWASP-IG-004)]]

[[Testing for Application Discovery (OWASP-IG-005)|4.2.5 Application Discovery (OWASP-IG-005)]]

[[Testing for Error Code (OWASP-IG-006)|4.2.6 Analysis of Error Codes (OWASP-IG-006)]]

[[Testing for configuration management|'''4.3 Configuration and Deploy Management Testing ''']]

[[Testing for infrastructure configuration management (OWASP-CM-003)|4.3.1 Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)]]

[[Testing for application configuration management (OWASP-CM-004)|4.3.2 Testing for Application Configuration Management weakness (OWASP-CM-002)]]

[[Testing for file extensions handling (OWASP-CM-005)|4.3.3 Testing for File Extensions Handling (OWASP-CM-003)]]

[[Testing for Old, Backup and Unreferenced Files (OWASP-CM-006)|4.3.4 Old, Backup and Unreferenced Files (OWASP-CM-004) ]]

[[Testing for Admin Interfaces (OWASP-CM-007)|4.3.5 Infrastructure and Application Admin Interfaces (OWASP-CM-005)]]

[[Testing for HTTP Methods and XST (OWASP-CM-008)|4.3.6 Testing for Bad HTTP Methods (OWASP-CM-006)]][new - Abian Blome]

> Informative Error Messages [MAT NOTE: in info gathering] 

[[Testing for Database credentials/connection strings available|4.3.7 Testing for Database credentials/connection strings available (OWASP-CM-007)]]

[[Testing for Content Security Policy weakness|4.3.8 Testing for Content Security Policy weakness (OWASP-CM-008)]][New! - Simone Onofri]

[[Testing for Missing HSTS header|4.3.9 Testing for Missing HSTS header (OWASP-CM-009)]][New! Juan Manuel Bahamonde ]

[[Testing for RIA policy files weakness|4.3.10 Testing for RIA policy files weakness (OWASP-CM-010)]] [New!]

> Incorrect time[New! MAT NOTE: explain the test in detail please]

> Unpatched components and libraries (e.g. JavaScript libraries)[New! NOTE: tu discuss it]

> Test data in production systems (and vice versa)[New! MAT NOTE: this is not a particular test that could find a vulnerability] 

[[Testing for authentication|'''4.4 Authentication Testing ''']]

[[Testing for credentials transport (OWASP-AT-001)|4.4.1 Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)]] [Robert Winkel]

[[Testing for user enumeration (OWASP-AT-002)|4.4.2 Testing for User Enumeration and Guessable User Account (OWASP-AT-002)]] [Robert Winkel]

[[Testing for default credentials (OWASP-AT-003)|4.4.3 Testing for default credentials (OWASP-AT-003)]]

[[Testing for Weak lock out mechanism (OWASP-AT-004)|4.4.4 Testing for Weak lock out mechanism (OWASP-AT-004)]] [New! - Robert Winkel]

> Account lockout DoS [New! - Robert Winkel - we can put it in the 4.4.4]

[[Testing for Bypassing Authentication Schema (OWASP-AT-005)|4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)]]

[[Testing for Vulnerable Remember Password (OWASP-AT-006)|4.4.6 Testing for vulnerable remember
password functionality (OWASP-AT-006)]] [Robert Winkel]

[[Testing for Browser cache weakness (OWASP-AT-007)|4.4.7 Testing for Browser cache weakness (OWASP-AT-007)]] [New! - Abian Blome]

[[Testing for Weak password policy (OWASP-AT-008)|4.4.8 Testing for Weak password policy (OWASP-AT-008)]] [New! - Robert Winkel]

[[Testing for Weak or unenforced username policy (OWASP-AT-009)|4.4.9 Testing for Weak or unenforced username policy (OWASP-AT-009)]] [New! - Robert Winkel]

> Weak security question/answer [New! - Robert Winkel - MAT Note: same as AT-006] 

[[Testing for failure to restrict access to authenticated resource(OWASP-AT-010)|4.4.10 Testing for failure to restrict access to authenticated resource (OWASP-AT-010)]] [New!] 

[[Testing for weak password change or reset functionalities (OWASP-AT-011)|4.4.11 Testing for weak password change or reset functionalities (OWASP-AT-011)]] [New! - Robert Winkel] 

[[Testing for Captcha (OWASP-AT-012)|4.4.12 Testing for CAPTCHA (OWASP-AT-012)]]

> Weaker authentication in alternative channel (e.g. mobile app, IVR, help desk) [New!: MAT Note: to explain better the kind of test to perform please] 

[[Testing for Session Management|'''4.5 Session Management Testing''']]

[[Testing for Session_Management_Schema (OWASP-SM-001)|4.5.1 Testing for Bypassing Session Management Schema (OWASP-SM-001)]]

[[Testing for cookies attributes (OWASP-SM-002)|4.5.2 Testing for Cookies attributes (Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity) (OWASP-SM-002)]]

[[Testing for Session Fixation (OWASP-SM-003)|4.5.3 Testing for Session Fixation (OWASP-SM-003)]]

[[Testing for Exposed Session Variables (OWASP-SM-004)|4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)]]

[[Testing for CSRF (OWASP-SM-005)|4.5.5 Testing for Cross Site Request Forgery (CSRF) (OWASP-SM-005)]]

> Weak Session Token (MAT NOTE included in 4.5.1)

[[Testing for Session token not restricted properly (OWASP-SM-006)|4.5.6 Testing for Session token not restricted properly (such as domain or path not set properly) (OWASP-SM-006)]] [New! - Abian Blome] 

> Session passed over http (NOTE: included in SM-004) [New!] 

[[Testing for logout functionality (OWASP-SM-007)|4.5.7 Testing for logout functionality (OWASP-SM-007)]]

>Session token not removed on server after logout [New!: NOTE included in the above test] 

> Logout function not properly implemented (NOTE:same above) 

> Persistent session token [New! NOTE: this is not a vulnerability if session time out is correctly performed] 

[[Testing for Session puzzling (OWASP-SM-008)|4.5.8 Testing for Session puzzling (OWASP-SM-008)]] [New! - Abian Blome]

> Missing user-viewable log of authentication events [NOTE: needs more details: which test perform?]

[[Testing for Authorization|'''4.6 Authorization Testing''']]

[[Testing for Path Traversal (OWASP-AZ-001)|4.6.1 Testing Directory traversal/file include (OWASP-AZ-001) [Juan Galiana] ]]

[[Testing for Bypassing Authorization Schema (OWASP-AZ-002)|4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)]]

[[Testing for Privilege escalation (OWASP-AZ-003)|4.6.3 Testing for Privilege Escalation (OWASP-AZ-003) [Irene Abezgauz]]]

[[Testing for Insecure Direct Object References (OWASP-AZ-004)|4.6.4 Testing for Insecure Direct Object References (OWASP-AZ-004) [Irene Abezgauz] ]]

[[Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)|4.6.5 Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005) [New!] ]]

> Server component has excessive privileges (e.g. indexing service, reporting interface, file generator)[New!] 
> Lack of enforcement of application entry points (including exposure of objects)[New!] 

[[Testing for business logic (OWASP-BL-001)|'''4.7 Business Logic Testing (OWASP-BL-001)''']] [To review--> contributor here]
Business Logic 

Business logic data validation[New!] NOTE MAT: to discuss this section 
Ability to forge requests[New!] 
Lack of integrity checks (e.g. overwriting updates) [New!] 
Lack of tamper evidence[New!] 
Use of untrusted time source[New!] 
Lack of limits to excessive rate (speed) of use[New!] 
Lack of limits to size of request[New!] 
Lack of limit to number of times a function can be used[New!] 
Bypass of correct sequence[New!] 
Missing user-viewable log of actvity[New!] 
Self-hosted payment cardholder data processing[New!] 
Lack of security incident reporting information[New!] 
Defenses against application mis-use[New!] 

[[Testing for Data Validation|'''4.8 Data Validation Testing''']]

[[Testing for Reflected Cross site scripting (OWASP-DV-001) |4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001) ]]

[[Testing for Stored Cross site scripting (OWASP-DV-002) |4.8.2 Testing for Stored Cross Site Scripting (OWASP-DV-002) ]]

[[Testing for HTTP Verb Tampering (OWASP-DV-003)|4.8.3 Testing for HTTP Verb Tampering [Brad Causey] ]]

[[Testing for HTTP Parameter pollution (OWASP-DV-004)|4.8.4 Testing for HTTP Parameter pollution [Luca Carettoni, Stefano Di Paola, Brad Causey] ]]

[[Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)|4.8.5 Testing for Unvalidated Redirects and Forwards [Brad Causey] ]]

[[Testing for SQL Injection (OWASP-DV-005)| 4.8.5 Testing for SQL Injection (OWASP-DV-005) Ismael Gonçalves]]

[[Testing for Oracle|4.8.5.1 Oracle Testing]]

[[Testing for MySQL|4.8.5.2 MySQL Testing]]

[[Testing for SQL Server|4.8.5.3 SQL Server Testing]]

[[Testing for MS Access |4.8.5.4 MS Access Testing]]

[[Testing for NoSQL injection|4.8.5.5 Testing for NoSQL injection [New!]]]

[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.5.5 Testing PostgreSQL (from OWASP BSP) ]]

[[Testing for LDAP Injection (OWASP-DV-006)|4.8.6 Testing for LDAP Injection (OWASP-DV-006)]]

[[Testing for ORM Injection (OWASP-DV-007)|4.8.7 Testing for ORM Injection (OWASP-DV-007)]]

[[Testing for XML Injection (OWASP-DV-008)|4.8.8 Testing for XML Injection (OWASP-DV-008)]]

[[Testing for SSI Injection (OWASP-DV-009)|4.8.9 Testing for SSI Injection (OWASP-DV-009)]]

[[Testing for XPath Injection (OWASP-DV-010)|4.8.10 Testing for XPath Injection (OWASP-DV-010)]]

[[Testing for IMAP/SMTP Injection (OWASP-DV-011)|4.8.11 IMAP/SMTP Injection (OWASP-DV-011)]]

[[Testing for Code Injection (OWASP-DV-012)|4.8.12 Testing for Code Injection (OWASP-DV-012)]]

[[Testing for Command Injection (OWASP-DV-013)|4.8.13 Testing for Command Injection (OWASP-DV-013) [Juan Galiana]]]

[[Testing for Buffer Overflow (OWASP-DV-014)|4.8.14 Testing for Buffer overflow (OWASP-DV-014)]]

[[Testing for Heap Overflow|4.8.14.1 Testing for Heap overflow]]

[[Testing for Stack Overflow|4.8.14.2 Testing for Stack overflow]]

[[Testing for Format String|4.8.14.3 Testing for Format string]]

[[Testing for Incubated Vulnerability (OWASP-DV-015)|4.8.15 Testing for incubated vulnerabilities (OWASP-DV-015)]]

[[Testing for HTTP Splitting/Smuggling (OWASP-DV-016)|4.8.16 Testing for HTTP Splitting/Smuggling (OWASP-DV-016) [Juan Galiana] ]]

> Regular expression DoS[New!] note: to understand better 

[[Data Encryption (New!)]]

[[Testing for Insecure encryption usage (OWASP-EN-001)| 4.9.1 Testing for Insecure encryption usage (OWASP-EN-001]]

[[Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)| 4.9.2 Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)]]

[[Testing for Padding Oracle (OWASP-EN-003)| 4.9.3 Testing for Padding Oracle (OWASP-EN-003) [Giorgio Fedon]]]

> [[Testing for Cacheable HTTPS Response | x.x.3 Testing for Cacheable HTTPS Response 
Cache directives insecure 
> Testing for Insecure Cryptographic Storage [put in x.x.1] 
[[Testing for Sensitive information sent via unencrypted channels | x.x.4 

[[Web Service (XML Interpreter)|'''4.10 Web Service Testing''']] [Tom Eston]

[[Scoping a Web Service Test (OWASP-WS-001)|4.10.1 Scoping a Web Service Test (OWASP-WS-001)]]

[[WS Information Gathering (OWASP-WS-002)|4.10.2 WS Information Gathering (OWASP-WS-002)]]

[[WS Authentication Testing (OWASP-WS-003)|4.10.3 WS Authentication Testing (OWASP-WS-003)]]

[[WS Management Interface Testing (OWASP-WS-004)|4.10.4 WS Management Interface Testing (OWASP-WS-004)]]

[[Weak XML Structure Testing (OWASP-WS-005)|4.10.5 Weak XML Structure Testing (OWASP-WS-005)]]

[[XML Content-Level Testing (OWASP-WS-006)|4.10.6 XML Content-Level Testing (OWASP-WS-006)]]

[[WS HTTP GET Parameters/REST Testing (OWASP-WS-007)|4.10.7 WS HTTP GET Parameters/REST Testing (OWASP-WS-007)]]

[[WS Naughty SOAP Attachment Testing (OWASP-WS-008)|4.10.8 WS Naughty SOAP Attachment Testing (OWASP-WS-008)]]

[[WS Replay/MiTM Testing (OWASP-WS-009)|4.10.9 WS Replay/MiTM Testing (OWASP-WS-009)]]

[[WS BEPL Testing (OWASP-WS-010)|4.10.10 WS BEPL Testing (OWASP-WS-010)]]

[[Client Side Testing|'''4.11 Client Side Testing''']] [New!]

[[Testing for DOM-based Cross site scripting (OWASP-DV-003)|4.11.1 Testing for DOM based Cross Site Scripting (OWASP-CS-001) [Stefano Di Paola]]

[[Testing for HTML5 (OWASP CS-002)|4.11.2 Testing for HTML5 (OWASP CS-002) [Juan Galiana] ]] 

[[Testing for Cross site flashing (OWASP-DV-004)|4.11.3 Testing for Cross Site Flashing (OWASP-CS-003)]]

[[Testing for Testing for ClickHijacking (OWASP-CS-004)|4.11.4 Testing for Testing for ClickHijacking (OWASP-CS-004) ]] 

==[[Writing Reports: value the real risk |5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]] [To review--> contributor here]

[[How to write the report of the testing |5.2 How to write the report of the testing]] [To review--> contributor here]

==[[Appendix A: Testing Tools |Appendix A: Testing Tools ]]==

* Black Box Testing Tools [To review--> Amro. We need only tools fo webapp testing]

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers [To review--> David Fern]
* Books [To review--> David Fern]
* Useful Websites [To review--> David Fern]

==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]==

* Fuzz Categories [To review--> contributor here]

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==

[To review--> contributor here]

----

[[Category:OWASP Testing Project]]

OWASP Testing Guide v4 Table of Contents

2012-09-04T02:03:52Z

Robert WInkel:

__NOTOC__

'''This is DRAFT of the table of content of the New Testing Guide v4.''' 
 You can download the stable version [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here] 

Back to the OWASP Testing Guide Project:
http://www.owasp.org/index.php/OWASP_Testing_Project

'''Updated: 31st August 2012'''

[[ OWTGv4 Contributors list|'''Contributors List]]

----

The following are the main improvements we have to realize: 

(1) - Add new testing techniques and OWASP Top10 update: 
- Testing for HTTP Verb tampering 
- Testing for HTTP Parameter Pollutions 
- Testing for URL Redirection 
- Testing for Insecure Direct Object References 
- Testing for Insecure Cryptographic Storage 
- Testing for Failure to Restrict URL Access 
- Testing for Insufficient Transport Layer Protection 
- Testing for Unvalidated Redirects and Forwards. 
 
(2) - Review and improve all the sections in v3, 
 
(3) - Create a more readable guide, eliminating some sections that are not
really useful, Rationalize some sections as Session Management Testing.

(4) Pavol says: - add new opensource testing tools that appeared during last 3 years
(and are missing in the OWASP Testing Guide v3)

- add few useful and life-scenarios of possible
vulnerabilities in Bussiness Logic Testing (many testers have no idea what
vulnerabilities in Business Logic exactly mean)

- "Brute force testing" of "session ID" is missing in "Session Management
Testing", describe other tools for Session ID entropy analysis
(e.g. Stompy)

- in "Data Validation Testing" describe some basic obfuscation methods for
malicious code injection including the statements how it is possible to
detect it (web application obfuscation is quite succesfull in bypassing
many data validation controls)

- split the phase Logout and Browser Cache Management" into two sections
 
The following is a DRAFT of the Toc based on the feedback already received.

 
'''T A B L E o f C O N T E N T S (DRAFT)'''
----

==[[Testing Guide Foreword|Foreword by OWASP Chair]]== [To review--> OWASP Chair]

==[[Testing Guide Frontispiece |1. Frontispiece]]== [To review--> Mat]

'''[[Testing Guide Frontispiece|1.1 About the OWASP Testing Guide Project]]''' [To review--> Mat]

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]''' [To review--> ]

==[[Testing Guide Introduction|2. Introduction]]==

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

2.4 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation Security requirements test derivation],[https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_and_Non_Functional_Test_Requirements functional and non functional test requirements], and [https://www.owasp.org/index.php/Testing_Guide_Introduction#Test_Cases_Through_Use_and_Misuse_Cases test cases through use and misuse cases]

2.5 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Test_Data_Analysis_and_Reporting Security test data analysis and reporting: root cause identification and business/role case test data reporting]

==[[The OWASP Testing Framework|3. The OWASP Testing Framework]]==

'''3.1. Overview'''

'''3.2. Phase 1: Before Development Begins '''

'''3.3. Phase 2: During Definition and Design'''

'''3.4. Phase 3: During Development'''

'''3.5. Phase 4: During Deployment'''

'''3.6. Phase 5: Maintenance and Operations'''

'''3.7. A Typical SDLC Testing Workflow '''

==[[Web Application Penetration Testing |4. Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']] [To review--> Mat]

[[Testing Checklist| 4.1.1 Testing Checklist]] [To review at the end of brainstorming --> Mat]

[[Testing: Information Gathering|'''4.2 Information Gathering ''']] [To review--> contributor here]

[[Testing for configuration management|'''4.3 Configuration and Deploy Management Testing ''']]

Infrastructure Configuration management weakness 
Application Configuration management weakness 
File extensions handling 
Old, backup and unreferenced files 
Access to Admin interfaces 
Bad HTTP Methods enabled, [new] 
Informative Error Messages 
Database credentials/connection strings available 

[[Testing for authentication|'''4.4 Authentication Testing ''']]

Credentials transport over an unencrypted channel [Robert Winkel] 
User enumeration (also Guessable user account) [Robert Winkel] 
Default passwords [Robert Winkel] 
Weak lock out mechanism [New! - Robert Winkel] 
Account lockout DoS [New! - Robert Winkel] 
Bypassing authentication schema 
Directory traversal/file include 
Vulnerable remember password [Robert Winkel] 
Browser cache weakness [New!] 
Weak password policy [New! - Robert Winkel] 
Weak username policy [New! - Robert Winkel] 
Weak security question/answer [New! - Robert Winkel] 
Failure to restrict access to authenticated resource [New!] 
Weak password change function [New! - Robert Winkel] 
Testing for CAPTCHA 

[[Testing for Session Management|'''4.5 Session Management Testing''']]

Bypassing Session Management Schema 
Weak Session Token 
Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity 
Exposed sensitive session variables 
CSRF 
Session passed over http [New!] 
Session token within URL [New!] 
Session Fixation 
Session token not removed on server after logout [New!] 
Persistent session token [New!] 
Session token not restrcited properly (such as domain or path not set properly) [New!] 
Logout function not properly implemented 

[[Testing for Authorization|'''4.6 Authorization Testing''']]

Bypassing authorization schema 
Privilege Escalation 
Insecure Direct Object References 
Failure to Restrict access to authorized resource [New!] 

[[Testing for business logic (OWASP-BL-001)|'''4.7 Business Logic Testing (OWASP-BL-001)''']] [To review--> contributor here]
Business Logic 

[[Testing for Data Validation|'''4.8 Data Validation Testing''']]

Reflected XSS 
Stored XSS 
HTTP Verb Tampering [Brad Causey] 
HTTP Parameter pollution [Brad Causey] 
Unvalidated Redirects and Forwards [Brad Causey] 
SQL Injection [Brad Causey] 
LDAP Injection 
ORM Injection 
XML Injection 
SSI Injection 
XPath Injection 
SOAP Injection 
IMAP/SMTP Injection 
Code Injection 
OS Commanding 
Buffer overflow 
Incubated vulnerability 
HTTP Splitting/Smuggling 

[[Testing for Data Encryption (New!)]]

Application did not use encryption 
Weak SSL/TSL Ciphers, Insufficient 
Transport Layer Protection 
Cacheable HTTPS Response 
Cache directives insecure 
Insecure Cryptographic Storage [mainly CR Guide] 
Sensitive information sent via unencrypted
channels 

[[ XML Interpreter? (New!)]]

Weak XML Structure
XML content-level
WS HTTP GET parameters/REST
WS Naughty SOAP attachments
WS Replay Testing

[[ Client Side Testing (New!) ]]

DOM XSS 
Cross Site Flashing 
ClickHijacking 

==[[Writing Reports: value the real risk |5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]] [To review--> contributor here]

[[How to write the report of the testing |5.2 How to write the report of the testing]] [To review--> contributor here]

==[[Appendix A: Testing Tools |Appendix A: Testing Tools ]]==

* Black Box Testing Tools [To review--> Amro. We need only tools fo webapp testing]

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers [To review--> contributor here]
* Books [To review--> contributor here]
* Useful Websites [To review--> contributor here]

==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]==

* Fuzz Categories [To review--> contributor here]

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==

[To review--> contributor here]

----

[[Category:OWASP Testing Project]]

OWASP Testing Guide v4 Table of Contents

2012-09-04T01:51:18Z

Robert WInkel: Added Robert Winkel as contributor to several Authentication Testing test cases

__NOTOC__

'''This is DRAFT of the table of content of the New Testing Guide v4.''' 
 You can download the stable version [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here] 

Back to the OWASP Testing Guide Project:
http://www.owasp.org/index.php/OWASP_Testing_Project

'''Updated: 31st August 2012'''

[[ OWTGv4 Contributors list|'''Contributors List]]

----

The following are the main improvements we have to realize: 

(1) - Add new testing techniques and OWASP Top10 update: 
- Testing for HTTP Verb tampering 
- Testing for HTTP Parameter Pollutions 
- Testing for URL Redirection 
- Testing for Insecure Direct Object References 
- Testing for Insecure Cryptographic Storage 
- Testing for Failure to Restrict URL Access 
- Testing for Insufficient Transport Layer Protection 
- Testing for Unvalidated Redirects and Forwards. 
 
(2) - Review and improve all the sections in v3, 
 
(3) - Create a more readable guide, eliminating some sections that are not
really useful, Rationalize some sections as Session Management Testing.

(4) Pavol says: - add new opensource testing tools that appeared during last 3 years
(and are missing in the OWASP Testing Guide v3)

- add few useful and life-scenarios of possible
vulnerabilities in Bussiness Logic Testing (many testers have no idea what
vulnerabilities in Business Logic exactly mean)

- "Brute force testing" of "session ID" is missing in "Session Management
Testing", describe other tools for Session ID entropy analysis
(e.g. Stompy)

- in "Data Validation Testing" describe some basic obfuscation methods for
malicious code injection including the statements how it is possible to
detect it (web application obfuscation is quite succesfull in bypassing
many data validation controls)

- split the phase Logout and Browser Cache Management" into two sections
 
The following is a DRAFT of the Toc based on the feedback already received.

 
'''T A B L E o f C O N T E N T S (DRAFT)'''
----

==[[Testing Guide Foreword|Foreword by OWASP Chair]]== [To review--> OWASP Chair]

==[[Testing Guide Frontispiece |1. Frontispiece]]== [To review--> Mat]

'''[[Testing Guide Frontispiece|1.1 About the OWASP Testing Guide Project]]''' [To review--> Mat]

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]''' [To review--> ]

==[[Testing Guide Introduction|2. Introduction]]==

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

2.4 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation Security requirements test derivation],[https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_and_Non_Functional_Test_Requirements functional and non functional test requirements], and [https://www.owasp.org/index.php/Testing_Guide_Introduction#Test_Cases_Through_Use_and_Misuse_Cases test cases through use and misuse cases]

2.5 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Test_Data_Analysis_and_Reporting Security test data analysis and reporting: root cause identification and business/role case test data reporting]

==[[The OWASP Testing Framework|3. The OWASP Testing Framework]]==

'''3.1. Overview'''

'''3.2. Phase 1: Before Development Begins '''

'''3.3. Phase 2: During Definition and Design'''

'''3.4. Phase 3: During Development'''

'''3.5. Phase 4: During Deployment'''

'''3.6. Phase 5: Maintenance and Operations'''

'''3.7. A Typical SDLC Testing Workflow '''

==[[Web Application Penetration Testing |4. Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']] [To review--> Mat]

[[Testing Checklist| 4.1.1 Testing Checklist]] [To review at the end of brainstorming --> Mat]

[[Testing: Information Gathering|'''4.2 Information Gathering ''']] [To review--> contributor here]

[[Testing for configuration management|'''4.3 Configuration and Deploy Management Testing ''']]

Infrastructure Configuration management weakness 
Application Configuration management weakness 
File extensions handling 
Old, backup and unreferenced files 
Access to Admin interfaces 
Bad HTTP Methods enabled, [new] 
Informative Error Messages 
Database credentials/connection strings available 

[[Testing for authentication|'''4.4 Authentication Testing ''']]

Credentials transport over an unencrypted channel [Robert Winkel] 
User enumeration (also Guessable user account) [Robert Winkel] 
Default passwords [Robert Winkel] 
Weak lock out mechanism [New! - Robert Winkel] 
Account lockout DoS [New! - Robert Winkel] 
Bypassing authentication schema 
Directory traversal/file include 
Vulnerable remember password 
Browser cache weakness [New!] 
Weak password policy [New! - Robert Winkel] 
Weak username policy [New! - Robert Winkel] 
Weak security question/answer [New! - Robert Winkel] 
Failure to Restrict access to authenticated resource [New!] 
Weak password change function [New! - Robert Winkel] 
Testing for CAPTCHA 

[[Testing for Session Management|'''4.5 Session Management Testing''']]

Bypassing Session Management Schema 
Weak Session Token 
Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity 
Exposed sensitive session variables 
CSRF 
Session passed over http [New!] 
Session token within URL [New!] 
Session Fixation 
Session token not removed on server after logout [New!] 
Persistent session token [New!] 
Session token not restrcited properly (such as domain or path not set properly) [New!] 
Logout function not properly implemented 

[[Testing for Authorization|'''4.6 Authorization Testing''']]

Bypassing authorization schema 
Privilege Escalation 
Insecure Direct Object References 
Failure to Restrict access to authorized resource [New!] 

[[Testing for business logic (OWASP-BL-001)|'''4.7 Business Logic Testing (OWASP-BL-001)''']] [To review--> contributor here]
Business Logic 

[[Testing for Data Validation|'''4.8 Data Validation Testing''']]

Reflected XSS 
Stored XSS 
HTTP Verb Tampering [Brad Causey] 
HTTP Parameter pollution [Brad Causey] 
Unvalidated Redirects and Forwards [Brad Causey] 
SQL Injection [Brad Causey] 
LDAP Injection 
ORM Injection 
XML Injection 
SSI Injection 
XPath Injection 
SOAP Injection 
IMAP/SMTP Injection 
Code Injection 
OS Commanding 
Buffer overflow 
Incubated vulnerability 
HTTP Splitting/Smuggling 

[[Testing for Data Encryption (New!)]]

Application did not use encryption 
Weak SSL/TSL Ciphers, Insufficient 
Transport Layer Protection 
Cacheable HTTPS Response 
Cache directives insecure 
Insecure Cryptographic Storage [mainly CR Guide] 
Sensitive information sent via unencrypted
channels 

[[ XML Interpreter? (New!)]]

Weak XML Structure
XML content-level
WS HTTP GET parameters/REST
WS Naughty SOAP attachments
WS Replay Testing

[[ Client Side Testing (New!) ]]

DOM XSS 
Cross Site Flashing 
ClickHijacking 

==[[Writing Reports: value the real risk |5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]] [To review--> contributor here]

[[How to write the report of the testing |5.2 How to write the report of the testing]] [To review--> contributor here]

==[[Appendix A: Testing Tools |Appendix A: Testing Tools ]]==

* Black Box Testing Tools [To review--> Amro. We need only tools fo webapp testing]

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers [To review--> contributor here]
* Books [To review--> contributor here]
* Useful Websites [To review--> contributor here]

==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]==

* Fuzz Categories [To review--> contributor here]

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==

[To review--> contributor here]

----

[[Category:OWASP Testing Project]]