OWASP - User contributions [en]

Testing for Session Management

2007-01-12T19:06:32Z

Vwiswell: proofreading

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 

{{Template:OWASP Testing Guide v2}}

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

[[ Analysis of the Session Management Schema AoC| 4.5.1 Analysis of the Session Management Schema]] 
This paragraph describes how to analyse a Session Management Schema, with the goal to understand how the Session Management mechanism has been developed and if it is possible to break it 
[[ Cookie and Session Token Manipulation AoC|4.5.2 Cookie and Session Token Manipulation]] 
Here it is explained how to test the security of session Token issued to the Client: how to make a cookie reverse engineering, and a cookie manipulation to force an hijacked session to work 
[[ Exposed Session Variables AoC|4.5.3 Exposed Session Variables ]] 
Session Tokens represent confidential informations because they tie the user identity with his own session. It's possible to test if the session token is exposed to this vulnerability and try to create a replay session attack.
 
[[ Session Riding AoC|4.5.4 Session Riding ]] 
Session Riding descibes a way to force an unknowing user to execute unwanted actions on a web application in which he is currently authenticated. 
[[ HTTP Exploit AoC|4.5.5 HTTP Exploit ]] 
Here is described how to test for an HTTP Exploit. 

{{Category:OWASP Testing Project AoC}}

Testing for authentication

2007-01-12T18:55:55Z

Vwiswell: proofreading

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 

{{Template:OWASP Testing Guide v2}}

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

[[Default or Guessable User Account Testing AoC|4.4.1 Default or guessable (dictionary) user account]] 
First we test if there are default user accounts or guessable username/password combinations (dictionary testing)

[[Brute Force Testing AoC|4.4.2 Brute Force]] 
When a dictionary type attack fails, a tester can attempt to use brute force methods to gain authentication. Brute force testing is not easy to accomplish for testers because of the time required and the possible lockout of the tester.

[[Bypassing Authentication Schema AoC|4.4.3 Bypassing authentication schema]] 
Other passive testing methods attempt to bypass the authentication schema by recognizing that not all of the application's resources are adequately protected. The tester can access these resources without authentication.

[[Directory Traversal Testing AoC|4.4.4 Directory traversal/file include]] 
Directory Traversal Testing is a particular method to find a way to bypass the application and gain access to system resources. Typically, these vulnerabilities are caused by misconfiguration.

[[Vulnerable Remember Password and Pwd Reset AoC|4.4.5 Vulnerable remember password and pwd reset]] 
Here we test how the application manages the process of "password forgotten". We also check whether the application allows the user to store the password in the browser ("remember password" function).

[[Logout and Browser Cache Management Testing AoC|4.4.6 Logout and Browser Cache Management Testing]] 
As a final test we check that the logout and caching functions are properly implemented.

{{Category:OWASP Testing Project AoC}}

Testing for business logic

2007-01-12T18:50:10Z

Vwiswell: proofreading

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

== Brief Summary ==

Business logic comprises:
* Business rules that express business policy (such as channels, location, logistics, prices, and products); and
* Workflows that are the ordered tasks of passing documents or data from one participant (a person or a software system) to another.

The attacks on the business logic of an application are dangerous, difficult to detect and specific to that application.

==Description of the Issue==

Business logic can have security flaws that allow a user to do something that isn't allowed by the business. For example, if there is a limit on reimbursement of $1000, could an attacker misuse the system to request more money than is allowed? Or perhaps you are supposed to do operations in a particular order, but an attacker could invoke them out of sequence. Or can a user make a purchase for a negative amount of money? Frequently these business logic security checks simply are not present in the application.

Automated tools find it hard to understand context, hence it's up to a person to perform these kinds of tests.

'''Business Limits and Restrictions''' 

Consider the rules for the business function being provided by the application. Are there any limits or restrictions on people's behavior? Then consider whether the application enforces those rules. It's generally pretty easy to identify the test and analysis cases to verify the application if you're familiar with the business. If you are a third-party tester, then you're going to have to use your common sense and ask the business if different operations should be allowed by the application.

'''Example''': Setting the quantity of a product on an e-commerce site as a negative number may result in funds being credited to the attacker. The countermeasure to this problem is to implement stronger data validation, as the application permits negative numbers to be entered in the quantity field of the shopping cart.

==Black Box Testing and Examples==

Although uncovering logical vulnerabilities will probably always remain an art, one can attempt to go about it systematically to a great extent. Here is a suggested approach that consists of:
* Understanding the application
* Creating raw data for designing logical tests
* Designing the logical tests
* Standard prerequisites
* Execution of logical tests

===Understanding the application===

Understanding the application thoroughly is a prerequisite for designing logical tests. To start with:
* Get any documentation describing the application's functionality. Examples of this include:
** Application manuals
** Requirements documents
** Functional specifications
* Explore the application manually and try to understand all the different ways in which the application can be used, the acceptable usage scenarios and the authorization limits imposed on various users

===Creating raw data for designing logical tests===

In this phase, one should ideally come up with the following data:
* All application '''business scenarios'''. For example, for an e-commerce application this might look like,
** Product ordering
** Checkout
** Browse
** Search for a product
* '''Workflows'''. This is different from business scenarios since it involves a number of different users. Examples include:
** Order creation and approval
** Bulletin board (one user posts an article that is reviewed by a moderator and ultimately seen by all users)
* Different '''user roles'''
** Administrator
** Manager
** Staff
** CEO
* Different '''groups or departments''' (note that there could be a tree (e.g. the Sales group of the heavy engineering division) or tagged view (e.g. someone could be a member of Sales as well as marketing) associated with this.
** Purchasing
** Marketing
** Engineering
* '''Access rights of various user roles and groups''' - The application allows various users privileges on some resource (or asset) and we need to specify the constraints of these privileges. One simple way to know these business rules/constraints is to make use of the application documentation effectively. For example, look for clauses like "If the administrator allows individual user access..", "If configured by the administrator.." and you know the restriction imposed by the application.
* '''Privilege Table''' – After learning about the various privileges on the resources along with the constraints, you are all set to create a Privilege Table. Get answers to:
** What can each user role do on which resource with what constraint? This will help you in deducing who cannot do what on which resource.
** What are the policies across groups?

Consider the following privileges: "Approve expense report", "Book a conference room", "Transfer money from own account to another user's account". A privilege could be thought of as a combination of a verb (e.g. Approve, Book, Withdraw) and one or more nouns (Expense report, conference room, account). The output of this activity is a grid with the various privileges forming the leftmost column while all user roles and groups would form the column headings of other columns. There would also be a “Comments” column that qualifies data in this grid.

<blockquote style="background: white; border: 1px solid rgb(153, 153, 153); padding: 1em;">
{| class="wikitable" style="margin: 1em auto 1em auto"
| '''Privilege''' || '''Who can do this''' || '''Comment'''
|-
| Approve expense report || Any supervisor may approve report submitted by his subordinate ||
|-
| Submit expense report || Any employee may do this for himself ||
|-
| Transfer funds from one account to another || An account holder may transfer funds from own account to another account ||
|-
| View payslip || Any employee may see his own ||
|-
|}
</blockquote>

This data is a key input for designing logical tests.

===Developing logical tests===

Here are several guidelines to designing logical tests from the raw data gathered.

* '''Privilege Table''' - Make use of the privilege table as a reference while creating application specific logical threats. In general, develop a test for each admin privilege to check if it could be executed illegally by a user role with minimum privileges or no privilege. For example:
** Privilege: Operations Manager cannot approve a customer order
** Logical Test: Operations Manager approves a customer order

* '''Improper handling of special user action sequences''' - Navigating through an application in a certain way or revisiting pages out of synch can cause logical errors which may cause the application to do something it's not meant to. For example:
** A wizard application where one fills in forms and proceeds to the next step. One cannot in any normal way (according to the developers) enter the wizard in the middle of the process. Bookmarking a middle step (say step 4 of 7), then continuing with the other steps until completion or form submission, then revisiting the middle step that was bookmarked may "upset" the backend logic due to a weak ''state model''.

* '''Cover all business transaction paths''' - While designing tests, check for all alternative ways to perform the same business transaction. For example, create tests for both cash and credit payment modes.

* '''Client-side validation''' - Look at all client side validations and see how they could be the basis for designing logical tests. For example, a funds transfer transaction has a validation for negative values in the amount field. This information can be used to design a logical test such as "A user transfers negative amount of money".

===Standard prerequisites===

Typically, some initial activities useful as setup are:
* Create test users with different permissions
* Browse all the important business scenarios/workflows in the application

===Execution of logical tests===

Pick up each logical test and do the following:
* Analyze the HTTP/S requests underlying the acceptable usage scenario corresponding to the logical test
** Check the order of HTTP/S requests
** Understand the purpose of hidden fields, form fields, query string parameters being passed
* Try and subvert it by exploiting the known vulnerabilities
* Verify that the application fails for the test

==References==
'''Whitepapers''' 
* Business logic - http://en.wikipedia.org/wiki/Business_logic
* Prevent application logic attacks with sound app security practices - http://searchappsecurity.techtarget.com/qna/0,289202,sid92_gci1213424,00.html?bucket=NEWS&topic=302570 

'''Tools''' 

Automated tools are incapable of detecting logical vulnerabilities. For example, tools have no means of detecting if a bank’s "fund transfer" page allows a user to transfer a negative amount to another user (in other words, it allows a user to transfer a positive amount into his own account) nor do they have any mechanism to help the human testers to suspect this state of affairs.

'''Preventing transfer of a negative amount''': Tools could be enhanced so that they can report client side validations to the tester. For example, the tool may have a feature whereby it fills a form with strange values and attempts to submit it using a full-fledged browser implementation. It should check to see whether the browser actually submitted the request. Detecting that the browser has not submitted the request would signal to the tool that submitted values are not being accepted due to client-side validation. This would be reported to the tester, who would then understand the need for designing appropriate logical tests that bypass client-side validation. In our "negative amount transfer" example, the tester would learn that the transfer of negative amounts may be an interesting test. He could then design a test wherein the tool bypasses the client-side validation code and checks to see if the resulting response contains the string "funds transfer successful". The point is not that the tool will be able to detect this or other vulnerabilities of this nature, rather that, with some thought, it would be possible to add many such features to enlist the tools in aiding human testers to find such logical vulnerabilities.

 
{{Category:OWASP Testing Project AoC}}

Testing for business logic

2007-01-12T18:42:46Z

Vwiswell: proofreading

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

== Brief Summary ==

Business logic comprises:
* Business rules that express business policy (such as channels, location, logistics, prices, and products); and
* Workflows that are the ordered tasks of passing documents or data from one participant (a person or a software system) to another.

The attacks on the business logic of an application are dangerous, difficult to detect and specific to that application.

==Description of the Issue==

Business logic can have security flaws that allow a user to do something that isn't allowed by the business. For example, if there is a limit on reimbursement of $1000, could an attacker misuse the system to request more money than is allowed? Or perhaps you are supposed to do operations in a particular order, but an attacker could invoke them out of sequence. Or can a user make a purchase for a negative amount of money? Frequently these business logic security checks simply are not present in the application.

Automated tools find it hard to understand context, hence it's up to a person to perform these kinds of tests.

'''Business Limits and Restrictions''' 

Consider the rules for the business function being provided by the application. Are there any limits or restrictions on people's behavior? Then consider whether the application enforces those rules. It's generally pretty easy to identify the test and analysis cases to verify the application if you're familiar with the business. If you are a third-party tester, then you're going to have to use your common sense and ask the business if different operations should be allowed by the application.

'''Example''': Setting the quantity of a product on an e-commerce site as a negative number may result in funds being credited to the attacker. The countermeasure to this problem is to implement stronger data validation, as the application permits negative numbers to be entered in the quantity field of the shopping cart.

==Black Box Testing and Examples==

Although uncovering logical vulnerabilities will probably always remain an art, one can attempt to go about it systematically to a great extent. Here is a suggested approach that consists of:
* Understanding the application
* Creating raw data for designing logical tests
* Designing the logical tests
* Standard prerequisites
* Execution of logical tests

===Understanding the application===

Understanding the application thoroughly is a prerequisite for designing logical tests. To start with:
* Get any documentation describing the application's functionality. Examples of this include:
** Application manuals
** Requirements documents
** Functional specifications
* Explore the application manually and try to understand all the different ways in which the application can be used, the acceptable usage scenarios and the authorization limits imposed on various users

===Creating raw data for designing logical tests===

In this phase, one should ideally come up with the following data:
* All application '''business scenarios'''. For example, for an e-commerce application this might look like,
** Product ordering
** Checkout
** Browse
** Search for a product
* '''Workflows'''. This is different from business scenarios since it involves a number of different users. Examples include:
** Order creation and approval
** Bulletin board (one user posts an article that is reviewed by a moderator and ultimately seen by all users)
* Different '''user roles'''
** Administrator
** Manager
** Staff
** CEO
* Different '''groups or departments''' (note that there could be a tree (e.g. the Sales group of the heavy engineering division) or tagged view (e.g. someone could be a member of Sales as well as marketing) associated with this.
** Purchasing
** Marketing
** Engineering
* '''Access rights of various user roles and groups''' - The application allows various users privileges on some resource (or asset) and we need to specify the constraints of these privileges. One simple way to know these business rules/constraints is to make use of the application documentation effectively. For example, look for clauses like "If the administrator allows individual user access..", "If configured by the administrator.." and you know the restriction imposed by the application.
* '''Privilege Table''' – After learning about the various privileges on the resources along with the constraints, you are all set to create a Privilege Table. Get answers to:
** What can each user role do on which resource with what constraint? This will help you in deducing who cannot do what on which resource.
** What are the policies across groups?

Consider the following privileges: "Approve expense report", "Book a conference room", "Transfer money from own account to another user's account". A privilege could be thought of as a combination of a verb (e.g. Approve, Book, Withdraw) and one or more nouns (Expense report, conference room, account). The output of this activity is a grid with the various privileges forming the leftmost column while all user roles and groups would form the column headings of other columns. There would also be a “Comments” column that qualifies data in this grid.

<blockquote style="background: white; border: 1px solid rgb(153, 153, 153); padding: 1em;">
{| class="wikitable" style="margin: 1em auto 1em auto"
| '''Privilege''' || '''Who can do this''' || '''Comment'''
|-
| Approve expense report || Any supervisor may approve report submitted by his subordinate ||
|-
| Submit expense report || Any employee may do this for himself ||
|-
| Transfer funds from one account to another || An account holder may transfer funds from own account to another account ||
|-
| View payslip || Any employee may see his own ||
|-
|}
</blockquote>

This data is a key input for designing logical tests.

===Developing logical tests===

Here are several guidelines to designing logical tests from the raw data gathered.

* '''Privilege Table''' - Make use of the privilege table as a reference while creating application specific logical threats. In general, develop a test for each admin privilege to check if it could be executed illegally by a user role with minimum privileges or no privilege. For example:
** Privilege: Operations Manager cannot approve a customer order
** Logical Test: Operations Manager approves a customer order

* '''Improper handling of special user action sequences''' - Navigating through an application in a certain way or revisiting pages out of synch can cause logical errors which may cause the application to do something it's not meant to. For example:
** A wizard application where one fills in forms and proceeds to the next step. One cannot in any normal way (according to the developers) enter the wizard in the middle of the process. Bookmarking a middle step (say step 4 of 7), then continuing with the other steps until completion or form submission, then revisiting the middle step that was bookmarked may "upset" the backend logic due to a weak ''state model''.

* '''Cover all business transaction paths''' - While designing tests, check for all alternative ways to perform the same business transaction. For example, create tests for both cash and credit payment modes.

* '''Client-side validation''' - Look at all client side validations and see how they could be the basis for designing logical tests. For example, a funds transfer transaction has a validation for negative values in the amount field. This information can be used to design a logical test such as "A user transfers negative amount of money".

===Standard prerequisites===

Typically, some initial activities useful as setup are:
* Create test users with different permissions
* Browse all the important business scenarios/workflows in the application

===Execution of logical tests===

Pick up each logical test and do the following:
* Analyze the HTTP/S requests underlying the acceptable usage scenario corresponding to the logical test
** Check the order of HTTP/S requests
** Understand the purpose of hidden fields, form fields, query string parameters being passed
* Try and subvert it by exploiting the known vulnerabilities
* Verify that the application fails for the test

==References==
'''Whitepapers''' 
* Business logic - http://en.wikipedia.org/wiki/Business_logic
* Prevent application logic attacks with sound app security practices - http://searchappsecurity.techtarget.com/qna/0,289202,sid92_gci1213424,00.html?bucket=NEWS&topic=302570 

'''Tools''' 

Automated tools are incapable of detecting logical vulnerabilities. For example, tools have no means of detecting if a bank’s "fund transfer" page allows a user to transfer a negative amount to another user (in other words, it allows a user to transfer a positive amount into his own account) nor do they have any mechanism to help the human testers to suspect this state of affairs.

'''Preventing transfer of a negative amount''': Tools could be enhanced so that they can report client side validations to the tester. For example, the tool may have a feature whereby it fills a form with strange values and attempts to submit it using a full-fledged browser implementation. It should check to see whether the browser actually submitted the request. Detecting that the browser has not submitted the request would signal to the tool that submitted values are not being accepted due to client-side validation. This would be reported to the tester, who would then understand the need for designing appropriate logical tests that bypass client-side validation. In our "negative amount transfer" example, the tester would learn that the transfer of negative amounts may be an interesting test. He could then design a test wherein the tool bypasses the client-side validation code and checks to see if the resulting response contains the string "funds transfer successful". The point is not that the tool will be able to detect this or other vulnerabilities of this nature, rather that, with some thought, it would be possible to add many such features to enlist the tools in aiding human testers to find such logical vulnerabilities.

 
{{Category:OWASP Testing Project AoC}}

Testing: Information Gathering

2007-01-12T17:07:35Z

Vwiswell:

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

=== Information Gathering ===
----
The first phase in security assessment is focused on collecting as much information as possible about a target application.
Information Gathering is a necessary step of a penetration test.

This task can be carried out in many different ways.

Using public tools (search engines), scanners, sending simple HTTP requests, or specially crafted requests, it is possible to force the application to leak information by sending back error messages or revealing the versions and technologies used by the application. 

Often it is possible to gather information by receiving a response from the application that, as a consequence of bad default configuration of the application server or web server, could reveal vulnerabilities in the configuration or bad server management.

[[Application Discovery AoC|4.2.1 Application Fingerprint]]

Application fingerprint is the first step of the Information Gathering process; knowing the version and type of a running web server allows testers to determine known vulnerabilities and the appropriate exploits to use during testing.

[[Application Discovery AoC|4.2.2 Application Discovery]]

Application discovery is an activity oriented to the identification of the web applications hosted on a web server/application server. 
This analysis is important because many times there is not a direct link connecting the main application backend. Discovery analysis can be useful to reveal details such as web-apps used for administrative purposes. In addition, it can reveal old versions of files or artifacts such as undeleted, obsolete scripts crafted during the test/development phase or as the result of maintenance.

[[Spidering and googling AoC|4.2.3 Spidering and googling]]

This phase of the Information Gathering process consists of browsing and capturing resources related to the application being tested. Search engines, such as Google, can be used to discover issues related to the web application structure or error pages produced by the application that have been exposed to the public domain.

[[Testing for Error Code|4.2.4 Analysis of error code]]

Web applications may divulge information during a penetration test which is not intended to be seen by an end user. Information such as error codes can inform the tester about technologies and products being used by the application. 
Such error codes can be easy to exploit without using any particular skill due to bad error handling strategy.

[[Infrastructure configuration management testing AoC|4.2.5 Infrastructure configuration management testing]]

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. 
Clearly, focusing only on the web application will not be an exhaustive test. It cannot be as comprehensive as the information possibly gathered by performing a broader infrastructure analysis.

[[SSL/TLS Testing AoC|4.2.5.1 SSL/TLS Testing]]

SSL and TLS are two protocols that provide, with the support of cryptography, secure channels for the protection, confidentiality, and authentication of the information being transmitted. 
Considering the criticality of these security implementations, it is important to verify the usage of a strong cipher algorithm and its proper implementation.

[[DB Listener Testing AoC|4.2.5.2 DB Listener Testing]]

During the configuration of a database server, many DB administrators do not adequately consider the security of the DB listener component. The listener could reveal sensitive data as well as configuration settings or running database instances. 
This information could provide some useful hints needed to compromise the reservedness, integrity and availability of the stored data. An accurate security analysis of the DB listener configuration can allow for the acquisition this information.

[[Application configuration management testing AoC|4.2.6 Application configuration management testing]]

Web applications hide some information that is usually not considered during the development or configuration of the application itself. 
This data can be discovered in the source code, in the log files or in the default error codes of the web servers. A correct approach to this topic is fundamental during a security assessment.

[[File extensions handling AoC|4.2.6.1 File extensions handling]]

The file extensions present in a web server or a web-app make it possible to identify the technologies which compose the target application, e.g. jsp and asp extensions. File extensions can also expose additional systems connected to the application.

[[Old file testing AoC|4.2.6.2 Old, backup and unreferenced files]]

Redundant, readable and downloadable files on a web server, such as old, backup and renamed files, are a big source of information leakage. It is necessary to verify the presence of these files because they may contain parts of source code, installation paths as well as passwords for applications and/or databases.

{{Category:OWASP Testing Project AoC}}

Testing: Introduction and objectives

2007-01-12T16:22:28Z

Vwiswell:

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

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

Given that an application owns a set of assets (resources of value such as the data in a database or on the file system), a vulnerability is a weakness in an asset that makes a threat possible.
So a threat is a potential occurrence that may harm an asset by exploiting a vulnerability.
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 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 the know vulnerabilities and document all the 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 in 2 phases:
* Passive mode: in the passive mode the tester tries to understand the application's logic, plays with the application; a tool can be used for information gathering such as 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. Header HTTP, parameters, cookies). For example the tester could find the following:
<pre>
https://www.example.com/login/Autentic_Form.html
</pre>
This indicates 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 tests in 8 sub-categories:
*Information Gathering
*Business Logic Testing
*Authentication Testing
*Session Management Testing
*Data Validation Testing
*Denial of Service Testing
*Web Services Testing
*AJAX Testing

Here is the list of tests that we will explain in the next paragraphs:

<center>[[Image:Table1.PNG]]</center>
<center>[[Image:Table2.PNG]]</center>
<center>[[Image:Table3.PNG]]</center>

{{Category:OWASP Testing Project AoC}}