OWASP - User contributions [en]

Testing for DOM-based Cross site scripting (OTG-CLIENT-001)

2008-11-02T16:56:38Z

Mr fusion: /* Black and Gray Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
DOM-based Cross-Site Scripting is the de-facto name for XSS bugs which are the result of active content on a page, typically JavaScript, obtaining user input and then doing something unsafe with it to lead to execution of injected code. This document will only discuss JavaScript bugs which lead to XSS.

The DOM, or Document Object Model is the structural format that may be used to represent documents in the browser. The DOM enables dynamic scripts such as Javascript to reference components of the document such as a form field or a session cookie. The DOM is also used by the browser for security - for example to limit scripts on different domains obtaining session cookies for other domains. A DOM-based cross site scripting vulnerability may occur when active content, such as a javascript function, is modified by a specially crafted request such that a DOM element that can be controlled by an attacker.

There have been very few papers published on this topic and, as such, very little standardization of its meaning and formalized testing exists.
 

== Description of the Issue ==
 
Not all XSS bugs require the attacker to control the content returned from the server, but can rather abuse poor JavaScript coding practices to achieve the same results. The results are the same as a typical XSS bug, only the means of delivery is different.

In comparison to other cross site scripting vulnerabilities (reflected and stored XSS), where an unsanitized parameter is passed by the server, returned to the user and executed in the context of the users browser, a DOM based cross site scripting vulnerability controls the flow of the code by using elements of the Document Object Model (DOM) along with code crafted by the attacker to change the flow.

Due to their nature, DOM based XSS vulnerabilities can be executed in many instances without the server being able to determine what is actually being executed. This may result in many of the general XSS filtering and detection rules impotent against such attacks.

The first hypothetical example uses the following client side code:

<script>
document.write("Site is at: " + document.location.href + ".");
</script>

An attacker may append #<script>alert('xss')</script> to the affect page URL which would, when executed display the alert box. In this instance, the appended code would not be sent to the server as everything after the # character is not treated as part of the query by the browser but as a fragment. In this example the code is immediately executed and an alert of "xss" is displayed in the page. Unlike the more common types of cross site scripting (persistent and non-persistent) which the code is sent to the server and redisplayed to the user, this is executed directly in the users browser without server contact.

The outcome of DOM based cross site scripting flaws are as wide ranging as those seen in more well known forms of XSS, including cookie retrieval, further malicious script injection etc and should therefore be treated with the same severity as such.
 

== Black and Gray Box testing and example ==
Blackbox testing for DOM-Based XSS 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 DOM Based XSS vulnerabilities:''' 
JavaScript applications differ significantly from other types of applications because they are often dynamically generated by the server, and to understand what code is being executed, the website being tested needs to be crawled to determine all the instances of JavaScript being executed and where user input is accepted. Many websites rely on large libraries of functions, which often stretch into the hundreds of thousands of lines of code and have not been developed in-house. In these cases, top-down testing often becomes the only really viable option, since many bottom level functions are never used, and analyzing them to determine which are sinks will use up more time than is often availiable. The same can also be said for top-down testing if the inputs or lack thereof is not identified to begin with.

User input comes in two main forms:

* Input written to the page by the server in a way that does not allow direct XSS
* Input obtained from client-side JavaScript objects

Here are two examples of how the server may insert data into JavaScript:
<pre>
var data = "<escaped data from the server>";

var result = someFunction("<escaped data from the server>");

And here are two examples of input from client-side JavaScript objects:

var data = window.location;

var result = someFunction(window.referer);
</pre>
While there is little difference to the JavaScript code in how they are retrieved, it is important to note that when input is received via the server, the server can apply any permutations to the data that it desires, whereas the permutations performed by JavaScript objects is fairly well understood and documented, and so if someFunction in the above example were a sink, then the exploitability of the former would depend on the filtering done by the server, whereas the latter would depend on the encoding done by the browser on the window.referer object.

Additionally, JavaScript is very often executed outside of <script> blocks, as evidenced by the many vectors which have led to XSS filter bypasses in the past, and so, when crawling the application, it is important to note the use of script in places such as event handlers and CSS blocks with expression attributes. Also, note that any off-site CSS or script objects will need to be assessed to determine what code is being executed.

Automated testing has only very limited success at identifying and validating DOM based XSS as they usually identify XSS by sending a specific payload and attempt to observe it in the server response. This may work fine for the simple example provided below, where the message parameter is reflected back to the user:
<pre>
<script>
var pos=document.URL.indexOf("message=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</script>
</pre>

but may not be detected in the following contrived case:
<pre>
<script>
var navAgt = navigator.userAgent;

if (navAgt.indexOf("MSIE")!=-1) {
document.write("You are using IE as a browser and visiting site: " + document.location.href + ".");
}
else
{
document.write("You are using an unknown browser.");
}
</script>
</pre>
For this reason, automated testing will not detect areas that may be susceptible to DOM based XSS unless the testing tool can perform addition analysis of the client side code.

Manual testing should therefore be undertaken and can be done by examining areas in the code where parameters are referred to that may be useful to an attacker.
Examples of such areas include places where code is dynamically written to the page and elsewhere where the DOM is modified or even where scripts are directly executed. Further examples
are described in the excellent DOM XSS article by Amit Klein, referenced at the end of this section.

 

== References ==
'''Whitepapers''' 
* Document Object Model (DOM) - http://en.wikipedia.org/wiki/Document_Object_Model
* DOM Based Cross Site Scripting or XSS of the Third Kind - Amit Klein http://www.webappsec.org/projects/articles/071105.shtml

Testing for DOM-based Cross site scripting (OTG-CLIENT-001)

2008-11-02T16:56:16Z

Mr fusion: /* Description of the Issue */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
DOM-based Cross-Site Scripting is the de-facto name for XSS bugs which are the result of active content on a page, typically JavaScript, obtaining user input and then doing something unsafe with it to lead to execution of injected code. This document will only discuss JavaScript bugs which lead to XSS.

The DOM, or Document Object Model is the structural format that may be used to represent documents in the browser. The DOM enables dynamic scripts such as Javascript to reference components of the document such as a form field or a session cookie. The DOM is also used by the browser for security - for example to limit scripts on different domains obtaining session cookies for other domains. A DOM-based cross site scripting vulnerability may occur when active content, such as a javascript function, is modified by a specially crafted request such that a DOM element that can be controlled by an attacker.

There have been very few papers published on this topic and, as such, very little standardization of its meaning and formalized testing exists.
 

== Description of the Issue ==
 
Not all XSS bugs require the attacker to control the content returned from the server, but can rather abuse poor JavaScript coding practices to achieve the same results. The results are the same as a typical XSS bug, only the means of delivery is different.

In comparison to other cross site scripting vulnerabilities (reflected and stored XSS), where an unsanitized parameter is passed by the server, returned to the user and executed in the context of the users browser, a DOM based cross site scripting vulnerability controls the flow of the code by using elements of the Document Object Model (DOM) along with code crafted by the attacker to change the flow.

Due to their nature, DOM based XSS vulnerabilities can be executed in many instances without the server being able to determine what is actually being executed. This may result in many of the general XSS filtering and detection rules impotent against such attacks.

The first hypothetical example uses the following client side code:

<script>
document.write("Site is at: " + document.location.href + ".");
</script>

An attacker may append #<script>alert('xss')</script> to the affect page URL which would, when executed display the alert box. In this instance, the appended code would not be sent to the server as everything after the # character is not treated as part of the query by the browser but as a fragment. In this example the code is immediately executed and an alert of "xss" is displayed in the page. Unlike the more common types of cross site scripting (persistent and non-persistent) which the code is sent to the server and redisplayed to the user, this is executed directly in the users browser without server contact.

The outcome of DOM based cross site scripting flaws are as wide ranging as those seen in more well known forms of XSS, including cookie retrieval, further malicious script injection etc and should therefore be treated with the same severity as such.
 

== Black and Gray Box testing and example ==
Blackbox testing for DOM-Based XSS 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 DOM Based XSS vulnerabilities:''' 
JavaScript applications differ significantly from other types of applications because they are often dynamically generated by the server, and to understand what code is being executed, the website being tested needs to be crawled to determine all the instances of JavaScript being executed and where user input is accepted. Many websites rely on large libraries of functions, which often stretch into the hundreds of thousands of lines of code and have not been developed in-house. In these cases, top-down testing often becomes the only really viable option, since many bottom level functions are never used, and analyzing them to determine which are sinks will use up more time than is often availiable. The same can also be said for top-down testing if the inputs or lack thereof is not identified to begin with.

User input comes in two main forms:

* Input written to the page by the server in a way that does not allow direct XSS
* Input obtained from client-side JavaScript objects

Here are two examples of how the server may insert data into JavaScript:
<pre>
var data = "<escaped data from the server>";

var result = someFunction("<escaped data from the server>");

And here are two examples of input from client-side JavaScript objects:

var data = window.location;

var result = someFunction(window.referer);
</pre>
While there is little difference to the JavaScript code in how they are retrieved, it is important to note that when input is received via the server, the server can apply any permutations to the data that it desires, whereas the permutations performed by JavaScript objects is fairly well understood and documented, and so if someFunction in the above example were a sink, then the exploitability of the former would depend on the filtering done by the server, whereas the latter would depend on the encoding done by the browser on the window.referer object.

Additionally, JavaScript is very often executed outside of <script> blocks, as evidenced by the many vectors which have led to XSS filter bypasses in the past, and so, when crawling the application, it is important to note the use of script in places such as event handlers and CSS blocks with expression attributes. Also, note that any off-site CSS or script objects will need to be assessed to determine what code is being executed.

Automated testing has only very limited success at identifying and validating DOM based XSS as they usually identify XSS by sending a specific payload and attempt to observe it in the server response. This may work fine for the simple example provided below, where the message parameter is reflected back to the user:
<pre>
<script>
var pos=document.URL.indexOf("message=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</script>
</pre>

but may not be detected in the following contrived case:
<pre>
<script>
var navAgt = navigator.userAgent;

if (navAgt.indexOf("MSIE")!=-1) {
document.write("You are using IE as a browser and visiting site: " + document.location.href + ".");
}
else
{
document.write("You are using an unknown browser.");
}
</script>
</pre>
For this reason, automated testing will not detect areas that may be susceptible to DOM based XSS unless the testing tool can perform addition analysis of the client side code.

Manual testing should therefore be undertaken and can be done by examining areas in the code where parameters are referred to that may be useful to an attacker.
Examples of such areas include places where code is dynamically written to the page and elsewhere where the DOM is modified or even where scripts are directly executed. Further examples
are described in the excellent DOM XSS article by Amit Klein, referenced at the end of this section.

 

== References ==
'''Whitepapers''' 
* Document Object Model (DOM) - http://en.wikipedia.org/wiki/Document_Object_Model
* DOM Based Cross Site Scripting or XSS of the Third Kind - Amit Klein http://www.webappsec.org/projects/articles/071105.shtml

Testing for DOM-based Cross site scripting (OTG-CLIENT-001)

2008-11-02T16:38:39Z

Mr fusion: /* Brief Summary */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
DOM-based Cross-Site Scripting is the de-facto name for XSS bugs which are the result of active content on a page, typically JavaScript, obtaining user input and then doing something unsafe with it to lead to execution of injected code. This document will only discuss JavaScript bugs which lead to XSS.

The DOM, or Document Object Model is the structural format that may be used to represent documents in the browser. The DOM enables dynamic scripts such as Javascript to reference components of the document such as a form field or a session cookie. The DOM is also used by the browser for security - for example to limit scripts on different domains obtaining session cookies for other domains. A DOM-based cross site scripting vulnerability may occur when active content, such as a javascript function, is modified by a specially crafted request such that a DOM element that can be controlled by an attacker.

There have been very few papers published on this topic and, as such, very little standardization of its meaning and formalized testing exists.
 

== Description of the Issue ==
 
Not all XSS bugs require the attacker to control the content returned from the server, but can rather abuse poor JavaScript coding practices to achieve the same results. The results are the same as a typical XSS bug, only the means of delivery is different.

In comparison to other cross site scripting vulnerabilities (reflected and stored XSS), where an unsanitized parameter is passed by the server, returned to the user and executed in the contect of the users browser, a DOM based cross site scripting vulnerability controls the flow of the code by using elements of the Document Object Model (DOM) along with code crafted by the attacker to change the flow.

Due to their nature, DOM based XSS vulnerabilities can be executed in many instances without the server being able to determine what is actually being executed. This may result in many of the general XSS filtering and detection rules impotent against such attacks.

The first hypothetical example uses the following client side code:

<script>
document.write("Site is at: " + document.location.href + ".");
</script>

An attacker may append #<script>alert('xss')</script> to the affect page URL which would, when executed display the alert box. In this instance, the appended code would not be sent to the server
as everything after the # character is not treated as part of the query by the browser but yet as a fragment. In this example the code is immediately executed and an alert of "xss" is displayed in the page. Unlike the more common types of cross site scripting (persistent and non-persistent) which the code is sent to the server and redisplayed to the user, this is immediately executed in the users browser.

The outcome of DOM based cross site scripting flaws are as wide ranging as those seen in more well known forms of XSS, including cookie retrieval, further malicious script injection etc and should therefore be treated with the same severity as such.
 

== Black and Gray Box testing and example ==
Blackbox testing for DOM-Based XSS 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 DOM Based XSS vulnerabilities:''' 
JavaScript applications differ significantly from other types of applications because they are often dynamically generated by the server, and to understand what code is being executed, the website being tested needs to be crawled to determine all the instances of JavaScript being executed and where user input is accepted. Many websites rely on large libraries of functions, which often stretch into the hundreds of thousands of lines of code and have not been developed in-house. In these cases, top-down testing often becomes the only really viable option, since many bottom level functions are never used, and analyzing them to determine which are sinks will use up more time than is often availiable. The same can also be said for top-down testing if the inputs or lack thereof is not identified to begin with.

User input comes in two main forms:

* Input written to the page by the server in a way that does not allow direct XSS
* Input obtained from client-side JavaScript objects

Here are two examples of how the server may insert data into JavaScript:
<pre>
var data = "<escaped data from the server>";

var result = someFunction("<escaped data from the server>");

And here are two examples of input from client-side JavaScript objects:

var data = window.location;

var result = someFunction(window.referer);
</pre>
While there is little difference to the JavaScript code in how they are retrieved, it is important to note that when input is received via the server, the server can apply any permutations to the data that it desires, whereas the permutations performed by JavaScript objects is fairly well understood and documented, and so if someFunction in the above example were a sink, then the exploitability of the former would depend on the filtering done by the server, whereas the latter would depend on the encoding done by the browser on the window.referer object.

Additionally, JavaScript is very often executed outside of <script> blocks, as evidenced by the many vectors which have led to XSS filter bypasses in the past, and so, when crawling the application, it is important to note the use of script in places such as event handlers and CSS blocks with expression attributes. Also, note that any off-site CSS or script objects will need to be assessed to determine what code is being executed.

Automated testing has only very limited success at identifying and validating DOM based XSS as they usually identify XSS by sending a specific payload and attempt to observe it in the server response. This may work fine for the simple example provided below, where the message parameter is reflected back to the user:
<pre>
<script>
var pos=document.URL.indexOf("message=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</script>
</pre>

but may not be detected in the following contrived case:
<pre>
<script>
var navAgt = navigator.userAgent;

if (navAgt.indexOf("MSIE")!=-1) {
document.write("You are using IE as a browser and visiting site: " + document.location.href + ".");
}
else
{
document.write("You are using an unknown browser.");
}
</script>
</pre>
For this reason, automated testing will not detect areas that may be susceptible to DOM based XSS unless the testing tool can perform addition analysis of the client side code.

Manual testing should therefore be undertaken and can be done by examining areas in the code where parameters are referred to that may be useful to an attacker.
Examples of such areas include places where code is dynamically written to the page and elsewhere where the DOM is modified or even where scripts are directly executed. Further examples
are described in the excellent DOM XSS article by Amit Klein, referenced at the end of this section.

 

== References ==
'''Whitepapers''' 
* Document Object Model (DOM) - http://en.wikipedia.org/wiki/Document_Object_Model
* DOM Based Cross Site Scripting or XSS of the Third Kind - Amit Klein http://www.webappsec.org/projects/articles/071105.shtml

Testing Guide Frontispiece

2008-10-05T17:03:39Z

Mr fusion: /* v3 Authors */

{{Template:OWASP Testing Guide v3}}

==Welcome to the OWASP Testing Guide 3.0==
“Open and collaborative knowledge: that’s the OWASP way.” 
-- [[User:Mmeucci|Matteo Meucci]] 

OWASP thanks the many authors, reviewers, and editors for their hard work in bringing this guide to where it is today. If you have any comments or suggestions on the Testing Guide, please e-mail the Testing Guide mail list:

http://lists.owasp.org/mailman/listinfo/owasp-testing

Or drop a mail to the project leader: [mailto:matteo.meucci@gmail.com Matteo Meucci]

==Version 3.0==

The OWASP Testing Guide Version 3 wants to improve version 2 and create new sections and controls. This new version has added: 
• Configuration Management and Authorization Testing sections and Encoded Injection Appendix; 
• 36 new articles (1 taken from the BSP); 
Version 3 improved 9 articles, for a total of 10 Testing categories and 66 controls.

==Copyright and License==

Copyright (c) 2008 The OWASP Foundation.

This document is released under the [http://creativecommons.org/licenses/by-sa/2.5/ Creative Commons 2.5 License]. Please read and understand the license and copyright conditions.

==Revision History ==

The Testing Guide v3 comes in September 2008. The Testing guide originated in 2003 with Dan Cuthbert as one of the original editors. It was handed over to Eoin Keary in 2005 and transformed into a wiki. Matteo Meucci has decided to take on the Testing guide and is now the lead of the OWASP Testing Guide Project.

; 15th September, 2008
: "OWASP Testing Guide", Version 3.0

; December 25, 2006
: "OWASP Testing Guide", Version 2.0

; July 14, 2004
: "OWASP Web Application Penetration Checklist", Version 1.1

; December 2004
: "The OWASP Testing Guide", Version 1.0

== Editors ==
'''Matteo Meucci''': OWASP Testing Guide Lead from 2007. 

'''Eoin Keary''': OWASP Testing Guide 2005-2007 Lead. 

'''Daniel Cuthbert''': OWASP Testing Guide 2003-2005 Lead.

== v3 Authors ==

{| border="0"
| valign="top" |
* Anurag Agarwwal
* Daniele Bellucci
* Arian Coronel
* Stefano Di Paola
| valign="top" |
* Giorgio Fedon
* Adam Goodman
* Christian Heinrich
* Kevin Horvath
| valign="top" |
* Ginarico Ingrosso
* Roberto Suggi Liverani
* Kuza55
* Pavol Luptak
| valign="top" |
* Ferruh Mavituna
* Marco Mella
* Matteo Meucci
* Marco Morana
| valign="top" |
* Antonio Parata
* Cecil Su
* Harish Skanda Sureddy
* Mark Roxberry
| valign="top" |
* Andrew Van der Stock
|}

== v3 Reviewers ==

{| border="0"
| valign="top" |
* Marco Cova
* Kevin Fuller
| valign="top" |
* Matteo Meucci
* Nam Nguyen
|}

== v2 Authors ==

{| border="0"
| valign="top" |
* Vicente Aguilera
* Mauro Bregolin
* Tom Brennan
* Gary Burns
* Luca Carettoni
* Dan Cornell
* Mark Curphey
* Daniel Cuthbert
* Sebastien Deleersnyder
* Stephen DeVries
* Stefano Di Paola
| valign="top" |
* David Endler
* Giorgio Fedon
* Javier Fernández-Sanguino
* Glyn Geoghegan
* Stan Guzik
* Madhura Halasgikar
* Eoin Keary
* David Litchfield
* Andrea Lombardini
* Ralph M. Los
* Claudio Merloni
| valign="top" |
* Matteo Meucci
* Marco Morana
* Laura Nunez
* Gunter Ollmann
* Antonio Parata
* Yiannis Pavlosoglou
* Carlo Pelliccioni
* Harinath Pudipeddi
* Alberto Revelli
* Mark Roxberry
* Tom Ryan
| valign="top" |
* Anush Shetty
* Larry Shields
* Dafydd Studdard
* Andrew van der Stock
* Ariel Waissbein
* Jeff Williams
* Tushar Vartak
|}

== v2 Reviewers ==

{| border="0"
| valign="top" |
* Vicente Aguilera
* Marco Belotti
| valign="top" |
* Mauro Bregolin
* Marco Cova
| valign="top" |
* Daniel Cuthbert
* Paul Davies
| valign="top" |
* Stefano Di Paola
* Matteo G.P. Flora
| valign="top" |
* Simona Forti
* Darrell Groundy
| valign="top" |
* Eoin Keary
* James Kist
| valign="top" |
* Katie McDowell
* Marco Mella
| valign="top" |
* Matteo Meucci
* Syed Mohamed A.
| valign="top" |
* Antonio Parata
* Alberto Revelli
| valign="top" |
* Mark Roxberry
* Dave Wichers
|}

==Trademarks==

* Java, Java Web Server, and JSP are registered trademarks of Sun Microsystems, Inc.
* Merriam-Webster is a trademark of Merriam-Webster, Inc.
* Microsoft is a registered trademark of Microsoft Corporation.
* Octave is a service mark of Carnegie Mellon University.
* VeriSign and Thawte are registered trademarks of VeriSign, Inc.
* Visa is a registered trademark of VISA USA.
* OWASP is a registered trademark of the OWASP Foundation

All other products and company names may be trademarks of their respective owners. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark.

OWASP Testing Guide v3 Table of Contents

2008-08-25T01:16:22Z

Mr fusion: /* 4. (M.Meucci) Web Application Penetration Testing */

__NOTOC__

This is the draft of table of content of the New Testing Guide.
You can download the stable version [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_pdf.zip here]

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

Testing Guide v3 (draft)
Updated: 24th August 2008
(new)--> new articles, (toimp)--> needs to improve or to review, (xxx%) --> current state of the article

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

==[[Testing Guide Foreword|(toimp)Foreword by OWASP Chair]]==

==[[Testing Guide Frontispiece |(toimp: M.Meucci)1. Frontispiece]]==

'''[[Testing Guide Frontispiece|(toimp: M.Meucci)1.1 About the OWASP Testing Guide Project]]'''

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''

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

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

(new: M. Morana 90%) 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]

(new: M. Morana 100%) 2.4.1 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Tests_Integrated_in_Developers_and_Testers_Workflow Security tests integrated in developers and testers workflows]

(new: M. Morana 100%) 2.4.2 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Developers.27_Security_Tests Developers' security tests: unit tests and component level tests]

(new: M. Morana 90%) 2.4.3 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_Testers.27_Security_Tests Functional testers' security tests: integrated system tests, tests in UAT, and production environment]

(new: M. Morana 100%) 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. (M.Meucci) Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']]

[[Testing Checklist| (new: M.Meucci - 100% ) 4.1.1 Testing Checklist]]

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

[[Testing: Spiders Robots and Crawlers|(new:C.Heinrich - 0%)4.2.1 Spiders, Robots and Crawlers]]

[[Testing: Search engine discovery|(new:C.Heinrich - 0%)4.2.2 Search Engine Discovery/Reconnaissance]]

[[Testing: Identify application entry points| (new: K.Horvath - 100%) 4.2.3 Identify application entry points]]

[[Testing for Web Application Fingerprint|4.2.4 Testing for Web Application Fingerprint]]

[[Testing for Application Discovery|4.2.5 Application Discovery]]

[[Testing for Error Code|4.2.6 Analysis of Error Codes]]

[[Testing for configuration management|''' (new) 4.3 Configuration Management Testing''']]

[[Testing for SSL-TLS| 4.3.1 SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity]] 

[[Testing for DB Listener|4.3.2 DB Listener Testing]]

[[Testing for infrastructure configuration management| (new) 4.3.3 Infrastructure Configuration Management Testing]]

[[Testing for application configuration management|4.3.4 Application Configuration Management Testing]]

[[Testing for file extensions handling|4.3.5 Testing for File Extensions Handling]]

[[Testing for old_file|4.3.6 Old, Backup and Unreferenced Files]]

[[Testing for Admin Interfaces|(imp: A. Goodman - 100%) 4.3.7 Infrastructure and Application Admin Interfaces]]

[[Testing for HTTP Methods and XST| (imp: A. van der Stock - 100%)4.3.8 Testing for HTTP Methods and XST]]

[[Testing for business logic|'''(K.Horvath - 100%) 4.4 Business Logic Testing''']]

[[Testing for authentication|'''(M.Meucci - 100%) 4.5 Authentication Testing''']]

[[Testing for credentials transport|(new: G.Ingrosso - 100%) 4.5.1 Credentials transport over an encrypted channel]]

[[Testing for user enumeration|(new: M.Meucci, M.Mella - 90%) 4.5.2 Testing for user enumeration]]

[[Testing for Default or Guessable User Account|(K.Horvath - 100% - adam updated) 4.5.3 Testing for Guessable (Dictionary) User Account]]

[[Testing for Brute Force|4.5.4 Brute Force Testing]]

[[Testing for Bypassing Authentication Schema|4.5.5 Testing for bypassing authentication schema]]

[[Testing for Vulnerable Remember Password and Pwd Reset|4.5.6 Testing for vulnerable remember
password and pwd reset]]

[[Testing for Logout and Browser Cache Management|4.5.7 Testing for Logout and Browser Cache Management Testing]]

[[Testing for Captcha|(new: P.Luptak - 100% ) 4.5.8 Testing for CAPTCHA]]

[[Testing Multiple Factors Authentication| (new: G.Fedon) 4.5.9 Testing Multiple Factors Authentication]]

[[Testing for Race Conditions| (new: A. Goodman - 100%) 4.5.10 Testing for Race Conditions]]

[[Testing for Authorization|'''(new: M.Meucci - 100%) 4.6 Authorization testing''']]

[[Testing for Path Traversal|(new) 4.6.1 Testing for path traversal]]

[[Testing for Bypassing Authorization Schema|(new: M.Meucci - 100%)4.6.2 Testing for bypassing authorization schema]]

[[Testing for Privilege escalation|(new: Cecil Su, M.Meucci - 100%)4.6.3 Testing for Privilege Escalation]]

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

[[Testing for Session_Management_Schema|(new: M.Meucci - 100%) 4.7.1 Testing for Session Management Schema]]

[[Testing for cookies attributes| (new: K.Horvath - 100%) 4.7.2 Testing for Cookies attributes]]

[[Testing for Session Fixation| (M.Meucci - 100% (updated by adam)) 4.7.3 Testing for Session Fixation]]

[[Testing for Exposed Session Variables|4.7.4 Testing for Exposed Session Variables ]]

[[Testing for CSRF|4.7.5 Testing for CSRF]]

[[Testing for HTTP Exploit|4.7.6 Testing for HTTP Exploit ]]

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

[[Testing for Reflected Cross site scripting|(new: A. Coronel -100%)4.8.1 Testing for Reflected Cross Site Scripting]]

[[Testing for Stored Cross site scripting|(new: R. Suggi Liverani - 100%)4.8.2 Testing for Stored Cross Site Scripting]]

[[Testing for DOM-based Cross site scripting|(new: A.Agarwwal, Kuza55 - 80%) 4.8.3 Testing for DOM based Cross Site Scripting]]

[[Testing for Cross site flashing|(new: A.Agarwwal, S.Di Paola - 0%)4.8.4 Testing for Cross Site Flashing]]

[[Testing for SQL Injection| 4.8.5 Testing for SQL Injection ]]

[[Testing for Oracle|4.8.5.1 Oracle Testing ]]

[[Testing for MySQL|4.8.5.2 MySQL Testing ]]

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

[[Testing for MS Access|(new:A.Parata - 90%) 4.8.5.4 MS Access Testing]]

[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.5.5 (new: D.Bellucci 100% from OWASP BSP) Testing PostgreSQL]]

[[Testing for LDAP Injection|4.8.6 Testing for LDAP Injection]]

[[Testing for ORM Injection|4.8.7 Testing for ORM Injection]]

[[Testing for XML Injection|4.8.8 Testing for XML Injection]]

[[Testing for SSI Injection|4.8.9 Testing for SSI Injection]]

[[Testing for XPath Injection|4.8.10 Testing for XPath Injection]]

[[Testing for IMAP/SMTP Injection|4.8.11 IMAP/SMTP Injection]]

[[Testing for Code Injection|4.8.12 Testing for Code Injection]]

[[Testing for Command Injection|4.8.13 Testing for Command Injection]]

[[Testing for Buffer Overflow|4.8.14 Testing for Buffer overflow]]

[[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|4.8.15 Testing for incubated vulnerabilities]]

[[Testing for Denial of Service|'''4.9 Testing for Denial of Service''']]

[[Testing for SQL Wildcard Attacks|(new: F.Mavituna - 100%) 4.9.1 Testing for SQL Wildcard Attacks]]

[[Testing for DoS Locking Customer Accounts|4.9.2 Testing for DoS Locking Customer Accounts]]

[[Testing for DoS Buffer Overflows|4.9.3 Testing for DoS Buffer Overflows]]

[[Testing for DoS User Specified Object Allocation|4.9.4 Testing for DoS User Specified Object Allocation]]

[[Testing for User Input as a Loop Counter|4.9.5 Testing for User Input as a Loop Counter]]

[[Testing for Writing User Provided Data to Disk|4.9.6 Testing for Writing User Provided Data to Disk]]

[[Testing for DoS Failure to Release Resources|4.9.7 Testing for DoS Failure to Release Resources]]

[[Testing for Storing too Much Data in Session|4.9.8 Testing for Storing too Much Data in Session]]

[[Testing for Web Services|(toimp: M.Meucci -100%) '''4.10 Web Services Testing''']]

[[Testing: WS Information Gathering|(new: M.Meucci -100%) 4.10.1 WS Information Gathering]]

[[Testing WSDL|(new: M.Meucci -100%) 4.10.2 Testing WSDL]]

[[Testing for XML Structural|(toimp: M.Meucci -100%)4.10.3 XML Structural Testing ]]

[[Testing for XML Content-Level|4.10.4 XML Content-level Testing ]]

[[Testing for WS HTTP GET parameters/REST attacks|4.10.5 HTTP GET parameters/REST Testing ]]

[[Testing for Naughty SOAP Attachments|4.10.6 Naughty SOAP attachments ]]

[[Testing for WS Replay|4.10.7 Replay Testing ]]

[[Testing_for_AJAX:_introduction|'''4.11 AJAX Testing''']]

[[Testing for AJAX Vulnerabilities|4.11.1 AJAX Vulnerabilities]]

[[Testing for AJAX|4.11.2 How to test AJAX]]

==[[Writing Reports: value the real risk |(toimp: Mat)5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]]

[[How to write the report of the testing |5.2 How to write the report of the testing]]

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

* Black Box Testing Tools
* Source Code Analyzers
* Other Tools

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers
* Books
* Useful Websites

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

* Fuzz Categories
** Recursive fuzzing
** Replasive fuzzing
* Cross Site Scripting (XSS)
* Buffer Overflows and Format String Errors
** Buffer Overflows (BFO)
** Format String Errors (FSE)
** Integer Overflows (INT)
* SQL Injection
** Passive SQL Injection (SQP)
** Active SQL Injection (SQI)
* LDAP Injection
* XPATH Injection

==[[OWASP Testing Guide Appendix D: Encoded Injection | (new: Harish S.)Appendix D: Encoded Injection]]==

----

[[Category:OWASP Testing Project]]

Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

2008-08-25T01:14:56Z

Mr fusion: /* Gray Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.
 

== Description of the Issue ==
 
An application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. Such changes may include:

- user account provisioning 
- Site design and layout 
- data manipultion 
- configuration changes 

In many instances, such interfaces are usually implemented with little thought of how to separate them from the normal users of the site. Testing is aimed at discovering these administrator interfaces and accessing functionality intended for the privileged users.
 

== Black Box testing and example ==
The following describes vectors that may be used to test for the presence of administrative interfaces. These techniques may also be used for testing for related issues including privilege escalation and are described elsewhere in this guide in greater detail: 

* Directory and file Enumeration - An administrative interface may be present but not visibly available to the tester. Attempting to guess the path of the administrative interface may be as simple as requesting:
/admin or /administrator etc.. 
A tester may have to also identify the filename of the administration page. Forcible browsing to the identified page may provide access to the interface.

* Comments and links in Source - Many sites use common code that is loaded for all site users. By examining all source sent to the client, links to administrator functionality may be discovered and should be investigated.

* Reviewing Server and Application Documentation - If the application server or application is deployed in its default configuration it may be possible to access the administration interface using information described in configuration or help documentation. Default password lists should be consulted if an administrative interface is found and credentials are required.

* Alternative Server Port - Administration interfaces may be seen on a different port on the host than the main application. For example, Apache Tomcat's Administration interface can often be seen on port 8080.

* Parameter Tampering - A GET or POST parameter or a cookie variable may be required to enable the administrator functionality. Clues to this
include the presence of hidden fields such as:

<input type="hidden" name="admin" value="no"> or in a cookie: Cookie: session_cookie; useradmin=0
 
Once an administrative interface has been discovered, a combination of the above techniques may be used to attempt to bypass authentication. If this fails, the
tester may wish to attempt a brute force attack. In such an instance the tester should be aware of the potential for administrative account lockout if such functionality is present.

== Gray Box testing and example ==
A more detailed examination of the server and application components should be undertaken to ensure hardening (i.e. administrator pages are not accessible to everyone through the use of IP filtering or other controls), and where applicable, verification that all components do not use default credentials or configurations.
 
Source code should be reviewed to ensure that the authorization and authentication model ensures clear separation of duties between normal users and site administrators. User interface functions shared between normal and administrator users should be reviewed to ensure clear separation between the drawing of such components and information leakage from such shared functionality.
 

== References ==
* Default Password list: http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php

OWASP Testing Guide v3 Table of Contents

2008-08-25T01:10:03Z

Mr fusion: /* 4. (M.Meucci) Web Application Penetration Testing */

__NOTOC__

This is the draft of table of content of the New Testing Guide.
You can download the stable version [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_pdf.zip here]

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

Testing Guide v3 (draft)
Updated: 24th August 2008
(new)--> new articles, (toimp)--> needs to improve or to review, (xxx%) --> current state of the article

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

==[[Testing Guide Foreword|(toimp)Foreword by OWASP Chair]]==

==[[Testing Guide Frontispiece |(toimp: M.Meucci)1. Frontispiece]]==

'''[[Testing Guide Frontispiece|(toimp: M.Meucci)1.1 About the OWASP Testing Guide Project]]'''

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''

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

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

(new: M. Morana 90%) 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]

(new: M. Morana 100%) 2.4.1 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Tests_Integrated_in_Developers_and_Testers_Workflow Security tests integrated in developers and testers workflows]

(new: M. Morana 100%) 2.4.2 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Developers.27_Security_Tests Developers' security tests: unit tests and component level tests]

(new: M. Morana 90%) 2.4.3 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_Testers.27_Security_Tests Functional testers' security tests: integrated system tests, tests in UAT, and production environment]

(new: M. Morana 100%) 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. (M.Meucci) Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']]

[[Testing Checklist| (new: M.Meucci - 100% ) 4.1.1 Testing Checklist]]

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

[[Testing: Spiders Robots and Crawlers|(new:C.Heinrich - 0%)4.2.1 Spiders, Robots and Crawlers]]

[[Testing: Search engine discovery|(new:C.Heinrich - 0%)4.2.2 Search Engine Discovery/Reconnaissance]]

[[Testing: Identify application entry points| (new: K.Horvath - 100%) 4.2.3 Identify application entry points]]

[[Testing for Web Application Fingerprint|4.2.4 Testing for Web Application Fingerprint]]

[[Testing for Application Discovery|4.2.5 Application Discovery]]

[[Testing for Error Code|4.2.6 Analysis of Error Codes]]

[[Testing for configuration management|''' (new) 4.3 Configuration Management Testing''']]

[[Testing for SSL-TLS| 4.3.1 SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity]] 

[[Testing for DB Listener|4.3.2 DB Listener Testing]]

[[Testing for infrastructure configuration management| (new) 4.3.3 Infrastructure Configuration Management Testing]]

[[Testing for application configuration management|4.3.4 Application Configuration Management Testing]]

[[Testing for file extensions handling|4.3.5 Testing for File Extensions Handling]]

[[Testing for old_file|4.3.6 Old, Backup and Unreferenced Files]]

[[Testing for Admin Interfaces|(A. Goodman - 90%) 4.3.7 Infrastructure and Application Admin Interfaces]]

[[Testing for HTTP Methods and XST| (imp: A. van der Stock - 100%)4.3.8 Testing for HTTP Methods and XST]]

[[Testing for business logic|'''(K.Horvath - 100%) 4.4 Business Logic Testing''']]

[[Testing for authentication|'''(M.Meucci - 100%) 4.5 Authentication Testing''']]

[[Testing for credentials transport|(new: G.Ingrosso - 100%) 4.5.1 Credentials transport over an encrypted channel]]

[[Testing for user enumeration|(new: M.Meucci, M.Mella - 90%) 4.5.2 Testing for user enumeration]]

[[Testing for Default or Guessable User Account|(K.Horvath - 100% - adam updated) 4.5.3 Testing for Guessable (Dictionary) User Account]]

[[Testing for Brute Force|4.5.4 Brute Force Testing]]

[[Testing for Bypassing Authentication Schema|4.5.5 Testing for bypassing authentication schema]]

[[Testing for Vulnerable Remember Password and Pwd Reset|4.5.6 Testing for vulnerable remember
password and pwd reset]]

[[Testing for Logout and Browser Cache Management|4.5.7 Testing for Logout and Browser Cache Management Testing]]

[[Testing for Captcha|(new: P.Luptak - 100% ) 4.5.8 Testing for CAPTCHA]]

[[Testing Multiple Factors Authentication| (new: G.Fedon) 4.5.9 Testing Multiple Factors Authentication]]

[[Testing for Race Conditions| (new: A. Goodman - 100%) 4.5.10 Testing for Race Conditions]]

[[Testing for Authorization|'''(new: M.Meucci - 100%) 4.6 Authorization testing''']]

[[Testing for Path Traversal|(new) 4.6.1 Testing for path traversal]]

[[Testing for Bypassing Authorization Schema|(new: M.Meucci - 100%)4.6.2 Testing for bypassing authorization schema]]

[[Testing for Privilege escalation|(new: Cecil Su, M.Meucci - 100%)4.6.3 Testing for Privilege Escalation]]

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

[[Testing for Session_Management_Schema|(new: M.Meucci - 100%) 4.7.1 Testing for Session Management Schema]]

[[Testing for cookies attributes| (new: K.Horvath - 100%) 4.7.2 Testing for Cookies attributes]]

[[Testing for Session Fixation| (M.Meucci - 100% (updated by adam)) 4.7.3 Testing for Session Fixation]]

[[Testing for Exposed Session Variables|4.7.4 Testing for Exposed Session Variables ]]

[[Testing for CSRF|4.7.5 Testing for CSRF]]

[[Testing for HTTP Exploit|4.7.6 Testing for HTTP Exploit ]]

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

[[Testing for Reflected Cross site scripting|(new: A. Coronel -100%)4.8.1 Testing for Reflected Cross Site Scripting]]

[[Testing for Stored Cross site scripting|(new: R. Suggi Liverani - 100%)4.8.2 Testing for Stored Cross Site Scripting]]

[[Testing for DOM-based Cross site scripting|(new: A.Agarwwal, Kuza55 - 80%) 4.8.3 Testing for DOM based Cross Site Scripting]]

[[Testing for Cross site flashing|(new: A.Agarwwal, S.Di Paola - 0%)4.8.4 Testing for Cross Site Flashing]]

[[Testing for SQL Injection| 4.8.5 Testing for SQL Injection ]]

[[Testing for Oracle|4.8.5.1 Oracle Testing ]]

[[Testing for MySQL|4.8.5.2 MySQL Testing ]]

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

[[Testing for MS Access|(new:A.Parata - 90%) 4.8.5.4 MS Access Testing]]

[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.5.5 (new: D.Bellucci 100% from OWASP BSP) Testing PostgreSQL]]

[[Testing for LDAP Injection|4.8.6 Testing for LDAP Injection]]

[[Testing for ORM Injection|4.8.7 Testing for ORM Injection]]

[[Testing for XML Injection|4.8.8 Testing for XML Injection]]

[[Testing for SSI Injection|4.8.9 Testing for SSI Injection]]

[[Testing for XPath Injection|4.8.10 Testing for XPath Injection]]

[[Testing for IMAP/SMTP Injection|4.8.11 IMAP/SMTP Injection]]

[[Testing for Code Injection|4.8.12 Testing for Code Injection]]

[[Testing for Command Injection|4.8.13 Testing for Command Injection]]

[[Testing for Buffer Overflow|4.8.14 Testing for Buffer overflow]]

[[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|4.8.15 Testing for incubated vulnerabilities]]

[[Testing for Denial of Service|'''4.9 Testing for Denial of Service''']]

[[Testing for SQL Wildcard Attacks|(new: F.Mavituna - 100%) 4.9.1 Testing for SQL Wildcard Attacks]]

[[Testing for DoS Locking Customer Accounts|4.9.2 Testing for DoS Locking Customer Accounts]]

[[Testing for DoS Buffer Overflows|4.9.3 Testing for DoS Buffer Overflows]]

[[Testing for DoS User Specified Object Allocation|4.9.4 Testing for DoS User Specified Object Allocation]]

[[Testing for User Input as a Loop Counter|4.9.5 Testing for User Input as a Loop Counter]]

[[Testing for Writing User Provided Data to Disk|4.9.6 Testing for Writing User Provided Data to Disk]]

[[Testing for DoS Failure to Release Resources|4.9.7 Testing for DoS Failure to Release Resources]]

[[Testing for Storing too Much Data in Session|4.9.8 Testing for Storing too Much Data in Session]]

[[Testing for Web Services|(toimp: M.Meucci -100%) '''4.10 Web Services Testing''']]

[[Testing: WS Information Gathering|(new: M.Meucci -100%) 4.10.1 WS Information Gathering]]

[[Testing WSDL|(new: M.Meucci -100%) 4.10.2 Testing WSDL]]

[[Testing for XML Structural|(toimp: M.Meucci -100%)4.10.3 XML Structural Testing ]]

[[Testing for XML Content-Level|4.10.4 XML Content-level Testing ]]

[[Testing for WS HTTP GET parameters/REST attacks|4.10.5 HTTP GET parameters/REST Testing ]]

[[Testing for Naughty SOAP Attachments|4.10.6 Naughty SOAP attachments ]]

[[Testing for WS Replay|4.10.7 Replay Testing ]]

[[Testing_for_AJAX:_introduction|'''4.11 AJAX Testing''']]

[[Testing for AJAX Vulnerabilities|4.11.1 AJAX Vulnerabilities]]

[[Testing for AJAX|4.11.2 How to test AJAX]]

==[[Writing Reports: value the real risk |(toimp: Mat)5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]]

[[How to write the report of the testing |5.2 How to write the report of the testing]]

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

* Black Box Testing Tools
* Source Code Analyzers
* Other Tools

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers
* Books
* Useful Websites

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

* Fuzz Categories
** Recursive fuzzing
** Replasive fuzzing
* Cross Site Scripting (XSS)
* Buffer Overflows and Format String Errors
** Buffer Overflows (BFO)
** Format String Errors (FSE)
** Integer Overflows (INT)
* SQL Injection
** Passive SQL Injection (SQP)
** Active SQL Injection (SQI)
* LDAP Injection
* XPATH Injection

==[[OWASP Testing Guide Appendix D: Encoded Injection | (new: Harish S.)Appendix D: Encoded Injection]]==

----

[[Category:OWASP Testing Project]]

Testing for Session Fixation (OTG-SESS-003)

2008-08-25T01:09:19Z

Mr fusion: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
When an application does not renew the cookie after a successful user authentication, it could be possible to find a session fixation vulnerability and force a user to utilize a cookie known by the attacker. In that case an attacker could steal the user session (session hijacking).
 
== Description of the Issue ==
 
Session fixation vulnerabilities occur when: 
* A web application authenticates a user without first invalidating the existing session ID, thereby continuing to use the session ID already associated with the user.
* An attacker is able to force a known session ID on a user so that, once the user authenticates, the attacker has access to the authenticated session.
In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using the same session identifier, giving the attacker access to the user's account through the active session.
 
Furthermore, the issue described above is problematic for sites which issue a session identifier over HTTP and then redirect the user to a HTTPS login form. If the session identifier is not reissued upon authentication, the identifier may be eavesdropped and may be used by an attacker to hijack the session.
 

== Black Box testing and example ==
'''Testing for Session Fixation vulnerabilities:''' 
The first step is to make a request to the site to be tested (example www.example.com). If we request the following:
GET www.example.com
We will obtain the following answer:
<pre>
HTTP/1.1 200 OK
Date: Wed, 14 Aug 2008 08:45:11 GMT
Server: IBM_HTTP_Server
Set-Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1; Path=/; secure
Cache-Control: no-cache="set-cookie,set-cookie2"
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html;charset=Cp1254
Content-Language: en-US
</pre>
We observe that the application sets a new session identifier JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 for the client. 
Next, if we successfully authenticate to the application with the following POST HTTPS:
<pre>
POST https://www.example.com/authentication.php HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com
Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1
Content-Type: application/x-www-form-urlencoded
Content-length: 57

Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in
</pre>
We observe the following response from the server:
<pre>
HTTP/1.1 200 OK
Date: Thu, 14 Aug 2008 14:52:58 GMT
Server: Apache/2.2.2 (Fedora)
X-Powered-By: PHP/5.1.6
Content-language: en
Cache-Control: private, must-revalidate, max-age=0
X-Content-Encoding: gzip
Content-length: 4090
Connection: close
Content-Type: text/html; charset=UTF-8
...
HTML data
...
</pre>
As no new cookie has been issued upon a successful authentication we know that it is possible to perform session hijacking.
 
'''Result Expected:''' 
We can send a valid session identifier to a user (possibly using a social engineering trick), wait for them to authenticate, and subsequently verify that privileges have been assigned to this cookie. 

== Gray Box testing and example ==
Talk with developers and understand if they have implemented a session token renew after a user successful authentication. 
'''Result Expected:''' 
The application should always first invalidating the existing session ID before authenticating a user and if the authentication is successful, provide another sessionID.
 
== References ==
'''Whitepapers''' 
* http://www.owasp.org/index.php/Session_Fixation
* Chris Shiflett: http://shiflett.org/articles/session-fixation
 
'''Tools''' 
* OWASP WebScarab: [[OWASP_WebScarab_Project]]

Testing for Session Fixation (OTG-SESS-003)

2008-08-25T00:58:07Z

Mr fusion: /* Description of the Issue */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
When an application does not renew the cookie after a successful user authentication, it could be possible to find a session fixation vulnerability and force a user to utilize a cookie known by the attacker. In that case an attacker could steal the user session (session hijacking).
 
== Description of the Issue ==
 
Session fixation vulnerabilities occur when: 
* A web application authenticates a user without first invalidating the existing session ID, thereby continuing to use the session ID already associated with the user.
* An attacker is able to force a known session ID on a user so that, once the user authenticates, the attacker has access to the authenticated session.
In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using the same session identifier, giving the attacker access to the user's account through the active session.
 
Furthermore, the issue described above is problematic for sites which issue a session identifier over HTTP and then redirect the user to a HTTPS login form. If the session identifier is not reissued upon authentication, the identifier may be eavesdropped and may be used by an attacker to hijack the session.
 

== Black Box testing and example ==
'''Testing for Session Fixation vulnerabilities:''' 
The first step is to access to the domain to test, for example www.example.com. If we request the following:
GET www.example.com
We will obtain the following answer:
<pre>
HTTP/1.1 200 OK
Date: Wed, 14 Aug 2008 08:45:11 GMT
Server: IBM_HTTP_Server
Set-Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1; Path=/; secure
Cache-Control: no-cache="set-cookie,set-cookie2"
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html;charset=Cp1254
Content-Language: en-US
</pre>
We can notice that the application will set a new JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 on the client browser. 
Now, if we authenticate on the application, for example sending the following POST HTTPS:
<pre>
POST https://www.example.com/authentication.php HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com
Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1
Content-Type: application/x-www-form-urlencoded
Content-length: 57

Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in
</pre>
if we obtain an answer as the following:
<pre>
HTTP/1.1 200 OK
Date: Thu, 14 Aug 2008 14:52:58 GMT
Server: Apache/2.2.2 (Fedora)
X-Powered-By: PHP/5.1.6
Content-language: en
Cache-Control: private, must-revalidate, max-age=0
X-Content-Encoding: gzip
Content-length: 4090
Connection: close
Content-Type: text/html; charset=UTF-8
...
HTML data
...
</pre>
we can understand that the application does not renew the user cookie after a successful authentication.
 
'''Result Expected:''' 
Now we can try to inject a valid cookie to a user (using a social engineering trick) and verify that it is possible to hijack the user session.
 
== Gray Box testing and example ==
Talk with developers and understand if they have implemented a session token renew after a user successful authentication. 
'''Result Expected:''' 
The application should always first invalidating the existing session ID before authenticating a user and if the authentication is successful, provide another sessionID.
 
== References ==
'''Whitepapers''' 
* http://www.owasp.org/index.php/Session_Fixation
* Chris Shiflett: http://shiflett.org/articles/session-fixation
 
'''Tools''' 
* OWASP WebScarab: [[OWASP_WebScarab_Project]]

OWASP Testing Guide v3 Table of Contents

2008-08-24T23:21:16Z

Mr fusion: /* 4. (M.Meucci) Web Application Penetration Testing */

__NOTOC__

This is the draft of table of content of the New Testing Guide.
You can download the stable version [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_pdf.zip here]

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

Testing Guide v3 (draft)
Updated: 24th August 2008
(new)--> new articles, (toimp)--> needs to improve or to review, (xxx%) --> current state of the article

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

==[[Testing Guide Foreword|(toimp)Foreword by OWASP Chair]]==

==[[Testing Guide Frontispiece |(toimp: M.Meucci)1. Frontispiece]]==

'''[[Testing Guide Frontispiece|(toimp: M.Meucci)1.1 About the OWASP Testing Guide Project]]'''

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''

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

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

(new: M. Morana 90%) 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]

(new: M. Morana 100%) 2.4.1 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Tests_Integrated_in_Developers_and_Testers_Workflow Security tests integrated in developers and testers workflows]

(new: M. Morana 100%) 2.4.2 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Developers.27_Security_Tests Developers' security tests: unit tests and component level tests]

(new: M. Morana 90%) 2.4.3 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_Testers.27_Security_Tests Functional testers' security tests: integrated system tests, tests in UAT, and production environment]

(new: M. Morana 100%) 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. (M.Meucci) Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']]

[[Testing Checklist| (new: M.Meucci - 100% ) 4.1.1 Testing Checklist]]

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

[[Testing: Spiders Robots and Crawlers|(new:C.Heinrich - 0%)4.2.1 Spiders, Robots and Crawlers]]

[[Testing: Search engine discovery|(new:C.Heinrich - 0%)4.2.2 Search Engine Discovery/Reconnaissance]]

[[Testing: Identify application entry points| (new: K.Horvath - 100%) 4.2.3 Identify application entry points]]

[[Testing for Web Application Fingerprint|4.2.4 Testing for Web Application Fingerprint]]

[[Testing for Application Discovery|4.2.5 Application Discovery]]

[[Testing for Error Code|4.2.6 Analysis of Error Codes]]

[[Testing for configuration management|''' (new) 4.3 Configuration Management Testing''']]

[[Testing for SSL-TLS| 4.3.1 SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity]] 

[[Testing for DB Listener|4.3.2 DB Listener Testing]]

[[Testing for infrastructure configuration management| (new) 4.3.3 Infrastructure Configuration Management Testing]]

[[Testing for application configuration management|4.3.4 Application Configuration Management Testing]]

[[Testing for file extensions handling|4.3.5 Testing for File Extensions Handling]]

[[Testing for old_file|4.3.6 Old, Backup and Unreferenced Files]]

[[Testing for Admin Interfaces|(A. Goodman - 90%) 4.3.7 Infrastructure and Application Admin Interfaces]]

[[Testing for HTTP Methods and XST| (imp: A. van der Stock - 100%)4.3.8 Testing for HTTP Methods and XST]]

[[Testing for business logic|'''(K.Horvath - 100%) 4.4 Business Logic Testing''']]

[[Testing for authentication|'''(M.Meucci - 100%) 4.5 Authentication Testing''']]

[[Testing for credentials transport|(new: G.Ingrosso - 100%) 4.5.1 Credentials transport over an encrypted channel]]

[[Testing for user enumeration|(new: M.Meucci, M.Mella - 90%) 4.5.2 Testing for user enumeration]]

[[Testing for Default or Guessable User Account|(K.Horvath - 100% - adam updated) 4.5.3 Testing for Guessable (Dictionary) User Account]]

[[Testing for Brute Force|4.5.4 Brute Force Testing]]

[[Testing for Bypassing Authentication Schema|4.5.5 Testing for bypassing authentication schema]]

[[Testing for Vulnerable Remember Password and Pwd Reset|4.5.6 Testing for vulnerable remember
password and pwd reset]]

[[Testing for Logout and Browser Cache Management|4.5.7 Testing for Logout and Browser Cache Management Testing]]

[[Testing for Captcha|(new: P.Luptak - 100% ) 4.5.8 Testing for CAPTCHA]]

[[Testing Multiple Factors Authentication| (new: G.Fedon) 4.5.9 Testing Multiple Factors Authentication]]

[[Testing for Race Conditions| (new: A. Goodman - 100%) 4.5.10 Testing for Race Conditions]]

[[Testing for Authorization|'''(new: M.Meucci - 100%) 4.6 Authorization testing''']]

[[Testing for Path Traversal|(new) 4.6.1 Testing for path traversal]]

[[Testing for Bypassing Authorization Schema|(new: M.Meucci - 100%)4.6.2 Testing for bypassing authorization schema]]

[[Testing for Privilege escalation|(new: Cecil Su, M.Meucci - 100%)4.6.3 Testing for Privilege Escalation]]

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

[[Testing for Session_Management_Schema|(new: M.Meucci - 100%) 4.7.1 Testing for Session Management Schema]]

[[Testing for cookies attributes| (new: K.Horvath - 100%) 4.7.2 Testing for Cookies attributes]]

[[Testing for Session Fixation| (new: M.Meucci - 100%) 4.7.3 Testing for Session Fixation]]

[[Testing for Exposed Session Variables|4.7.4 Testing for Exposed Session Variables ]]

[[Testing for CSRF|4.7.5 Testing for CSRF]]

[[Testing for HTTP Exploit|4.7.6 Testing for HTTP Exploit ]]

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

[[Testing for Reflected Cross site scripting|(new: A. Coronel -100%)4.8.1 Testing for Reflected Cross Site Scripting]]

[[Testing for Stored Cross site scripting|(new: R. Suggi Liverani - 100%)4.8.2 Testing for Stored Cross Site Scripting]]

[[Testing for DOM-based Cross site scripting|(new: A.Agarwwal, Kuza55 - 80%) 4.8.3 Testing for DOM based Cross Site Scripting]]

[[Testing for Cross site flashing|(new: A.Agarwwal, S.Di Paola - 0%)4.8.4 Testing for Cross Site Flashing]]

[[Testing for SQL Injection| 4.8.5 Testing for SQL Injection ]]

[[Testing for Oracle|4.8.5.1 Oracle Testing ]]

[[Testing for MySQL|4.8.5.2 MySQL Testing ]]

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

[[Testing for MS Access|(new:A.Parata - 90%) 4.8.5.4 MS Access Testing]]

[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.5.5 (new: D.Bellucci 100% from OWASP BSP) Testing PostgreSQL]]

[[Testing for LDAP Injection|4.8.6 Testing for LDAP Injection]]

[[Testing for ORM Injection|4.8.7 Testing for ORM Injection]]

[[Testing for XML Injection|4.8.8 Testing for XML Injection]]

[[Testing for SSI Injection|4.8.9 Testing for SSI Injection]]

[[Testing for XPath Injection|4.8.10 Testing for XPath Injection]]

[[Testing for IMAP/SMTP Injection|4.8.11 IMAP/SMTP Injection]]

[[Testing for Code Injection|4.8.12 Testing for Code Injection]]

[[Testing for Command Injection|4.8.13 Testing for Command Injection]]

[[Testing for Buffer Overflow|4.8.14 Testing for Buffer overflow]]

[[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|4.8.15 Testing for incubated vulnerabilities]]

[[Testing for Denial of Service|'''4.9 Testing for Denial of Service''']]

[[Testing for SQL Wildcard Attacks|(new: F.Mavituna - 100%) 4.9.1 Testing for SQL Wildcard Attacks]]

[[Testing for DoS Locking Customer Accounts|4.9.2 Testing for DoS Locking Customer Accounts]]

[[Testing for DoS Buffer Overflows|4.9.3 Testing for DoS Buffer Overflows]]

[[Testing for DoS User Specified Object Allocation|4.9.4 Testing for DoS User Specified Object Allocation]]

[[Testing for User Input as a Loop Counter|4.9.5 Testing for User Input as a Loop Counter]]

[[Testing for Writing User Provided Data to Disk|4.9.6 Testing for Writing User Provided Data to Disk]]

[[Testing for DoS Failure to Release Resources|4.9.7 Testing for DoS Failure to Release Resources]]

[[Testing for Storing too Much Data in Session|4.9.8 Testing for Storing too Much Data in Session]]

[[Testing for Web Services|(toimp: M.Meucci -100%) '''4.10 Web Services Testing''']]

[[Testing: WS Information Gathering|(new: M.Meucci -100%) 4.10.1 WS Information Gathering]]

[[Testing WSDL|(new: M.Meucci -100%) 4.10.2 Testing WSDL]]

[[Testing for XML Structural|(toimp: M.Meucci -100%)4.10.3 XML Structural Testing ]]

[[Testing for XML Content-Level|4.10.4 XML Content-level Testing ]]

[[Testing for WS HTTP GET parameters/REST attacks|4.10.5 HTTP GET parameters/REST Testing ]]

[[Testing for Naughty SOAP Attachments|4.10.6 Naughty SOAP attachments ]]

[[Testing for WS Replay|4.10.7 Replay Testing ]]

[[Testing_for_AJAX:_introduction|'''4.11 AJAX Testing''']]

[[Testing for AJAX Vulnerabilities|4.11.1 AJAX Vulnerabilities]]

[[Testing for AJAX|4.11.2 How to test AJAX]]

==[[Writing Reports: value the real risk |(toimp: Mat)5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]]

[[How to write the report of the testing |5.2 How to write the report of the testing]]

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

* Black Box Testing Tools
* Source Code Analyzers
* Other Tools

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers
* Books
* Useful Websites

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

* Fuzz Categories
** Recursive fuzzing
** Replasive fuzzing
* Cross Site Scripting (XSS)
* Buffer Overflows and Format String Errors
** Buffer Overflows (BFO)
** Format String Errors (FSE)
** Integer Overflows (INT)
* SQL Injection
** Passive SQL Injection (SQP)
** Active SQL Injection (SQI)
* LDAP Injection
* XPATH Injection

==[[OWASP Testing Guide Appendix D: Encoded Injection | (new: Harish S.)Appendix D: Encoded Injection]]==

----

[[Category:OWASP Testing Project]]

Testing for Race Conditions (OWASP-AT-010)

2008-08-24T23:20:35Z

Mr fusion: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
A race condition is a flaw that produces an unexpected result when timing of actions impact other actions. An example may be seen on a multithreaded application where actions are being performed on the same data. Race conditions, by their very nature, are difficult to test for.

==Description of the Issue==
Race conditions may occur when a process is critically or unexpectedly dependent on the sequence or timings of other events.
In a web application environment, where multiple requests can be processed at a given time, developers may leave concurrency to be handled
by the framework, server or programming language.
The following simplified example illustrates a potential concurrency problem in a transactional web application and relates to a joint savings account in which both users (threads) are logged into the same account and attempting a transfer. 
 
Account A has 100 credits. 
Account B has 100 credits. 
 
Both User 1 and User 2 want to transfer 10 credits from Account A to Account B. If the transaction was correct the outcome should be: 
 
Account A has 80 credits. 
Account B has 120 credits. 
 
However, due to concurrency issues, the following result could be obtained: 
 
User 1 checks the value of Account A (=100 credits) 
User 2 checks the value of Account A (=100 credits) 
User 2 takes 10 credits from Account A (=90 credits) and put it in Account B (=110 credits) 
User 1 takes 10 credits from Account A (Still believed to contain 100 credits) (=90 credits) and puts it into Account B (=120 credits). 
 
Result:
Account A has 90 credits. 
Account B has 120 credits. 
 

Another example can be seen in OWASP's WebGoat project under the Thread Safety lesson and shows how a shopping cart can be manipulated to purchase items for less than their advertised price. This, as with the example above, is due to the data changing between the time of check and its time of use.

==Black Box testing and example==
Testing for race conditions is problematic due to their nature, and external influences on testing including server load, network latency etc will all play a part in the presence and detection of the condition. 
However, testing can be focused at specific transactional areas of the application, where time of read to time of use of specific data variables could be adversely affected by concurrency issues.
 
Black Box testing attempts to force a race condition may include the ability to make multiple simultaneous requests while observing the outcome for unexpected behavior.
 
Examples of such areas are illustrated in the paper "On Race Vulnerabilities in Web Applications", cited in the further reading section. The authors suggest that it may be possible in certain circumstances to:

* Create multiple user accounts with the same username.
* Bypass account lockouts against brute forcing.
 
Testers should be aware of the security implications of race conditions and their factors surrounding their difficulty of testing.

==Gray Box testing and example==

Code review may reveal likely areas of concern for concurrency issues. More information on reviewing code for concurrency issues can be seen at: 
http://www.owasp.org/index.php/Reviewing_Code_for_Race_Conditions

==References==

iSec Partners - Concurrency attacks in Web Applications http://isecpartners.com/files/iSEC%20Partners%20-%20Concurrency%20Attacks%20in%20Web%20Applications.pdf 
B. Sullivan and B. Hoffman - Premature Ajax-ulation and You https://www.blackhat.com/presentations/bh-usa-07/Sullivan_and_Hoffman/Whitepaper/bh-usa-07-sullivan_and_hoffman-WP.pdf 
Thread Safety Challenge in WebGoat - http://www.owasp.org/index.php/OWASP_WebGoat_Project 
R. Paleari, D. Marrone, D. Bruschi, M. Monga - On Race Vulnerabilities in Web Applications http://security.dico.unimi.it/~roberto/pubs/dimva08-web.pdf

Testing for Race Conditions (OWASP-AT-010)

2008-08-24T23:10:45Z

Mr fusion: /* References */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
A race condition is a flaw that produces an unexpected result when timing of actions impact other actions. An example may be seen on a multithreaded application where actions are being performed on the same data. Race conditions, by their very nature, are difficult to test for.

==Description of the Issue==
Race conditions may occur when a process is critically or unexpectedly dependent on the sequence or timings of other events.
In a web application environment, where multiple requests can be processed at a given time, developers may leave concurrency to be handled
by the framework, server or programming language.
The following simplified example illustrates a potential concurrency problem in a transactional web application and relates to a joint savings account in which both users (threads) are logged into the same account and attempting a transfer. 
 
Account A has 100 credits. 
Account B has 100 credits. 
 
Both User 1 and User 2 want to transfer 10 credits from Account A to Account B. If the transaction was correct the outcome should be: 
 
Account A has 80 credits. 
Account B has 120 credits. 
 
However, due to concurrency issues, the following result could be obtained: 
 
User 1 checks the value of Account A (=100 credits) 
User 2 checks the value of Account A (=100 credits) 
User 2 takes 10 credits from Account A (=90 credits) and put it in Account B (=110 credits) 
User 1 takes 10 credits from Account A (Still believed to contain 100 credits) (=90 credits) and puts it into Account B (=120 credits). 
 
Result:
Account A has 90 credits. 
Account B has 120 credits. 
 

Another example can be seen in OWASP's WebGoat project under the Thread Safety lesson and shows how a shopping cart can be manipulated to purchase items for less than their advertised price. This, as with the example above, is due to the data changing between the time of check and its time of use.

==Black Box testing and example==
Testing for race conditions is problematic due to their nature, and external influences on testing including server load, network latency etc will all play a part in the presence and detection of the condition. 
However, testing can be focused at specific transactional areas of the application, where time of read to time of use of specific data variables could be adversely affected by concurrency issues.
 
Black Box testing attempts to force a race condition may include the ability to make multiple simultaneous requests while observing the outcome for unexpected behavior.

==Gray Box testing and example==

Code review may reveal likely areas of concern for concurrency issues. More information on reviewing code for concurrency issues can be seen at: 
http://www.owasp.org/index.php/Reviewing_Code_for_Race_Conditions

==References==

iSec Partners - Concurrency attacks in Web Applications http://isecpartners.com/files/iSEC%20Partners%20-%20Concurrency%20Attacks%20in%20Web%20Applications.pdf 
B. Sullivan and B. Hoffman - Premature Ajax-ulation and You https://www.blackhat.com/presentations/bh-usa-07/Sullivan_and_Hoffman/Whitepaper/bh-usa-07-sullivan_and_hoffman-WP.pdf 
Thread Safety Challenge in WebGoat - http://www.owasp.org/index.php/OWASP_WebGoat_Project 
R. Paleari, D. Marrone, D. Bruschi, M. Monga - On Race Vulnerabilities in Web Applications http://security.dico.unimi.it/~roberto/pubs/dimva08-web.pdf

Testing for Race Conditions (OWASP-AT-010)

2008-08-24T23:10:35Z

Mr fusion: /* References */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
A race condition is a flaw that produces an unexpected result when timing of actions impact other actions. An example may be seen on a multithreaded application where actions are being performed on the same data. Race conditions, by their very nature, are difficult to test for.

==Description of the Issue==
Race conditions may occur when a process is critically or unexpectedly dependent on the sequence or timings of other events.
In a web application environment, where multiple requests can be processed at a given time, developers may leave concurrency to be handled
by the framework, server or programming language.
The following simplified example illustrates a potential concurrency problem in a transactional web application and relates to a joint savings account in which both users (threads) are logged into the same account and attempting a transfer. 
 
Account A has 100 credits. 
Account B has 100 credits. 
 
Both User 1 and User 2 want to transfer 10 credits from Account A to Account B. If the transaction was correct the outcome should be: 
 
Account A has 80 credits. 
Account B has 120 credits. 
 
However, due to concurrency issues, the following result could be obtained: 
 
User 1 checks the value of Account A (=100 credits) 
User 2 checks the value of Account A (=100 credits) 
User 2 takes 10 credits from Account A (=90 credits) and put it in Account B (=110 credits) 
User 1 takes 10 credits from Account A (Still believed to contain 100 credits) (=90 credits) and puts it into Account B (=120 credits). 
 
Result:
Account A has 90 credits. 
Account B has 120 credits. 
 

Another example can be seen in OWASP's WebGoat project under the Thread Safety lesson and shows how a shopping cart can be manipulated to purchase items for less than their advertised price. This, as with the example above, is due to the data changing between the time of check and its time of use.

==Black Box testing and example==
Testing for race conditions is problematic due to their nature, and external influences on testing including server load, network latency etc will all play a part in the presence and detection of the condition. 
However, testing can be focused at specific transactional areas of the application, where time of read to time of use of specific data variables could be adversely affected by concurrency issues.
 
Black Box testing attempts to force a race condition may include the ability to make multiple simultaneous requests while observing the outcome for unexpected behavior.

==Gray Box testing and example==

Code review may reveal likely areas of concern for concurrency issues. More information on reviewing code for concurrency issues can be seen at: 
http://www.owasp.org/index.php/Reviewing_Code_for_Race_Conditions

==References==

iSec Partners - Concurrency attacks in Web Applications http://isecpartners.com/files/iSEC%20Partners%20-%20Concurrency%20Attacks%20in%20Web%20Applications.pdf 
B. Sullivan and B. Hoffman - Premature Ajax-ulation and You https://www.blackhat.com/presentations/bh-usa-07/Sullivan_and_Hoffman/Whitepaper/bh-usa-07-sullivan_and_hoffman-WP.pdf 
Thread Safety Challenge in WebGoat - http://www.owasp.org/index.php/OWASP_WebGoat_Project
R. Paleari, D. Marrone, D. Bruschi, M. Monga - On Race Vulnerabilities in Web Applications http://security.dico.unimi.it/~roberto/pubs/dimva08-web.pdf

Testing for Race Conditions (OWASP-AT-010)

2008-08-24T23:06:36Z

Mr fusion: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
A race condition is a flaw that produces an unexpected result when timing of actions impact other actions. An example may be seen on a multithreaded application where actions are being performed on the same data. Race conditions, by their very nature, are difficult to test for.

==Description of the Issue==
Race conditions may occur when a process is critically or unexpectedly dependent on the sequence or timings of other events.
In a web application environment, where multiple requests can be processed at a given time, developers may leave concurrency to be handled
by the framework, server or programming language.
The following simplified example illustrates a potential concurrency problem in a transactional web application and relates to a joint savings account in which both users (threads) are logged into the same account and attempting a transfer. 
 
Account A has 100 credits. 
Account B has 100 credits. 
 
Both User 1 and User 2 want to transfer 10 credits from Account A to Account B. If the transaction was correct the outcome should be: 
 
Account A has 80 credits. 
Account B has 120 credits. 
 
However, due to concurrency issues, the following result could be obtained: 
 
User 1 checks the value of Account A (=100 credits) 
User 2 checks the value of Account A (=100 credits) 
User 2 takes 10 credits from Account A (=90 credits) and put it in Account B (=110 credits) 
User 1 takes 10 credits from Account A (Still believed to contain 100 credits) (=90 credits) and puts it into Account B (=120 credits). 
 
Result:
Account A has 90 credits. 
Account B has 120 credits. 
 

Another example can be seen in OWASP's WebGoat project under the Thread Safety lesson and shows how a shopping cart can be manipulated to purchase items for less than their advertised price. This, as with the example above, is due to the data changing between the time of check and its time of use.

==Black Box testing and example==
Testing for race conditions is problematic due to their nature, and external influences on testing including server load, network latency etc will all play a part in the presence and detection of the condition. 
However, testing can be focused at specific transactional areas of the application, where time of read to time of use of specific data variables could be adversely affected by concurrency issues.
 
Black Box testing attempts to force a race condition may include the ability to make multiple simultaneous requests while observing the outcome for unexpected behavior.

==Gray Box testing and example==

Code review may reveal likely areas of concern for concurrency issues. More information on reviewing code for concurrency issues can be seen at: 
http://www.owasp.org/index.php/Reviewing_Code_for_Race_Conditions

==References==

iSec Partners - Concurrency attacks in Web Applications http://isecpartners.com/files/iSEC%20Partners%20-%20Concurrency%20Attacks%20in%20Web%20Applications.pdf 
B. Sullivan and B. Hoffman - Premature Ajax-ulation and You https://www.blackhat.com/presentations/bh-usa-07/Sullivan_and_Hoffman/Whitepaper/bh-usa-07-sullivan_and_hoffman-WP.pdf 
Thread Safety Challenge in WebGoat - http://www.owasp.org/index.php/OWASP_WebGoat_Project

OWASP Testing Guide v3 Table of Contents

2008-08-24T22:51:11Z

Mr fusion: /* 4. (M.Meucci) Web Application Penetration Testing */

__NOTOC__

This is the draft of table of content of the New Testing Guide.
You can download the stable version [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_pdf.zip here]

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

Testing Guide v3 (draft)
Updated: 24th August 2008
(new)--> new articles, (toimp)--> needs to improve or to review, (xxx%) --> current state of the article

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

==[[Testing Guide Foreword|(toimp)Foreword by OWASP Chair]]==

==[[Testing Guide Frontispiece |(toimp: M.Meucci)1. Frontispiece]]==

'''[[Testing Guide Frontispiece|(toimp: M.Meucci)1.1 About the OWASP Testing Guide Project]]'''

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''

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

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

(new: M. Morana 90%) 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]

(new: M. Morana 100%) 2.4.1 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Tests_Integrated_in_Developers_and_Testers_Workflow Security tests integrated in developers and testers workflows]

(new: M. Morana 100%) 2.4.2 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Developers.27_Security_Tests Developers' security tests: unit tests and component level tests]

(new: M. Morana 90%) 2.4.3 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_Testers.27_Security_Tests Functional testers' security tests: integrated system tests, tests in UAT, and production environment]

(new: M. Morana 100%) 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. (M.Meucci) Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']]

[[Testing Checklist| (new: M.Meucci - 100% ) 4.1.1 Testing Checklist]]

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

[[Testing: Spiders Robots and Crawlers|(new:C.Heinrich - 0%)4.2.1 Spiders, Robots and Crawlers]]

[[Testing: Search engine discovery|(new:C.Heinrich - 0%)4.2.2 Search Engine Discovery/Reconnaissance]]

[[Testing: Identify application entry points| (new: K.Horvath - 100%) 4.2.3 Identify application entry points]]

[[Testing for Web Application Fingerprint|4.2.4 Testing for Web Application Fingerprint]]

[[Testing for Application Discovery|4.2.5 Application Discovery]]

[[Testing for Error Code|4.2.6 Analysis of Error Codes]]

[[Testing for configuration management|''' (new) 4.3 Configuration Management Testing''']]

[[Testing for SSL-TLS| 4.3.1 SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity]] 

[[Testing for DB Listener|4.3.2 DB Listener Testing]]

[[Testing for infrastructure configuration management| (new) 4.3.3 Infrastructure Configuration Management Testing]]

[[Testing for application configuration management|4.3.4 Application Configuration Management Testing]]

[[Testing for file extensions handling|4.3.5 Testing for File Extensions Handling]]

[[Testing for old_file|4.3.6 Old, Backup and Unreferenced Files]]

[[Testing for Admin Interfaces|(A. Goodman - 90%) 4.3.7 Infrastructure and Application Admin Interfaces]]

[[Testing for HTTP Methods and XST| (imp: A. van der Stock - 100%)4.3.8 Testing for HTTP Methods and XST]]

[[Testing for business logic|'''(K.Horvath - 100%) 4.4 Business Logic Testing''']]

[[Testing for authentication|'''(M.Meucci - 100%) 4.5 Authentication Testing''']]

[[Testing for credentials transport|(new: G.Ingrosso - 100%) 4.5.1 Credentials transport over an encrypted channel]]

[[Testing for user enumeration|(new: M.Meucci, M.Mella - 90%) 4.5.2 Testing for user enumeration]]

[[Testing for Default or Guessable User Account|(K.Horvath - 100% - adam updated) 4.5.3 Testing for Guessable (Dictionary) User Account]]

[[Testing for Brute Force|4.5.4 Brute Force Testing]]

[[Testing for Bypassing Authentication Schema|4.5.5 Testing for bypassing authentication schema]]

[[Testing for Vulnerable Remember Password and Pwd Reset|4.5.6 Testing for vulnerable remember
password and pwd reset]]

[[Testing for Logout and Browser Cache Management|4.5.7 Testing for Logout and Browser Cache Management Testing]]

[[Testing for Captcha|(new: P.Luptak - 100% ) 4.5.8 Testing for CAPTCHA]]

[[Testing Multiple Factors Authentication| (new: G.Fedon) 4.5.9 Testing Multiple Factors Authentication]]

[[Testing for Race Conditions| (new: A. Goodman - 90%) 4.5.10 Testing for Race Conditions]]

[[Testing for Authorization|'''(new: M.Meucci - 100%) 4.6 Authorization testing''']]

[[Testing for Path Traversal|(new) 4.6.1 Testing for path traversal]]

[[Testing for Bypassing Authorization Schema|(new: M.Meucci - 100%)4.6.2 Testing for bypassing authorization schema]]

[[Testing for Privilege escalation|(new: Cecil Su, M.Meucci - 100%)4.6.3 Testing for Privilege Escalation]]

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

[[Testing for Session_Management_Schema|(new: M.Meucci - 100%) 4.7.1 Testing for Session Management Schema]]

[[Testing for cookies attributes| (new: K.Horvath - 100%) 4.7.2 Testing for Cookies attributes]]

[[Testing for Session Fixation| (new: M.Meucci - 100%) 4.7.3 Testing for Session Fixation]]

[[Testing for Exposed Session Variables|4.7.4 Testing for Exposed Session Variables ]]

[[Testing for CSRF|4.7.5 Testing for CSRF]]

[[Testing for HTTP Exploit|4.7.6 Testing for HTTP Exploit ]]

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

[[Testing for Reflected Cross site scripting|(new: A. Coronel -100%)4.8.1 Testing for Reflected Cross Site Scripting]]

[[Testing for Stored Cross site scripting|(new: R. Suggi Liverani - 100%)4.8.2 Testing for Stored Cross Site Scripting]]

[[Testing for DOM-based Cross site scripting|(new: A.Agarwwal, Kuza55 - 80%) 4.8.3 Testing for DOM based Cross Site Scripting]]

[[Testing for Cross site flashing|(new: A.Agarwwal, S.Di Paola - 0%)4.8.4 Testing for Cross Site Flashing]]

[[Testing for SQL Injection| 4.8.5 Testing for SQL Injection ]]

[[Testing for Oracle|4.8.5.1 Oracle Testing ]]

[[Testing for MySQL|4.8.5.2 MySQL Testing ]]

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

[[Testing for MS Access|(new:A.Parata - 90%) 4.8.5.4 MS Access Testing]]

[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.5.5 (new: D.Bellucci 100% from OWASP BSP) Testing PostgreSQL]]

[[Testing for LDAP Injection|4.8.6 Testing for LDAP Injection]]

[[Testing for ORM Injection|4.8.7 Testing for ORM Injection]]

[[Testing for XML Injection|4.8.8 Testing for XML Injection]]

[[Testing for SSI Injection|4.8.9 Testing for SSI Injection]]

[[Testing for XPath Injection|4.8.10 Testing for XPath Injection]]

[[Testing for IMAP/SMTP Injection|4.8.11 IMAP/SMTP Injection]]

[[Testing for Code Injection|4.8.12 Testing for Code Injection]]

[[Testing for Command Injection|4.8.13 Testing for Command Injection]]

[[Testing for Buffer Overflow|4.8.14 Testing for Buffer overflow]]

[[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|4.8.15 Testing for incubated vulnerabilities]]

[[Testing for Denial of Service|'''4.9 Testing for Denial of Service''']]

[[Testing for SQL Wildcard Attacks|(new: F.Mavituna - 100%) 4.9.1 Testing for SQL Wildcard Attacks]]

[[Testing for DoS Locking Customer Accounts|4.9.2 Testing for DoS Locking Customer Accounts]]

[[Testing for DoS Buffer Overflows|4.9.3 Testing for DoS Buffer Overflows]]

[[Testing for DoS User Specified Object Allocation|4.9.4 Testing for DoS User Specified Object Allocation]]

[[Testing for User Input as a Loop Counter|4.9.5 Testing for User Input as a Loop Counter]]

[[Testing for Writing User Provided Data to Disk|4.9.6 Testing for Writing User Provided Data to Disk]]

[[Testing for DoS Failure to Release Resources|4.9.7 Testing for DoS Failure to Release Resources]]

[[Testing for Storing too Much Data in Session|4.9.8 Testing for Storing too Much Data in Session]]

[[Testing for Web Services|(toimp: M.Meucci -100%) '''4.10 Web Services Testing''']]

[[Testing: WS Information Gathering|(new: M.Meucci -100%) 4.10.1 WS Information Gathering]]

[[Testing WSDL|(new: M.Meucci -100%) 4.10.2 Testing WSDL]]

[[Testing for XML Structural|(toimp: M.Meucci -100%)4.10.3 XML Structural Testing ]]

[[Testing for XML Content-Level|4.10.4 XML Content-level Testing ]]

[[Testing for WS HTTP GET parameters/REST attacks|4.10.5 HTTP GET parameters/REST Testing ]]

[[Testing for Naughty SOAP Attachments|4.10.6 Naughty SOAP attachments ]]

[[Testing for WS Replay|4.10.7 Replay Testing ]]

[[Testing_for_AJAX:_introduction|'''4.11 AJAX Testing''']]

[[Testing for AJAX Vulnerabilities|4.11.1 AJAX Vulnerabilities]]

[[Testing for AJAX|4.11.2 How to test AJAX]]

==[[Writing Reports: value the real risk |(toimp: Mat)5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]]

[[How to write the report of the testing |5.2 How to write the report of the testing]]

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

* Black Box Testing Tools
* Source Code Analyzers
* Other Tools

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers
* Books
* Useful Websites

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

* Fuzz Categories
** Recursive fuzzing
** Replasive fuzzing
* Cross Site Scripting (XSS)
* Buffer Overflows and Format String Errors
** Buffer Overflows (BFO)
** Format String Errors (FSE)
** Integer Overflows (INT)
* SQL Injection
** Passive SQL Injection (SQP)
** Active SQL Injection (SQI)
* LDAP Injection
* XPATH Injection

==[[OWASP Testing Guide Appendix D: Encoded Injection | (new: Harish S.)Appendix D: Encoded Injection]]==

----

[[Category:OWASP Testing Project]]

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

2008-08-24T22:50:06Z

Mr fusion: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
Today's web applications typically run on popular open source or commercial software, that is installed on servers and requires configuration or customization by the server administrator. In addition, most of today's hardware appliances, i.e., network routers and database servers, offer web-based configuration or administrative interfaces. 
Often, these applications are not properly configured and the default credentials provided for initial authentication and configuration are never updated. In addition, it is typical to find generic accounts, left over from testing or administration, that use common usernames and passwords and are left enabled in the application and its infrastructure. 
These default username and password combinations are widely known by penetration testers and malicious hackers that can use them to gain access to various types of custom, open source, or commercial applications. 
In addition, weak password policy enforcements seen in many applications allow users to sign up using easy to guess usernames and passwords, and may also not allow password changes to be undertaken.
 
== Description of the Issue ==
The root cause of this problem can be identified as:
* Inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components.
* Programmers, who leave backdoors to easily access and test their application and later forget to remove them.
* Application administrators and users that choose an easy username and password for themselves
* Applications with built-in, non-removable default accounts with a pre-set username and password.
* Applications which leak information as to the validity of usernames during either authentication attempts, password resets or account signup.
 
An additional problem stems from the use of blank passwords, which are simply the result of a lack of security awareness or a desire to simplify administration.

== Black Box testing and example ==
In Blackbox testing the tester knows nothing about the application, its underlying infrastructure, and any username or password policies. In reality this is often this is not the case and some information about the application is known. If this is the case, simply skip the steps that refer to obtaining information you already have.

When testing a known application interface - for example a Cisco router web interface or a Weblogic administrator portal, check that the known usernames and passwords for these devices do not result in successful authentication. Common credentials for many systems can be found using a search engine or by using one of the sites listed in the Further Reading section.
 
When facing applications to which we do not have a list of default and common user accounts, or when common accounts do not work, we can perform manual testing:

 Note that the application being tested may have an account lockout, and multiple password guess attempts with a known username may cause the account to be locked. If it is possible to lock the administrator account, it may be troublesome for the system administrator to reset it 

 Many applications have verbose error messages that inform the site users as to the validity of entered usernames. This information will be helpful when testing for default or guessable user accounts. Such functionality can be found, for example, on the login page, password reset and forgotten password page, and sign up page. More information on this can be seen in the section titled: 'Testing for user enumeration'.
 
* Try the following usernames - "admin", "administrator", "root", "system", "guest", "operator", or "super". These are popular among system administrators and are often used. Additionally you could try "qa", "test", "test1", "testing", "guest" and similar names. Attempt any combination of the above in both the username and the password fields. If the application is vulnerable to username enumeration, and you successfully managed to identify any of the above usernames, attempt passwords in a similar manner. In addition try an empty password or one of the following "password", "pass123", "password123", "admin", or "guest" with the above accounts or any other enumerated accounts. Further permutations of the above can also be attempted. If these passwords fail, it may be worth using a common username and password list and attempting multiple requests against the application. This can, of course, be scripted to save time.
* Application administrative users are often named after the application or organization. This means if you are testing an application named "Obscurity", try using obscurity/obscurity or any other similar combination as the username and password.
* When performing a test for a customer, attempt using names of contacts you have received as usernames with any common passwords.
* Viewing the User Registration page may help determine the expected format and length of the application usernames and passwords. If a user registration page does not exist, determine if the organization uses a standard naming convention for user names such as their email address or the name before the "@" in the email.
* Attempt using all the above usernames with blank passwords.
* Review the page source and javascript either through a proxy or by viewing the source. Look for any references to users and passwords in the source. For example "If username='admin' then starturl=/admin.asp else /index.asp" (for a successful login vs a failed login). Also, if you have a valid account, then login and view every request and response for a valid login vs an invalid login, such as additional hidden parameters, interesting GET request (login=yes), etc.
* Look for account names and passwords written in comments in the source code. Also look in backup directories etc for source code that may contain comments of interest.
* Try to extrapolate from the application how usernames are generated. For example, can a user create their own username or does the system create an account for the user based on some personal information or a predictable sequence? If the application does create its own accounts in a predictable sequence, such as user7811, try fuzzing all possible accounts recursively. If you can identify a different response from the application when using a valid username and a wrong password, then you can try a brute force attack on the valid username (or quickly try any of the identified common passwords above or in the reference section).
* If the application creates its own passwords for new users, whether or not the username is created by the application or by the user, then try to determine if the password is predictable. Try to create many new accounts in quick succession to compare and determine if the passwords are predictable. If predictable, then try to correlate these with the usernames, or any enumerated accounts, and use them as a basis for a brute force attack.

'''Result Expected:''' 
Successful authentication to the application or system being tested. 

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

* Talk to the IT personnel to determine passwords they use for administrative access and how administration of the application is undertaken.
* Examine the password policy for the application, checking whether username and passwords are complex, difficult to guess, and not related to the application name, person name, or administrative names ("system").
* Examine the user database for default names, application names, and easily guessed names as described in the Black Box testing section. Check for empty password fields.
* Examine the code for hard coded usernames and passwords.
* Check for configuration files that contain usernames and passwords. 

'''Result Expected:''' 
Successful authentication to the application or system being tested. 

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

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

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

2008-08-24T22:48:53Z

Mr fusion: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
Today's web applications typically run on popular open source or commercial software, that is installed on servers and requires configuration or customization by the server administrator. In addition, most of today's hardware appliances, i.e., network routers and database servers, offer web-based configuration or administrative interfaces. 
Often, these applications are not properly configured and the default credentials provided for initial authentication and configuration are never updated. In addition, it is typical to find generic accounts, left over from testing or administration, that use common usernames and passwords and are left enabled in the application and its infrastructure. 
These default username and password combinations are widely known by penetration testers and malicious hackers that can use them to gain access to various types of custom, open source, or commercial applications. 
In addition, weak password policy enforcements seen in many applications allow users to sign up using easy to guess usernames and passwords, and may also not allow password changes to be undertaken.
 
== Description of the Issue ==
The root cause of this problem can be identified as:
* Inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components.
* Programmers, who leave backdoors to easily access and test their application and later forget to remove them.
* Application administrators and users that choose an easy username and password for themselves
* Applications with built-in, non-removable default accounts with a pre-set username and password.
* Applications which leak information as to the validity of usernames during either authentication attempts, password resets or account signup.
 
An additional problem stems from the use of blank passwords, which are simply the result of a lack of security awareness or a desire to simplify administration.

== Black Box testing and example ==
In Blackbox testing the tester knows nothing about the application, its underlying infrastructure, and any username or password policies. In reality this is often this is not the case and some information about the application is known. If this is the case, simply skip the steps that refer to obtaining information you already have.

When testing a known application interface - for example a Cisco router web interface or a Weblogic administrator portal, check that the known usernames and passwords for these devices do not result in successful authentication. Common credentials for many systems can be found using a search engine or by using one of the sites listed in the Further Reading section.
 
When facing applications to which we do not have a list of default and common user accounts, or when common accounts do not work, we can perform manual testing:

 Note that the application being tested may have an account lockout, and multiple password guess attempts with a known username may cause the account to be locked. If it is possible to lock the administrator account, it may be troublesome for the system administrator to reset it 

 Many applications have verbose error messages that inform the site users as to the validity of entered usernames. Such functionality can be found, for example, on the login page, password reset and forgotten password page, and sign up page. More information on this can be seen in the section titled: XXXXXXXXXXXXXXXXXX.
 
* Try the following usernames - "admin", "administrator", "root", "system", "guest", "operator", or "super". These are popular among system administrators and are often used. Additionally you could try "qa", "test", "test1", "testing", "guest" and similar names. Attempt any combination of the above in both the username and the password fields. If the application is vulnerable to username enumeration, and you successfully managed to identify any of the above usernames, attempt passwords in a similar manner. In addition try an empty password or one of the following "password", "pass123", "password123", "admin", or "guest" with the above accounts or any other enumerated accounts. Further permutations of the above can also be attempted. If these passwords fail, it may be worth using a common username and password list and attempting multiple requests against the application. This can, of course, be scripted to save time.
* Application administrative users are often named after the application or organization. This means if you are testing an application named "Obscurity", try using obscurity/obscurity or any other similar combination as the username and password.
* When performing a test for a customer, attempt using names of contacts you have received as usernames with any common passwords.
* Viewing the User Registration page may help determine the expected format and length of the application usernames and passwords. If a user registration page does not exist, determine if the organization uses a standard naming convention for user names such as their email address or the name before the "@" in the email.
* Attempt using all the above usernames with blank passwords.
* Review the page source and javascript either through a proxy or by viewing the source. Look for any references to users and passwords in the source. For example "If username='admin' then starturl=/admin.asp else /index.asp" (for a successful login vs a failed login). Also, if you have a valid account, then login and view every request and response for a valid login vs an invalid login, such as additional hidden parameters, interesting GET request (login=yes), etc.
* Look for account names and passwords written in comments in the source code. Also look in backup directories etc for source code that may contain comments of interest.
* Try to extrapolate from the application how usernames are generated. For example, can a user create their own username or does the system create an account for the user based on some personal information or a predictable sequence? If the application does create its own accounts in a predictable sequence, such as user7811, try fuzzing all possible accounts recursively. If you can identify a different response from the application when using a valid username and a wrong password, then you can try a brute force attack on the valid username (or quickly try any of the identified common passwords above or in the reference section).
* If the application creates its own passwords for new users, whether or not the username is created by the application or by the user, then try to determine if the password is predictable. Try to create many new accounts in quick succession to compare and determine if the passwords are predictable. If predictable, then try to correlate these with the usernames, or any enumerated accounts, and use them as a basis for a brute force attack.

'''Result Expected:''' 
Successful authentication to the application or system being tested. 

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

* Talk to the IT personnel to determine passwords they use for administrative access and how administration of the application is undertaken.
* Examine the password policy for the application, checking whether username and passwords are complex, difficult to guess, and not related to the application name, person name, or administrative names ("system").
* Examine the user database for default names, application names, and easily guessed names as described in the Black Box testing section. Check for empty password fields.
* Examine the code for hard coded usernames and passwords.
* Check for configuration files that contain usernames and passwords. 

'''Result Expected:''' 
Successful authentication to the application or system being tested. 

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

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

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

2008-08-24T22:46:24Z

Mr fusion: /* Description of the Issue */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
Today's web applications typically run on popular open source or commercial software, that is installed on servers and requires configuration or customization by the server administrator. In addition, most of today's hardware appliances, i.e., network routers and database servers, offer web-based configuration or administrative interfaces. 
Often, these applications are not properly configured and the default credentials provided for initial authentication and configuration are never updated. In addition, it is typical to find generic accounts, left over from testing or administration, that use common usernames and passwords and are left enabled in the application and its infrastructure. 
These default username and password combinations are widely known by penetration testers and malicious hackers that can use them to gain access to various types of custom, open source, or commercial applications. 
In addition, weak password policy enforcements seen in many applications allow users to sign up using easy to guess usernames and passwords, and may also not allow password changes to be undertaken.
 
== Description of the Issue ==
The root cause of this problem can be identified as:
* Inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components.
* Programmers, who leave backdoors to easily access and test their application and later forget to remove them.
* Application administrators and users that choose an easy username and password for themselves
* Applications with built-in, non-removable default accounts with a pre-set username and password.
* Applications which leak information as to the validity of usernames during either authentication attempts, password resets or account signup.
 
An additional problem stems from the use of blank passwords, which are simply the result of a lack of security awareness or a desire to simplify administration.

== Black Box testing and example ==
In Blackbox testing the tester knows nothing about the application, its underlying infrastructure, and any username or password policies. In reality this is often this is not the case and some information about the application is known. If this is the case, simply skip the steps that refer to obtaining information you already have.

When testing a known application interface - for example a Cisco router web interface or a Weblogic administrator portal, check that the known usernames and passwords for these devices do not result in successful authentication. Common credentials for many systems can be found using a search engine or by using one of the sites listed in the Further Reading section.
 
When facing applications to which we do not have a list of default and common user accounts, or when common accounts do not work, we can perform manual testing:

 Note that the application being tested may have an account lockout, and multiple password guess attempts with a known username may cause the account to be locked. If it is possible to lock the administrator account, it may be troublesome for the system administrator to reset it 

* Try the following usernames - "admin", "administrator", "root", "system", "guest", "operator", or "super". These are popular among system administrators and are often used. Additionally you could try "qa", "test", "test1", "testing", "guest" and similar names. Attempt any combination of the above in both the username and the password fields. If the application is vulnerable to username enumeration, and you successfully managed to identify any of the above usernames, attempt passwords in a similar manner. In addition try an empty password or one of the following "password", "pass123", "password123", "admin", or "guest" with the above accounts or any other enumerated accounts. Further permutations of the above can also be attempted. If these passwords fail, it may be worth using a common username and password list and attempting multiple requests against the application. This can, of course, be scripted to save time.
* Application administrative users are often named after the application or organization. This means if you are testing an application named "Obscurity", try using obscurity/obscurity or any other similar combination as the username and password.
* When performing a test for a customer, attempt using names of contacts you have received as usernames with any common passwords.
* Viewing the User Registration page may help determine the expected format and length of the application usernames and passwords. If a user registration page does not exist, determine if the organization uses a standard naming convention for user names such as their email address or the name before the "@" in the email.
* Attempt using all the above usernames with blank passwords.
* Review the page source and javascript either through a proxy or by viewing the source. Look for any references to users and passwords in the source. For example "If username='admin' then starturl=/admin.asp else /index.asp" (for a successful login vs a failed login). Also, if you have a valid account, then login and view every request and response for a valid login vs an invalid login, such as additional hidden parameters, interesting GET request (login=yes), etc.
* Look for account names and passwords written in comments in the source code. Also look in backup directories etc for source code that may contain comments of interest.
* Try to extrapolate from the application how usernames are generated. For example, can a user create their own username or does the system create an account for the user based on some personal information or a predictable sequence? If the application does create its own accounts in a predictable sequence, such as user7811, try fuzzing all possible accounts recursively. If you can identify a different response from the application when using a valid username and a wrong password, then you can try a brute force attack on the valid username (or quickly try any of the identified common passwords above or in the reference section).
* If the application creates its own passwords for new users, whether or not the username is created by the application or by the user, then try to determine if the password is predictable. Try to create many new accounts in quick succession to compare and determine if the passwords are predictable. If predictable, then try to correlate these with the usernames, or any enumerated accounts, and use them as a basis for a brute force attack.

'''Result Expected:''' 
Successful authentication to the application or system being tested. 

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

* Talk to the IT personnel to determine passwords they use for administrative access and how administration of the application is undertaken.
* Examine the password policy for the application, checking whether username and passwords are complex, difficult to guess, and not related to the application name, person name, or administrative names ("system").
* Examine the user database for default names, application names, and easily guessed names as described in the Black Box testing section. Check for empty password fields.
* Examine the code for hard coded usernames and passwords.
* Check for configuration files that contain usernames and passwords. 

'''Result Expected:''' 
Successful authentication to the application or system being tested. 

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

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

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

2008-08-24T22:43:09Z

Mr fusion: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
Today's web applications typically run on popular open source or commercial software, that is installed on servers and requires configuration or customization by the server administrator. In addition, most of today's hardware appliances, i.e., network routers and database servers, offer web-based configuration or administrative interfaces. 
Often, these applications are not properly configured and the default credentials provided for initial authentication and configuration are never updated. In addition, it is typical to find generic accounts, left over from testing or administration, that use common usernames and passwords and are left enabled in the application and its infrastructure. 
These default username and password combinations are widely known by penetration testers and malicious hackers that can use them to gain access to various types of custom, open source, or commercial applications. 
In addition, weak password policy enforcements seen in many applications allow users to sign up using easy to guess usernames and passwords, and may also not allow password changes to be undertaken.
 
== Description of the Issue ==
The root cause of this problem can be identified as:
* Inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components.
* Programmers, who leave backdoors to easily access and test their application and later forget to remove them.
* Application administrators and users that choose an easy username and password for themselves
* Applications with built-in, non-removable default accounts with a pre-set username and password.
 
An additional problem stems from the use of blank passwords, which are simply the result of a lack of security awareness or a desire to simplify administration.

== Black Box testing and example ==
In Blackbox testing the tester knows nothing about the application, its underlying infrastructure, and any username or password policies. In reality this is often this is not the case and some information about the application is known. If this is the case, simply skip the steps that refer to obtaining information you already have.

When testing a known application interface - for example a Cisco router web interface or a Weblogic administrator portal, check that the known usernames and passwords for these devices do not result in successful authentication. Common credentials for many systems can be found using a search engine or by using one of the sites listed in the Further Reading section.
 
When facing applications to which we do not have a list of default and common user accounts, or when common accounts do not work, we can perform manual testing:

 Note that the application being tested may have an account lockout, and multiple password guess attempts with a known username may cause the account to be locked. If it is possible to lock the administrator account, it may be troublesome for the system administrator to reset it 

* Try the following usernames - "admin", "administrator", "root", "system", "guest", "operator", or "super". These are popular among system administrators and are often used. Additionally you could try "qa", "test", "test1", "testing", "guest" and similar names. Attempt any combination of the above in both the username and the password fields. If the application is vulnerable to username enumeration, and you successfully managed to identify any of the above usernames, attempt passwords in a similar manner. In addition try an empty password or one of the following "password", "pass123", "password123", "admin", or "guest" with the above accounts or any other enumerated accounts. Further permutations of the above can also be attempted. If these passwords fail, it may be worth using a common username and password list and attempting multiple requests against the application. This can, of course, be scripted to save time.
* Application administrative users are often named after the application or organization. This means if you are testing an application named "Obscurity", try using obscurity/obscurity or any other similar combination as the username and password.
* When performing a test for a customer, attempt using names of contacts you have received as usernames with any common passwords.
* Viewing the User Registration page may help determine the expected format and length of the application usernames and passwords. If a user registration page does not exist, determine if the organization uses a standard naming convention for user names such as their email address or the name before the "@" in the email.
* Attempt using all the above usernames with blank passwords.
* Review the page source and javascript either through a proxy or by viewing the source. Look for any references to users and passwords in the source. For example "If username='admin' then starturl=/admin.asp else /index.asp" (for a successful login vs a failed login). Also, if you have a valid account, then login and view every request and response for a valid login vs an invalid login, such as additional hidden parameters, interesting GET request (login=yes), etc.
* Look for account names and passwords written in comments in the source code. Also look in backup directories etc for source code that may contain comments of interest.
* Try to extrapolate from the application how usernames are generated. For example, can a user create their own username or does the system create an account for the user based on some personal information or a predictable sequence? If the application does create its own accounts in a predictable sequence, such as user7811, try fuzzing all possible accounts recursively. If you can identify a different response from the application when using a valid username and a wrong password, then you can try a brute force attack on the valid username (or quickly try any of the identified common passwords above or in the reference section).
* If the application creates its own passwords for new users, whether or not the username is created by the application or by the user, then try to determine if the password is predictable. Try to create many new accounts in quick succession to compare and determine if the passwords are predictable. If predictable, then try to correlate these with the usernames, or any enumerated accounts, and use them as a basis for a brute force attack.

'''Result Expected:''' 
Successful authentication to the application or system being tested. 

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

* Talk to the IT personnel to determine passwords they use for administrative access and how administration of the application is undertaken.
* Examine the password policy for the application, checking whether username and passwords are complex, difficult to guess, and not related to the application name, person name, or administrative names ("system").
* Examine the user database for default names, application names, and easily guessed names as described in the Black Box testing section. Check for empty password fields.
* Examine the code for hard coded usernames and passwords.
* Check for configuration files that contain usernames and passwords. 

'''Result Expected:''' 
Successful authentication to the application or system being tested. 

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

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

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

2008-08-24T22:40:19Z

Mr fusion:

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
Today's web applications typically run on popular open source or commercial software, that is installed on servers and requires configuration or customization by the server administrator. In addition, most of today's hardware appliances, i.e., network routers and database servers, offer web-based configuration or administrative interfaces. 
Often, these applications are not properly configured and the default credentials provided for initial authentication and configuration are never updated. In addition, it is typical to find generic accounts, left over from testing or administration, that use common usernames and passwords and are left enabled in the application and its infrastructure. 
These default username and password combinations are widely known by penetration testers and malicious hackers that can use them to gain access to various types of custom, open source, or commercial applications. 
In addition, weak password policy enforcements seen in many applications allow users to sign up using easy to guess usernames and passwords, and may also not allow password changes to be undertaken.
 
== Description of the Issue ==
The root cause of this problem can be identified as:
* Inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components.
* Programmers, who leave backdoors to easily access and test their application and later forget to remove them.
* Application administrators and users that choose an easy username and password for themselves
* Applications with built-in, non-removable default accounts with a pre-set username and password.
 
An additional problem stems from the use of blank passwords, which are simply the result of a lack of security awareness or a desire to simplify administration.

== Black Box testing and example ==
In Blackbox testing the tester knows nothing about the application, its underlying infrastructure, and any username or password policies. In reality this is often this is not the case and some information about the application is known. If this is the case, simply skip the steps that refer to obtaining information you already have.

When testing a known application interface - for example a Cisco router web interface or a Weblogic administrator portal, check that the known usernames and passwords for these devices do not result in successful authentication. Common credentials for many systems can be found using a search engine or by using one of the sites listed in the Further Reading section.
 
When facing applications to which we do not have a list of default and common user accounts, or when common accounts do not work, we can perform manual testing:

 Note that the application being tested may have an account lockout, and multiple password guess attempts with a known username may cause the account to be locked. If it is possible to lock the administrator account, it may be troublesome for the system administrator to reset it 

* Try the following usernames - "admin", "administrator", "root", "system", "guest", "operator", or "super". These are popular among system administrators and are often used. Additionally you could try "qa", "test", "test1", "testing", "guest" and similar names. Attempt any combination of the above in both the username and the password fields. If the application is vulnerable to username enumeration, and you successfully managed to identify any of the above usernames, attempt passwords in a similar manner. In addition try an empty password or one of the following "password", "pass123", "password123", "admin", or "guest" with the above accounts or any other enumerated accounts. Further permutations of the above can also be attempted.
* Application administrative users are often named after the application or organization. This means if you are testing an application named "Obscurity", try using obscurity/obscurity or any other similar combination as the username and password.
* When performing a test for a customer, attempt using names of contacts you have received as usernames with any common passwords.
* Viewing the User Registration page may help determine the expected format and length of the application usernames and passwords. If a user registration page does not exist, determine if the organization uses a standard naming convention for user names such as their email address or the name before the "@" in the email.
* Attempt using all the above usernames with blank passwords.
* Review the page source and javascript either through a proxy or by viewing the source. Look for any page references (such as "If admin then starturl=/admin else /index.asp") for a successful login vs a failed login. Also, if you have a valid account, then login and view every request and response for a valid login vs an invalid login, such as additional hidden parameters, interesting GET request (login=yes), etc.
* Look for account names and passwords written in comments in the source code. Also look in backup directories etc for source code that may contain comments of interest.
* Try to extrapolate from the application how usernames are generated. For example, can a user create their own username or does the system create an account for the user based on some personal information or a predictable sequence? If the application does create its own accounts in a predictable sequence, such as user7811, try fuzzing all possible accounts recursively. If you can identify a different response from the application when using a valid username and a wrong password, then you can try a brute force attack on the valid username (or quickly try any of the identified common passwords above or in the reference section).
* If the application creates its own passwords for new users, whether or not the username is created by the application or by the user, then try to determine if the password is predictable. Try to create many new accounts in quick succession to compare and determine if the passwords are predictable. If predictable, then try to correlate these with the usernames, or any enumerated accounts, and use them as a basis for a brute force attack.

'''Result Expected:''' 
Successful authentication to the application or system being tested. 

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

* Talk to the IT personnel to determine passwords they use for administrative access and how administration of the application is undertaken.
* Examine the password policy for the application, checking whether username and passwords are complex, difficult to guess, and not related to the application name, person name, or administrative names ("system").
* Examine the user database for default names, application names, and easily guessed names as described in the Black Box testing section. Check for empty password fields.
* Examine the code for hard coded usernames and passwords.
* Check for configuration files that contain usernames and passwords. 

'''Result Expected:''' 
Successful authentication to the application or system being tested. 

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

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

Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

2008-08-24T21:57:54Z

Mr fusion: /* Gray Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.
 

== Description of the Issue ==
 
An application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. Such changes may include:

- user account provisioning 
- Site design and layout 
- data manipultion 
- configuration changes 

In many instances, such interfaces are usually implemented with little thought of how to separate them from the normal users of the site. Testing is aimed at discovering these administrator interfaces and accessing functionality intended for the privileged users.
 

== Black Box testing and example ==
The following describes vectors that may be used to test for the presence of administrative interfaces. These techniques may also be used for testing for related issues including privilege escalation and are described elsewhere in this guide in greater detail: 

* Directory and file Enumeration - An administrative interface may be present but not visibly available to the tester. Attempting to guess the path of the administrative interface may be as simple as requesting:
/admin or /administrator etc.. 
A tester may have to also identify the filename of the administration page. Forcible browsing to the identified page may provide access to the interface.

* Comments and links in Source - Many sites use common code that is loaded for all site users. By examining all source sent to the client, links to administrator functionality may be discovered and should be investigated.

* Reviewing Server and Application Documentation - If the application server or application is deployed in its default configuration it may be possible to access the administration interface using information described in configuration or help documentation. Default password lists should be consulted if an administrative interface is found and credentials are required.

* Alternative Server Port - Administration interfaces may be seen on a different port on the host than the main application. For example, Apache Tomcat's Administration interface can often be seen on port 8080.

* Parameter Tampering - A GET or POST parameter or a cookie variable may be required to enable the administrator functionality. Clues to this
include the presence of hidden fields such as:

<input type="hidden" name="admin" value="no"> or in a cookie: Cookie: session_cookie; useradmin=0
 
Once an administrative interface has been discovered, a combination of the above techniques may be used to attempt to bypass authentication. If this fails, the
tester may wish to attempt a brute force attack. In such an instance the tester should be aware of the potential for administrative account lockout if such functionality is present.

== Gray Box testing and example ==
An more detailed examination of the server and application components should be undertaken to ensure hardening (i.e. administrator pages are not accessible to everyone through the use of IP filtering or other controls), and where applicable, verification that all components do not use default credentials or configurations.
 
Source code should be reviewed to ensure that the authorization and authentication model ensures clear separation of duties between normal users and site administrators. User interface functions shared between normal and administrator users should be reviewed to ensure clear separation between the drawing of such components and information leakage from such shared functionality.
 

== References ==
* Default Password list: http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php

Identify application entry points (OTG-INFO-006)

2008-08-24T21:24:31Z

Mr fusion: /* Brief Summary */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
Enumerating the application and its attack surface is a key precursor before any thorough testing can be undertaken, as it allows the tester to identify likely areas of weakness. This section aims to help identify and map out areas within the application that should be investigated once enumeration and mapping has been completed.
 

== Description of the Issue ==
 

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

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

Below are some points of interests for all requests and responses. Within the requests section focus on the GET and POST methods, as these appear the majority of the requests. Note that other methods, such as PUT and DELETE, can be used. Often, these more rare requests, if allowed, can expose vulnerabilities. There is a special section in this guide dedicated for testing these HTTP methods.

'''Requests:'''

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

'''Responses:'''

*Identify where new cookies are set (Set-Cookie header), modified, or added to.
*Identify where there are any redirects (300 HTTP status code), 400 status codes, in particular 403 Forbidden, and 500 internal server errors during normal responses (i.e., unmodified requests).
*Also note where any interesting headers are used. For example, "Server: BIG-IP" indicates that the site is load balanced. Thus, if a site is load balanced and one server is incorrectly configured, then you might have to make multiple requests to access the vulnerable server, depending on the type of load balancing used.

 

== Black Box testing and example ==
'''Testing for application entry points:''' 
The following are 2 examples on how to check for application entry points. 

'''EXAMPLE 1:'''

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

Example 1 of a simplified GET request:

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

'''Result Expected:''' 

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

'''EXAMPLE 2:'''

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

Example 2 of a simplified POST request:

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

Body of the POST message:

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

'''Result Expected:''' 

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

== Gray Box testing and example ==

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

== References ==

'''Whitepapers''' 

*RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1 -
http://tools.ietf.org/html/rfc2616

'''Tools''' 

'''Intercepting Proxy:''' 

*OWASP: Webscarab -
http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
*Dafydd Stuttard: Burp proxy -
http://portswigger.net/proxy/
*MileSCAN: Paros Proxy -
http://www.parosproxy.org/download.shtml

'''Browser Plug-in:''' 

*"TamperIE" for Internet Explorer -
http://www.bayden.com/TamperIE/
*Adam Judson: "Tamper Data" for Firefox -
https://addons.mozilla.org/en-US/firefox/addon/966

Test HTTP Methods (OTG-CONFIG-006)

2008-08-24T21:04:47Z

Mr fusion: /* Short Description of the Issue (Topic and Explanation) */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
HTTP offers a number of methods that can be used to performs actions on the web server. Many of theses methods are designed to aid developers deploy and test HTTP applications. These HTTP methods can be used for nefarious purposes if the web server is misconfigured. Additionally, Cross Site Tracing (XST), a form of cross site scripting using the servers HTTP TRACE method, is examined. 

== Short Description of the Issue (Topic and Explanation) ==
While GET and POST are by far the most common methods that are used to access information provided by a web server, the Hypertext Transfer Protocol (HTTP) allows several other (and somewhat less known) methods. RFC 2616 (which describes HTTP version 1.1 which is the today standard) defines the following eight methods:

* HEAD
* GET
* POST
* PUT
* DELETE
* TRACE
* OPTIONS
* CONNECT

Some of these methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users. More specifically, the methods that should be disabled are the following:

* PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim server as a file repository
* DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack
* CONNECT: This method could allow a client to use the web server as a proxy
* TRACE: This method simply echoes back to the client whatever string has been sent to the server, and it is used mainly for debugging purposes. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman (see links at the bottom of the page)

If an application needs one or more of these methods, such as REST Web Services (which may require PUT or DELETE), it is important to check that their usage is properly limited to trusted users and safe conditions.

== Arbitrary HTTP Methods ==

Arshan Dabirsiaghi (see links) discovered that many web application frameworks allowed well chosen and / or arbitrary HTTP methods to bypass an environment level access control check:

* Many frameworks and languages treat "HEAD" as a "GET" request, albeit one without any body in the response. If a security constraint was set on "GET" requests such that only "authenticatedUsers" could access GET requests for a particular servlet or resource, it would be bypassed for the "HEAD" version. This allowed unauthorized blind submission of any privileged GET request

* Some frameworks allowed arbitrary HTTP methods such as "JEFF" or "CATS" to be used without limitation. These were treated as if a "GET" method was issued, and again were found not to be subject to method role based access control checks on a number of languages and frameworks, again allowing unauthorized blind submission of privileged GET requests.

In many cases, code which explicitly checked for a "GET" or "POST" method would be safe.

== Black Box testing and example ==
'''Discover the Supported Methods''' 
To perform this test, we need some way to figure out which HTTP methods are supported by the web server we are examining. The OPTIONS HTTP method provides us with the most direct and effective way to do that. RFC 2616 states that “The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI”.

The testing method is extremely straightforward and we only need to fire up netcat (or telnet):
<pre>
icesurfer@nightblade ~ $ nc www.victim.com 80
OPTIONS / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:00:29 GMT
Connection: close
Allow: GET, HEAD, POST, TRACE, OPTIONS
Content-Length: 0

icesurfer@nightblade ~ $
</pre>
As we can see in the example, OPTIONS provides a list of the methods that are supported by the web server, and in this case we can see, for instance, that TRACE method is enabled. The danger that is posed by this method is illustrated in the following section 
'''Test XST Potential''' 
Note: in order to understand the logic and the goals of this attack you need to be familiar with [[Cross_site_scripting_AoC | Cross Site Scripting attacks]].

The TRACE method, while apparently harmless, can be successfully leveraged in some scenarios to steal legitimate users' credentials. This attack technique was discovered by Jeremiah Grossman in 2003, in an attempt to bypass the [[HTTPOnly]] tag that Microsoft introduced in Internet Explorer 6 sp1 to protect cookies from being accessed by JavaScript. As a matter of fact, one of the most recurring attack patterns in Cross Site Scripting is to access the document.cookie object and send it to a web server controlled by the attacker so that he/she can hijack the victim's session. Tagging a cookie as httpOnly forbids JavaScript to access it, protecting it from being sent to a third party. However, the TRACE method can be used to bypass this protection and access the cookie even in this scenario.

As mentioned before, TRACE simply returns any string that is sent to the web server. In order to verify its presence (or to double-check the results of the OPTIONS request shown above), we can proceed as shown in the following example:
<pre>
icesurfer@nightblade ~ $ nc www.victim.com 80
TRACE / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:01:48 GMT
Connection: close
Content-Type: message/http
Content-Length: 39

TRACE / HTTP/1.1
Host: www.victim.com
</pre>
As we can see, the response body is exactly a copy of our original request, meaning that our target allows this method. Now, where is the danger lurking? If we instruct a browser to issue a TRACE request to the web server, and this browser has a cookie for that domain, the cookie will be automatically included in the request headers, and will therefore echoed back in the resulting response. At that point, the cookie string will be accessible by JavaScript and it will be finally possible to send it to a third party even when the cookie is tagged as httpOnly.

There are multiple ways to make a browser issue a TRACE request, as the XMLHTTP ActiveX control in Internet Explorer and XMLDOM in Mozilla and Netscape. However, for security reasons the browser is allowed to start a connection only to the domain where the hostile script resides. This is a mitigating factor, as the attacker needs to combine the TRACE method with another vulnerability in order to mount the attack. Basically, an attacker has two ways to successfully launch a Cross Site Tracing attack:

* 1.Leveraging another server-side vulnerability: the attacker injects the hostile JavaScript snippet, that contains the TRACE request, in the vulnerable application, as in a normal Cross Site Scripting attack
* 2.Leveraging a client-side vulnerability: the attacker creates a malicious website that contains the hostile JavaScript snippet and exploits some cross-domain vulnerability of the browser of the victim, in order to make the JavaScript code successfully perform a connection to the site that supports the TRACE method and that originated the cookie that the attacker is trying to steal.

More detailed information, together with code samples, can be found in the original whitepaper written by Jeremiah Grossman. 

== Black Box Testing of HTTP method tampering ==

Testing for HTTP method tampering is essentially the same as testing for XST.

=== Testing for arbitrary HTTP methods ===

Find a page you'd like to visit that has a security constraint such that it would normally force a 302 redirect to a login page or forces a login directly. The test URL in this example works like this - as do many web applications. However, if you obtain a "200" response that is not a login page, it is possible to bypass authentication and thus authorization.

<pre>
[rapidoffenseunit:~] vanderaj% nc www.example.com 80
JEFF / HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:38:40 GMT
Server: Apache
Set-Cookie: PHPSESSID=K53QW...
</pre>

If your framework or firewall or application does not support the "JEFF" method, it should issue an error page (or preferably a 405 Not Allowed or 501 Not implemented error page). If it services the request, it is vulnerable to this issue.

If you feel that the system is vulnerable to this issue, issue CSRF-like attacks to exploit the issue more fully:

* FOOBAR /admin/createUser.php?member=myAdmin
* JEFF /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
* CATS /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

With some luck, using the above three commands - modified to suit the application under test and testing requirements - a new user would be created, a password assigned, and made an admin.

=== Testing for HEAD access control bypass ===

Find a page you'd like to visit that has a security constraint such that it would normally force a 302 redirect to a login page or forces a login directly. The test URL in this example works like this - as do many web applications. However, if you obtain a "200" response that is not a login page, it is possible to bypass authentication and thus authorization.

<pre>
[rapidoffenseunit:~] vanderaj% nc www.example.com 80
HEAD /admin HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:44:11 GMT
Server: Apache
Set-Cookie: PHPSESSID=pKi...; path=/; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: adminOnlyCookie1=...; expires=Tue, 18-Aug-2009 22:44:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie2=...; expires=Mon, 18-Aug-2008 22:54:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie3=...; expires=Sun, 19-Aug-2007 22:44:30 GMT; domain=www.example.com
Content-Language: EN
Connection: close
Content-Type: text/html; charset=ISO-8859-1
</pre>

If you get a "405 Method not allowed" or "501 Method Unimplemented", the application/framework/language/system/firewall is working correctly. If a "200" response code comes back, and the response contains no body, it's likely that the application has processed the request without authentication or authorization and further testing is warranted.

If you feel that the system is vulnerable to this issue, issue CSRF-like attacks to exploit the issue more fully:

* HEAD /admin/createUser.php?member=myAdmin
* HEAD /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
* HEAD /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

With some luck, using the above three commands - modified to suit the application under test and testing requirements - a new user would be created, a password assigned, and made an admin, all using blind request submission.

== Gray Box testing and example ==
The testing in a Gray Box scenario follows the same steps of a Black Box scenario
 
== References ==
'''Whitepapers''' 
* RFC 2616: “Hypertext Transfer Protocol -- HTTP/1.1”
* RFC 2109 and RFC 2965: “HTTP State Management Mechanism”
* Jeremiah Grossman: "Cross Site Tracing (XST)" - http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf 
* Amit Klein: "XS(T) attack variants which can, in some cases, eliminate the need for TRACE" - http://www.securityfocus.com/archive/107/308433
* Arshan Dabirsiaghi: "Bypassing VBAAC with HTTP Verb Tampering" - http://www.aspectsecurity.com/documents/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf

'''Tools'''
* NetCat - http://www.vulnwatch.org/netcat

Test HTTP Methods (OTG-CONFIG-006)

2008-08-24T21:00:52Z

Mr fusion: /* Brief Summary */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
HTTP offers a number of methods that can be used to performs actions on the web server. Many of theses methods are designed to aid developers deploy and test HTTP applications. These HTTP methods can be used for nefarious purposes if the web server is misconfigured. Additionally, Cross Site Tracing (XST), a form of cross site scripting using the servers HTTP TRACE method, is examined. 

== Short Description of the Issue (Topic and Explanation) ==
While GET and POST are by far the most common methods that are used to access information provided by a web server, the Hypertext Transfer Protocol (HTTP) allows several other (and somewhat less known) methods. RFC 2616 (which describes HTTP version 1.1 which is the today standard) defines the following eight methods:

* HEAD
* GET
* POST
* PUT
* DELETE
* TRACE
* OPTIONS
* CONNECT

Some of these methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users. More specifically, the methods that should be disabled are the following:

* PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim server as a file repository
* DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack
* CONNECT: This method could allow a client to use the web server as a proxy
* TRACE: This method simply echoes back to the client whatever string has been sent to the server, and it is used mainly for debugging purposes. This method, apparently harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman (see links at the bottom of the page)

If an application needs one or more of these methods, such as REST Web Services requiring PUT or DELETE, it is important to check that their use is properly limited to trusted users and safe conditions.

== Arbitrary HTTP Methods ==

Arshan Dabirsiaghi (see links) discovered that many web application frameworks allowed well chosen and / or arbitrary HTTP methods to bypass an environment level access control check:

* Many frameworks and languages treat "HEAD" as a "GET" request, albeit one without any body in the response. If a security constraint was set on "GET" requests such that only "authenticatedUsers" could access GET requests for a particular servlet or resource, it would be bypassed for the "HEAD" version. This allowed unauthorized blind submission of any privileged GET request

* Some frameworks allowed arbitrary HTTP methods such as "JEFF" or "CATS" to be used without limitation. These were treated as if a "GET" method was issued, and again were found not to be subject to method role based access control checks on a number of languages and frameworks, again allowing unauthorized blind submission of privileged GET requests.

In many cases, code which explicitly checked for a "GET" or "POST" method would be safe.

== Black Box testing and example ==
'''Discover the Supported Methods''' 
To perform this test, we need some way to figure out which HTTP methods are supported by the web server we are examining. The OPTIONS HTTP method provides us with the most direct and effective way to do that. RFC 2616 states that “The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI”.

The testing method is extremely straightforward and we only need to fire up netcat (or telnet):
<pre>
icesurfer@nightblade ~ $ nc www.victim.com 80
OPTIONS / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:00:29 GMT
Connection: close
Allow: GET, HEAD, POST, TRACE, OPTIONS
Content-Length: 0

icesurfer@nightblade ~ $
</pre>
As we can see in the example, OPTIONS provides a list of the methods that are supported by the web server, and in this case we can see, for instance, that TRACE method is enabled. The danger that is posed by this method is illustrated in the following section 
'''Test XST Potential''' 
Note: in order to understand the logic and the goals of this attack you need to be familiar with [[Cross_site_scripting_AoC | Cross Site Scripting attacks]].

The TRACE method, while apparently harmless, can be successfully leveraged in some scenarios to steal legitimate users' credentials. This attack technique was discovered by Jeremiah Grossman in 2003, in an attempt to bypass the [[HTTPOnly]] tag that Microsoft introduced in Internet Explorer 6 sp1 to protect cookies from being accessed by JavaScript. As a matter of fact, one of the most recurring attack patterns in Cross Site Scripting is to access the document.cookie object and send it to a web server controlled by the attacker so that he/she can hijack the victim's session. Tagging a cookie as httpOnly forbids JavaScript to access it, protecting it from being sent to a third party. However, the TRACE method can be used to bypass this protection and access the cookie even in this scenario.

As mentioned before, TRACE simply returns any string that is sent to the web server. In order to verify its presence (or to double-check the results of the OPTIONS request shown above), we can proceed as shown in the following example:
<pre>
icesurfer@nightblade ~ $ nc www.victim.com 80
TRACE / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:01:48 GMT
Connection: close
Content-Type: message/http
Content-Length: 39

TRACE / HTTP/1.1
Host: www.victim.com
</pre>
As we can see, the response body is exactly a copy of our original request, meaning that our target allows this method. Now, where is the danger lurking? If we instruct a browser to issue a TRACE request to the web server, and this browser has a cookie for that domain, the cookie will be automatically included in the request headers, and will therefore echoed back in the resulting response. At that point, the cookie string will be accessible by JavaScript and it will be finally possible to send it to a third party even when the cookie is tagged as httpOnly.

There are multiple ways to make a browser issue a TRACE request, as the XMLHTTP ActiveX control in Internet Explorer and XMLDOM in Mozilla and Netscape. However, for security reasons the browser is allowed to start a connection only to the domain where the hostile script resides. This is a mitigating factor, as the attacker needs to combine the TRACE method with another vulnerability in order to mount the attack. Basically, an attacker has two ways to successfully launch a Cross Site Tracing attack:

* 1.Leveraging another server-side vulnerability: the attacker injects the hostile JavaScript snippet, that contains the TRACE request, in the vulnerable application, as in a normal Cross Site Scripting attack
* 2.Leveraging a client-side vulnerability: the attacker creates a malicious website that contains the hostile JavaScript snippet and exploits some cross-domain vulnerability of the browser of the victim, in order to make the JavaScript code successfully perform a connection to the site that supports the TRACE method and that originated the cookie that the attacker is trying to steal.

More detailed information, together with code samples, can be found in the original whitepaper written by Jeremiah Grossman. 

== Black Box Testing of HTTP method tampering ==

Testing for HTTP method tampering is essentially the same as testing for XST.

=== Testing for arbitrary HTTP methods ===

Find a page you'd like to visit that has a security constraint such that it would normally force a 302 redirect to a login page or forces a login directly. The test URL in this example works like this - as do many web applications. However, if you obtain a "200" response that is not a login page, it is possible to bypass authentication and thus authorization.

<pre>
[rapidoffenseunit:~] vanderaj% nc www.example.com 80
JEFF / HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:38:40 GMT
Server: Apache
Set-Cookie: PHPSESSID=K53QW...
</pre>

If your framework or firewall or application does not support the "JEFF" method, it should issue an error page (or preferably a 405 Not Allowed or 501 Not implemented error page). If it services the request, it is vulnerable to this issue.

If you feel that the system is vulnerable to this issue, issue CSRF-like attacks to exploit the issue more fully:

* FOOBAR /admin/createUser.php?member=myAdmin
* JEFF /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
* CATS /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

With some luck, using the above three commands - modified to suit the application under test and testing requirements - a new user would be created, a password assigned, and made an admin.

=== Testing for HEAD access control bypass ===

Find a page you'd like to visit that has a security constraint such that it would normally force a 302 redirect to a login page or forces a login directly. The test URL in this example works like this - as do many web applications. However, if you obtain a "200" response that is not a login page, it is possible to bypass authentication and thus authorization.

<pre>
[rapidoffenseunit:~] vanderaj% nc www.example.com 80
HEAD /admin HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:44:11 GMT
Server: Apache
Set-Cookie: PHPSESSID=pKi...; path=/; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: adminOnlyCookie1=...; expires=Tue, 18-Aug-2009 22:44:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie2=...; expires=Mon, 18-Aug-2008 22:54:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie3=...; expires=Sun, 19-Aug-2007 22:44:30 GMT; domain=www.example.com
Content-Language: EN
Connection: close
Content-Type: text/html; charset=ISO-8859-1
</pre>

If you get a "405 Method not allowed" or "501 Method Unimplemented", the application/framework/language/system/firewall is working correctly. If a "200" response code comes back, and the response contains no body, it's likely that the application has processed the request without authentication or authorization and further testing is warranted.

If you feel that the system is vulnerable to this issue, issue CSRF-like attacks to exploit the issue more fully:

* HEAD /admin/createUser.php?member=myAdmin
* HEAD /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
* HEAD /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

With some luck, using the above three commands - modified to suit the application under test and testing requirements - a new user would be created, a password assigned, and made an admin, all using blind request submission.

== Gray Box testing and example ==
The testing in a Gray Box scenario follows the same steps of a Black Box scenario
 
== References ==
'''Whitepapers''' 
* RFC 2616: “Hypertext Transfer Protocol -- HTTP/1.1”
* RFC 2109 and RFC 2965: “HTTP State Management Mechanism”
* Jeremiah Grossman: "Cross Site Tracing (XST)" - http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf 
* Amit Klein: "XS(T) attack variants which can, in some cases, eliminate the need for TRACE" - http://www.securityfocus.com/archive/107/308433
* Arshan Dabirsiaghi: "Bypassing VBAAC with HTTP Verb Tampering" - http://www.aspectsecurity.com/documents/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf

'''Tools'''
* NetCat - http://www.vulnwatch.org/netcat

OWASP Testing Guide v3 Table of Contents

2008-08-24T05:13:14Z

Mr fusion: /* 4. (M.Meucci) Web Application Penetration Testing */

__NOTOC__

This is the draft of table of content of the New Testing Guide.
You can download the stable version [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_pdf.zip here]

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

Testing Guide v3 (draft)
Updated: 23rd August 2008
(new)--> new articles, (toimp)--> needs to improve or to review, (xxx%) --> current state of the article

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

==[[Testing Guide Foreword|(toimp)Foreword by OWASP Chair]]==

==[[Testing Guide Frontispiece |(toimp: M.Meucci)1. Frontispiece]]==

'''[[Testing Guide Frontispiece|(toimp: M.Meucci)1.1 About the OWASP Testing Guide Project]]'''

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''

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

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

(new: M. Morana 90%) 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]

(new: M. Morana 100%) 2.4.1 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Tests_Integrated_in_Developers_and_Testers_Workflow Security tests integrated in developers and testers workflows]

(new: M. Morana 100%) 2.4.2 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Developers.27_Security_Tests Developers' security tests: unit tests and component level tests]

(new: M. Morana 90%) 2.4.3 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_Testers.27_Security_Tests Functional testers' security tests: integrated system tests, tests in UAT, and production environment]

(new: M. Morana 100%) 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. (M.Meucci) Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']]

[[Testing Checklist| (new: M.Meucci - 100% ) 4.1.1 Testing Checklist]]

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

[[Testing: Spiders Robots and Crawlers|(new:C.Heinrich - 0%)4.2.1 Spiders, Robots and Crawlers]]

[[Testing: Search engine discovery|(new:C.Heinrich - 0%)4.2.2 Search Engine Discovery/Reconnaissance]]

[[Testing: Identify application entry points| (new: K.Horvath - 100%) 4.2.3 Identify application entry points]]

[[Testing for Web Application Fingerprint|4.2.4 Testing for Web Application Fingerprint]]

[[Testing for Application Discovery|4.2.5 Application Discovery]]

[[Testing for Error Code|4.2.6 Analysis of Error Codes]]

[[Testing for configuration management|''' (new) 4.3 Configuration Management Testing''']]

[[Testing for SSL-TLS| 4.3.1 SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity]] 

[[Testing for DB Listener|4.3.2 DB Listener Testing]]

[[Testing for infrastructure configuration management| (new) 4.3.3 Infrastructure Configuration Management Testing]]

[[Testing for application configuration management|4.3.4 Application Configuration Management Testing]]

[[Testing for file extensions handling|4.3.5 Testing for File Extensions Handling]]

[[Testing for old_file|4.3.6 Old, Backup and Unreferenced Files]]

[[Testing for Admin Interfaces|(Adam - 100%) 4.3.7 Infrastructure and Application Admin Interfaces]]

[[Testing for HTTP Methods and XST| (imp: A. van der Stock - 100%)4.3.8 Testing for HTTP Methods and XST]]

[[Testing for business logic|'''(K.Horvath - 100%) 4.4 Business Logic Testing''']]

[[Testing for authentication|'''(M.Meucci - 100%) 4.5 Authentication Testing''']]

[[Testing for credentials transport|(new: G.Ingrosso - 100%) 4.5.1 Credentials transport over an encrypted channel]]

[[Testing for user enumeration|(new: M.Meucci, M.Mella - 90%) 4.5.2 Testing for user enumeration]]

[[Testing for Default or Guessable User Account|(to imp: K.Horvath - 100%) 4.5.3 Testing for Guessable (Dictionary) User Account]]

[[Testing for Brute Force|4.5.4 Brute Force Testing]]

[[Testing for Bypassing Authentication Schema|4.5.5 Testing for bypassing authentication schema]]

[[Testing for Vulnerable Remember Password and Pwd Reset|4.5.6 Testing for vulnerable remember
password and pwd reset]]

[[Testing for Logout and Browser Cache Management|4.5.7 Testing for Logout and Browser Cache Management Testing]]

[[Testing for Captcha|(new: P.Luptak - 100% ) 4.5.8 Testing for CAPTCHA]]

[[Testing Multiple Factors Authentication| (new: G.Fedon) 4.5.9 Testing Multiple Factors Authentication]]

[[Testing for Race Conditions| (new: Adam - 100%) 4.5.10 Testing for Race Conditions]]

[[Testing for Authorization|'''(new: M.Meucci - 100%) 4.6 Authorization testing''']]

[[Testing for Path Traversal|(new) 4.6.1 Testing for path traversal]]

[[Testing for Bypassing Authorization Schema|(new: M.Meucci - 100%)4.6.2 Testing for bypassing authorization schema]]

[[Testing for Privilege escalation|(new: Cecil Su, M.Meucci - 100%)4.6.3 Testing for Privilege Escalation]]

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

[[Testing for Session_Management_Schema|(new: M.Meucci - 100%) 4.7.1 Testing for Session Management Schema]]

[[Testing for cookies attributes| (new: K.Horvath - 100%) 4.7.2 Testing for Cookies attributes]]

[[Testing for Session Fixation| (new: M.Meucci - 100%) 4.7.3 Testing for Session Fixation]]

[[Testing for Exposed Session Variables|4.7.4 Testing for Exposed Session Variables ]]

[[Testing for CSRF|4.7.5 Testing for CSRF]]

[[Testing for HTTP Exploit|4.7.6 Testing for HTTP Exploit ]]

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

[[Testing for Reflected Cross site scripting|(new: A. Coronel -100%)4.8.1 Testing for Reflected Cross Site Scripting]]

[[Testing for Stored Cross site scripting|(new: R. Suggi Liverani - 100%)4.8.2 Testing for Stored Cross Site Scripting]]

[[Testing for DOM-based Cross site scripting|(new: A.Agarwwal, Kuza55 - 80%) 4.8.3 Testing for DOM based Cross Site Scripting]]

[[Testing for Cross site flashing|(new: A.Agarwwal, S.Di Paola - 0%)4.8.4 Testing for Cross Site Flashing]]

[[Testing for SQL Injection| 4.8.5 Testing for SQL Injection ]]

[[Testing for Oracle|4.8.5.1 Oracle Testing ]]

[[Testing for MySQL|4.8.5.2 MySQL Testing ]]

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

[[Testing for MS Access|(new:A.Parata - 90%) 4.8.5.4 MS Access Testing]]

[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.5.5 (new: D.Bellucci 100% from OWASP BSP) Testing PostgreSQL]]

[[Testing for LDAP Injection|4.8.6 Testing for LDAP Injection]]

[[Testing for ORM Injection|4.8.7 Testing for ORM Injection]]

[[Testing for XML Injection|4.8.8 Testing for XML Injection]]

[[Testing for SSI Injection|4.8.9 Testing for SSI Injection]]

[[Testing for XPath Injection|4.8.10 Testing for XPath Injection]]

[[Testing for IMAP/SMTP Injection|4.8.11 IMAP/SMTP Injection]]

[[Testing for Code Injection|4.8.12 Testing for Code Injection]]

[[Testing for Command Injection|4.8.13 Testing for Command Injection]]

[[Testing for Buffer Overflow|4.8.14 Testing for Buffer overflow]]

[[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|4.8.15 Testing for incubated vulnerabilities]]

[[Testing for Denial of Service|'''4.9 Testing for Denial of Service''']]

[[Testing for SQL Wildcard Attacks|(new: F.Mavituna - 100%) 4.9.1 Testing for SQL Wildcard Attacks]]

[[Testing for DoS Locking Customer Accounts|4.9.2 Testing for DoS Locking Customer Accounts]]

[[Testing for DoS Buffer Overflows|4.9.3 Testing for DoS Buffer Overflows]]

[[Testing for DoS User Specified Object Allocation|4.9.4 Testing for DoS User Specified Object Allocation]]

[[Testing for User Input as a Loop Counter|4.9.5 Testing for User Input as a Loop Counter]]

[[Testing for Writing User Provided Data to Disk|4.9.6 Testing for Writing User Provided Data to Disk]]

[[Testing for DoS Failure to Release Resources|4.9.7 Testing for DoS Failure to Release Resources]]

[[Testing for Storing too Much Data in Session|4.9.8 Testing for Storing too Much Data in Session]]

[[Testing for Web Services|(toimp: M.Meucci -100%) '''4.10 Web Services Testing''']]

[[Testing: WS Information Gathering|(new: M.Meucci -100%) 4.10.1 WS Information Gathering]]

[[Testing WSDL|(new: M.Meucci -100%) 4.10.2 Testing WSDL]]

[[Testing for XML Structural|(toimp: M.Meucci -100%)4.10.3 XML Structural Testing ]]

[[Testing for XML Content-Level|4.10.4 XML Content-level Testing ]]

[[Testing for WS HTTP GET parameters/REST attacks|4.10.5 HTTP GET parameters/REST Testing ]]

[[Testing for Naughty SOAP Attachments|4.10.6 Naughty SOAP attachments ]]

[[Testing for WS Replay|4.10.7 Replay Testing ]]

[[Testing_for_AJAX:_introduction|'''4.11 AJAX Testing''']]

[[Testing for AJAX Vulnerabilities|4.11.1 AJAX Vulnerabilities]]

[[Testing for AJAX|4.11.2 How to test AJAX]]

==[[Writing Reports: value the real risk |(toimp: Mat)5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]]

[[How to write the report of the testing |5.2 How to write the report of the testing]]

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

* Black Box Testing Tools
* Source Code Analyzers
* Other Tools

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers
* Books
* Useful Websites

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

* Fuzz Categories
** Recursive fuzzing
** Replasive fuzzing
* Cross Site Scripting (XSS)
* Buffer Overflows and Format String Errors
** Buffer Overflows (BFO)
** Format String Errors (FSE)
** Integer Overflows (INT)
* SQL Injection
** Passive SQL Injection (SQP)
** Active SQL Injection (SQI)
* LDAP Injection
* XPATH Injection

==[[OWASP Testing Guide Appendix D: Encoded Injection | (new: Harish S.)Appendix D: Encoded Injection]]==

----

[[Category:OWASP Testing Project]]

Testing for Race Conditions (OWASP-AT-010)

2008-08-24T05:10:27Z

Mr fusion: /* Description of the Issue */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
A race condition is a flaw that produces an unexpected result when timing of actions impact other actions. An example may be seen on a multithreaded application where actions are being performed on the same data. Race conditions, by their very nature, are difficult to test for.

==Description of the Issue==
Race conditions may occur when a process is critically or unexpectedly dependent on the sequence or timings of other events.
In a web application environment, where multiple requests can be processed at a given time, developers may leave concurrency to be handled
by the framework, server or programming language.
The following simplified example illustrates a potential concurrency problem in a transactional web application and relates to a joint savings account in which both users (threads) are logged into the same account and attempting a transfer. 
 
Account A has 100 credits. 
Account B has 100 credits. 
 
Both User 1 and User 2 want to transfer 10 credits from Account A to Account B. If the transaction was correct the outcome should be: 
 
Account A has 80 credits. 
Account B has 120 credits. 
 
However, due to concurrency issues, the following result could be obtained: 
 
User 1 checks the value of Account A (=100 credits) 
User 2 checks the value of Account A (=100 credits) 
User 2 takes 10 credits from Account A (=90 credits) and put it in Account B (=110 credits) 
User 1 takes 10 credits from Account A (Still believed to contain 100 credits) (=90 credits) and puts it into Account B (=120 credits). 
 
Result:
Account A has 90 credits. 
Account B has 120 credits. 
 

Another example can be seen in OWASP's WebGoat project under the Thread Safety lesson and shows how a shopping cart can be manipulated to purchase items for less than their advertised price. This, as with the example above, is due to the data changing between the time of check and its time of use.

==Black Box testing and example==
Testing for race conditions is problematic due to their nature, and external influences on testing including server load, network latency etc will all play a part in the presence and detection of the condition. 
Attempts to force a race condition may include the ability to make multiple simultaneous requests while observing the outcome for unexpected behavior.

==Gray Box testing and example==

Code review may reveal likely areas of concern for concurrency issues. More information on reviewing code for concurrency issues can be seen at: 
http://www.owasp.org/index.php/Reviewing_Code_for_Race_Conditions

==References==

iSec Partners - Concurrency attacks in Web Applications http://isecpartners.com/files/iSEC%20Partners%20-%20Concurrency%20Attacks%20in%20Web%20Applications.pdf 
B. Sullivan and B. Hoffman - Premature Ajax-ulation and You https://www.blackhat.com/presentations/bh-usa-07/Sullivan_and_Hoffman/Whitepaper/bh-usa-07-sullivan_and_hoffman-WP.pdf 
Thread Safety Challenge in WebGoat - http://www.owasp.org/index.php/OWASP_WebGoat_Project

Testing for Race Conditions (OWASP-AT-010)

2008-08-24T05:06:48Z

Mr fusion: /* References */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
A race condition is a flaw that produces an unexpected result when timing of actions impact other actions. An example may be seen on a multithreaded application where actions are being performed on the same data. Race conditions, by their very nature, are difficult to test for.

==Description of the Issue==
Race conditions may occur when a process is critically or unexpectedly dependent on the sequence or timings of other events.
In a web application environment, where multiple requests can be processed at a given time, developers may leave concurrency to be handled
by the framework, server or programming language.
The following simplified example illustrates a potential concurrency problem in a transactional web application and relates to a joint savings account in which both users (threads) are logged into the same account and attempting a transfer. 
 
Account A has 100 credits. 
Account B has 100 credits. 
 
Both User 1 and User 2 want to transfer 10 credits from Account A to Account B. If the transaction was correct the outcome should be: 
 
Account A has 80 credits. 
Account B has 120 credits. 
 
However, due to concurrency issues, the following result could be obtained: 
 
User 1 checks the value of Account A (=100 credits) 
User 2 checks the value of Account A (=100 credits) 
User 2 takes 10 credits from Account A (=90 credits) and put it in Account B (=110 credits) 
User 1 takes 10 credits from Account A (Still believed to contain 100 credits) (=90 credits) and puts it into Account B (=120 credits). 
 
Result:
Account A has 90 credits. 
Account B has 120 credits. 
 

==Black Box testing and example==
Testing for race conditions is problematic due to their nature, and external influences on testing including server load, network latency etc will all play a part in the presence and detection of the condition. 
Attempts to force a race condition may include the ability to make multiple simultaneous requests while observing the outcome for unexpected behavior.

==Gray Box testing and example==

Code review may reveal likely areas of concern for concurrency issues. More information on reviewing code for concurrency issues can be seen at: 
http://www.owasp.org/index.php/Reviewing_Code_for_Race_Conditions

==References==

iSec Partners - Concurrency attacks in Web Applications http://isecpartners.com/files/iSEC%20Partners%20-%20Concurrency%20Attacks%20in%20Web%20Applications.pdf 
B. Sullivan and B. Hoffman - Premature Ajax-ulation and You https://www.blackhat.com/presentations/bh-usa-07/Sullivan_and_Hoffman/Whitepaper/bh-usa-07-sullivan_and_hoffman-WP.pdf 
Thread Safety Challenge in WebGoat - http://www.owasp.org/index.php/OWASP_WebGoat_Project

Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

2008-08-24T04:55:52Z

Mr fusion: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.
 

== Description of the Issue ==
 
An application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. Such changes may include:

- user account provisioning 
- Site design and layout 
- data manipultion 
- configuration changes 

In many instances, such interfaces are usually implemented with little thought of how to separate them from the normal users of the site. Testing is aimed at discovering these administrator interfaces and accessing functionality intended for the privileged users.
 

== Black Box testing and example ==
The following describes vectors that may be used to test for the presence of administrative interfaces. These techniques may also be used for testing for related issues including privilege escalation and are described elsewhere in this guide in greater detail: 

* Directory and file Enumeration - An administrative interface may be present but not visibly available to the tester. Attempting to guess the path of the administrative interface may be as simple as requesting:
/admin or /administrator etc.. 
A tester may have to also identify the filename of the administration page. Forcible browsing to the identified page may provide access to the interface.

* Comments and links in Source - Many sites use common code that is loaded for all site users. By examining all source sent to the client, links to administrator functionality may be discovered and should be investigated.

* Reviewing Server and Application Documentation - If the application server or application is deployed in its default configuration it may be possible to access the administration interface using information described in configuration or help documentation. Default password lists should be consulted if an administrative interface is found and credentials are required.

* Alternative Server Port - Administration interfaces may be seen on a different port on the host than the main application. For example, Apache Tomcat's Administration interface can often be seen on port 8080.

* Parameter Tampering - A GET or POST parameter or a cookie variable may be required to enable the administrator functionality. Clues to this
include the presence of hidden fields such as:

<input type="hidden" name="admin" value="no"> or in a cookie: Cookie: session_cookie; useradmin=0
 
Once an administrative interface has been discovered, a combination of the above techniques may be used to attempt to bypass authentication. If this fails, the
tester may wish to attempt a brute force attack. In such an instance the tester should be aware of the potential for administrative account lockout if such functionality is present.

== Gray Box testing and example ==
An examination of the server and application components should be undertaken to ensure hardening (i.e. administrator pages are not accessible to everyone through the use of IP filtering or other controls), and where applicable, verification that all components do not use default credentials or configurations.
 
Source code should be reviewed to ensure that the authorization and authentication model ensures clear separation of duties between normal users and site administrators. User interface functions shared between normal and administrator users should be reviewed to ensure clear separation between the drawing of such components and information leakage from such shared functionality.
 

== References ==
* Default Password list: http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php

Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

2008-08-24T04:55:02Z

Mr fusion: /* Gray Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.
 

== Description of the Issue ==
 
An application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. Such changes may include:

- user account provisioning 
- Site design and layout 
- data manipultion 
- configuration changes 

In many instances, such interfaces are usually implemented with little thought of how to separate them from the normal users of the site. Testing is aimed at discovering these administrator interfaces and accessing functionality intended for the privileged users.
 

== Black Box testing and example ==
The following describes vectors that may be used to test for the presence of administrative interfaces. These techniques may also be used for testing for related issues including privilege escalation and are described elsewhere in this guide in greater detail: 

* Directory and file Enumeration - An administrative interface may be present but not visibly available to the tester. Attempting to guess the path of the administrative interface may be as simple as requesting:
/admin or /administrator etc.. 
A tester may have to also identify the filename of the administration page. Forcible browsing to the identified page may provide access to the interface.

* Comments and links in Source - Many sites use common code that is loaded for all site users. By examining all source sent to the client, links to administrator functionality may be discovered and should be investigated.

* Reviewing Server and Application Documentation - If the application server or application is deployed in its default configuration it may be possible
to access the administration interface using information described in configuration or help documentation. Default password lists should be consulted if an administrative interface is found and credentials are required.

* Alternative Server Port - Administration interfaces may be seen on a different port on the host than the main application. For example, Apache Tomcat's Administration interface can often be seen on port 8080.

* Parameter Tampering - A GET or POST parameter or a cookie variable may be required to enable the administrator functionality. Clues to this
include the presence of hidden fields such as:

<input type="hidden" name="admin" value="no"> or in a cookie: Cookie: session_cookie; useradmin=0
 
Once an administrative interface has been discovered, a combination of the above techniques may be used to attempt to bypass authentication. If this fails, the
tester may wish to attempt a brute force attack. In such an instance the tester should be aware of the potential for administrative account lockout if such functionality is present.

== Gray Box testing and example ==
An examination of the server and application components should be undertaken to ensure hardening (i.e. administrator pages are not accessible to everyone through the use of IP filtering or other controls), and where applicable, verification that all components do not use default credentials or configurations.
 
Source code should be reviewed to ensure that the authorization and authentication model ensures clear separation of duties between normal users and site administrators. User interface functions shared between normal and administrator users should be reviewed to ensure clear separation between the drawing of such components and information leakage from such shared functionality.
 

== References ==
* Default Password list: http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php

OWASP Testing Project v3 Roadmap

2008-08-23T19:45:55Z

Mr fusion:

'''OWASP Testing Guide v3 Roadmap'''

* '''26th April 2008: start the new project'''
OWASP Leaders brainstorming.
 Call for participation.
 [http://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Startup Index brainstorming]
 [http://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Table_of_Contents Index draft]
 Discuss th article content.
 Deadline: Sun 18th May 2008.

* '''20th May 2008'''
New draft Index

* '''25th May 2008'''
'''Updated index:'''
Added or to improve:

(toimp)1. Frontispiece

(toimp)1.1 About the OWASP Testing Guide Project

(new) 2.4 Security requirements test derivation, functional and non functional test requirements, and test cases through use and misuse cases

(new) 2.4.1 Security tests integrated in developers and testers workflows

(new) 2.4.2 Developers' security tests: Unit Tests, component level tests, etc

(new) 2.4.3 Functional testers' security tests: integrated system tests, tests in UAT, and production environment

(new) 2.5 Security test data analysis and reporting: root cause identification and business/role case test data reporting

4. (toimp) Web Application Penetration Testing

4.1 Introduction and Objectives

(new) 4.1.1 Testing Checklist

(toimp) 4.2 Information Gathering

(new)4.2.1 Spiders, Robots and Crawlers

(new) 4.2.2 Search Engine Discovery/Reconnaissance

(new) 4.2.3 Identify application entry points

4.2.3 (toimp) Testing for Web Application Fingerprint

(toimp)4.2.5 Analysis of Error Codes

(new) 4.3 Configuration Management Testing

(toimp) 4.3.1 SSL/TLS Testing (SSL Version, Alghoritms, Key lenght, Digital Cert. Validity

(toimp) 4.3.3 Application Configuration Management Testing

(new) 4.3.4 Testing for misconfiguration

(new) 4.3.7 Infrastructure and Application Admin Interfaces

(toimp)4.4 Business Logic Testing

(toimp)4.5 Authentication Testing

(new)4.5.1 Credentials transport over an encrypted channel

(new) 4.5.2 Testing for user enumeration

(to imp) 4.5.2 Testing for Guessable (Dictionary) User Account

(new) 4.6 Authorization testing

(new) 4.6.1 Testing for Path Traversal

(new)4.6.2 Testing for bypassing authorization schema

(new)4.6.3 Testing for Privilege Escalation

(new)4.7.2 Test the token strength (old 4.5.2 Testing for Cookie and Session Token Manipulation)

(new) 4.7.3 Testing for Cookies attributes

(new)4.8.1 Testing for Reflected Cross Site Scripting

(new)4.8.2 Testing for Stored Cross Site Scripting

(new) 4.8.3 Testing for DOM based Cross Site Scripting

(new)4.8.4 Testing for Cross Site Flashing

(toimp) 4.8.1.1 Testing for XST

(toimp) 4.8.2 Testing for SQL Injection

(toimp) 4.10 Web Services Testing

(new)4.11 Client site testing

(new) 4.11.1 AJAX Testing

(new)4.11.2 Flash Testing

(new)4.11.3 RIA Testing

(toimp: Mat)5. Writing Reports: value the real risk

* '''26th May 2008'''
Added:
 4.3.8 Testing for HTTP Methods and XST in Infrastucture and Application Testing section
 Sent Paragraph Template to the list
 Sent new index to the list

* '''28th May 2008'''
Added:
New Testing Guide checklist.

* '''30th May 2008'''
Added:
 Session Fixation
 Discuss abouut new Aspect paper about HTTP verb manipulation

* '''1st June 2008'''
Les's start writing!

* '''15th June 2008'''
Added:
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.3 Identify application entry points 
2.4 Security requirements test derivation,functional and non functional test requirements, and test cases through use and misuse cases 
4.4 Business Logic Testing 
4.6 Authorization testing 
4.5.3 Testing for Guessable (Dictionary) User Account 
4.6 Authorization testing 
4.6.2 Testing for Bypassing Authorization Schema 
4.6.3 Testing for Privilege Escalation 

* '''29th June 2008'''
Written (M.Meucci):
Testing_for_user_enumeration

* '''7th July 2008'''
Written:
Testing_for_Default_or_Guessable_User_Account (K.Horvath) 
Testing_for_business_logic (K.Horvath)

* '''9th July 2008'''
Testing_for_cookies_attributes (K.Horvath)

* '''12th August 2008'''
Articles reviewed/written (M.Meucci): 
Testing:_Introduction_and_objectives 
Testing_Checklist 
4.3 Configuration Management Testing 
4.2 Information Gathering 

* '''13 August 2008'''
Reviewed (M.Meucci): 
Testing_for_business_logic
Testing_for_SQL_Wildcard_Attacks (Rick.mitchell) 
Added: 
(new: G.Fedon) 4.5.9 Testing Multiple Factors Authentication 
Written (M.Meucci): 
Testing_for_authentication

* '''14 August 2008'''
Reviewed (M.Meucci):
Testing_for_credentials_transport 
Written (M.Meucci): 
Testing_for_user_enumeration (M.Mella) 
Testing_for_authorization 
Testing_for_Session_Management 
merged the 2 articles: 
Testing for Session_Management_Schema 
Testing for Cookie and Session Token Manipulation 
Now we have a new one: Testing for Session_Management_Schema 

* '''15 August 2008'''
Testing_for_Session_Fixation 

* '''16th August 2008'''
Reviewed (M.Cova): 
4.2 Information Gathering 
4.3 Configuration Management Testing 
4.5 Authentication Testing 

* '''18th August 2008'''
Reviewed (M.Cova): 
4.6 Authorization testing 
Written (A.van der Stock): 
Testing_for_HTTP_Methods_and_XST (HTTP Verb) 

* '''20th August 2008'''
Reviewed (M.Cova): 
Web Services 
Written (A.Parata): 
4.8.5.4 MS Access Testing

* '''21st August 2008'''
Updated (M.Meucci): 
Testing_for_Session_Fixation 
Testing_for_Bypassing_Authorization_Schema 
Testing_for_Privilege_escalation 

* '''22nd August 2008'''
Writing (Adam):
Testing_for_Admin_Interfaces 
Update/Write: 
(imp: M.Meucci -100%) 4.10 Web Services Testing 
(new: M.Meucci -100%) 4.10.1 WS Information Gathering 
(new: M.Meucci -100%) 4.10.2 Testing WSDL 
(imp: M.Meucci -100%)4.10.3 XML Structural Testing 
Improved: 
Testing_for_Data_Validation 

* '''23rd August 2008'''
Deleted: 
Client Side Testing (we have not time to finish this section: we can focus on DOM XSS and Cross Site Flashing articles) 
Added: 
AJAX Testing 
Updated: 
(new: M.Meucci) 4.1.1 Testing Checklist 

----
'''TODO:''' 
Article to finish: 
(new:C.Heinrich - 0%)4.2.1 Spiders, Robots and Crawlers 
(new:C.Heinrich - 0%)4.2.2 Search Engine Discovery/Reconnaissance 
(new: M.Meucci, M.Mella - 90%) 4.5.2 Testing for user enumeration 
(new: G.Fedon) 4.5.9 Testing Multiple Factors Authentication 
(new: A.Agarwwal, Kuza55 - 80%) 4.8.3 Testing for DOM based Cross Site Scripting 
(new: A.Agarwwal, S.Di Paola - 0%)4.8.4 Testing for Cross Site Flashing 
Articles to review: 
MS Access Testing 
Testing PostgreSQL 
Testing for Race Conditions 
Infrastructure and Application Admin Interfaces 
----
'''Project deadlines:'''
# 21st May: Project status presentation at the OWASP AppSec Euro 08 Conference in Belgium.
# 15th June - Participants to report on project status.
# 24th August - Finish the writing phase.
# 15th September - Project completion. Participants should deliver final project report.

Testing for Race Conditions (OWASP-AT-010)

2008-08-23T19:44:49Z

Mr fusion: /* Gray Box testing and example */

Testing for Race Conditions (OWASP-AT-010)

2008-08-23T19:39:05Z

Mr fusion: /* Black Box testing and example */

Testing for Race Conditions (OWASP-AT-010)

2008-08-23T19:30:41Z

Mr fusion: /* Description of the Issue */

Testing for Race Conditions (OWASP-AT-010)

2008-08-23T19:29:50Z

Mr fusion: /* Description of the Issue */

Testing for Race Conditions (OWASP-AT-010)

2008-08-23T19:07:38Z

Mr fusion: New page: {{Template:OWASP Testing Guide v3}} == Brief Summary == A race condition is a flaw that produces an unexpected result when timing of actions impact other actions. An example may be seen o...

OWASP Testing Guide v3 Table of Contents

2008-08-23T18:55:50Z

Mr fusion: /* 4. (M.Meucci) Web Application Penetration Testing */

__NOTOC__

This is the draft of table of content of the New Testing Guide.
You can download the stable version [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_pdf.zip here]

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

Testing Guide v3 (draft)
Updated: 23rd August 2008
(new)--> new articles, (toimp)--> needs to improve or to review, (xxx%) --> current state of the article

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

==[[Testing Guide Foreword|(toimp)Foreword by OWASP Chair]]==

==[[Testing Guide Frontispiece |(toimp: M.Meucci)1. Frontispiece]]==

'''[[Testing Guide Frontispiece|(toimp: M.Meucci)1.1 About the OWASP Testing Guide Project]]'''

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''

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

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

(new: M. Morana 90%) 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]

(new: M. Morana 100%) 2.4.1 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Tests_Integrated_in_Developers_and_Testers_Workflow Security tests integrated in developers and testers workflows]

(new: M. Morana 100%) 2.4.2 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Developers.27_Security_Tests Developers' security tests: unit tests and component level tests]

(new: M. Morana 90%) 2.4.3 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_Testers.27_Security_Tests Functional testers' security tests: integrated system tests, tests in UAT, and production environment]

(new: M. Morana 100%) 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. (M.Meucci) Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']]

[[Testing Checklist| (new: M.Meucci - 100% ) 4.1.1 Testing Checklist]]

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

[[Testing: Spiders Robots and Crawlers|(new:C.Heinrich - 0%)4.2.1 Spiders, Robots and Crawlers]]

[[Testing: Search engine discovery|(new:C.Heinrich - 0%)4.2.2 Search Engine Discovery/Reconnaissance]]

[[Testing: Identify application entry points| (new: K.Horvath - 100%) 4.2.3 Identify application entry points]]

[[Testing for Web Application Fingerprint|4.2.4 Testing for Web Application Fingerprint]]

[[Testing for Application Discovery|4.2.5 Application Discovery]]

[[Testing for Error Code|4.2.6 Analysis of Error Codes]]

[[Testing for configuration management|''' (new) 4.3 Configuration Management Testing''']]

[[Testing for SSL-TLS| 4.3.1 SSL/TLS Testing (SSL Version, Alghoritms, Key lenght, Digital Cert. Validity]] 

[[Testing for DB Listener|4.3.2 DB Listener Testing]]

[[Testing for infrastructure configuration management| (new) 4.3.3 Infrastructure Configuration Management Testing]]

[[Testing for application configuration management|4.3.4 Application Configuration Management Testing]]

[[Testing for file extensions handling|4.3.5 Testing for File Extensions Handling]]

[[Testing for old_file|4.3.6 Old, Backup and Unreferenced Files]]

[[Testing for Admin Interfaces|(Adam - 100%) 4.3.7 Infrastructure and Application Admin Interfaces]]

[[Testing for HTTP Methods and XST| (imp: A. van der Stock - 100%)4.3.8 Testing for HTTP Methods and XST]]

[[Testing for business logic|'''(K.Horvath - 100%) 4.4 Business Logic Testing''']]

[[Testing for authentication|'''(M.Meucci - 100%) 4.5 Authentication Testing''']]

[[Testing for credentials transport|(new: G.Ingrosso - 100%) 4.5.1 Credentials transport over an encrypted channel]]

[[Testing for user enumeration|(new: M.Meucci, M.Mella - 90%) 4.5.2 Testing for user enumeration]]

[[Testing for Default or Guessable User Account|(to imp: K.Horvath - 100%) 4.5.3 Testing for Guessable (Dictionary) User Account]]

[[Testing for Brute Force|4.5.4 Brute Force Testing]]

[[Testing for Bypassing Authentication Schema|4.5.5 Testing for bypassing authentication schema]]

[[Testing for Vulnerable Remember Password and Pwd Reset|4.5.6 Testing for vulnerable remember
password and pwd reset]]

[[Testing for Logout and Browser Cache Management|4.5.7 Testing for Logout and Browser Cache Management Testing]]

[[Testing for Captcha|(new: P.Luptak - 100% ) 4.5.8 Testing for CAPTCHA]]

[[Testing Multiple Factors Authentication| (new: G.Fedon) 4.5.9 Testing Multiple Factors Authentication]]

[[Testing for Race Conditions| (new: Adam) 4.5.10 Testing for Race Conditions]]

[[Testing for Authorization|'''(new: M.Meucci - 100%) 4.6 Authorization testing''']]

[[Testing for Path Traversal|(new) 4.6.1 Testing for path traversal]]

[[Testing for Bypassing Authorization Schema|(new: M.Meucci - 100%)4.6.2 Testing for bypassing authorization schema]]

[[Testing for Privilege escalation|(new: Cecil Su, M.Meucci - 100%)4.6.3 Testing for Privilege Escalation]]

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

[[Testing for Session_Management_Schema|(new: M.Meucci - 100%) 4.7.1 Testing for Session Management Schema]]

[[Testing for cookies attributes| (new: K.Horvath - 100%) 4.7.2 Testing for Cookies attributes]]

[[Testing for Session Fixation| (new: M.Meucci - 100%) 4.7.3 Testing for Session Fixation]]

[[Testing for Exposed Session Variables|4.7.4 Testing for Exposed Session Variables ]]

[[Testing for CSRF|4.7.5 Testing for CSRF]]

[[Testing for HTTP Exploit|4.7.6 Testing for HTTP Exploit ]]

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

[[Testing for Reflected Cross site scripting|(new: A. Coronel -100%)4.8.1 Testing for Reflected Cross Site Scripting]]

[[Testing for Stored Cross site scripting|(new: R. Suggi Liverani - 100%)4.8.2 Testing for Stored Cross Site Scripting]]

[[Testing for DOM-based Cross site scripting|(new: A.Agarwwal, Kuza55 - 80%) 4.8.3 Testing for DOM based Cross Site Scripting]]

[[Testing for Cross site flashing|(new: A.Agarwwal, S.Di Paola - 0%)4.8.4 Testing for Cross Site Flashing]]

[[Testing for SQL Injection| 4.8.5 Testing for SQL Injection ]]

[[Testing for Oracle|4.8.5.1 Oracle Testing ]]

[[Testing for MySQL|4.8.5.2 MySQL Testing ]]

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

[[Testing for MS Access|(new:A.Parata - 90%) 4.8.5.4 MS Access Testing]]

[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.5.5 (new: D.Bellucci 100% from OWASP BSP) Testing PostgreSQL]]

[[Testing for LDAP Injection|4.8.6 Testing for LDAP Injection]]

[[Testing for ORM Injection|4.8.7 Testing for ORM Injection]]

[[Testing for XML Injection|4.8.8 Testing for XML Injection]]

[[Testing for SSI Injection|4.8.9 Testing for SSI Injection]]

[[Testing for XPath Injection|4.8.10 Testing for XPath Injection]]

[[Testing for IMAP/SMTP Injection|4.8.11 IMAP/SMTP Injection]]

[[Testing for Code Injection|4.8.12 Testing for Code Injection]]

[[Testing for Command Injection|4.8.13 Testing for Command Injection]]

[[Testing for Buffer Overflow|4.8.14 Testing for Buffer overflow]]

[[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|4.8.15 Testing for incubated vulnerabilities]]

[[Testing for Denial of Service|'''4.9 Testing for Denial of Service''']]

[[Testing for SQL Wildcard Attacks|(new: F.Mavituna - 100%) 4.9.1 Testing for SQL Wildcard Attacks]]

[[Testing for DoS Locking Customer Accounts|4.9.2 Testing for DoS Locking Customer Accounts]]

[[Testing for DoS Buffer Overflows|4.9.3 Testing for DoS Buffer Overflows]]

[[Testing for DoS User Specified Object Allocation|4.9.4 Testing for DoS User Specified Object Allocation]]

[[Testing for User Input as a Loop Counter|4.9.5 Testing for User Input as a Loop Counter]]

[[Testing for Writing User Provided Data to Disk|4.9.6 Testing for Writing User Provided Data to Disk]]

[[Testing for DoS Failure to Release Resources|4.9.7 Testing for DoS Failure to Release Resources]]

[[Testing for Storing too Much Data in Session|4.9.8 Testing for Storing too Much Data in Session]]

[[Testing for Web Services|(toimp: M.Meucci -100%) '''4.10 Web Services Testing''']]

[[Testing: WS Information Gathering|(new: M.Meucci -100%) 4.10.1 WS Information Gathering]]

[[Testing WSDL|(new: M.Meucci -100%) 4.10.2 Testing WSDL]]

[[Testing for XML Structural|(toimp: M.Meucci -100%)4.10.3 XML Structural Testing ]]

[[Testing for XML Content-Level|4.10.4 XML Content-level Testing ]]

[[Testing for WS HTTP GET parameters/REST attacks|4.10.5 HTTP GET parameters/REST Testing ]]

[[Testing for Naughty SOAP Attachments|4.10.6 Naughty SOAP attachments ]]

[[Testing for WS Replay|4.10.7 Replay Testing ]]

[[Testing_for_AJAX:_introduction|'''4.11 AJAX Testing''']]

[[Testing for AJAX Vulnerabilities|4.11.1 AJAX Vulnerabilities]]

[[Testing for AJAX|4.11.2 How to test AJAX]]

==[[Writing Reports: value the real risk |(toimp: Mat)5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]]

[[How to write the report of the testing |5.2 How to write the report of the testing]]

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

* Black Box Testing Tools
* Source Code Analyzers
* Other Tools

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers
* Books
* Useful Websites

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

* Fuzz Categories
** Recursive fuzzing
** Replasive fuzzing
* Cross Site Scripting (XSS)
* Buffer Overflows and Format String Errors
** Buffer Overflows (BFO)
** Format String Errors (FSE)
** Integer Overflows (INT)
* SQL Injection
** Passive SQL Injection (SQP)
** Active SQL Injection (SQI)
* LDAP Injection
* XPATH Injection

==[[OWASP Testing Guide Appendix D: Encoded Injection | (new: Harish S.)Appendix D: Encoded Injection]]==

----

[[Category:OWASP Testing Project]]

Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

2008-08-23T18:03:03Z

Mr fusion: /* Gray Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.
 

== Description of the Issue ==
 
An application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. Such changes may include:

- user account provisioning 
- Site design and layout 
- data manipultion 
- configuration changes 

In many instances, such interfaces are usually implemented with little thought of how to separate them from the normal users of the site. Testing is aimed at discovering these administrator interfaces and accessing functionality intended for the privileged users.
 

== Black Box testing and example ==
The following describes vectors that may be used to test for the presence of administrative interfaces. These techniques may also be used for testing for related issues including privilege escalation and are described elsewhere in this guide in greater detail: 

* Directory and file Enumeration - An administrative interface may be present but not visibly available to the tester. Attempting to guess the path of the administrative interface may be as simple as requesting:
/admin or /administrator etc.. 
A tester may have to also identify the filename of the administration page. Forcible browsing to the identified page may provide access to the interface.

* Comments and links in Source - Many sites use common code that is loaded for all site users. By examining all source sent to the client, links to administrator functionality may be discovered and should be investigated.

* Reviewing Server and Application Documentation - If the application server or application is deployed in its default configuration it may be possible
to access the administration interface using information described in configuration or help documentation. Default password lists should be consulted if an administrative interface is found and credentials are required.

* Alternative Server Port - Administration interfaces may be seen on a different port on the host than the main application. For example, Apache Tomcat's Administration interface can often be seen on port 8080.

* Parameter Tampering - A GET or POST parameter or a cookie variable may be required to enable the administrator functionality. Clues to this
include the presence of hidden fields such as:

<input type="hidden" name="admin" value="no"> or in a cookie: Cookie: session_cookie; useradmin=0
 
Once an administrative interface has been discovered, a combination of the above techniques may be used to attempt to bypass authentication. If this fails, the
tester may wish to attempt a brute force attack. In such an instance the tester should be aware of the potential for administrative account lockout if such functionality is present.

== Gray Box testing and example ==
Code should be examined to ensure clear separation of duties and enforcement of user authorization and administration function access. The server and application components should be verified to ensure hardening, and validation that they are not configured as the default.

== References ==
* Default Password list: http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php

Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

2008-08-23T05:25:25Z

Mr fusion: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

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

== Brief Summary ==
 
Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.
 

== Description of the Issue ==
 
An application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. Such changes may include:

- user account provisioning 
- Site design and layout 
- data manipultion 
- configuration changes 

In many instances, such interfaces are usually implemented with little thought of how to separate them from the normal users of the site. Testing is aimed at discovering these administrator interfaces and accessing functionality intended for the privileged users.
 

== Black Box testing and example ==
The following describes vectors that may be used to test for the presence of administrative interfaces. These techniques may also be used for testing for related issues including privilege escalation and are described elsewhere in this guide in greater detail: 

* Directory and file Enumeration - An administrative interface may be present but not visibly available to the tester. Attempting to guess the path of the administrative interface may be as simple as requesting:
/admin or /administrator etc.. 
A tester may have to also identify the filename of the administration page. Forcible browsing to the identified page may provide access to the interface.

* Comments and links in Source - Many sites use common code that is loaded for all site users. By examining all source sent to the client, links to administrator functionality may be discovered and should be investigated.

* Reviewing Server and Application Documentation - If the application server or application is deployed in its default configuration it may be possible
to access the administration interface using information described in configuration or help documentation. Default password lists should be consulted if an administrative interface is found and credentials are required.

* Alternative Server Port - Administration interfaces may be seen on a different port on the host than the main application. For example, Apache Tomcat's Administration interface can often be seen on port 8080.

* Parameter Tampering - A GET or POST parameter or a cookie variable may be required to enable the administrator functionality. Clues to this
include the presence of hidden fields such as:

<input type="hidden" name="admin" value="no"> or in a cookie: Cookie: session_cookie; useradmin=0
 
Once an administrative interface has been discovered, a combination of the above techniques may be used to attempt to bypass authentication. If this fails, the
tester may wish to attempt a brute force attack. In such an instance the tester should be aware of the potential for administrative account lockout if such functionality is present.

== Gray Box testing and example ==
Code should be examined to ensure clear separation of duties and enforcement of user authorization and administration function access. The server and application components should be verified to ensure hardening and validation that they are not configured as the default.

== References ==
Default Password list: http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php

Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

2008-08-23T05:24:40Z

Mr fusion: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

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

== Brief Summary ==
 
Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.
 

== Description of the Issue ==
 
An application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. Such changes may include:

- user account provisioning 
- Site design and layout 
- data manipultion 
- configuration changes 

In many instances, such interfaces are usually implemented with little thought of how to separate them from the normal users of the site. Testing is aimed at discovering these administrator interfaces and accessing functionality intended for the privileged users.
 

== Black Box testing and example ==
The following describes vectors that may be used to test for the presence of administrative interfaces. These techniques may also be used for testing for related issues including privilege escalation and are described elsewhere in this guide in greater detail: 

* Directory and file Enumeration - An administrative interface may be present but not visibly available to the tester. Attempting to guess the path of the administrative interface may be as simple as requesting:
/admin or /administrator etc.. 
A tester may have to also identify the filename of the administration page. Forcible browsing to the identified page may provide access to the interface.

* Comments and links in Source - Many sites use common code that is loaded for all site users. By examining all source sent to the client, links to administrator functionality may be discovered and should be investigated.

* Reviewing Server and Application Documentation - If the application server or application is deployed in its default configuration it may be possible
to access the administration interface using information described in configuration or help documentation. Default password lists should be consulted if an administrative interface is found and credentials are required.

* Alternative Server Port - Administration interfaces may be seen on a different port on the host. For example Apache Tomcat Administration interface can often
be seen on port 8080.

* Parameter Tampering - A GET or POST parameter or a cookie variable may be required to enable the administrator functionality. Clues to this
include the presence of hidden fields such as:

<input type="hidden" name="admin" value="no"> or in a cookie: Cookie: session_cookie; useradmin=0
 
Once an administrative interface has been discovered, a combination of the above techniques may be used to attempt to bypass authentication. If this fails, the
tester may wish to attempt a brute force attack. In such an instance the tester should be aware of the potential for administrative account lockout if such functionality is present.

== Gray Box testing and example ==
Code should be examined to ensure clear separation of duties and enforcement of user authorization and administration function access. The server and application components should be verified to ensure hardening and validation that they are not configured as the default.

== References ==
Default Password list: http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php

OWASP Testing Project v3 Roadmap

2008-08-23T05:20:16Z

Mr fusion:

'''OWASP Testing Guide v3 Roadmap'''

* '''26th April 2008: start the new project'''
OWASP Leaders brainstorming.
 Call for participation.
 [http://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Startup Index brainstorming]
 [http://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Table_of_Contents Index draft]
 Discuss th article content.
 Deadline: Sun 18th May 2008.

* '''20th May 2008'''
New draft Index

* '''25th May 2008'''
'''Updated index:'''
Added or to improve:

(toimp)1. Frontispiece

(toimp)1.1 About the OWASP Testing Guide Project

(new) 2.4 Security requirements test derivation, functional and non functional test requirements, and test cases through use and misuse cases

(new) 2.4.1 Security tests integrated in developers and testers workflows

(new) 2.4.2 Developers' security tests: Unit Tests, component level tests, etc

(new) 2.4.3 Functional testers' security tests: integrated system tests, tests in UAT, and production environment

(new) 2.5 Security test data analysis and reporting: root cause identification and business/role case test data reporting

4. (toimp) Web Application Penetration Testing

4.1 Introduction and Objectives

(new) 4.1.1 Testing Checklist

(toimp) 4.2 Information Gathering

(new)4.2.1 Spiders, Robots and Crawlers

(new) 4.2.2 Search Engine Discovery/Reconnaissance

(new) 4.2.3 Identify application entry points

4.2.3 (toimp) Testing for Web Application Fingerprint

(toimp)4.2.5 Analysis of Error Codes

(new) 4.3 Configuration Management Testing

(toimp) 4.3.1 SSL/TLS Testing (SSL Version, Alghoritms, Key lenght, Digital Cert. Validity

(toimp) 4.3.3 Application Configuration Management Testing

(new) 4.3.4 Testing for misconfiguration

(new) 4.3.7 Infrastructure and Application Admin Interfaces

(toimp)4.4 Business Logic Testing

(toimp)4.5 Authentication Testing

(new)4.5.1 Credentials transport over an encrypted channel

(new) 4.5.2 Testing for user enumeration

(to imp) 4.5.2 Testing for Guessable (Dictionary) User Account

(new) 4.6 Authorization testing

(new) 4.6.1 Testing for Path Traversal

(new)4.6.2 Testing for bypassing authorization schema

(new)4.6.3 Testing for Privilege Escalation

(new)4.7.2 Test the token strength (old 4.5.2 Testing for Cookie and Session Token Manipulation)

(new) 4.7.3 Testing for Cookies attributes

(new)4.8.1 Testing for Reflected Cross Site Scripting

(new)4.8.2 Testing for Stored Cross Site Scripting

(new) 4.8.3 Testing for DOM based Cross Site Scripting

(new)4.8.4 Testing for Cross Site Flashing

(toimp) 4.8.1.1 Testing for XST

(toimp) 4.8.2 Testing for SQL Injection

(toimp) 4.10 Web Services Testing

(new)4.11 Client site testing

(new) 4.11.1 AJAX Testing

(new)4.11.2 Flash Testing

(new)4.11.3 RIA Testing

(toimp: Mat)5. Writing Reports: value the real risk

* '''26th May 2008'''
Added:
 4.3.8 Testing for HTTP Methods and XST in Infrastucture and Application Testing section
 Sent Paragraph Template to the list
 Sent new index to the list

* '''28th May 2008'''
Added:
New Testing Guide checklist.

* '''30th May 2008'''
Added:
 Session Fixation
 Discuss abouut new Aspect paper about HTTP verb manipulation

* '''1st June 2008'''
Les's start writing!

* '''15th June 2008'''
Added:
4.1.1 Testing Checklist 
4.2 Information Gathering 
4.2.1 Spiders, Robots and Crawlers 
4.2.3 Identify application entry points 
2.4 Security requirements test derivation,functional and non functional test requirements, and test cases through use and misuse cases 
4.4 Business Logic Testing 
4.6 Authorization testing 
4.5.3 Testing for Guessable (Dictionary) User Account 
4.6 Authorization testing 
4.6.2 Testing for Bypassing Authorization Schema 
4.6.3 Testing for Privilege Escalation 

* '''29th June 2008'''
Written (M.Meucci):
Testing_for_user_enumeration

* '''7th July 2008'''
Written:
Testing_for_Default_or_Guessable_User_Account (K.Horvath) 
Testing_for_business_logic (K.Horvath)

* '''9th July 2008'''
Testing_for_cookies_attributes (K.Horvath)

* '''12th August 2008'''
Articles reviewed/written (M.Meucci): 
Testing:_Introduction_and_objectives 
Testing_Checklist 
4.3 Configuration Management Testing 
4.2 Information Gathering 

* '''13 August 2008'''
Reviewed (M.Meucci): 
Testing_for_business_logic
Testing_for_SQL_Wildcard_Attacks (Rick.mitchell) 
Added: 
(new: G.Fedon) 4.5.9 Testing Multiple Factors Authentication 
Written (M.Meucci): 
Testing_for_authentication

* '''14 August 2008'''
Reviewed (M.Meucci):
Testing_for_credentials_transport 
Written (M.Meucci): 
Testing_for_user_enumeration (M.Mella) 
Testing_for_authorization 
Testing_for_Session_Management 
merged the 2 articles: 
Testing for Session_Management_Schema 
Testing for Cookie and Session Token Manipulation 
Now we have a new one: Testing for Session_Management_Schema 

* '''15 August 2008'''
Testing_for_Session_Fixation 

* '''16th August 2008'''
Reviewed (M.Cova): 
4.2 Information Gathering 
4.3 Configuration Management Testing 
4.5 Authentication Testing 

* '''18th August 2008'''
Reviewed (M.Cova): 
4.6 Authorization testing 
Written (A.van der Stock): 
Testing_for_HTTP_Methods_and_XST (HTTP Verb) 

* '''20th August 2008'''
Reviewed (M.Cova): 
Web Services 
Written (A.Parata): 
4.8.5.4 MS Access Testing

* '''21st August 2008'''
Updated (M.Meucci): 
Testing_for_Session_Fixation 
Testing_for_Bypassing_Authorization_Schema 
Testing_for_Privilege_escalation 

* '''22nd August 2008'''
Writing (Adam):
Testing_for_Admin_Interfaces 
Update/Write: 
(imp: M.Meucci -100%) 4.10 Web Services Testing 
(new: M.Meucci -100%) 4.10.1 WS Information Gathering 
(new: M.Meucci -100%) 4.10.2 Testing WSDL 
(imp: M.Meucci -100%)4.10.3 XML Structural Testing 
Improved: 
Testing_for_Data_Validation 

----
'''TODO:''' 
Article to finish: 
(new: M.Meucci - 90% ) 4.1.1 Testing Checklist 
(new:C.Heinrich - 0%)4.2.1 Spiders, Robots and Crawlers 
(new:C.Heinrich - 0%)4.2.2 Search Engine Discovery/Reconnaissance 
(new: Adam -90%) 4.3.7 Infrastructure and Application Admin Interfaces 
(new: M.Meucci, M.Mella - 90%) 4.5.2 Testing for user enumeration 
(new: G.Fedon) 4.5.9 Testing Multiple Factors Authentication 
(new: A.Agarwwal, Kuza55 - 80%) 4.8.3 Testing for DOM based Cross Site Scripting 
(new: A.Agarwwal, S.Di Paola - 0%)4.8.4 Testing for Cross Site Flashing 
Articles to review: 
MS Access Testing 
Testing PostgreSQL 

----
'''Project deadlines:'''
# 21st May: Project status presentation at the OWASP AppSec Euro 08 Conference in Belgium.
# 15th June - Participants to report on project status.
# 24th August - Finish the writing phase.
# 15th September - Project completion. Participants should deliver final project report.

Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

2008-08-23T05:18:57Z

Mr fusion: /* References */

{{Template:OWASP Testing Guide v3}}

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

== Brief Summary ==
 
Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.
 

== Description of the Issue ==
 
An application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. Such changes may include:

- user account provisioning 
- Site design and layout 
- data manipultion 
- configuration changes 

In many instances, such interfaces are usually implemented with little thought of how to separate them from the normal users of the site. Testing is aimed at discovering these administrator interfaces and accessing functionality intended for the privileged users.
 

== Black Box testing and example ==
The following describes vectors that may be used to test for the presence of administrative interfaces. These techniques may also be used for testing for related issues including privilege escalation and are described elsewhere in this guide in greater detail: 

* Directory and file Enumeration - An administrative interface may be present but not visibly available to the tester. Attempting to guess the path of the administrative interface may be as simple as requesting:
/admin or /administrator etc.. 
A tester may have to also identify the filename of the administration page. Forcible browsing to the identified page may provide access to the interface.

* Comments and links in Source - Many sites use common code that is loaded for all site users. By examining all source sent to the client, links to administrator functionality may be discovered and should be investigated.

* Reviewing Server and Application Documentation - If the application server or application is deployed in its default configuration it may be possible
to access the administration interface using information described in configuration or help documentation. Default password lists should be consulted if an administrative interface is found and credentials are required.

* Alternative Server Port - Administration interfaces may be seen on a different port on the host. For example Apache Tomcat Administration interface can often
be seen on port 8080.

* Parameter Tampering - A GET or POST parameter or a cookie variable may be required to enable the administrator functionality. Clues to this
include the presence of hidden fields such as:

<input type="hidden" name="admin" value="no"> or: Cookie: session_cookie; useradmin=0
 
Once an administrative interface has been discovered, a combination of the above techniques may be used to attempt to bypass authentication. If this fails, the
tester may wish to attempt a brute force attack. In such an instance the tester should be aware of the potential for administrative account lockout if such functionality is present.

== Gray Box testing and example ==
Code should be examined to ensure clear separation of duties and enforcement of user authorization and administration function access. The server and application components should be verified to ensure hardening and validation that they are not configured as the default.

== References ==
Default Password list: http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php

Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

2008-08-23T05:08:25Z

Mr fusion: /* Gray Box testing and example */

{{Template:OWASP Testing Guide v3}}

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

== Brief Summary ==
 
Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.
 

== Description of the Issue ==
 
An application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. Such changes may include:

- user account provisioning 
- Site design and layout 
- data manipultion 
- configuration changes 

In many instances, such interfaces are usually implemented with little thought of how to separate them from the normal users of the site. Testing is aimed at discovering these administrator interfaces and accessing functionality intended for the privileged users.
 

== Black Box testing and example ==
The following describes vectors that may be used to test for the presence of administrative interfaces. These techniques may also be used for testing for related issues including privilege escalation and are described elsewhere in this guide in greater detail: 

* Directory and file Enumeration - An administrative interface may be present but not visibly available to the tester. Attempting to guess the path of the administrative interface may be as simple as requesting:
/admin or /administrator etc.. 
A tester may have to also identify the filename of the administration page. Forcible browsing to the identified page may provide access to the interface.

* Comments and links in Source - Many sites use common code that is loaded for all site users. By examining all source sent to the client, links to administrator functionality may be discovered and should be investigated.

* Reviewing Server and Application Documentation - If the application server or application is deployed in its default configuration it may be possible
to access the administration interface using information described in configuration or help documentation. Default password lists should be consulted if an administrative interface is found and credentials are required.

* Alternative Server Port - Administration interfaces may be seen on a different port on the host. For example Apache Tomcat Administration interface can often
be seen on port 8080.

* Parameter Tampering - A GET or POST parameter or a cookie variable may be required to enable the administrator functionality. Clues to this
include the presence of hidden fields such as:

<input type="hidden" name="admin" value="no"> or: Cookie: session_cookie; useradmin=0
 
Once an administrative interface has been discovered, a combination of the above techniques may be used to attempt to bypass authentication. If this fails, the
tester may wish to attempt a brute force attack. In such an instance the tester should be aware of the potential for administrative account lockout if such functionality is present.

== Gray Box testing and example ==
Code should be examined to ensure clear separation of duties and enforcement of user authorization and administration function access. The server and application components should be verified to ensure hardening and validation that they are not configured as the default.

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

Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

2008-08-23T04:19:17Z

Mr fusion: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

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

== Brief Summary ==
 
Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.
 

== Description of the Issue ==
 
An application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. Such changes may include:

- user account provisioning 
- Site design and layout 
- data manipultion 
- configuration changes 

In many instances, such interfaces are usually implemented with little thought of how to separate them from the normal users of the site. Testing is aimed at discovering these administrator interfaces and accessing functionality intended for the privileged users.
 

== Black Box testing and example ==
The following describes vectors that may be used to test for the presence of administrative interfaces. These techniques may also be used for testing for related issues including privilege escalation and are described elsewhere in this guide in greater detail: 

* Directory and file Enumeration - An administrative interface may be present but not visibly available to the tester. Attempting to guess the path of the administrative interface may be as simple as requesting:
/admin or /administrator etc.. 
A tester may have to also identify the filename of the administration page. Forcible browsing to the identified page may provide access to the interface.

* Comments and links in Source - Many sites use common code that is loaded for all site users. By examining all source sent to the client, links to administrator functionality may be discovered and should be investigated.

* Reviewing Server and Application Documentation - If the application server or application is deployed in its default configuration it may be possible
to access the administration interface using information described in configuration or help documentation. Default password lists should be consulted if an administrative interface is found and credentials are required.

* Alternative Server Port - Administration interfaces may be seen on a different port on the host. For example Apache Tomcat Administration interface can often
be seen on port 8080.

* Parameter Tampering - A GET or POST parameter or a cookie variable may be required to enable the administrator functionality. Clues to this
include the presence of hidden fields such as:

<input type="hidden" name="admin" value="no"> or: Cookie: session_cookie; useradmin=0
 
Once an administrative interface has been discovered, a combination of the above techniques may be used to attempt to bypass authentication. If this fails, the
tester may wish to attempt a brute force attack. In such an instance the tester should be aware of the potential for administrative account lockout if such functionality is present.

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

Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

2008-08-22T04:05:42Z

Mr fusion: /* Description of the Issue */

Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

2008-08-22T04:05:09Z

Mr fusion: /* Description of the Issue */

Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

2008-08-22T03:55:41Z

Mr fusion: /* Brief Summary */