Testing for Default or Guessable User Account (OWASP-AT-003)

2008-06-10T22:42:51Z

Khorvath: /* References */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
Today's web application typically runs on popular software, open source or commercial, that is installed on servers and requires configuration or customization by the server administrator. In addition, most of today's hardware appliances, i.e. network routers, database servers, etc., offer web-based configurations or administrative interfaces. 
Often, these applications are not properly configured and the default credentials provided for authentication are never updated. In addition, it is typical to find generic accounts such as for testing or administration that use common usernames and passwords are left enabled on the application. 
These default username/password combinations are widely known by penetration testers and malicious hackers that can use them to gain access to various types of custom or commercial applications. 

== Description of the Issue ==
The sources for this problem are often inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components, programmers, who leave backdoors to easily access and test the application and later forgetting to remove them, application administrators and users that choose an easy username and password for themselves, and applications with built in, non-removable default accounts with a pre-set username and password. Another problem is blank passwords, which are simply a result of security unawareness and a desire to simplify administration.

== Black Box testing and example ==
In blackbox testing we know nothing about the application, its underlying infrastructure, and any username or password policies. Often this is not the case and some information about the application is provided – simply skip the steps that refer to obtaining information you already have.

When testing a known application interface, such as a Cisco router web interface, or Weblogic admin access, check the known usernames and passwords for these devices. This can be done either by Google, or using one of the references in the Further Reading section.

When facing a home-grown application, to which we do not have a list of default and common user accounts, we need to test it manually, following these guidelines:
* 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", "guest" 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 managed 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.
* Application administrative users are often named after the application. 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.
* 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.
* Attempt using all the above usernames with blank passwords.
* Try to extrapolate from the application how usernames are created. such as can a user create his own account or does the system create an account for you based on some personal information or predictable sequence. If the application does create is own account in a predictable sequence, such as user7811, try fuzzing all possible accounts recursively. If you can identify a different response from the application with a valid username and bad 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).
*If the application creates its own passwords for new users, whether or not the username is created by the application or by the user, then try to determine if the password is predictable. Try to create as 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.

'''Result Expected:''' 
Authorized access to system or application being tested. 

== Gray Box testing and example ==
The steps described next rely on an entirely Gray Box approach. If only some of the information is available to you, refer to black box testing to fill the gaps.

Talk to the IT personnel to determine which passwords they use for administrative access.

Check whether these usernames and passwords are complex, difficult to guess, and not related to the application name, person name, or administrative names ("system").
Note blank passwords.
Check in the user database for default names, application names, and easily guessed names as described in the Black Box testing section. Check for empty password fields.

Examine the code for hard coded usernames and passwords.

Check for configuration files that contain usernames and passwords. 

'''Result Expected:''' 
Authorized access to 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/ 

{{Category:OWASP Testing Project AoC}}

Testing for Default or Guessable User Account (OWASP-AT-003)

2008-06-10T22:40:36Z

Khorvath: /* References */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
Today's web application typically runs on popular software, open source or commercial, that is installed on servers and requires configuration or customization by the server administrator. In addition, most of today's hardware appliances, i.e. network routers, database servers, etc., offer web-based configurations or administrative interfaces. 
Often, these applications are not properly configured and the default credentials provided for authentication are never updated. In addition, it is typical to find generic accounts such as for testing or administration that use common usernames and passwords are left enabled on the application. 
These default username/password combinations are widely known by penetration testers and malicious hackers that can use them to gain access to various types of custom or commercial applications. 

== Description of the Issue ==
The sources for this problem are often inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components, programmers, who leave backdoors to easily access and test the application and later forgetting to remove them, application administrators and users that choose an easy username and password for themselves, and applications with built in, non-removable default accounts with a pre-set username and password. Another problem is blank passwords, which are simply a result of security unawareness and a desire to simplify administration.

== Black Box testing and example ==
In blackbox testing we know nothing about the application, its underlying infrastructure, and any username or password policies. Often this is not the case and some information about the application is provided – simply skip the steps that refer to obtaining information you already have.

When testing a known application interface, such as a Cisco router web interface, or Weblogic admin access, check the known usernames and passwords for these devices. This can be done either by Google, or using one of the references in the Further Reading section.

When facing a home-grown application, to which we do not have a list of default and common user accounts, we need to test it manually, following these guidelines:
* 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", "guest" 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 managed 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.
* Application administrative users are often named after the application. 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.
* 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.
* Attempt using all the above usernames with blank passwords.
* Try to extrapolate from the application how usernames are created. such as can a user create his own account or does the system create an account for you based on some personal information or predictable sequence. If the application does create is own account in a predictable sequence, such as user7811, try fuzzing all possible accounts recursively. If you can identify a different response from the application with a valid username and bad 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).
*If the application creates its own passwords for new users, whether or not the username is created by the application or by the user, then try to determine if the password is predictable. Try to create as 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.

'''Result Expected:''' 
Authorized access to system or application being tested. 

== Gray Box testing and example ==
The steps described next rely on an entirely Gray Box approach. If only some of the information is available to you, refer to black box testing to fill the gaps.

Talk to the IT personnel to determine which passwords they use for administrative access.

Check whether these usernames and passwords are complex, difficult to guess, and not related to the application name, person name, or administrative names ("system").
Note blank passwords.
Check in the user database for default names, application names, and easily guessed names as described in the Black Box testing section. Check for empty password fields.

Examine the code for hard coded usernames and passwords.

Check for configuration files that contain usernames and passwords. 

'''Result Expected:''' 
Authorized access to system being tested 

== References ==
'''Whitepapers''' 
* CIRT http://www.cirt.net/cgi-bin/passwd.pl
* Government Security - Default Logins and Passwords for Networked Devices http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
* Virus.org http://www.virus.org/default-password/ 

{{Category:OWASP Testing Project AoC}}

Testing for Default or Guessable User Account (OWASP-AT-003)

2008-06-10T22:34:40Z

Khorvath: /* Gray Box testing and example */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
Today's web application typically runs on popular software, open source or commercial, that is installed on servers and requires configuration or customization by the server administrator. In addition, most of today's hardware appliances, i.e. network routers, database servers, etc., offer web-based configurations or administrative interfaces. 
Often, these applications are not properly configured and the default credentials provided for authentication are never updated. In addition, it is typical to find generic accounts such as for testing or administration that use common usernames and passwords are left enabled on the application. 
These default username/password combinations are widely known by penetration testers and malicious hackers that can use them to gain access to various types of custom or commercial applications. 

== Description of the Issue ==
The sources for this problem are often inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components, programmers, who leave backdoors to easily access and test the application and later forgetting to remove them, application administrators and users that choose an easy username and password for themselves, and applications with built in, non-removable default accounts with a pre-set username and password. Another problem is blank passwords, which are simply a result of security unawareness and a desire to simplify administration.

== Black Box testing and example ==
In blackbox testing we know nothing about the application, its underlying infrastructure, and any username or password policies. Often this is not the case and some information about the application is provided – simply skip the steps that refer to obtaining information you already have.

When testing a known application interface, such as a Cisco router web interface, or Weblogic admin access, check the known usernames and passwords for these devices. This can be done either by Google, or using one of the references in the Further Reading section.

When facing a home-grown application, to which we do not have a list of default and common user accounts, we need to test it manually, following these guidelines:
* 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", "guest" 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 managed 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.
* Application administrative users are often named after the application. 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.
* 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.
* Attempt using all the above usernames with blank passwords.
* Try to extrapolate from the application how usernames are created. such as can a user create his own account or does the system create an account for you based on some personal information or predictable sequence. If the application does create is own account in a predictable sequence, such as user7811, try fuzzing all possible accounts recursively. If you can identify a different response from the application with a valid username and bad 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).
*If the application creates its own passwords for new users, whether or not the username is created by the application or by the user, then try to determine if the password is predictable. Try to create as 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.

'''Result Expected:''' 
Authorized access to system or application being tested. 

== Gray Box testing and example ==
The steps described next rely on an entirely Gray Box approach. If only some of the information is available to you, refer to black box testing to fill the gaps.

Talk to the IT personnel to determine which passwords they use for administrative access.

Check whether these usernames and passwords are complex, difficult to guess, and not related to the application name, person name, or administrative names ("system").
Note blank passwords.
Check in the user database for default names, application names, and easily guessed names as described in the Black Box testing section. Check for empty password fields.

Examine the code for hard coded usernames and passwords.

Check for configuration files that contain usernames and passwords. 

'''Result Expected:''' 
Authorized access to system being tested 

== References ==
'''Whitepapers''' 
* CIRT http://www.cirt.net/cgi-bin/passwd.pl
* DarkLab http://phenoelit.darklab.org/cgi-bin/display.pl?SUBF=list&SORT=1
* Government Security - Default Logins and Passwords for Networked Devices http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
* Virus.org http://www.virus.org/default-password/ 

{{Category:OWASP Testing Project AoC}}

Testing for Default or Guessable User Account (OWASP-AT-003)

2008-06-10T22:32:28Z

Khorvath: /* Black Box testing and example */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
Today's web application typically runs on popular software, open source or commercial, that is installed on servers and requires configuration or customization by the server administrator. In addition, most of today's hardware appliances, i.e. network routers, database servers, etc., offer web-based configurations or administrative interfaces. 
Often, these applications are not properly configured and the default credentials provided for authentication are never updated. In addition, it is typical to find generic accounts such as for testing or administration that use common usernames and passwords are left enabled on the application. 
These default username/password combinations are widely known by penetration testers and malicious hackers that can use them to gain access to various types of custom or commercial applications. 

== Description of the Issue ==
The sources for this problem are often inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components, programmers, who leave backdoors to easily access and test the application and later forgetting to remove them, application administrators and users that choose an easy username and password for themselves, and applications with built in, non-removable default accounts with a pre-set username and password. Another problem is blank passwords, which are simply a result of security unawareness and a desire to simplify administration.

== Black Box testing and example ==
In blackbox testing we know nothing about the application, its underlying infrastructure, and any username or password policies. Often this is not the case and some information about the application is provided – simply skip the steps that refer to obtaining information you already have.

When testing a known application interface, such as a Cisco router web interface, or Weblogic admin access, check the known usernames and passwords for these devices. This can be done either by Google, or using one of the references in the Further Reading section.

When facing a home-grown application, to which we do not have a list of default and common user accounts, we need to test it manually, following these guidelines:
* 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", "guest" 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 managed 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.
* Application administrative users are often named after the application. 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.
* 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.
* Attempt using all the above usernames with blank passwords.
* Try to extrapolate from the application how usernames are created. such as can a user create his own account or does the system create an account for you based on some personal information or predictable sequence. If the application does create is own account in a predictable sequence, such as user7811, try fuzzing all possible accounts recursively. If you can identify a different response from the application with a valid username and bad 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).
*If the application creates its own passwords for new users, whether or not the username is created by the application or by the user, then try to determine if the password is predictable. Try to create as 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.

'''Result Expected:''' 
Authorized access to system or application being tested. 

== Gray Box testing and example ==
The steps described next rely on an entirely Gray Box approach. If only some of the information is available to you, refer to black box testing to fill the gaps.

Talk to the IT personnel to determine which passwords they use for administrative access.

Check whether these usernames and passwords are complex, difficult to guess, and not related to the application name, person name, or administrative names ("system").
Note blank passwords.
Check in the user database for default names, application names, and easily guessed names as described in the Black Box testing section. Check for empty password fields.

Examine the code for hard coded usernames and passwords.

Check for configuration files that contain usernames and passwords. 
'''Result Expected:''' 
Authorized access to system being tested 

== References ==
'''Whitepapers''' 
* CIRT http://www.cirt.net/cgi-bin/passwd.pl
* DarkLab http://phenoelit.darklab.org/cgi-bin/display.pl?SUBF=list&SORT=1
* Government Security - Default Logins and Passwords for Networked Devices http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
* Virus.org http://www.virus.org/default-password/ 

{{Category:OWASP Testing Project AoC}}

Testing for Default or Guessable User Account (OWASP-AT-003)

2008-06-10T21:56:38Z

Khorvath: /* Brief Summary */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
Today's web application typically runs on popular software, open source or commercial, that is installed on servers and requires configuration or customization by the server administrator. In addition, most of today's hardware appliances, i.e. network routers, database servers, etc., offer web-based configurations or administrative interfaces. 
Often, these applications are not properly configured and the default credentials provided for authentication are never updated. In addition, it is typical to find generic accounts such as for testing or administration that use common usernames and passwords are left enabled on the application. 
These default username/password combinations are widely known by penetration testers and malicious hackers that can use them to gain access to various types of custom or commercial applications. 

== Description of the Issue ==
The sources for this problem are often inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components, programmers, who leave backdoors to easily access and test the application and later forgetting to remove them, application administrators and users that choose an easy username and password for themselves, and applications with built in, non-removable default accounts with a pre-set username and password. Another problem is blank passwords, which are simply a result of security unawareness and a desire to simplify administration.

== Black Box testing and example ==
In blackbox testing we know nothing about the application, its underlying infrastructure, and any username and/or password policies. Often this is not the case and some information about the application is provided – simply skip the steps that refer to obtaining information you already have.

When testing a known application interface, such as a Cisco router web interface, or Weblogic admin access, check the known usernames and passwords for these devices. This can be done either by Google, or using one of the references in the Further Reading section.

When facing a home-grown application, to which we do not have a list of default and common user accounts, we need to test it manually, following these guidelines:
* Try the following usernames - "admin", "administrator", "root", "system", 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 managed to identify any of the above usernames, attempt passwords in a similar manner.
* Application administrative users are often named after the application. This means if you are testing an application named "Obscurity", try using obscurity/obscurity as the username and password.
* When performing a test for a customer, attempt using names of contacts you have received as usernames.
* 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.
* Attempt using all the above usernames with blank passwords.

'''Result Expected:''' 
Authorized access to system being tested. 

== Gray Box testing and example ==
The steps described next rely on an entirely Gray Box approach. If only some of the information is available to you, refer to black box testing to fill the gaps.

Talk to the IT personnel to determine which passwords they use for administrative access.

Check whether these usernames and passwords are complex, difficult to guess, and not related to the application name, person name, or administrative names ("system").
Note blank passwords.
Check in the user database for default names, application names, and easily guessed names as described in the Black Box testing section. Check for empty password fields.

Examine the code for hard coded usernames and passwords.

Check for configuration files that contain usernames and passwords. 
'''Result Expected:''' 
Authorized access to system being tested 

== References ==
'''Whitepapers''' 
* CIRT http://www.cirt.net/cgi-bin/passwd.pl
* DarkLab http://phenoelit.darklab.org/cgi-bin/display.pl?SUBF=list&SORT=1
* Government Security - Default Logins and Passwords for Networked Devices http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
* Virus.org http://www.virus.org/default-password/ 

{{Category:OWASP Testing Project AoC}}

Testing for Default or Guessable User Account (OWASP-AT-003)

2008-06-10T21:54:49Z

Khorvath: /* Brief Summary */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
Today's web application typically runs on popular software, open source or commercial, that is installed on servers and requires configuration or customization by the server administrator. In addition, most of today's hardware appliances, i.e. network routers, database servers, etc., offer web-based configurations or administrative interfaces. 
Often, these applications are not properly configured and the default credentials provided for authentication are never updated. In addition, it is typical to find generic accounts such as for testing or administration that use common usernames and passwords are left enabled on the application. 
These default username/password combinations are widely known by penetration testers and malicious hackers that can use them to gain access to various types of custom or commercial applications. 
 

== Description of the Issue ==
The sources for this problem are often inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components, programmers, who leave backdoors to easily access and test the application and later forgetting to remove them, application administrators and users that choose an easy username and password for themselves, and applications with built in, non-removable default accounts with a pre-set username and password. Another problem is blank passwords, which are simply a result of security unawareness and a desire to simplify administration.

== Black Box testing and example ==
In blackbox testing we know nothing about the application, its underlying infrastructure, and any username and/or password policies. Often this is not the case and some information about the application is provided – simply skip the steps that refer to obtaining information you already have.

When testing a known application interface, such as a Cisco router web interface, or Weblogic admin access, check the known usernames and passwords for these devices. This can be done either by Google, or using one of the references in the Further Reading section.

When facing a home-grown application, to which we do not have a list of default and common user accounts, we need to test it manually, following these guidelines:
* Try the following usernames - "admin", "administrator", "root", "system", 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 managed to identify any of the above usernames, attempt passwords in a similar manner.
* Application administrative users are often named after the application. This means if you are testing an application named "Obscurity", try using obscurity/obscurity as the username and password.
* When performing a test for a customer, attempt using names of contacts you have received as usernames.
* 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.
* Attempt using all the above usernames with blank passwords.

'''Result Expected:''' 
Authorized access to system being tested. 

== Gray Box testing and example ==
The steps described next rely on an entirely Gray Box approach. If only some of the information is available to you, refer to black box testing to fill the gaps.

Talk to the IT personnel to determine which passwords they use for administrative access.

Check whether these usernames and passwords are complex, difficult to guess, and not related to the application name, person name, or administrative names ("system").
Note blank passwords.
Check in the user database for default names, application names, and easily guessed names as described in the Black Box testing section. Check for empty password fields.

Examine the code for hard coded usernames and passwords.

Check for configuration files that contain usernames and passwords. 
'''Result Expected:''' 
Authorized access to system being tested 

== References ==
'''Whitepapers''' 
* CIRT http://www.cirt.net/cgi-bin/passwd.pl
* DarkLab http://phenoelit.darklab.org/cgi-bin/display.pl?SUBF=list&SORT=1
* Government Security - Default Logins and Passwords for Networked Devices http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
* Virus.org http://www.virus.org/default-password/ 

{{Category:OWASP Testing Project AoC}}

Testing for cookies attributes (OTG-SESS-002)

2008-06-10T20:54:42Z

Khorvath: /* Description of the Issue */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
Cookies are often a key attack vector for malicious users (typically targeting other users) and as such the application should always take due diligence to protect these cookies. In this section we will look at how an application can take the necessary precautions when assigning cookies and how to test that these attributes have been correctly configured.
 

== Description of the Issue ==
 
The importance and secure use of Cookies cannot be understated, especially within dynamic web applications which need to maintain state across a stateless protocol such as HTTP. To understand the importance of cookies it is imperative to understand what they are primarily used for. These primary functions usually consist of being used as a session authorization/authentication token and/or as a temporary data container. Thus if an attacker by some means was able to acquire a session token such as by cross site scripting (XSS) or sniffing an unencrypted session then they could use this cookie to hijack a valid current session. Additionally cookies are set to maintain state across multiple requests. Since HTTP is stateless the server can not determine if a request it receives is part of a current session or the start of a new session without some type of identifier. This identifier is very commonly a cookie although not always. As you can imagine there are many different types of applications that need to keep track of session state across multiple request. The primary one that comes to mind would be an online store. As a user adds multiple items to a shopping cart this data needs to be retained in subsequent requests to the application. Cookies are very commonly used for this task and are set by the application using the Set-Cookie directive in the applications HTTP response, and is usually in a name=value format (if cookies are enabled and if they are supported, which is the case for all modern web browsers). Once an application has told the browser to use a particular cookie the browser will send this cookie in each subsequent request. A cookie can contain data such as items from an online shopping cart, the price of these items, the quantity of these items, personal information, user IDs, etc. Due to the sensitive nature of information in cookies they are typically encoded or encrypted in an attempt to protect this information. Many times multiple cookies will be set (separated by a semicolon) upon subsequent request especially in the case of an online store as you add multiple items to your shopping cart. Additionally you will typically have a cookie for authentication (session token as indicated above) once you login and multiple others cookies used to identify the items you wish to purchase and their auxiliary information (ie price, quantity, etc) in the online store type of application.

Now that you have an understanding of how cookies are set, when they are set, what they are used for, why they are used, and their importance; lets take a look at what attributes can be set for a cookie and how to test if they are secure. The following is a list of the attributes that can be set for each cookie and what they mean. The next section will focus on how to test for each attribute.

*secure - This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests.
If the application can be accessed over HTTP and HTTPS then their is the potential that the cookie can be sent in cleartext.

*HttpOnly - This attribute is used to help prevent attacks such as cross-site scripting since it does not allow the cookie to be accessed via a client side script such as JavaScript. Note that not all browsers support this functionality.

*domain - This attribute is used to compare against the domain of the server in which the URL is being requested. If the domain matches or if its a sub-domain then the path attribute will be checked next.
Note that only hosts within the specified domain can set a cookie for that domain. Also the domain attribute can not be a top level domain (such as .gov or .com) to prevent against servers being able to set arbitrary cookies for another domain. If domain attribute is not set then the default value of domain is set to the hostname of the server which generated the cookie.
For example if a cookie is set by an application at app.mydomain.com with no domain attribute set, then the cookie would be resubmitted for all subsequent requests for app.mydomain.com and its subdomains (such as hacker.app.mydomain.com), but not to otherapp.mydomain.com. If a developer wanted to loosen this restriction then he could set the domain attribute to mydomain.com. In this case the cookie would be sent to all requests for app.mydomain.com, its subdomains such as hacker.app.mydomain.com and even bank.mydomain.com.
If there was a vulnerable server on a subdomain such as (otherapp.mydomain.com) and the domain attribute has been set to loosely (for example mydomain.com), then the vulnerable server could be used to harvest cookies (such as session tokens).

*path - In addition to the domain, the URL path can be specified for which the cookie is valid. If the domain and path match then the cookie will be sent in the request.
Just as with the domain attribute if the path attribute is set to loosely then it could leave the application vulnerable to attack by other applications on the same server. For example if the path attribute was set to the web server root "/" then the applications cookies will be sent to every application within the same domain.

*expires - This attribute is used to set persistent cookies, since the cookie does not expire until the set date is exceeded. This persistent cookie will be used by this browser session and subsequent sessions until the cookie expires. Once the expiration date has exceeded the browser will delete the cookie. Alternatively if this attribute is not set then the cookie is only valid in the current browser session and the cookie will be deleted when the session ends.

 

== Black Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 

Using an intercepting proxy or browser plugin trap all responses where a cookie is set by the application (using the Set-cookie directive) and inspect the cookie for the following:

*Secure Attribute - Whenever a cookie contains sensitive information or is a session token then it should always be passed using an encrypted tunnel. For example after logging into an application and a session token is set using a cookie, then verify it is tagged using the ";secure" flag. If it is not then it the browser believes it safe to pass via an unencrypted channel such as using HTTP.

*HttpOnly Attribute - This attribute should always be set even though not every browser supports it. This attribute aides in securing the cookie from being accessed by a client side script so check to see if the ";HttpOnly" tag has been set.

*Domain Attribute - Verify that the domain has not been set to loosely. As noted above it should only be set for the server that needs to receive the cookie. For example if the application resides on server app.mysite.com then it should be set to "; domain=app.mysite.com" and NOT "; domain=.mysite.com" as this would allow other potentially vulnerable servers to receive the cookie.

*Path Attribute - Verify that the path attribute, just as the Domain attribute, has not been set to loosely. Even if the Domain attribute has been configured as tight as possible, if the path is set to the root directory "/" then it can be vulnerable to less secure applications on the same server. For example if the application resides at /myapp/ then verify that the cookies path is set to "; path=/myapp/" and NOT "; path=/" or "; path=/myapp". Notice here that the trailing "/" must be used after myapp. If it is not used the browser will send the cookie to any path the matches "myapp" such as "myapp-exploited"

*expires Attribute - Verify that if this attribute is set to a time in the future that it does not contain any sensitive information. For example if a cookie is set to "; expires=Fri, 13-Jun-2010 13:45:29 GMT" and it is currently June 10th 2008 then you want to inspect the cookie. If the cookie is a session token that is stored on the users hard drive then an attacker or local user (such as an admin) who has access to this cookie can access the application by resubmitting this token until the expiration date passes.

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

*RFC 2965 - HTTP State Management Mechanism

'''Tools''' 

*Intercepting Proxy
*Browser Plug-in

Testing for cookies attributes (OTG-SESS-002)

2008-06-10T20:51:59Z

Khorvath: /* References */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
Cookies are often a key attack vector for malicious users (typically targeting other users) and as such the application should always take due diligence to protect these cookies. In this section we will look at how an application can take the necessary precautions when assigning cookies and how to test that these attributes have been correctly configured.
 

== Description of the Issue ==
 
The importance and secure use of Cookies cannot be understated, especially within dynamic web applications which need to maintain state across a stateless protocol such as HTTP. To understand the importance of cookies it is imperative to understand what they are primarily used for. These primary functions usually consist of being used as a session authorization/authentication token and/or as a temporary data container. Thus if an attacker by some means was able to acquire a session token such as by cross site scripting (XSS) or sniffing an unencrypted session then they could use this cookie to hijack a valid current session. Additionally cookies are set to maintain state across multiple requests. Since HTTP is stateless the server can not determine if a request it receives is part of a current session or the start of a new session without some type of identifier. This identifier is very commonly a cookie although not always. As you can imagine there are many different types of applications that need to keep track of session state across multiple request. The primary one that comes to mind would be an online store. As a user adds multiple items to a shopping cart this data needs to be retained in subsequent requests to the application. Cookies are very commonly used for this task and are set by the application using the Set-Cookie directive in the applications HTTP response, and is usually in a name=value format (if cookies are enabled and if they are supported, which is the case for all modern web browsers). Once an application has told the browser to use a particular cookie the browser will send this cookie in each subsequent request. A cookie can contain data such as items from an online shopping cart, the price of these items, the quantity of these items, personal information, user IDs, etc. Due to the sensitive nature of information in cookies they are typically encoded or encrypted in an attempt to protect this information. Many times multiple cookies will be set (separated by a semicolon) upon subsequent request especially in the case of an online store as you add multiple items to your shopping cart. Additionally you will typically have a cookie for authentication (session token as indicated above) once you login and multiple others cookies used to identify the items you wish to purchase and their auxiliary information (ie price, quantity, etc) in the online store type of application.

Now that you have an understanding of how cookies are set, when they are set, what they are used for, why they are used, and their importance; lets take a look at what attributes can be set for a cookie and how to test if they are secure. The following is a list of the attributes that can be set for each cookie and what they mean. The next section will focus on how to test for each attribute.

*secure - This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests.
If the application can be accessed over HTTP and HTTPS then their is the potential that the cookie can be sent in cleartext.

*HttpOnly - This attribute is used to help prevent attacks such as cross-site scripting since it does not allow the cookie to be accessed via a client side script such as JavaScript. Note that not all browsers support this functionality.

*domain - This attribute is used to compare against the domain of the server in which the URL is being requested. If the domain matches or if its a sub-domain then the path attribute will be checked next.
Note that only hosts within the specified domain can set a cookie for that domain. Also the domain attribute can not be a top level domain (such as .gov or .com) to prevent against servers being able to set arbitrary cookies for another domain. If domain attribute is not set then the default value of domain is set to the hostname of the server which generated the cookie.
For example if a cookie is set by an application at app.mydomain.com with no domain attribute set, then the cookie would be resubmitted for all subsequent requests for app.mydomain.com and its subdomains (such as hacker.app.mydomain.com), but not to otherapp.mydomain.com. If a developer wanted to loosen this restriction then he could set the domain attribute to mydomain.com. In this case the cookie would be sent to all requests for app.mydomain.com, its subdomains such as hacker.app.mydomain.com and even bank.mydomain.com.
If there was a vulnerable server on a subdomain such as (otherapp.mydomain.com) and the domain attribute has been set to loosely (for example mydomain.com), then the vulnerable server could be used to harvest cookies (such as session tokens).

*path - In addition to the domain, the URL path can be specified for which the cookie is valid. If the domain and path match then the cookie will be sent in the request.
Just as with the domain attribute if the path attribute is set to loosely then it could leave the application vulnerable to attack by other applications on the same server. For example if the path attribute was set to the web server root "/" then the applications cookies will be sent to every application within the same domain.

*expires - This attribute is used to set persistent cookies, since the cookie does not expire until the set date is exceeded. This persistent cookie will be used by this browser session and subsequent sessions until the cookie expires. Once the expiration date has exceeded the browser will delete the cookie. Alternatively if this attribute is not set then the cookie is only valid in the current browser session and the cookie will be deleted when the session ends.

 

== Black Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 

Using an intercepting proxy or browser plugin trap all responses where a cookie is set by the application (using the Set-cookie directive) and inspect the cookie for the following:

*Secure Attribute - Whenever a cookie contains sensitive information or is a session token then it should always be passed using an encrypted tunnel. For example after logging into an application and a session token is set using a cookie, then verify it is tagged using the ";secure" flag. If it is not then it the browser believes it safe to pass via an unencrypted channel such as using HTTP.

*HttpOnly Attribute - This attribute should always be set even though not every browser supports it. This attribute aides in securing the cookie from being accessed by a client side script so check to see if the ";HttpOnly" tag has been set.

*Domain Attribute - Verify that the domain has not been set to loosely. As noted above it should only be set for the server that needs to receive the cookie. For example if the application resides on server app.mysite.com then it should be set to "; domain=app.mysite.com" and NOT "; domain=.mysite.com" as this would allow other potentially vulnerable servers to receive the cookie.

*Path Attribute - Verify that the path attribute, just as the Domain attribute, has not been set to loosely. Even if the Domain attribute has been configured as tight as possible, if the path is set to the root directory "/" then it can be vulnerable to less secure applications on the same server. For example if the application resides at /myapp/ then verify that the cookies path is set to "; path=/myapp/" and NOT "; path=/" or "; path=/myapp". Notice here that the trailing "/" must be used after myapp. If it is not used the browser will send the cookie to any path the matches "myapp" such as "myapp-exploited"

*expires Attribute - Verify that if this attribute is set to a time in the future that it does not contain any sensitive information. For example if a cookie is set to "; expires=Fri, 13-Jun-2010 13:45:29 GMT" and it is currently June 10th 2008 then you want to inspect the cookie. If the cookie is a session token that is stored on the users hard drive then an attacker or local user (such as an admin) who has access to this cookie can access the application by resubmitting this token until the expiration date passes.

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

*RFC 2965 - HTTP State Management Mechanism

'''Tools''' 

*Intercepting Proxy
*Browser Plug-in

Testing for cookies attributes (OTG-SESS-002)

2008-06-10T20:40:17Z

Khorvath: /* Gray Box testing and example */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
Cookies are often a key attack vector for malicious users (typically targeting other users) and as such the application should always take due diligence to protect these cookies. In this section we will look at how an application can take the necessary precautions when assigning cookies and how to test that these attributes have been correctly configured.
 

== Description of the Issue ==
 
The importance and secure use of Cookies cannot be understated, especially within dynamic web applications which need to maintain state across a stateless protocol such as HTTP. To understand the importance of cookies it is imperative to understand what they are primarily used for. These primary functions usually consist of being used as a session authorization/authentication token and/or as a temporary data container. Thus if an attacker by some means was able to acquire a session token such as by cross site scripting (XSS) or sniffing an unencrypted session then they could use this cookie to hijack a valid current session. Additionally cookies are set to maintain state across multiple requests. Since HTTP is stateless the server can not determine if a request it receives is part of a current session or the start of a new session without some type of identifier. This identifier is very commonly a cookie although not always. As you can imagine there are many different types of applications that need to keep track of session state across multiple request. The primary one that comes to mind would be an online store. As a user adds multiple items to a shopping cart this data needs to be retained in subsequent requests to the application. Cookies are very commonly used for this task and are set by the application using the Set-Cookie directive in the applications HTTP response, and is usually in a name=value format (if cookies are enabled and if they are supported, which is the case for all modern web browsers). Once an application has told the browser to use a particular cookie the browser will send this cookie in each subsequent request. A cookie can contain data such as items from an online shopping cart, the price of these items, the quantity of these items, personal information, user IDs, etc. Due to the sensitive nature of information in cookies they are typically encoded or encrypted in an attempt to protect this information. Many times multiple cookies will be set (separated by a semicolon) upon subsequent request especially in the case of an online store as you add multiple items to your shopping cart. Additionally you will typically have a cookie for authentication (session token as indicated above) once you login and multiple others cookies used to identify the items you wish to purchase and their auxiliary information (ie price, quantity, etc) in the online store type of application.

Now that you have an understanding of how cookies are set, when they are set, what they are used for, why they are used, and their importance; lets take a look at what attributes can be set for a cookie and how to test if they are secure. The following is a list of the attributes that can be set for each cookie and what they mean. The next section will focus on how to test for each attribute.

*secure - This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests.
If the application can be accessed over HTTP and HTTPS then their is the potential that the cookie can be sent in cleartext.

*HttpOnly - This attribute is used to help prevent attacks such as cross-site scripting since it does not allow the cookie to be accessed via a client side script such as JavaScript. Note that not all browsers support this functionality.

*domain - This attribute is used to compare against the domain of the server in which the URL is being requested. If the domain matches or if its a sub-domain then the path attribute will be checked next.
Note that only hosts within the specified domain can set a cookie for that domain. Also the domain attribute can not be a top level domain (such as .gov or .com) to prevent against servers being able to set arbitrary cookies for another domain. If domain attribute is not set then the default value of domain is set to the hostname of the server which generated the cookie.
For example if a cookie is set by an application at app.mydomain.com with no domain attribute set, then the cookie would be resubmitted for all subsequent requests for app.mydomain.com and its subdomains (such as hacker.app.mydomain.com), but not to otherapp.mydomain.com. If a developer wanted to loosen this restriction then he could set the domain attribute to mydomain.com. In this case the cookie would be sent to all requests for app.mydomain.com, its subdomains such as hacker.app.mydomain.com and even bank.mydomain.com.
If there was a vulnerable server on a subdomain such as (otherapp.mydomain.com) and the domain attribute has been set to loosely (for example mydomain.com), then the vulnerable server could be used to harvest cookies (such as session tokens).

*path - In addition to the domain, the URL path can be specified for which the cookie is valid. If the domain and path match then the cookie will be sent in the request.
Just as with the domain attribute if the path attribute is set to loosely then it could leave the application vulnerable to attack by other applications on the same server. For example if the path attribute was set to the web server root "/" then the applications cookies will be sent to every application within the same domain.

*expires - This attribute is used to set persistent cookies, since the cookie does not expire until the set date is exceeded. This persistent cookie will be used by this browser session and subsequent sessions until the cookie expires. Once the expiration date has exceeded the browser will delete the cookie. Alternatively if this attribute is not set then the cookie is only valid in the current browser session and the cookie will be deleted when the session ends.

 

== Black Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 

Using an intercepting proxy or browser plugin trap all responses where a cookie is set by the application (using the Set-cookie directive) and inspect the cookie for the following:

*Secure Attribute - Whenever a cookie contains sensitive information or is a session token then it should always be passed using an encrypted tunnel. For example after logging into an application and a session token is set using a cookie, then verify it is tagged using the ";secure" flag. If it is not then it the browser believes it safe to pass via an unencrypted channel such as using HTTP.

*HttpOnly Attribute - This attribute should always be set even though not every browser supports it. This attribute aides in securing the cookie from being accessed by a client side script so check to see if the ";HttpOnly" tag has been set.

*Domain Attribute - Verify that the domain has not been set to loosely. As noted above it should only be set for the server that needs to receive the cookie. For example if the application resides on server app.mysite.com then it should be set to "; domain=app.mysite.com" and NOT "; domain=.mysite.com" as this would allow other potentially vulnerable servers to receive the cookie.

*Path Attribute - Verify that the path attribute, just as the Domain attribute, has not been set to loosely. Even if the Domain attribute has been configured as tight as possible, if the path is set to the root directory "/" then it can be vulnerable to less secure applications on the same server. For example if the application resides at /myapp/ then verify that the cookies path is set to "; path=/myapp/" and NOT "; path=/" or "; path=/myapp". Notice here that the trailing "/" must be used after myapp. If it is not used the browser will send the cookie to any path the matches "myapp" such as "myapp-exploited"

*expires Attribute - Verify that if this attribute is set to a time in the future that it does not contain any sensitive information. For example if a cookie is set to "; expires=Fri, 13-Jun-2010 13:45:29 GMT" and it is currently June 10th 2008 then you want to inspect the cookie. If the cookie is a session token that is stored on the users hard drive then an attacker or local user (such as an admin) who has access to this cookie can access the application by resubmitting this token until the expiration date passes.

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

*Intercepting Proxy
*Browser Plug-in
...

Testing for cookies attributes (OTG-SESS-002)

2008-06-10T20:39:12Z

Khorvath: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
Cookies are often a key attack vector for malicious users (typically targeting other users) and as such the application should always take due diligence to protect these cookies. In this section we will look at how an application can take the necessary precautions when assigning cookies and how to test that these attributes have been correctly configured.
 

== Description of the Issue ==
 
The importance and secure use of Cookies cannot be understated, especially within dynamic web applications which need to maintain state across a stateless protocol such as HTTP. To understand the importance of cookies it is imperative to understand what they are primarily used for. These primary functions usually consist of being used as a session authorization/authentication token and/or as a temporary data container. Thus if an attacker by some means was able to acquire a session token such as by cross site scripting (XSS) or sniffing an unencrypted session then they could use this cookie to hijack a valid current session. Additionally cookies are set to maintain state across multiple requests. Since HTTP is stateless the server can not determine if a request it receives is part of a current session or the start of a new session without some type of identifier. This identifier is very commonly a cookie although not always. As you can imagine there are many different types of applications that need to keep track of session state across multiple request. The primary one that comes to mind would be an online store. As a user adds multiple items to a shopping cart this data needs to be retained in subsequent requests to the application. Cookies are very commonly used for this task and are set by the application using the Set-Cookie directive in the applications HTTP response, and is usually in a name=value format (if cookies are enabled and if they are supported, which is the case for all modern web browsers). Once an application has told the browser to use a particular cookie the browser will send this cookie in each subsequent request. A cookie can contain data such as items from an online shopping cart, the price of these items, the quantity of these items, personal information, user IDs, etc. Due to the sensitive nature of information in cookies they are typically encoded or encrypted in an attempt to protect this information. Many times multiple cookies will be set (separated by a semicolon) upon subsequent request especially in the case of an online store as you add multiple items to your shopping cart. Additionally you will typically have a cookie for authentication (session token as indicated above) once you login and multiple others cookies used to identify the items you wish to purchase and their auxiliary information (ie price, quantity, etc) in the online store type of application.

Now that you have an understanding of how cookies are set, when they are set, what they are used for, why they are used, and their importance; lets take a look at what attributes can be set for a cookie and how to test if they are secure. The following is a list of the attributes that can be set for each cookie and what they mean. The next section will focus on how to test for each attribute.

*secure - This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests.
If the application can be accessed over HTTP and HTTPS then their is the potential that the cookie can be sent in cleartext.

*HttpOnly - This attribute is used to help prevent attacks such as cross-site scripting since it does not allow the cookie to be accessed via a client side script such as JavaScript. Note that not all browsers support this functionality.

*domain - This attribute is used to compare against the domain of the server in which the URL is being requested. If the domain matches or if its a sub-domain then the path attribute will be checked next.
Note that only hosts within the specified domain can set a cookie for that domain. Also the domain attribute can not be a top level domain (such as .gov or .com) to prevent against servers being able to set arbitrary cookies for another domain. If domain attribute is not set then the default value of domain is set to the hostname of the server which generated the cookie.
For example if a cookie is set by an application at app.mydomain.com with no domain attribute set, then the cookie would be resubmitted for all subsequent requests for app.mydomain.com and its subdomains (such as hacker.app.mydomain.com), but not to otherapp.mydomain.com. If a developer wanted to loosen this restriction then he could set the domain attribute to mydomain.com. In this case the cookie would be sent to all requests for app.mydomain.com, its subdomains such as hacker.app.mydomain.com and even bank.mydomain.com.
If there was a vulnerable server on a subdomain such as (otherapp.mydomain.com) and the domain attribute has been set to loosely (for example mydomain.com), then the vulnerable server could be used to harvest cookies (such as session tokens).

*path - In addition to the domain, the URL path can be specified for which the cookie is valid. If the domain and path match then the cookie will be sent in the request.
Just as with the domain attribute if the path attribute is set to loosely then it could leave the application vulnerable to attack by other applications on the same server. For example if the path attribute was set to the web server root "/" then the applications cookies will be sent to every application within the same domain.

*expires - This attribute is used to set persistent cookies, since the cookie does not expire until the set date is exceeded. This persistent cookie will be used by this browser session and subsequent sessions until the cookie expires. Once the expiration date has exceeded the browser will delete the cookie. Alternatively if this attribute is not set then the cookie is only valid in the current browser session and the cookie will be deleted when the session ends.

 

== Black Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 

Using an intercepting proxy or browser plugin trap all responses where a cookie is set by the application (using the Set-cookie directive) and inspect the cookie for the following:

*Secure Attribute - Whenever a cookie contains sensitive information or is a session token then it should always be passed using an encrypted tunnel. For example after logging into an application and a session token is set using a cookie, then verify it is tagged using the ";secure" flag. If it is not then it the browser believes it safe to pass via an unencrypted channel such as using HTTP.

*HttpOnly Attribute - This attribute should always be set even though not every browser supports it. This attribute aides in securing the cookie from being accessed by a client side script so check to see if the ";HttpOnly" tag has been set.

*Domain Attribute - Verify that the domain has not been set to loosely. As noted above it should only be set for the server that needs to receive the cookie. For example if the application resides on server app.mysite.com then it should be set to "; domain=app.mysite.com" and NOT "; domain=.mysite.com" as this would allow other potentially vulnerable servers to receive the cookie.

*Path Attribute - Verify that the path attribute, just as the Domain attribute, has not been set to loosely. Even if the Domain attribute has been configured as tight as possible, if the path is set to the root directory "/" then it can be vulnerable to less secure applications on the same server. For example if the application resides at /myapp/ then verify that the cookies path is set to "; path=/myapp/" and NOT "; path=/" or "; path=/myapp". Notice here that the trailing "/" must be used after myapp. If it is not used the browser will send the cookie to any path the matches "myapp" such as "myapp-exploited"

*expires Attribute - Verify that if this attribute is set to a time in the future that it does not contain any sensitive information. For example if a cookie is set to "; expires=Fri, 13-Jun-2010 13:45:29 GMT" and it is currently June 10th 2008 then you want to inspect the cookie. If the cookie is a session token that is stored on the users hard drive then an attacker or local user (such as an admin) who has access to this cookie can access the application by resubmitting this token until the expiration date passes.

== Gray Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 

*Intercepting Proxy
*Browser Plug-in
...

Testing for cookies attributes (OTG-SESS-002)

2008-06-10T19:26:38Z

Khorvath: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
Cookies are often a key attack vector for malicious users (typically targeting other users) and as such the application should always take due diligence to protect these cookies. In this section we will look at how an application can take the necessary precautions when assigning cookies and how to test that these attributes have been correctly configured.
 

== Description of the Issue ==
 
The importance and secure use of Cookies cannot be understated, especially within dynamic web applications which need to maintain state across a stateless protocol such as HTTP. To understand the importance of cookies it is imperative to understand what they are primarily used for. These primary functions usually consist of being used as a session authorization/authentication token and/or as a temporary data container. Thus if an attacker by some means was able to acquire a session token such as by cross site scripting (XSS) or sniffing an unencrypted session then they could use this cookie to hijack a valid current session. Additionally cookies are set to maintain state across multiple requests. Since HTTP is stateless the server can not determine if a request it receives is part of a current session or the start of a new session without some type of identifier. This identifier is very commonly a cookie although not always. As you can imagine there are many different types of applications that need to keep track of session state across multiple request. The primary one that comes to mind would be an online store. As a user adds multiple items to a shopping cart this data needs to be retained in subsequent requests to the application. Cookies are very commonly used for this task and are set by the application using the Set-Cookie directive in the applications HTTP response, and is usually in a name=value format (if cookies are enabled and if they are supported, which is the case for all modern web browsers). Once an application has told the browser to use a particular cookie the browser will send this cookie in each subsequent request. A cookie can contain data such as items from an online shopping cart, the price of these items, the quantity of these items, personal information, user IDs, etc. Due to the sensitive nature of information in cookies they are typically encoded or encrypted in an attempt to protect this information. Many times multiple cookies will be set (separated by a semicolon) upon subsequent request especially in the case of an online store as you add multiple items to your shopping cart. Additionally you will typically have a cookie for authentication (session token as indicated above) once you login and multiple others cookies used to identify the items you wish to purchase and their auxiliary information (ie price, quantity, etc) in the online store type of application.

Now that you have an understanding of how cookies are set, when they are set, what they are used for, why they are used, and their importance; lets take a look at what attributes can be set for a cookie and how to test if they are secure. The following is a list of the attributes that can be set for each cookie and what they mean. The next section will focus on how to test for each attribute.

*secure - This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests.
If the application can be accessed over HTTP and HTTPS then their is the potential that the cookie can be sent in cleartext.

*HttpOnly - This attribute is used to help prevent attacks such as cross-site scripting since it does not allow the cookie to be accessed via a client side script such as JavaScript. Note that not all browsers support this functionality.

*domain - This attribute is used to compare against the domain of the server in which the URL is being requested. If the domain matches or if its a sub-domain then the path attribute will be checked next.
Note that only hosts within the specified domain can set a cookie for that domain. Also the domain attribute can not be a top level domain (such as .gov or .com) to prevent against servers being able to set arbitrary cookies for another domain. If domain attribute is not set then the default value of domain is set to the hostname of the server which generated the cookie.
For example if a cookie is set by an application at app.mydomain.com with no domain attribute set, then the cookie would be resubmitted for all subsequent requests for app.mydomain.com and its subdomains (such as hacker.app.mydomain.com), but not to otherapp.mydomain.com. If a developer wanted to loosen this restriction then he could set the domain attribute to mydomain.com. In this case the cookie would be sent to all requests for app.mydomain.com, its subdomains such as hacker.app.mydomain.com and even bank.mydomain.com.
If there was a vulnerable server on a subdomain such as (otherapp.mydomain.com) and the domain attribute has been set to loosely (for example mydomain.com), then the vulnerable server could be used to harvest cookies (such as session tokens).

*path - In addition to the domain, the URL path can be specified for which the cookie is valid. If the domain and path match then the cookie will be sent in the request.
Just as with the domain attribute if the path attribute is set to loosely then it could leave the application vulnerable to attack by other applications on the same server. For example if the path attribute was set to the web server root "/" then the applications cookies will be sent to every application within the same domain.

*expires - This attribute is used to set persistent cookies, since the cookie does not expire until the set date is exceeded. This persistent cookie will be used by this browser session and subsequent sessions until the cookie expires. Once the expiration date has exceeded the browser will delete the cookie. Alternatively if this attribute is not set then the cookie is only valid in the current browser session and the cookie will be deleted when the session ends.

 

== Black Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 

Using an intercepting proxy or browser plugin trap all responses where a cookie is set by the application (using the Set-cookie directive) and inspect the cookie for the following:

*Secure Attribute - Whenever a cookie contains sensitive information or is a session token then it should always be passed using an encrypted tunnel. For example after logging into an application and a session token is set using a cookie, then verify it is tagged using the "secure" flag. If it is not then it the browser believes it safe to pass via an unencrypted channel such as using HTTP.

*
... 
'''Result Expected:''' 
... 

== Gray Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 

*Intercepting Proxy
*Browser Plug-in
...

Testing for cookies attributes (OTG-SESS-002)

2008-06-09T23:31:41Z

Khorvath: /* Description of the Issue */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
Cookies are often a key attack vector for malicious users (typically targeting other users) and as such the application should always take due diligence to protect these cookies. In this section we will look at how an application can take the necessary precautions when assigning cookies and how to test that these attributes have been correctly configured.
 

== Description of the Issue ==
 
The importance and secure use of Cookies cannot be understated, especially within dynamic web applications which need to maintain state across a stateless protocol such as HTTP. To understand the importance of cookies it is imperative to understand what they are primarily used for. These primary functions usually consist of being used as a session authorization/authentication token and/or as a temporary data container. Thus if an attacker by some means was able to acquire a session token such as by cross site scripting (XSS) or sniffing an unencrypted session then they could use this cookie to hijack a valid current session. Additionally cookies are set to maintain state across multiple requests. Since HTTP is stateless the server can not determine if a request it receives is part of a current session or the start of a new session without some type of identifier. This identifier is very commonly a cookie although not always. As you can imagine there are many different types of applications that need to keep track of session state across multiple request. The primary one that comes to mind would be an online store. As a user adds multiple items to a shopping cart this data needs to be retained in subsequent requests to the application. Cookies are very commonly used for this task and are set by the application using the Set-Cookie directive in the applications HTTP response, and is usually in a name=value format (if cookies are enabled and if they are supported, which is the case for all modern web browsers). Once an application has told the browser to use a particular cookie the browser will send this cookie in each subsequent request. A cookie can contain data such as items from an online shopping cart, the price of these items, the quantity of these items, personal information, user IDs, etc. Due to the sensitive nature of information in cookies they are typically encoded or encrypted in an attempt to protect this information. Many times multiple cookies will be set (separated by a semicolon) upon subsequent request especially in the case of an online store as you add multiple items to your shopping cart. Additionally you will typically have a cookie for authentication (session token as indicated above) once you login and multiple others cookies used to identify the items you wish to purchase and their auxiliary information (ie price, quantity, etc) in the online store type of application.

Now that you have an understanding of how cookies are set, when they are set, what they are used for, why they are used, and their importance; lets take a look at what attributes can be set for a cookie and how to test if they are secure. The following is a list of the attributes that can be set for each cookie and what they mean. The next section will focus on how to test for each attribute.

*secure - This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests.
If the application can be accessed over HTTP and HTTPS then their is the potential that the cookie can be sent in cleartext.

*HttpOnly - This attribute is used to help prevent attacks such as cross-site scripting since it does not allow the cookie to be accessed via a client side script such as JavaScript. Note that not all browsers support this functionality.

*domain - This attribute is used to compare against the domain of the server in which the URL is being requested. If the domain matches or if its a sub-domain then the path attribute will be checked next.
Note that only hosts within the specified domain can set a cookie for that domain. Also the domain attribute can not be a top level domain (such as .gov or .com) to prevent against servers being able to set arbitrary cookies for another domain. If domain attribute is not set then the default value of domain is set to the hostname of the server which generated the cookie.
For example if a cookie is set by an application at app.mydomain.com with no domain attribute set, then the cookie would be resubmitted for all subsequent requests for app.mydomain.com and its subdomains (such as hacker.app.mydomain.com), but not to otherapp.mydomain.com. If a developer wanted to loosen this restriction then he could set the domain attribute to mydomain.com. In this case the cookie would be sent to all requests for app.mydomain.com, its subdomains such as hacker.app.mydomain.com and even bank.mydomain.com.
If there was a vulnerable server on a subdomain such as (otherapp.mydomain.com) and the domain attribute has been set to loosely (for example mydomain.com), then the vulnerable server could be used to harvest cookies (such as session tokens).

*path - In addition to the domain, the URL path can be specified for which the cookie is valid. If the domain and path match then the cookie will be sent in the request.
Just as with the domain attribute if the path attribute is set to loosely then it could leave the application vulnerable to attack by other applications on the same server. For example if the path attribute was set to the web server root "/" then the applications cookies will be sent to every application within the same domain.

*expires - This attribute is used to set persistent cookies, since the cookie does not expire until the set date is exceeded. This persistent cookie will be used by this browser session and subsequent sessions until the cookie expires. Once the expiration date has exceeded the browser will delete the cookie. Alternatively if this attribute is not set then the cookie is only valid in the current browser session and the cookie will be deleted when the session ends.

 

== Black Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== Gray Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 

*Intercepting Proxy
*Browser Plug-in
...

Testing for cookies attributes (OTG-SESS-002)

2008-06-08T04:12:32Z

Khorvath: /* Description of the Issue */

Testing for cookies attributes (OTG-SESS-002)

2008-06-08T03:42:56Z

Khorvath: /* Brief Summary */

Testing for cookies attributes (OTG-SESS-002)

2008-06-08T03:39:51Z

Khorvath: /* Description of the Issue */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
Cookies are often a key attack vector for malicious users and as such the application should always take due diligence to protect them. In this section we will look at how an application can take the necessary precautions when assigning cookies and how to test that these attributes have been correctly configured.
 

== Description of the Issue ==
 
The importance and secure use of Cookies cannot be understated, especially within dynamic web applications which need to maintain state across a stateless protocol such as HTTP. To understand the importance of cookies it is imperative to understand what they are primarily used for. These primary functions usually consist of being used as a session authorization/authentication token and/or as a temporary data container. Thus if an attacker by some means was able to acquire a session token such as by cross site scripting (XSS) or sniffing an unencrypted session then they could use this cookie to hijack a valid current session. Additionally cookies are set to maintain state across multiple requests. Since HTTP is stateless the server can not determine if a request it receives is part of a current session or the start of a new session without some type of identifier. This identifier is very commonly a cookie although not always. As you can imagine there are many different types of applications that need to keep track of session state across multiple request. The primary one that comes to mind would be an online store. As a user adds multiple items to a shopping cart this data needs to be retained in subsequent requests to the application. Cookies are very commonly used for this task and are set by the application using the Set-Cookie directive in the applications HTTP response, and is usually in a name=value format (if cookies are enabled and if they are supported, which is the case for all modern web browsers). Once an application has told the browser to use a particular cookie the browser will send this cookie in each subsequent request. A cookie can contain data such as items from an online shopping cart, the price of these items, the quantity of these items, personal information, user IDs, etc. Due to the sensitive nature of information in cookies they are typically encoded or encrypted in an attempt to protect this information. Many times multiple cookies will be set (separated by a semicolon) upon subsequent request especially in the case of an online store as you add multiple items to your shopping cart. Additionally you will typically have a cookie for authentication (session token as indicated above) once you login and multiple others cookies used to identify the items you wish to purchase and their auxiliary information (ie price, quantity, etc) in the online store type of application.

Now that you have an understanding of how cookies are set, when they are set, what they are used for, why they are used, and their importance; lets take a look at what attributes can be set for a cookie and how to test if they are secure.
 

== Black Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== Gray Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 

*Intercepting Proxy
*Browser Plug-in
...

Testing for cookies attributes (OTG-SESS-002)

2008-06-08T03:32:48Z

Khorvath: /* Description of the Issue */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
Cookies are often a key attack vector for malicious users and as such the application should always take due diligence to protect them. In this section we will look at how an application can take the necessary precautions when assigning cookies and how to test that these attributes have been correctly configured.
 

== Description of the Issue ==
 
The importance and secure use of Cookies cannot be understated, especially within dynamic web applications which need to maintain state across a stateless protocol such as HTTP. To understand the importance of cookies it is imperative to understand what they are primarily used for. These primary functions usually consist of being used as a session authorization/authentication token and/or as a temporary data container. Thus if an attacker by some means was able to acquire a session token such as by cross site scripting (XSS) or sniffing an unencrypted session then they could use this cookie to hijack a valid current session. Additionally cookies are set to maintain state across multiple requests. Since HTTP is stateless the server can not determine if a request it receives is part of a current session or the start of a new session without some type of identifier. This identifier is very commonly a cookie although not always. As you can imagine there are many different types of applications that need to keep track of session state across multiple request. The primary one that comes to mind would be an online store. As a user adds multiple items to a shopping cart this data needs to be retained in subsequent requests to the application. Cookies are very commonly used for this task and are set by the application using the Set-Cookie directive in the applications HTTP response, and is usually in a name=value format (if cookies are enabled and if they are supported, which is the case for all modern web browsers). Once an application has told the browser to use a particular cookie the browser will send this cookie in each subsequent request. A cookie can contain data such as items from an online shopping cart, the price of these items, the quantity of these items, personal information, user IDs, etc. Due to the sensitive nature of information in cookies they are typically encoded or encrypted in an attempt to protect this information. Many times multiple cookies will be set upon subsequent request especially in the case of an online store as you add multiple items to your shopping cart. Additionally you will typically have a cookie for authentication (session token as indicated above) once you login and multiple others cookies used to identify the items you wish to purchase and their auxiliary information (ie price, quantity, etc)

Now that you have an understanding of how cookies are set, when they are set, what they are used for, why they are used, and their importance; lets take a look at what attributes can be set for a cookie and how to test if they are secure.
 

== Black Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== Gray Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 

*Intercepting Proxy
*Browser Plug-in
...

Testing for cookies attributes (OTG-SESS-002)

2008-06-08T02:10:08Z

Khorvath: /* References */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
Cookies are often a key attack vector for malicious users and as such the application should always take due diligence to protect them. In this section we will look at how an application can take the necessary precautions when assigning cookies and how to test that these attributes have been correctly configured.
 

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

*Intercepting Proxy
*Browser Plug-in
...

Testing for cookies attributes (OTG-SESS-002)

2008-06-08T02:05:42Z

Khorvath: /* Brief Summary */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
Cookies are often a key attack vector for malicious users and as such the application should always take due diligence to protect them. In this section we will look at how an application can take the necessary precautions when assigning cookies and how to test that these attributes have been correctly configured.
 

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

Identify application entry points (OTG-INFO-006)

2008-06-08T01:08:08Z

Khorvath: /* Description of the Issue */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
Enumerating the application and its attack surface is a key precursor before any attack should commence. This section will help you identify and map out every area within the application that should be investigated once your enumeration and mapping phase has been completed.
 
== Description of the Issue ==
 

Before any testing begins always get a good understanding of the application and how the user/browser communicates with it as you walk through the application. As you walk through the application pay special attention to all HTTP request (GET and POST Methods also known as Verbs) and every parameter and form field that is passed to the application. In addition to this pay attention to when GET requests are used and when POST request are used to pass parameters. It is very common that GET request will be used but when sensitive information is passed it will be done within the body of a POST request. Note here that to see the parameters sent in a POST request you will need to use a tool such as an intercepting proxy (for example OWASP's Webscarab) or a browser plug-in. Within the POST request also make special note of any hidden form fields that are being passed to the application as these usually contain sensitive information such as state information, quantity of items, the price of items, etc, that the developer never intended for you to see or change.

In the author's experience it has been very useful in using an intercepting proxy and a spreadsheet for this stage. The proxy will keep track of every request and response between you and the application as you walk through it. Additionally at this point I usually trap every request and response so that I can see exactly every header, parameter, etc that is being passed to the application and what is being returned. This can be quite tedious at times especially on large interactive sites (think of a banking application) but with experience of knowing what to look for this time can be significantly reduced. As you walk through the application and notice any interesting parameters in the URL, custom header, or body of the message then note this in your spreadsheet. The spreadsheet should include the page you requested (might be good to add the request number from the proxy here also for reference), the interesting parameters, the type of request (POST/GET), authenticated/unauthenticated access, if SSL is used, if its part of a multi-step process, and any other special notes. Once you have every area of the application mapped out then you can go through the application and test each of the areas that you have identified and make notes for what worked and what didn't work. The rest of this guide will identify how to test each of these areas of interest but this section must be undertaken before any of the actual testing can commence.

Below I will identify some helpful points of interests for all requests and responses. Within the requests section I will focus on the GET and POST methods as these are the majority of the requests that are used. Also note that are other Methods that can be used such as PUT and DELETE which can be very dangerous if allowed. There is a special section in this guide dedicated for testing this so I will only make note of this to be as thorough as possible.

'''Requests:'''

*Identify where GET's are used and where POST's are used
*Identify all parameters identified within a POST request (these are in the body of the request)
*Within the POST request pay special attention to any hidden parameters. When a POST is sent the form fields you enter will be sent in the body of the message in addition to any hidden form fields that are automagically sent to the application as well. These typically aren't seen unless you are using a proxy or view the HTML source code. In addition the next page you see, its data, and your access can all be different depending on the value of this hidden parameter(s).
*Identify all parameters within the GET request (i.e. URL) in particular the query string (usually after a ? mark).
*Identify all the parameters of the query string which usually are in a pair format such as foo=bar. Also note many parameters can be in one query string such as separated by a &, ~, :, or any other special character or encoding.
*A special note when it comes to identifying multiple parameters in one string or within a POST request is that some or all of the parameters will be needed to execute your attacks. You need to identify all of the parameters (even if encoded or encrypted) and identify which ones are processed by the application. I will stop at this point as later sections will identify how to test these parameters but just make sure you identify each one of them.
*Also pay attention to any additional or custom type headers not typically seen (such as debug=False)

'''Responses:'''

*Identify where new cookies are set (set-cookie directive), modified, and/or added to.
*Identify where there are any redirects (300 type messages), 400 type messages in particular 403 Forbidden, and 500 internal server errors during normal responses (i.e. unmodified requests).
*Also not where any interesting headers are identified such as "Server: BIG-IP" which indicates the site is being load balanced. Thus if load balanced and one server is incorrectly configured then you might have to make multiple requests to access the vulnerable server depending on the type of load balancing used.

 

== Black Box testing and example ==
'''Testing for application entry points:''' 
... 

'''EXAMPLE 1:'''

This example shows a GET request that would purchase an item from an online shopping application.

Example 1 of a simplified GET request:

*GET https://x.x.x.x/shoppingApp/buyme.asp?CUSTOMERID=100&ITEM=z101a&PRICE=62.50&IP=x.x.x.x
*Host: x.x.x.x
*Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIGZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy

'''Result Expected:''' 

Here you would note all the parameters of the request such as CUSTOMERID, ITEM, PRICE, IP, and the Cookie (which could just be encoded parameters or used for session state)

'''EXAMPLE 2:'''

This example shows a POST request that would login you into an application.

Example 2 of a simplified POST request:

*POST https://x.x.x.x/KevinNotSoGoodApp/authenticate.asp?service=login
*Host: x.x.x.x
*Cookie: SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIHByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMTIzNA==
*CustomCookie=00my00trusted00ip00is00x.x.x.x00

Body of the POST message:

*user=admin&pass=pass123&debug=true&fromtrustIP=true

'''Result Expected:''' 

In this example you would note all the parameters as you have before but notice that the parameters are passed in the body of the message and not in the URL. Additionally note that there is a custom cookie that is being used.
... 

== Gray Box testing and example ==

Testing for application entry points via a Gray Box methodology would consist of everything already identified above with one caveat. This would be if there are any external sources where the application receives data from and processes it (such as SNMP traps, syslog messages, SMTP, or SOAP messages from other servers). If there are any external sources of input into the application then a meeting with the application developers could identify any functions that would accept and/or expect user input and how its formated. For example the developer could help in understanding how to formulate a correct SOAP request that the application would accept and where the web service resides (if the web service or any other function hasn't already been identified during the black box testing).

== References ==

'''Tools''' 

*Intercepting Proxy
*Browser Plug-in

Identify application entry points (OTG-INFO-006)

2008-06-07T01:03:44Z

Khorvath: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
Enumerating the application and its attack surface is a key precursor before any attack should commence. This section will help you identify and map out every area within the application that should be investigated once your enumeration and mapping phase has been completed.
 
== Description of the Issue ==
 

You should always get a good understanding of the application and how the user/browser communicates with it as you walk through the application. As you walk through the application pay special attention to all HTTP request (GET and POST Methods also known as Verbs) and every parameter and form field that is passed to the application. In addition to this pay attention to when GET requests are used and when POST request are used to pass parameters. It is very common that GET request will be used but when sensitive information is passed it will be done within the body of a POST request. Note here that to see the parameters sent in a POST request you will need to use a tool such as an intercepting proxy (for example OWASP's Webscarab) or a browser plug-in. Within the POST request also make special note of any hidden form fields that are being passed to the application as these usually contain sensitive information such as state information, quantity of items, the price of items, etc, that the developer never intended for you to see or change.

In the author's experience it has been very useful in using an intercepting proxy and a spreadsheet for this stage. The proxy will keep track of every request and response between you and the application as you walk through it. Additionally at this point I usually trap every request and response so that I can see exactly every header, parameter, etc that is being passed to the application and what is being returned. This can be quite tedious at times especially on large interactive sites (think of a banking application) but with experience of knowing what to look for this time can be significantly reduced. As you walk through the application and notice any interesting parameters in the URL, custom header, or body of the message then note this in your spreadsheet. The spreadsheet should include the page you requested (might be good to add the request number from the proxy here also for reference), the interesting parameters, the type of request (POST/GET), authenticated/unauthenticated access, if SSL is used, if its part of a multi-step process, and any other special notes. Once you have every area of the application mapped out then you can go through the application and test each of the areas that you have identified and make notes for what worked and what didn't work. The rest of this guide will identify how to test each of these areas of interest but this section must be undertaken before any of the actual testing can commence.

Below I will identify some helpful points of interests for all requests and responses. Within the requests section I will focus on the GET and POST methods as these are the majority of the requests that are used. Also note that are other Methods that can be used such as PUT and DELETE which can be very dangerous if allowed. There is a special section in this guide dedicated for testing this so I will only make note of this to be as thorough as possible.

'''Requests:'''

*Identify where GET's are used and where POST's are used
*Identify all parameters identified within a POST request (these are in the body of the request)
*Within the POST request pay special attention to any hidden parameters. When a POST is sent the form fields you enter will be sent in the body of the message in addition to any hidden form fields that are automagically sent to the application as well. These typically aren't seen unless you are using a proxy or view the HTML source code. In addition the next page you see, its data, and your access can all be different depending on the value of this hidden parameter(s).
*Identify all parameters within the GET request (i.e. URL) in particular the query string (usually after a ? mark).
*Identify all the parameters of the query string which usually are in a pair format such as foo=bar. Also note many parameters can be in one query string such as separated by a &, ~, :, or any other special character or encoding.
*A special note when it comes to identifying multiple parameters in one string or within a POST request is that some or all of the parameters will be needed to execute your attacks. You need to identify all of the parameters (even if encoded or encrypted) and identify which ones are processed by the application. I will stop at this point as later sections will identify how to test these parameters but just make sure you identify each one of them.
*Also pay attention to any additional or custom type headers not typically seen (such as debug=False)

'''Responses:'''

*Identify where new cookies are set (set-cookie directive), modified, and/or added to.
*Identify where there are any redirects (300 type messages), 400 type messages in particular 403 Forbidden, and 500 internal server errors during normal responses (i.e. unmodified requests).
*Also not where any interesting headers are identified such as "Server: BIG-IP" which indicates the site is being load balanced. Thus if load balanced and one server is incorrectly configured then you might have to make multiple requests to access the vulnerable server depending on the type of load balancing used.

 

== Black Box testing and example ==
'''Testing for application entry points:''' 
... 

'''EXAMPLE 1:'''

This example shows a GET request that would purchase an item from an online shopping application.

Example 1 of a simplified GET request:

*GET https://x.x.x.x/shoppingApp/buyme.asp?CUSTOMERID=100&ITEM=z101a&PRICE=62.50&IP=x.x.x.x
*Host: x.x.x.x
*Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIGZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy

'''Result Expected:''' 

Here you would note all the parameters of the request such as CUSTOMERID, ITEM, PRICE, IP, and the Cookie (which could just be encoded parameters or used for session state)

'''EXAMPLE 2:'''

This example shows a POST request that would login you into an application.

Example 2 of a simplified POST request:

*POST https://x.x.x.x/KevinNotSoGoodApp/authenticate.asp?service=login
*Host: x.x.x.x
*Cookie: SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIHByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMTIzNA==
*CustomCookie=00my00trusted00ip00is00x.x.x.x00

Body of the POST message:

*user=admin&pass=pass123&debug=true&fromtrustIP=true

'''Result Expected:''' 

In this example you would note all the parameters as you have before but notice that the parameters are passed in the body of the message and not in the URL. Additionally note that there is a custom cookie that is being used.
... 

== Gray Box testing and example ==

Testing for application entry points via a Gray Box methodology would consist of everything already identified above with one caveat. This would be if there are any external sources where the application receives data from and processes it (such as SNMP traps, syslog messages, SMTP, or SOAP messages from other servers). If there are any external sources of input into the application then a meeting with the application developers could identify any functions that would accept and/or expect user input and how its formated. For example the developer could help in understanding how to formulate a correct SOAP request that the application would accept and where the web service resides (if the web service or any other function hasn't already been identified during the black box testing).

== References ==

'''Tools''' 

*Intercepting Proxy
*Browser Plug-in

Identify application entry points (OTG-INFO-006)

2008-06-07T01:01:26Z

Khorvath: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
Enumerating the application and its attack surface is a key precursor before any attack should commence. This section will help you identify and map out every area within the application that should be investigated once your enumeration and mapping phase has been completed.
 
== Description of the Issue ==
 

You should always get a good understanding of the application and how the user/browser communicates with it as you walk through the application. As you walk through the application pay special attention to all HTTP request (GET and POST Methods also known as Verbs) and every parameter and form field that is passed to the application. In addition to this pay attention to when GET requests are used and when POST request are used to pass parameters. It is very common that GET request will be used but when sensitive information is passed it will be done within the body of a POST request. Note here that to see the parameters sent in a POST request you will need to use a tool such as an intercepting proxy (for example OWASP's Webscarab) or a browser plug-in. Within the POST request also make special note of any hidden form fields that are being passed to the application as these usually contain sensitive information such as state information, quantity of items, the price of items, etc, that the developer never intended for you to see or change.

In the author's experience it has been very useful in using an intercepting proxy and a spreadsheet for this stage. The proxy will keep track of every request and response between you and the application as you walk through it. Additionally at this point I usually trap every request and response so that I can see exactly every header, parameter, etc that is being passed to the application and what is being returned. This can be quite tedious at times especially on large interactive sites (think of a banking application) but with experience of knowing what to look for this time can be significantly reduced. As you walk through the application and notice any interesting parameters in the URL, custom header, or body of the message then note this in your spreadsheet. The spreadsheet should include the page you requested (might be good to add the request number from the proxy here also for reference), the interesting parameters, the type of request (POST/GET), authenticated/unauthenticated access, if SSL is used, if its part of a multi-step process, and any other special notes. Once you have every area of the application mapped out then you can go through the application and test each of the areas that you have identified and make notes for what worked and what didn't work. The rest of this guide will identify how to test each of these areas of interest but this section must be undertaken before any of the actual testing can commence.

Below I will identify some helpful points of interests for all requests and responses. Within the requests section I will focus on the GET and POST methods as these are the majority of the requests that are used. Also note that are other Methods that can be used such as PUT and DELETE which can be very dangerous if allowed. There is a special section in this guide dedicated for testing this so I will only make note of this to be as thorough as possible.

'''Requests:'''

*Identify where GET's are used and where POST's are used
*Identify all parameters identified within a POST request (these are in the body of the request)
*Within the POST request pay special attention to any hidden parameters. When a POST is sent the form fields you enter will be sent in the body of the message in addition to any hidden form fields that are automagically sent to the application as well. These typically aren't seen unless you are using a proxy or view the HTML source code. In addition the next page you see, its data, and your access can all be different depending on the value of this hidden parameter(s).
*Identify all parameters within the GET request (i.e. URL) in particular the query string (usually after a ? mark).
*Identify all the parameters of the query string which usually are in a pair format such as foo=bar. Also note many parameters can be in one query string such as separated by a &, ~, :, or any other special character or encoding.
*A special note when it comes to identifying multiple parameters in one string or within a POST request is that some or all of the parameters will be needed to execute your attacks. You need to identify all of the parameters (even if encoded or encrypted) and identify which ones are processed by the application. I will stop at this point as later sections will identify how to test these parameters but just make sure you identify each one of them.
*Also pay attention to any additional or custom type headers not typically seen (such as debug=False)

'''Responses:'''

*Identify where new cookies are set (set-cookie directive), modified, and/or added to.
*Identify where there are any redirects (300 type messages), 400 type messages in particular 403 Forbidden, and 500 internal server errors during normal responses (i.e. unmodified requests).
*Also not where any interesting headers are identified such as "Server: BIG-IP" which indicates the site is being load balanced. Thus if load balanced and one server is incorrectly configured then you might have to make multiple requests to access the vulnerable server depending on the type of load balancing used.

 

== Black Box testing and example ==
'''Testing for application entry points:''' 
... 

'''EXAMPLE 1:'''

This example shows a GET request that would purchase an item from an online shopping application.

Example 1 of a simplified GET request:

*GET https://x.x.x.x/shoppingApp/buyme.asp?CUSTOMERID=100&ITEM=z101a&PRICE=62.50&IP=x.x.x.x
*Host: x.x.x.x
*Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIGZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy

'''Result Expected:''' 

Here you would note all the parameters of the request such as CUSTOMERID, ITEM, PRICE, IP, and the Cookie (which could just be encoded parameters or used for session state)

'''EXAMPLE 2:'''

This example shows a POST request that would login you into an application
Example 2 of a simplified POST request:

*POST https://x.x.x.x/KevinNotSoGoodApp/authenticate.asp?service=login
*Host: x.x.x.x
*Cookie: SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIHByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMTIzNA==
*CustomCookie=00my00trusted00ip00is00x.x.x.x00

*user=admin&pass=pass123&debug=true&fromtrustIP=true

'''Result Expected:''' 

In this example you would note all the parameters as you have before but notice that the parameters are passed in the body of the message and not in the URL. Additionally note that there is a custom cookie that is being used.
... 

== Gray Box testing and example ==

Testing for application entry points via a Gray Box methodology would consist of everything already identified above with one caveat. This would be if there are any external sources where the application receives data from and processes it (such as SNMP traps, syslog messages, SMTP, or SOAP messages from other servers). If there are any external sources of input into the application then a meeting with the application developers could identify any functions that would accept and/or expect user input and how its formated. For example the developer could help in understanding how to formulate a correct SOAP request that the application would accept and where the web service resides (if the web service or any other function hasn't already been identified during the black box testing).

== References ==

'''Tools''' 

*Intercepting Proxy
*Browser Plug-in

Identify application entry points (OTG-INFO-006)

2008-06-06T19:33:58Z

Khorvath: /* References */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
Enumerating the application and its attack surface is a key precursor before any attack should commence. This section will help you identify and map out every area within the application that should be investigated once your enumeration and mapping phase has been completed.
 
== Description of the Issue ==
 

You should always get a good understanding of the application and how the user/browser communicates with it as you walk through the application. As you walk through the application pay special attention to all HTTP request (GET and POST Methods also known as Verbs) and every parameter and form field that is passed to the application. In addition to this pay attention to when GET requests are used and when POST request are used to pass parameters. It is very common that GET request will be used but when sensitive information is passed it will be done within the body of a POST request. Note here that to see the parameters sent in a POST request you will need to use a tool such as an intercepting proxy (for example OWASP's Webscarab) or a browser plug-in. Within the POST request also make special note of any hidden form fields that are being passed to the application as these usually contain sensitive information such as state information, quantity of items, the price of items, etc, that the developer never intended for you to see or change.

In the author's experience it has been very useful in using an intercepting proxy and a spreadsheet for this stage. The proxy will keep track of every request and response between you and the application as you walk through it. Additionally at this point I usually trap every request and response so that I can see exactly every header, parameter, etc that is being passed to the application and what is being returned. This can be quite tedious at times especially on large interactive sites (think of a banking application) but with experience of knowing what to look for this time can be significantly reduced. As you walk through the application and notice any interesting parameters in the URL, custom header, or body of the message then note this in your spreadsheet. The spreadsheet should include the page you requested (might be good to add the request number from the proxy here also for reference), the interesting parameters, the type of request (POST/GET), authenticated/unauthenticated access, if SSL is used, if its part of a multi-step process, and any other special notes. Once you have every area of the application mapped out then you can go through the application and test each of the areas that you have identified and make notes for what worked and what didn't work. The rest of this guide will identify how to test each of these areas of interest but this section must be undertaken before any of the actual testing can commence.

Below I will identify some helpful points of interests for all requests and responses. Within the requests section I will focus on the GET and POST methods as these are the majority of the requests that are used. Also note that are other Methods that can be used such as PUT and DELETE which can be very dangerous if allowed. There is a special section in this guide dedicated for testing this so I will only make note of this to be as thorough as possible.

'''Requests:'''

*Identify where GET's are used and where POST's are used
*Identify all parameters identified within a POST request (these are in the body of the request)
*Within the POST request pay special attention to any hidden parameters. When a POST is sent the form fields you enter will be sent in the body of the message in addition to any hidden form fields that are automagically sent to the application as well. These typically aren't seen unless you are using a proxy or view the HTML source code. In addition the next page you see, its data, and your access can all be different depending on the value of this hidden parameter(s).
*Identify all parameters within the GET request (i.e. URL) in particular the query string (usually after a ? mark).
*Identify all the parameters of the query string which usually are in a pair format such as foo=bar. Also note many parameters can be in one query string such as separated by a &, ~, :, or any other special character or encoding.
*A special note when it comes to identifying multiple parameters in one string or within a POST request is that some or all of the parameters will be needed to execute your attacks. You need to identify all of the parameters (even if encoded or encrypted) and identify which ones are processed by the application. I will stop at this point as later sections will identify how to test these parameters but just make sure you identify each one of them.
*Also pay attention to any additional or custom type headers not typically seen (such as debug=False)

'''Responses:'''

*Identify where new cookies are set (set-cookie directive), modified, and/or added to.
*Identify where there are any redirects (300 type messages), 400 type messages in particular 403 Forbidden, and 500 internal server errors during normal responses (i.e. unmodified requests).
*Also not where any interesting headers are identified such as "Server: BIG-IP" which indicates the site is being load balanced. Thus if load balanced and one server is incorrectly configured then you might have to make multiple requests to access the vulnerable server depending on the type of load balancing used.

 

== Black Box testing and example ==
'''Testing for application entry points:''' 
... 

''''EXAMPLE 1:''''

This example shows a GET request that would purchase an item from an online shopping application.

Example 1 of a simplified GET request:

*GET https://x.x.x.x/shoppingApp/buyme.asp?CUSTOMERID=100&ITEM=z101a&PRICE=62.50&IP=x.x.x.x
*Host: x.x.x.x
*Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIGZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy

'''Result Expected:''' 

Here you would note all the parameters of the request such as CUSTOMERID, ITEM, PRICE, IP, and the Cookie (which could just be encoded parameters or used for session state)

''''EXAMPLE 2:''''

This example shows a POST request that would login you into an application
Example 2 of a simplified POST request:

*POST https://x.x.x.x/KevinNotSoGoodApp/authenticate.asp?service=login
*Host: x.x.x.x
*Cookie: SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIHByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMTIzNA==
*CustomCookie=00my00trusted00ip00is00x.x.x.x00

*user=admin&pass=pass123&debug=true&fromtrustIP=true

'''Result Expected:''' 

In this example you would note all the parameters as you have before but notice that the parameters are passed in the body of the message and not in the URL. Additionally note that there is a custom cookie that is being used.
... 

== Gray Box testing and example ==

Testing for application entry points via a Gray Box methodology would consist of everything already identified above with one caveat. This would be if there are any external sources where the application receives data from and processes it (such as SNMP traps, syslog messages, SMTP, or SOAP messages from other servers). If there are any external sources of input into the application then a meeting with the application developers could identify any functions that would accept and/or expect user input and how its formated. For example the developer could help in understanding how to formulate a correct SOAP request that the application would accept and where the web service resides (if the web service or any other function hasn't already been identified during the black box testing).

== References ==

'''Tools''' 

*Intercepting Proxy
*Browser Plug-in

Identify application entry points (OTG-INFO-006)

2008-06-06T19:33:44Z

Khorvath: /* Gray Box testing and example */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==
 
Enumerating the application and its attack surface is a key precursor before any attack should commence. This section will help you identify and map out every area within the application that should be investigated once your enumeration and mapping phase has been completed.
 
== Description of the Issue ==
 

You should always get a good understanding of the application and how the user/browser communicates with it as you walk through the application. As you walk through the application pay special attention to all HTTP request (GET and POST Methods also known as Verbs) and every parameter and form field that is passed to the application. In addition to this pay attention to when GET requests are used and when POST request are used to pass parameters. It is very common that GET request will be used but when sensitive information is passed it will be done within the body of a POST request. Note here that to see the parameters sent in a POST request you will need to use a tool such as an intercepting proxy (for example OWASP's Webscarab) or a browser plug-in. Within the POST request also make special note of any hidden form fields that are being passed to the application as these usually contain sensitive information such as state information, quantity of items, the price of items, etc, that the developer never intended for you to see or change.

In the author's experience it has been very useful in using an intercepting proxy and a spreadsheet for this stage. The proxy will keep track of every request and response between you and the application as you walk through it. Additionally at this point I usually trap every request and response so that I can see exactly every header, parameter, etc that is being passed to the application and what is being returned. This can be quite tedious at times especially on large interactive sites (think of a banking application) but with experience of knowing what to look for this time can be significantly reduced. As you walk through the application and notice any interesting parameters in the URL, custom header, or body of the message then note this in your spreadsheet. The spreadsheet should include the page you requested (might be good to add the request number from the proxy here also for reference), the interesting parameters, the type of request (POST/GET), authenticated/unauthenticated access, if SSL is used, if its part of a multi-step process, and any other special notes. Once you have every area of the application mapped out then you can go through the application and test each of the areas that you have identified and make notes for what worked and what didn't work. The rest of this guide will identify how to test each of these areas of interest but this section must be undertaken before any of the actual testing can commence.

Below I will identify some helpful points of interests for all requests and responses. Within the requests section I will focus on the GET and POST methods as these are the majority of the requests that are used. Also note that are other Methods that can be used such as PUT and DELETE which can be very dangerous if allowed. There is a special section in this guide dedicated for testing this so I will only make note of this to be as thorough as possible.

'''Requests:'''

*Identify where GET's are used and where POST's are used
*Identify all parameters identified within a POST request (these are in the body of the request)
*Within the POST request pay special attention to any hidden parameters. When a POST is sent the form fields you enter will be sent in the body of the message in addition to any hidden form fields that are automagically sent to the application as well. These typically aren't seen unless you are using a proxy or view the HTML source code. In addition the next page you see, its data, and your access can all be different depending on the value of this hidden parameter(s).
*Identify all parameters within the GET request (i.e. URL) in particular the query string (usually after a ? mark).
*Identify all the parameters of the query string which usually are in a pair format such as foo=bar. Also note many parameters can be in one query string such as separated by a &, ~, :, or any other special character or encoding.
*A special note when it comes to identifying multiple parameters in one string or within a POST request is that some or all of the parameters will be needed to execute your attacks. You need to identify all of the parameters (even if encoded or encrypted) and identify which ones are processed by the application. I will stop at this point as later sections will identify how to test these parameters but just make sure you identify each one of them.
*Also pay attention to any additional or custom type headers not typically seen (such as debug=False)

'''Responses:'''

*Identify where new cookies are set (set-cookie directive), modified, and/or added to.
*Identify where there are any redirects (300 type messages), 400 type messages in particular 403 Forbidden, and 500 internal server errors during normal responses (i.e. unmodified requests).
*Also not where any interesting headers are identified such as "Server: BIG-IP" which indicates the site is being load balanced. Thus if load balanced and one server is incorrectly configured then you might have to make multiple requests to access the vulnerable server depending on the type of load balancing used.

 

== Black Box testing and example ==
'''Testing for application entry points:''' 
... 

''''EXAMPLE 1:''''

This example shows a GET request that would purchase an item from an online shopping application.

Example 1 of a simplified GET request:

*GET https://x.x.x.x/shoppingApp/buyme.asp?CUSTOMERID=100&ITEM=z101a&PRICE=62.50&IP=x.x.x.x
*Host: x.x.x.x
*Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIGZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy

'''Result Expected:''' 

Here you would note all the parameters of the request such as CUSTOMERID, ITEM, PRICE, IP, and the Cookie (which could just be encoded parameters or used for session state)

''''EXAMPLE 2:''''

This example shows a POST request that would login you into an application
Example 2 of a simplified POST request:

*POST https://x.x.x.x/KevinNotSoGoodApp/authenticate.asp?service=login
*Host: x.x.x.x
*Cookie: SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIHByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMTIzNA==
*CustomCookie=00my00trusted00ip00is00x.x.x.x00

*user=admin&pass=pass123&debug=true&fromtrustIP=true

'''Result Expected:''' 

In this example you would note all the parameters as you have before but notice that the parameters are passed in the body of the message and not in the URL. Additionally note that there is a custom cookie that is being used.
... 

== Gray Box testing and example ==

Testing for application entry points via a Gray Box methodology would consist of everything already identified above with one caveat. This would be if there are any external sources where the application receives data from and processes it (such as SNMP traps, syslog messages, SMTP, or SOAP messages from other servers). If there are any external sources of input into the application then a meeting with the application developers could identify any functions that would accept and/or expect user input and how its formated. For example the developer could help in understanding how to formulate a correct SOAP request that the application would accept and where the web service resides (if the web service or any other function hasn't already been identified during the black box testing).

== References ==

'''Tools''' 

*Web Proxy
*Browser Plug-in