OWASP - User contributions [en]

User:Eduardo Castellanos

2015-04-28T10:24:39Z

Eduardo Castellanos:

Former Web Application Developer.

Graduated from Universidad del Valle de Guatemala in 2009.
Obtained the title of: Licenciatura en Ingeniería en Ciencias de la Computación.

Worked as a Security Analyst for Sistemas Aplicativos S.A. / Verizon Business Security Solutions.

Test RIA cross domain policy (OTG-CONFIG-008)

2015-04-28T10:22:30Z

Eduardo Castellanos:

{{Template:OWASP Testing Guide v4}}

== Summary ==
Rich Internet Applications (RIA) have adopted Adobe's crossdomain.xml policy files to allow for controlled cross domain access to data and service consumption using technologies such as Oracle Java, Silverlight, and Adobe Flash. Therefore, a domain can grant remote access to its services from a different domain. However, often the policy files that describe the access restrictions are poorly configured. Poor configuration of the policy files enables Cross-site Request Forgery attacks, and may allow third parties to access sensitive data meant for the user.

=== What are cross-domain policy files? ===
A cross-domain policy file specifies the permissions that a web client such as Java, Adobe Flash, Adobe Reader, etc. use to access data across different domains. For Silverlight, Microsoft adopted a subset of the Adobe's crossdomain.xml, and additionally created it's own cross-domain policy file: clientaccesspolicy.xml.

Whenever a web client detects that a resource has to be requested from other domain, it will first look for a policy file in the target domain to determine if performing cross-domain requests, including headers, and socket-based connections are allowed.

Master policy files are located at the domain's root. A client may be instructed to load a different policy file but it will always check the master policy file first to ensure that the master policy file permits the requested policy file.

==== Crossdomain.xml vs. Clientaccesspolicy.xml ====
Most RIA applications support crossdomain.xml. However in the case of Silverlight, it will only work if the crossdomain.xml specifies that access is allowed from any domain. For more granular control with Silverlight, clientaccesspolicy.xml must be used.

Policy files grant several types of permissions:
* Accepted policy files (Master policy files can disable or restrict specific policy files)
* Sockets permissions
* Header permissions
* HTTP/HTTPS access permissions
* Allowing access based on cryptographic credentials

An example of an overly permissive policy file:
<pre>
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>
</pre>

=== How can cross domain policy files can be abused? ===
* Overly permissive cross-domain policies.
* Generating server responses that may be treated as cross-domain policy files.
* Using file upload functionality to upload files that may be treated as cross-domain policy files.

=== Impact of abusing cross-domain access ===
* Defeat CSRF protections.
* Read data restricted or otherwise protected by cross-origin policies.

== How to Test ==
'''Testing for RIA policy files weakness:''' <br>
To test for RIA policy file weakness the tester should try to retrieve the policy files crossdomain.xml and clientaccesspolicy.xml from the application's root, and from every folder found.<br><br>
For example, if the application's URL is http://www.owasp.org, the tester should try to download the files http://www.owasp.org/crossdomain.xml and http://www.owasp.org/clientaccesspolicy.xml.
<br><br>
After retrieving all the policy files, the permissions allowed should be be checked under the least privilege principle. Requests should only come from the domains, ports, or protocols that are necessary. Overly permissive policies should be avoided. Policies with "*" in them should be closely examined. <br><br>
Example:
<pre><cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy></pre>

'''Result Expected:'''<br>
*A list of policy files found. <br>
*A list of weak settings in the policies.<br>

==Tools==
* Nikto
* OWASP Zed Attack Proxy Project
* W3af

== References ==
'''Whitepapers'''<br>
* UCSD: "Analyzing the Crossdomain Policies of Flash Applications" - http://cseweb.ucsd.edu/~hovav/dist/crossdomain.pdf
* Adobe: "Cross-domain policy file specification" - http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
* Adobe: "Cross-domain policy file usage recommendations for Flash Player" - http://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html
* Oracle: "Cross-Domain XML Support" - http://www.oracle.com/technetwork/java/javase/plugin2-142482.html#CROSSDOMAINXML
* MSDN: "Making a Service Available Across Domain Boundaries" - http://msdn.microsoft.com/en-us/library/cc197955(v=vs.95).aspx
* MSDN: "Network Security Access Restrictions in Silverlight" - http://msdn.microsoft.com/en-us/library/cc645032(v=vs.95).aspx
* Stefan Esser: "Poking new holes with Flash Crossdomain Policy Files" http://www.hardened-php.net/library/poking_new_holes_with_flash_crossdomain_policy_files.html
* Jeremiah Grossman: "Crossdomain.xml Invites Cross-site Mayhem" http://jeremiahgrossman.blogspot.com/2008/05/crossdomainxml-invites-cross-site.html
* Google Doctype: "Introduction to Flash security " - http://code.google.com/p/doctype-mirror/wiki/ArticleFlashSecurity

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

2014-03-13T22:40:28Z

Eduardo Castellanos:

{{Template:OWASP Testing Guide v4}}

== Summary ==

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

== Test Objectives ==

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

HTML comments are also used by the developers to include debugging information about the application. Sometimes they forget about the comments and they leave them on in production. You should look for HTML comments which start with "".

== How to Test ==

=== Black Box testing and example ===

Check HTML source code for comments containing sensitive information which can help the attacker gain more insight about the application. It might be SQL code, usernames and passwords, internal IP addresses, or debugging information.

<pre>
...

<div class="table2">
<div class="col1">1</div><div class="col2">Mary</div>
<div class="col1">2</div><div class="col2">Peter</div>
<div class="col1">3</div><div class="col2">Joe</div>



</div>
...
</pre>

You could even find something like this:
<pre>

</pre>

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

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

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

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

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

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

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

which will result in the HTTP header:

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

and

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

will result in

Cache-Control: no-cache

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

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

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

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

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

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

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

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

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

==Tools==

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

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

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

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

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

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

2014-03-13T22:36:12Z

Eduardo Castellanos:

{{Template:OWASP Testing Guide v4}}

== Summary ==

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

== Test Objectives ==

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

HTML comments are also used by the developers to include debugging information about the application. Sometimes they forget about the comments and they leave them on in production. You should look for HTML comments which start with "".

== How to Test ==

=== Black Box testing and example ===

Check HTML source code for comments containing sensitive information which can help the attacker gain more insight about the application. It might be SQL code, usernames and passwords, internal IP addresses, or debugging information.

<pre>
...

<div class="table2">
<div class="col1">1</div><div class="col2">Mary</div>
<div class="col1">2</div><div class="col2">Peter</div>
<div class="col1">3</div><div class="col2">Joe</div>



</div>
...
</pre>

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

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

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

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

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

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

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

which will result in the HTTP header:

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

and

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

will result in

Cache-Control: no-cache

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

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

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

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

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

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

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

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

examples

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

==Tools==

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

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

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

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

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

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

2014-03-13T22:34:25Z

Eduardo Castellanos:

{{Template:OWASP Testing Guide v4}}

== Summary ==

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

== Test Objectives ==

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

HTML comments are also used by the developers to include debugging information about the application. Sometimes they forget about the comments and they leave them on in production. You should look for HTML comments which start with "".

== How to Test ==

=== Black Box testing and example ===

Check HTML comments for sensitive information which can help the attacker gain more insight about the application.

<pre>
...

<div class="table2">
<div class="col1">1</div><div class="col2">Mary</div>
<div class="col1">2</div><div class="col2">Peter</div>
<div class="col1">3</div><div class="col2">Joe</div>



</div>
...
</pre>

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

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

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

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

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

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

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

which will result in the HTTP header:

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

and

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

will result in

Cache-Control: no-cache

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

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

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

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

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

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

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

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

examples

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

==Tools==

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

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

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

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

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

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

2014-03-13T22:33:26Z

Eduardo Castellanos:

{{Template:OWASP Testing Guide v4}}

== Summary ==

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

== Test Objectives ==

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

HTML comments are also used by the developers to include debugging information about the application. Sometimes they forget about the comments and they leave them on in production. You should look for HTML comments which start with "".

== How to Test ==

=== Black Box testing and example ===

Check HTML comments for sensitive information which can help the attacker gain more insight about the application.

<pre>
...

<div class="table2">
<div class="col1">1</div><div class="col2">Mary</div>
<div class="col1">2</div><div class="col2">Peter</div>
<div class="col1">3</div><div class="col2">Joe</div>



</div>
...
</pre>

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

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

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

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

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

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

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

which will result in the HTTP header:

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

and

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

will result in

Cache-Control: no-cache

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

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

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

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

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

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

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

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

examples

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

==Tools==

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

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

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

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

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

Test RIA cross domain policy (OTG-CONFIG-008)

2014-03-13T21:03:41Z

Eduardo Castellanos:

Talk:Test RIA cross domain policy (OTG-CONFIG-008)

2014-03-13T21:02:18Z

Eduardo Castellanos: Created page with "Removing anything that has to do with CORS since it's already covered here: Test Cross Origin Resource Sharing (OTG-CLIENT-002)"

Removing anything that has to do with CORS since it's already covered here: Test Cross Origin Resource Sharing (OTG-CLIENT-002)

Test RIA cross domain policy (OTG-CONFIG-008)

2014-03-13T11:29:04Z

Eduardo Castellanos:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Rich Internet Applications (RIA) have adopted Adobe's crossdomain.xml policy files in order to allow for controlled cross domain access to data and service consumption using technologies such as Oracle Java, Silverlight, and Adobe Flash. Therefore, a domain can grant remote access to its services from a different domain. However, often the policy files that describe the access restrictions are poorly configured. Poor configuration of the policy files enables Cross-site Request Forgery attacks, and may allow third parties to access sensitive data meant for the user.

HTML5 also incorporates a new way of performing cross domain requests: Cross Origin Resource Sharing (CORS). These can also be improperly configured and enable an attacker to perform similar attacks.

== Description of the Issue ==
=== What are cross-domain policy files ===
A cross-domain policy file specifies the permissions that a web client such as Java, Adobe Flash, Adobe Reader, etc. to access data across different domains. For Silverlight, Microsoft adopted a subset of the Adobe's crossdomain.xml, and additionally created it's own cross-domain policy file: clientaccesspolicy.xml.

Whenever a web client detects that a resource has to be requested from other domain, it will first look for a policy file in the target domain in order to determine if performing cross-domain requests, including headers, and socket-based connections are allowed.

Master policy files are located at the domain's root. A client may be instructed to load a different policy file, however, it will always check the master policy file first to ensure that the master policy file permits the requested policy file.

==== Crossdomain.xml vs. Clientaccesspolicy.xml ====
Most RIA applications support crossdomain.xml. However in the case of Silverlight, it will only work if the crossdomain.xml specifies that access is allowed from any domain. For more granular control with Silverlight, clientaccesspolicy.xml must be used.

Policy files grant several types of permissions:
* Accepted policy files (Master policy files can disable or restrict specific policy files)
* Sockets permissions
* Header permissions
* HTTP/HTTPS access permissions
* Allowing access based on cryptographic credentials

An example of an overly permissive policy file:
<pre>
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>
</pre>
=== What is CORS===
CORS is HTML5's way of enabling web applications to perform cross-domain requests. CORS works by appending an "Origin" header to the HTTP request, then the server responds with a "Access-Control-Allow-Origin" header stating which website can issue cross domain requests. The server may answer with the Access-Control-Allow-Origin header set to * to indicate that it is a public resource.

=== How can cross domain policies can be abused ===
* Overly permissive cross-domain policies
* Generating server responses that may be treated as cross-domain policy files
* Using file upload functionality to upload files that may be treated as cross-domain policy files.
* Being able to set custom response headers to indicate cross domain access. (Access-Control-Allow-Origin: *)

=== Impact of abusing cross-domain access ===
* Defeat CSRF protections
* Read data restricted or otherwise protected by cross-origin policies.

== Black Box testing and example ==
'''Testing for RIA policy files weakness:''' <br>
In order to test for RIA policy file weakness you should try to retrieve the policy files crossdomain.xml and clientaccesspolicy.xml from the application's root, and from every folder found.<br><br>
For example, if the application's URL is http://www.owasp.org, you should try to download the files http://www.owasp.org/crossdomain.xml and http://www.owasp.org/clientaccesspolicy.xml.
<br><br>
After retrieving all the policy files, the permissions allowed should be be checked under the least privilege principle. Requests should only come from the domains, ports, or protocols that are necessary. Overly permissive policies should be avoided. Policies with "*" in them should be closely examined. <br><br>
Example:
<pre><cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy></pre>

'''Result Expected:'''<br>
A list of policy files found. <br>
A weak settings in the policies.<br>

'''Testing for CORS policy weakness:''' <br>
User your favorite interception proxy to issue an OPTIONS request to the server with the following headers set):<br>
* Origin: Origin can be any URL other than the website you are testing on or null.
* Access-Control-Request-Method: This can be GET, POST, PUT, DELETE, etc. You should try with different values.
* Access-Control-Request-Headers: This can be almost any request header. You should try to with sensitive headers. (This is optional)
<br>
A request will then look like this:

<pre>
OPTIONS /resources/target HTTP/1.1
Host: example.com
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://owasp.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.9 Safari/536.5
Access-Control-Request-Headers: x-extraheader, content-type
Accept: */*
Referer: http://example.com/page.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,es;q=0.6
</pre>

A successful response would look like this: <br>
<pre>
HTTP/1.1 200 OK
Date: Thu, 13 Mar 2014 10:18:45 GMT
Server: Apache
Access-Control-Allow-Origin: http://example.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-EXTRAHEADER, CONTENT-TYPE
Access-Control-Max-Age: 1728000
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain
</pre>

You should carefully inspect the "Access-Control-Allow-Origin", "Access-Control-Allow-Methods", "Access-Control-Allow-Credentials", "Access-Control-Allow-Headers", "Access-Control-Allow-Expose-Headers", and any other header that starts with "Access-Control-Allow-". The value of each of this headers should be set to the most restrictive setting. For example a specific domain for "Access-Control-Allow-Origin".
== References ==
'''Whitepapers'''<br>
* UCSD: "Analyzing the Crossdomain Policies of Flash Applications" - http://cseweb.ucsd.edu/~hovav/dist/crossdomain.pdf
* Adobe: "Cross-domain policy file specification" - http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
* Adobe: "Cross-domain policy file usage recommendations for Flash Player" - http://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html
* Oracle: "Cross-Domain XML Support" - http://www.oracle.com/technetwork/java/javase/plugin2-142482.html#CROSSDOMAINXML
* MSDN: "Making a Service Available Across Domain Boundaries" - http://msdn.microsoft.com/en-us/library/cc197955(v=vs.95).aspx
* MSDN: "Network Security Access Restrictions in Silverlight" - http://msdn.microsoft.com/en-us/library/cc645032(v=vs.95).aspx
* Stefan Esser: "Poking new holes with Flash Crossdomain Policy Files" http://www.hardened-php.net/library/poking_new_holes_with_flash_crossdomain_policy_files.html
* Jeremiah Grossman: "Crossdomain.xml Invites Cross-site Mayhem" http://jeremiahgrossman.blogspot.com/2008/05/crossdomainxml-invites-cross-site.html
* Google Doctype: "Introduction to Flash security " - http://code.google.com/p/doctype-mirror/wiki/ArticleFlashSecurity
* http://www.html5rocks.com/en/tutorials/cors/
* Krzysztof Kotowicz: "How to upload arbitrary file contents cross-domain"- http://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html
* W3C: "Cross-Origin Resource Sharing" - http://www.w3.org/TR/cors/
* Secureideas: "Grab a CORS Light" - http://blog.secureideas.com/2013/02/grab-cors-light.html
<br>
'''Tools'''<br>
* Nikto
* OWASP Zed Attack Proxy Project
* W3af

Test RIA cross domain policy (OTG-CONFIG-008)

2014-03-13T11:28:39Z

Eduardo Castellanos:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Rich Internet Applications (RIA) have adopted Adobe's crossdomain.xml policy files in order to allow for controlled cross domain access to data and service consumption using technologies such as Oracle Java, Silverlight, and Adobe Flash. Therefore, a domain can grant remote access to its services from a different domain. However, often the policy files that describe the access restrictions are poorly configured. Poor configuration of the policy files enables Cross-site Request Forgery attacks, and may allow third parties to access sensitive data meant for the user.

HTML5 also incorporates a new way of performing cross domain requests: Cross Origin Resource Sharing (CORS). These can also be improperly configured and enable an attacker to perform similar attacks.

== Description of the Issue ==
=== What are cross-domain policy files ===
A cross-domain policy file specifies the permissions that a web client such as Java, Adobe Flash, Adobe Reader, etc. to access data across different domains. For Silverlight, Microsoft adopted a subset of the Adobe's crossdomain.xml, and additionally created it's own cross-domain policy file: clientaccesspolicy.xml.

Whenever a web client detects that a resource has to be requested from other domain, it will first look for a policy file in the target domain in order to determine if performing cross-domain requests, including headers, and socket-based connections are allowed.

Master policy files are located at the domain's root. A client may be instructed to load a different policy file, however, it will always check the master policy file first to ensure that the master policy file permits the requested policy file.

==== Crossdomain.xml vs. Clientaccesspolicy.xml ====
Most RIA applications support crossdomain.xml. However in the case of Silverlight, it will only work if the crossdomain.xml specifies that access is allowed from any domain. For more granular control with Silverlight, clientaccesspolicy.xml must be used.

Policy files grant several types of permissions:
* Accepted policy files (Master policy files can disable or restrict specific policy files)
* Sockets permissions
* Header permissions
* HTTP/HTTPS access permissions
* Allowing access based on cryptographic credentials

An example of an overly permissive policy file:
<pre>
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>
</pre>
=== What is CORS===
CORS is HTML5's way of enabling web applications to perform cross-domain requests. CORS works by appending an "Origin" header to the HTTP request, then the server responds with a "Access-Control-Allow-Origin" header stating which website can issue cross domain requests. The server may answer with the Access-Control-Allow-Origin header set to * to indicate that it is a public resource.

=== How can cross domain policies can be abused ===
* Overly permissive cross-domain policies
* Generating server responses that may be treated as cross-domain policy files
* Using file upload functionality to upload files that may be treated as cross-domain policy files.
* Being able to set custom response headers to indicate cross domain access. (Access-Control-Allow-Origin: *)

=== Impact of abusing cross-domain access ===
* Defeat CSRF protections
* Read data restricted or otherwise protected by cross-origin policies.

== Black Box testing and example ==
'''Testing for RIA policy files weakness:''' <br>
In order to test for RIA policy file weakness you should try to retrieve the policy files crossdomain.xml and clientaccesspolicy.xml from the application's root, and from every folder found.<br><br>
For example, if the application's URL is http://www.owasp.org, you should try to download the files http://www.owasp.org/crossdomain.xml and http://www.owasp.org/clientaccesspolicy.xml.
<br><br>
After retrieving all the policy files, the permissions allowed should be be checked under the least privilege principle. Requests should only come from the domains, ports, or protocols that are necessary. Overly permissive policies should be avoided. Policies with "*" in them should be closely examined. <br><br>
Example:
<pre><cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy></pre>

'''Result Expected:'''<br>
A list of policy files found. <br>
A weak settings in the policies.<br>

'''Testing for CORS policy weakness:''' <br>
User your favorite interception proxy to issue an OPTIONS request to the server with the following headers set):<br>
* Origin: Origin can be any URL other than the website you are testing on or null.
* Access-Control-Request-Method: This can be GET, POST, PUT, DELETE, etc. You should try with different values.
* Access-Control-Request-Headers: This can be almost any request header. You should try to with sensitive headers. (This is optional)
<br>
A request will then look like this:

<pre>
OPTIONS /resources/target HTTP/1.1
Host: example.com
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://owasp.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.9 Safari/536.5
Access-Control-Request-Headers: x-extraheader, content-type
Accept: */*
Referer: http://example.com/page.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,es;q=0.6
</pre>

A successful response would look like this: <br>
<pre>
HTTP/1.1 200 OK
Date: Thu, 13 Mar 2014 10:18:45 GMT
Server: Apache
Access-Control-Allow-Origin: http://example.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-EXTRAHEADER, CONTENT-TYPE
Access-Control-Max-Age: 1728000
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain
</pre>

You should carefully inspect the "Access-Control-Allow-Origin", "Access-Control-Allow-Methods", "Access-Control-Allow-Credentials", "Access-Control-Allow-Headers", "Access-Control-Allow-Expose-Headers", and any other header that starts with "Access-Control-Allow-". The value of each of this headers should be set to the most restrictive setting. For example a specific domain for "Access-Control-Allow-Origin".
== References ==
'''Whitepapers'''<br>
* UCSD: "Analyzing the Crossdomain Policies of Flash Applications" - http://cseweb.ucsd.edu/~hovav/dist/crossdomain.pdf
* Adobe: "Cross-domain policy file specification" - http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
* Adobe: "Cross-domain policy file usage recommendations for Flash Player" - http://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html
* Oracle: "Cross-Domain XML Support" - http://www.oracle.com/technetwork/java/javase/plugin2-142482.html#CROSSDOMAINXML
* MSDN: "Making a Service Available Across Domain Boundaries" - http://msdn.microsoft.com/en-us/library/cc197955(v=vs.95).aspx
* MSDN: "Network Security Access Restrictions in Silverlight" - http://msdn.microsoft.com/en-us/library/cc645032(v=vs.95).aspx
* Stefan Esser: "Poking new holes with Flash Crossdomain Policy Files" http://www.hardened-php.net/library/poking_new_holes_with_flash_crossdomain_policy_files.html
* Jeremiah Grossman: "Crossdomain.xml Invites Cross-site Mayhem" http://jeremiahgrossman.blogspot.com/2008/05/crossdomainxml-invites-cross-site.html
* Google Doctype: "Introduction to Flash security " - http://code.google.com/p/doctype-mirror/wiki/ArticleFlashSecurity
* http://www.html5rocks.com/en/tutorials/cors/
* Krzysztof Kotowicz: "How to upload arbitrary file contents cross-domain"- http://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html
* W3C: "Cross-Origin Resource Sharing" - http://www.w3.org/TR/cors/
<br>
* Secureideas: "Grab a CORS Light" - http://blog.secureideas.com/2013/02/grab-cors-light.html
'''Tools'''<br>
* Nikto
* OWASP Zed Attack Proxy Project
* W3af

Test RIA cross domain policy (OTG-CONFIG-008)

2014-03-13T11:13:29Z

Eduardo Castellanos:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Rich Internet Applications (RIA) have adopted Adobe's crossdomain.xml policy files in order to allow for controlled cross domain access to data and service consumption using technologies such as Oracle Java, Silverlight, and Adobe Flash. Therefore, a domain can grant remote access to its services from a different domain. However, often the policy files that describe the access restrictions are poorly configured. Poor configuration of the policy files enables Cross-site Request Forgery attacks, and may allow third parties to access sensitive data meant for the user.

HTML5 also incorporates a new way of performing cross domain requests: Cross Origin Resource Sharing (CORS). These can also be improperly configured and enable an attacker to perform similar attacks.

== Description of the Issue ==
=== What are cross-domain policy files ===
A cross-domain policy file specifies the permissions that a web client such as Java, Adobe Flash, Adobe Reader, etc. to access data across different domains. For Silverlight, Microsoft adopted a subset of the Adobe's crossdomain.xml, and additionally created it's own cross-domain policy file: clientaccesspolicy.xml.

Whenever a web client detects that a resource has to be requested from other domain, it will first look for a policy file in the target domain in order to determine if performing cross-domain requests, including headers, and socket-based connections are allowed.

Master policy files are located at the domain's root. A client may be instructed to load a different policy file, however, it will always check the master policy file first to ensure that the master policy file permits the requested policy file.

==== Crossdomain.xml vs. Clientaccesspolicy.xml ====
Most RIA applications support crossdomain.xml. However in the case of Silverlight, it will only work if the crossdomain.xml specifies that access is allowed from any domain. For more granular control with Silverlight, clientaccesspolicy.xml must be used.

Policy files grant several types of permissions:
* Accepted policy files (Master policy files can disable or restrict specific policy files)
* Sockets permissions
* Header permissions
* HTTP/HTTPS access permissions
* Allowing access based on cryptographic credentials

An example of an overly permissive policy file:
<pre>
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>
</pre>
=== What is CORS===
CORS is HTML5's way of enabling web applications to perform cross-domain requests. CORS works by appending an "Origin" header to the HTTP request, then the server responds with a "Access-Control-Allow-Origin" header stating which website can issue cross domain requests. The server may answer with the Access-Control-Allow-Origin header set to * to indicate that it is a public resource.

=== How can cross domain policies can be abused ===
* Overly permissive cross-domain policies
* Generating server responses that may be treated as cross-domain policy files
* Using file upload functionality to upload files that may be treated as cross-domain policy files.
* Being able to set custom response headers to indicate cross domain access. (Access-Control-Allow-Origin: *)

=== Impact of abusing cross-domain access ===
* Defeat CSRF protections
* Read data restricted or otherwise protected by cross-origin policies.

== Black Box testing and example ==
'''Testing for RIA policy files weakness:''' <br>
In order to test for RIA policy file weakness you should try to retrieve the policy files crossdomain.xml and clientaccesspolicy.xml from the application's root, and from every folder found.<br><br>
For example, if the application's URL is http://www.owasp.org, you should try to download the files http://www.owasp.org/crossdomain.xml and http://www.owasp.org/clientaccesspolicy.xml.
<br><br>
After retrieving all the policy files, the permissions allowed should be be checked under the least privilege principle. Requests should only come from the domains, ports, or protocols that are necessary. Overly permissive policies should be avoided. Policies with "*" in them should be closely examined. <br><br>
Example:
<pre><cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy></pre>

'''Result Expected:'''<br>
A list of policy files found. <br>
A weak settings in the policies.<br>

'''Testing for CORS policy weakness:''' <br>
User your favorite interception proxy to issue an OPTIONS request to the server with the following headers set):<br>
* Origin: Origin can be any URL other than the website you are testing on or null.
* Access-Control-Request-Method: This can be GET, POST, PUT, DELETE, etc. You should try with different values.
* Access-Control-Request-Headers: This can be almost any request header. You should try to with sensitive headers. (This is optional)
<br>
A request will then look like this:

<pre>
OPTIONS /resources/target HTTP/1.1
Host: example.com
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://owasp.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.9 Safari/536.5
Access-Control-Request-Headers: x-extraheader, content-type
Accept: */*
Referer: http://example.com/page.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,es;q=0.6
</pre>

A successful response would look like this: <br>
<pre>
HTTP/1.1 200 OK
Date: Thu, 13 Mar 2014 10:18:45 GMT
Server: Apache
Access-Control-Allow-Origin: http://example.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-EXTRAHEADER, CONTENT-TYPE
Access-Control-Max-Age: 1728000
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain
</pre>

You should carefully inspect the "Access-Control-Allow-Origin", "Access-Control-Allow-Methods", "Access-Control-Allow-Credentials", "Access-Control-Allow-Headers", "Access-Control-Allow-Expose-Headers", and any other header that starts with "Access-Control-Allow-". The value of each of this headers should be set to the most restrictive setting. For example a specific domain for "Access-Control-Allow-Origin".
== References ==
'''Whitepapers'''<br>
* UCSD: "Analyzing the Crossdomain Policies of Flash Applications" - http://cseweb.ucsd.edu/~hovav/dist/crossdomain.pdf
* Adobe: "Cross-domain policy file specification" - http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
* Adobe: "Cross-domain policy file usage recommendations for Flash Player" - http://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html
* Oracle: "Cross-Domain XML Support" - http://www.oracle.com/technetwork/java/javase/plugin2-142482.html#CROSSDOMAINXML
* MSDN: "Making a Service Available Across Domain Boundaries" - http://msdn.microsoft.com/en-us/library/cc197955(v=vs.95).aspx
* MSDN: "Network Security Access Restrictions in Silverlight" - http://msdn.microsoft.com/en-us/library/cc645032(v=vs.95).aspx
* Stefan Esser: "Poking new holes with Flash Crossdomain Policy Files" http://www.hardened-php.net/library/poking_new_holes_with_flash_crossdomain_policy_files.html
* Jeremiah Grossman: "Crossdomain.xml Invites Cross-site Mayhem" http://jeremiahgrossman.blogspot.com/2008/05/crossdomainxml-invites-cross-site.html
* Google Doctype: "Introduction to Flash security " - http://code.google.com/p/doctype-mirror/wiki/ArticleFlashSecurity
* http://www.html5rocks.com/en/tutorials/cors/
* Krzysztof Kotowicz: "How to upload arbitrary file contents cross-domain"- http://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html
* W3C: "Cross-Origin Resource Sharing" - http://www.w3.org/TR/cors/
<br>
'''Tools'''<br>
* Nikto
* OWASP Zed Attack Proxy Project
* W3af

Test RIA cross domain policy (OTG-CONFIG-008)

2014-03-13T11:12:21Z

Eduardo Castellanos:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Rich Internet Applications (RIA) have adopted Adobe's crossdomain.xml policy files in order to allow for controlled cross domain access to data and service consumption using technologies such as Oracle Java, Silverlight, and Adobe Flash. Therefore, a domain can grant remote access to its services from a different domain. However, often the policy files that describe the access restrictions are poorly configured. Poor configuration of the policy files enables Cross-site Request Forgery attacks, and may allow third parties to access sensitive data meant for the user.

HTML5 also incorporates a new way of performing cross domain requests: Cross Origin Resource Sharing (CORS). These can also be improperly configured and enable an attacker to perform similar attacks.

== Description of the Issue ==
=== What are cross-domain policy files ===
A cross-domain policy file specifies the permissions that a web client such as Java, Adobe Flash, Adobe Reader, etc. to access data across different domains. For Silverlight, Microsoft adopted a subset of the Adobe's crossdomain.xml, and additionally created it's own cross-domain policy file: clientaccesspolicy.xml.

Whenever a web client detects that a resource has to be requested from other domain, it will first look for a policy file in the target domain in order to determine if performing cross-domain requests, including headers, and socket-based connections are allowed.

Master policy files are located at the domain's root. A client may be instructed to load a different policy file, however, it will always check the master policy file first to ensure that the master policy file permits the requested policy file.

==== Crossdomain.xml vs. Clientaccesspolicy.xml ====
Most RIA applications support crossdomain.xml. However in the case of Silverlight, it will only work if the crossdomain.xml specifies that access is allowed from any domain. For more granular control with Silverlight, clientaccesspolicy.xml must be used.

Policy files grant several types of permissions:
* Accepted policy files (Master policy files can disable or restrict specific policy files)
* Sockets permissions
* Header permissions
* HTTP/HTTPS access permissions
* Allowing access based on cryptographic credentials

An example of an overly permissive policy file:
<pre>
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>
</pre>
=== What is CORS===
CORS is HTML5's way of enabling web applications to perform cross-domain requests. CORS works by appending an "Origin" header to the HTTP request, then the server responds with a "Access-Control-Allow-Origin" header stating which website can issue cross domain requests. The server may answer with the Access-Control-Allow-Origin header set to * to indicate that it is a public resource.

=== How can cross domain policies can be abused ===
* Overly permissive cross-domain policies
* Generating server responses that may be treated as cross-domain policy files
* Using file upload functionality to upload files that may be treated as cross-domain policy files.
* Being able to set custom response headers to indicate cross domain access. (Access-Control-Allow-Origin: *)

=== Impact of abusing cross-domain access ===
* Defeat CSRF protections
* Read data restricted or otherwise protected by cross-origin policies.

== Black Box testing and example ==
'''Testing for RIA policy files weakness:''' <br>
In order to test for RIA policy file weakness you should try to retrieve the policy files crossdomain.xml and clientaccesspolicy.xml from the application's root, and from every folder found.<br><br>
For example, if the application's URL is http://www.owasp.org, you should try to download the files http://www.owasp.org/crossdomain.xml and http://www.owasp.org/clientaccesspolicy.xml.
<br><br>
After retrieving all the policy files, the permissions allowed should be be checked under the least privilege principle. Requests should only come from the domains, ports, or protocols that are necessary. Overly permissive policies should be avoided. Policies with "*" in them should be closely examined. <br><br>
Example:
<pre><cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy></pre>

'''Result Expected:'''<br>
A list of policy files found. <br>
A weak settings in the policies.<br>

'''Testing for CORS policy weakness:''' <br>
Issue an OPTIONS request to the server with the following headers set:<br>
* Origin: Origin can be any URL other than the website you are testing on or null.
* Access-Control-Request-Method: This can be GET, POST, PUT, DELETE, etc. You should try with different values.
* Access-Control-Request-Headers: This can be almost any request header. You should try to with sensitive headers. (This is optional)
<br>
A request will then look like this:

<pre>
OPTIONS /resources/target HTTP/1.1
Host: example.com
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://owasp.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.9 Safari/536.5
Access-Control-Request-Headers: x-extraheader, content-type
Accept: */*
Referer: http://example.com/page.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,es;q=0.6
</pre>

A successful response would look like this: <br>
<pre>
HTTP/1.1 200 OK
Date: Thu, 13 Mar 2014 10:18:45 GMT
Server: Apache
Access-Control-Allow-Origin: http://example.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-EXTRAHEADER, CONTENT-TYPE
Access-Control-Max-Age: 1728000
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain
</pre>

You should carefully inspect the "Access-Control-Allow-Origin", "Access-Control-Allow-Methods", "Access-Control-Allow-Credentials", "Access-Control-Allow-Headers", "Access-Control-Allow-Expose-Headers", and any other header that starts with "Access-Control-Allow-". The value of each of this headers should be set to the most restrictive setting. For example a specific domain for "Access-Control-Allow-Origin".
== References ==
'''Whitepapers'''<br>
* UCSD: "Analyzing the Crossdomain Policies of Flash Applications" - http://cseweb.ucsd.edu/~hovav/dist/crossdomain.pdf
* Adobe: "Cross-domain policy file specification" - http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
* Adobe: "Cross-domain policy file usage recommendations for Flash Player" - http://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html
* Oracle: "Cross-Domain XML Support" - http://www.oracle.com/technetwork/java/javase/plugin2-142482.html#CROSSDOMAINXML
* MSDN: "Making a Service Available Across Domain Boundaries" - http://msdn.microsoft.com/en-us/library/cc197955(v=vs.95).aspx
* MSDN: "Network Security Access Restrictions in Silverlight" - http://msdn.microsoft.com/en-us/library/cc645032(v=vs.95).aspx
* Stefan Esser: "Poking new holes with Flash Crossdomain Policy Files" http://www.hardened-php.net/library/poking_new_holes_with_flash_crossdomain_policy_files.html
* Jeremiah Grossman: "Crossdomain.xml Invites Cross-site Mayhem" http://jeremiahgrossman.blogspot.com/2008/05/crossdomainxml-invites-cross-site.html
* Google Doctype: "Introduction to Flash security " - http://code.google.com/p/doctype-mirror/wiki/ArticleFlashSecurity
* http://www.html5rocks.com/en/tutorials/cors/
* Krzysztof Kotowicz: "How to upload arbitrary file contents cross-domain"- http://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html
* W3C: "Cross-Origin Resource Sharing" - http://www.w3.org/TR/cors/
<br>
'''Tools'''<br>
* Nikto
* OWASP Zed Attack Proxy Project
* W3af

Test RIA cross domain policy (OTG-CONFIG-008)

2014-03-13T11:06:09Z

Eduardo Castellanos:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Rich Internet Applications (RIA) have adopted Adobe's crossdomain.xml policy files in order to allow for controlled cross domain access to data and service consumption using technologies such as Oracle Java, Silverlight, and Adobe Flash. Therefore, a domain can grant remote access to its services from a different domain. However, often the policy files that describe the access restrictions are poorly configured. Poor configuration of the policy files enables Cross-site Request Forgery attacks, and may allow third parties to access sensitive data meant for the user.

HTML5 also incorporates a new way of performing cross domain requests: Cross Origin Resource Sharing (CORS). These can also be improperly configured and enable an attacker to perform similar attacks.

== Description of the Issue ==
=== What are cross-domain policy files ===
A cross-domain policy file specifies the permissions that a web client such as Java, Adobe Flash, Adobe Reader, etc. to access data across different domains. For Silverlight, Microsoft adopted a subset of the Adobe's crossdomain.xml, and additionally created it's own cross-domain policy file: clientaccesspolicy.xml.

Whenever a web client detects that a resource has to be requested from other domain, it will first look for a policy file in the target domain in order to determine if performing cross-domain requests, including headers, and socket-based connections are allowed.

Master policy files are located at the domain's root. A client may be instructed to load a different policy file, however, it will always check the master policy file first to ensure that the master policy file permits the requested policy file.

==== Crossdomain.xml vs. Clientaccesspolicy.xml ====
Most RIA applications support crossdomain.xml. However in the case of Silverlight, it will only work if the crossdomain.xml specifies that access is allowed from any domain. For more granular control with Silverlight, clientaccesspolicy.xml must be used.

Policy files grant several types of permissions:
* Accepted policy files (Master policy files can disable or restrict specific policy files)
* Sockets permissions
* Header permissions
* HTTP/HTTPS access permissions
* Allowing access based on cryptographic credentials

An example of an overly permissive policy file:
<pre>
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>
</pre>
=== What is CORS===
CORS is HTML5's way of enabling web applications to perform cross-domain requests. CORS works by appending an "Origin" header to the HTTP request, then the server responds with a "Access-Control-Allow-Origin" header stating which website can issue cross domain requests. The server may answer with the Access-Control-Allow-Origin header set to * to indicate that it is a public resource.

=== How can cross domain policies can be abused ===
* Overly permissive cross-domain policies
* Generating server responses that may be treated as cross-domain policy files
* Using file upload functionality to upload files that may be treated as cross-domain policy files.
* Being able to set custom response headers to indicate cross domain access. (Access-Control-Allow-Origin: *)

=== Impact of abusing cross-domain access ===
* Defeat CSRF protections
* Read data restricted or otherwise protected by cross-origin policies.

== Black Box testing and example ==
'''Testing for RIA policy files weakness:''' <br>
In order to test for RIA policy file weakness you should try to retrieve the policy files crossdomain.xml and clientaccesspolicy.xml from the application's root, and from every folder found.<br><br>
For example, if the application's URL is http://www.owasp.org, you should try to download the files http://www.owasp.org/crossdomain.xml and http://www.owasp.org/clientaccesspolicy.xml.
<br><br>
After retrieving all the policy files, the permissions allowed should be be checked under the least privilege principle. Requests should only come from the domains, ports, or protocols that are necessary. Overly permissive policies should be avoided. Policies with "*" in them should be closely examined. <br><br>
Example:
<pre><cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy></pre>

'''Result Expected:'''<br>
A list of policy files found. <br>
A weak settings in the policies.<br>

'''Testing for CORS policy weakness:''' <br>
Issue an OPTIONS request to the server with the following headers set:<br>
* Origin: Origin can be any URL other than the website you are testing on or null.
* Access-Control-Request-Method: This can be GET, POST, PUT, DELETE, etc. You should try with different values.
* Access-Control-Request-Headers: This can be almost any request header. You should try to with sensitive headers. (This is optional)
<br>
A request will then look like this:

<pre>
OPTIONS /resources/target HTTP/1.1
Host: example.com
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://owasp.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.9 Safari/536.5
Access-Control-Request-Headers: x-extraheader, content-type
Accept: */*
Referer: http://example.com/page.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,es;q=0.6
</pre>

A successful response would look like this: <br>
<pre>
HTTP/1.1 200 OK
Date: Thu, 13 Mar 2014 10:18:45 GMT
Server: Apache
Access-Control-Allow-Origin: http://example.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-EXTRAHEADER, CONTENT-TYPE
Access-Control-Max-Age: 1728000
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain
</pre>

You should carefully inspect the "Access-Control-Allow-Origin", "Access-Control-Allow-Methods", "Access-Control-Allow-Credentials", "Access-Control-Allow-Headers", "Access-Control-Allow-Expose-Headers", and any other header that starts with "Access-Control-Allow-". The value of each of this headers should be set to the most restrictive setting. For example a specific domain for "Access-Control-Allow-Origin".
== References ==
'''Whitepapers'''<br>
* UCSD: "Analyzing the Crossdomain Policies of Flash Applications" - http://cseweb.ucsd.edu/~hovav/dist/crossdomain.pdf
* Adobe: "Cross-domain policy file specification" - http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
* Adobe: "Cross-domain policy file usage recommendations for Flash Player" - http://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html
* Oracle: "Cross-Domain XML Support" - http://www.oracle.com/technetwork/java/javase/plugin2-142482.html#CROSSDOMAINXML
* MSDN: "Making a Service Available Across Domain Boundaries" - http://msdn.microsoft.com/en-us/library/cc197955(v=vs.95).aspx
* MSDN: "Network Security Access Restrictions in Silverlight" - http://msdn.microsoft.com/en-us/library/cc645032(v=vs.95).aspx
* Stefan Esser: "Poking new holes with Flash Crossdomain Policy Files" http://www.hardened-php.net/library/poking_new_holes_with_flash_crossdomain_policy_files.html
* Jeremiah Grossman: "Crossdomain.xml Invites Cross-site Mayhem" http://jeremiahgrossman.blogspot.com/2008/05/crossdomainxml-invites-cross-site.html
* Google Doctype: "Introduction to Flash security " - http://code.google.com/p/doctype-mirror/wiki/ArticleFlashSecurity
* http://www.html5rocks.com/en/tutorials/cors/
* Krzysztof Kotowicz: "How to upload arbitrary file contents cross-domain"- http://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html
* W3C: "Cross-Origin Resource Sharing" - http://www.w3.org/TR/cors/
<br>
'''Tools'''<br>
* Nikto
* OWASP Zed Attack Proxy Project

Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)

2014-03-10T13:26:51Z

Eduardo Castellanos:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
Sensitive data must be protected when it is transmitted through the network. These data includes credentials and credit cards. As a rule of thumb if data must be protected when it is stored, it must be protected also during transmission.

HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. Use of these protocols ensure not only confidentiality but also authentication. Servers are authenticated using digital certificates, and it is also possibile to use client certificate for mutual authentication.

Even if high grade ciphers are today supported and normally used, some misconfiguration in server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.

== Description of the Issue ==
If control is missed and HTTP protocol is used to transmit sensitive information is a vulnerability [2] (e.g. credentials transmitted over HTTP [3]) and there are a specific OWASP Testing Guide v4’s test.

If SSL/TLS service is present it is good but it increments the attack surface and some vulnerabilities insist on it, such as:
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.
* Certificate validity must be ensured.
Other vulnerabilities linked to this is:
* Software exposed must be updated due to possibility of known vulnerabilities [4].
* Usage of Secure flag for Session Cookies [5].
* Usage of HTTP Strict Transport Security (HSTS) [6].
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.

===Sensitive data transmitted in clear-text===
If the application transmits sensitive information via unencrypted channels - e.g. HTTP - it is a vulnerability. Typically it is possible to find BASIC authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.

===Weak SSL/TLS Ciphers/Protocols/Keys===
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.
Briefly, the key points for the cipher suite determination are the following:
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server).

It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control, for example, whether or not conversations with clients will support 40-bit encryption only.

#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.
#The server sends a ServerHelloDone message and waits for a client response.
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.

===SSL certificate validity – client and server===

When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates, like follow:
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.
# The server sends a ServerHelloDone message and waits for a client response.
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.

In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this Guide, we will focus on the main criteria involved in ascertaining certificate validity:

* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);
* Checking that the certificate is currently valid;
* Checking that the name of the site and the name reported in the certificate match.

Let is examine each check more in detail.

* Each browser comes with a preloaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates).

* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed.

* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced.

===Other vulnerabilities===
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as Infrastructure vulnerability if software is not up to date [4]. Futhermore for a correct protection of data during transmission Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP [9]).

Also there are some attacks can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.

== Black Box testing and example ==

===Testing for sensitive data transmitted in clear-text===
Various typologies of information which must be protected can be also transmitted in clear text. It is possible to check if these information is transmitted over HTTP instead of HTTPS.

Please refer to specific Tests for full details, for credentials [3] and other kind of data [2].

=====Example 1. Basic Authentication over HTTP=====
A typical example is the usage of Basic Authentication over HTTP. Also because with Basic Authentication, after login, credentials are encoded - and not encrypted - into HTTP Headers.
<pre>
$ curl -kis http://example.com/restricted/
HTTP/1.1 401 Authorization Required
Date: Fri, 01 Aug 2013 00:00:00 GMT
WWW-Authenticate: Basic realm="Restricted Area"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Length: 162
Content-Type: text/html

<html><head><title>401 Authorization Required</title></head>
<body bgcolor=white>
<h1>401 Authorization Required</h1>

Invalid login credentials!

</body></html>
</pre>

===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===
Large number of available cipher suites and quick progress in cryptanalysis makes judging a SSL server a non-trivial task. At the time of writing these criteria are widely recognized as minimum checklist:
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).
* No Export (EXP) level cipher suites, due to can be easly broken [10].
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].
A most complete checklist includes:
* Secure Renegotiation should be enabled.
* MD5 should not be used, due to known collision attacks. [35]
* RC4 should not be used, due to crypto-analytical attacks [15].
* Server should be protected from BEAST Attack [16].
* Server should be protected from CRIME attack, TLS compression must be disabled [17].
* Server should support Forward Secrecy [18].

Following standards can be used as reference while assessing SSL servers:
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].

Some tools and scanners both free - e.g. SSLAudit [28] or SSLScan [29] and commercial - e.g. Tenable Nessus [27], and other used into examples - can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way is also to check them manually with openssl [30] or using tool’s output as an input for manual evaluation using the references on the bottom on the Test to stay updated.

Sometimes the SSL/TLS enabled service is not directly accessible and you can access it only via HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port in order to start SSL/TLS handshake. This will obviously not work since desired port is accessible only via HTTP proxy. You can easily circumvent this by using relaying software such as socat [37].

====Example 2. SSL service recognition via nmap====
First step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).
In this example we search for SSL services using nmap with “-sV” option, used for identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.

<pre>
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST
Nmap scan report for www.example.com (127.0.0.1)
Host is up, received user-set (0.20s latency).
Not shown: 89 filtered ports
Reason: 89 no-responses
PORT STATE SERVICE REASON VERSION
21/tcp open ftp syn-ack Pure-FTPd
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)
25/tcp open smtp syn-ack Exim smtpd 4.80
26/tcp open smtp syn-ack Exim smtpd 4.80
80/tcp open http syn-ack
110/tcp open pop3 syn-ack Dovecot pop3d
143/tcp open imap syn-ack Dovecot imapd
443/tcp open ssl/http syn-ack Apache
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80
993/tcp open ssl/imap syn-ack Dovecot imapd
995/tcp open ssl/pop3 syn-ack Dovecot pop3d
Service Info: Hosts: example.com
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds
</pre>

====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====
nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].

<pre>
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST
Nmap scan report for www.example.com (127.0.0.1)
Host is up (0.090s latency).
rDNS record for 127.0.0.1: www.example.com
PORT STATE SERVICE
443/tcp open https
| ssl-cert: Subject: commonName=www.example.org
| Issuer: commonName=*******
| Public Key type: rsa
| Public Key bits: 1024
| Not valid before: 2010-01-23T00:00:00+00:00
| Not valid after: 2020-02-28T23:59:59+00:00
| MD5: *******
|_SHA-1: *******
| ssl-enum-ciphers:
| SSLv3:
| ciphers:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
| TLSv1.0:
| ciphers:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
|_ least strength: strong
465/tcp open smtps
| ssl-cert: Subject: commonName=*.exapmple.com
| Issuer: commonName=*******
| Public Key type: rsa
| Public Key bits: 2048
| Not valid before: 2010-01-23T00:00:00+00:00
| Not valid after: 2020-02-28T23:59:59+00:00
| MD5: *******
|_SHA-1: *******
| ssl-enum-ciphers:
| SSLv3:
| ciphers:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
| TLSv1.0:
| ciphers:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
|_ least strength: strong
993/tcp open imaps
| ssl-cert: Subject: commonName=*.exapmple.com
| Issuer: commonName=*******
| Public Key type: rsa
| Public Key bits: 2048
| Not valid before: 2010-01-23T00:00:00+00:00
| Not valid after: 2020-02-28T23:59:59+00:00
| MD5: *******
|_SHA-1: *******
| ssl-enum-ciphers:
| SSLv3:
| ciphers:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
| TLSv1.0:
| ciphers:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
|_ least strength: strong
995/tcp open pop3s
| ssl-cert: Subject: commonName=*.exapmple.com
| Issuer: commonName=*******
| Public Key type: rsa
| Public Key bits: 2048
| Not valid before: 2010-01-23T00:00:00+00:00
| Not valid after: 2020-02-28T23:59:59+00:00
| MD5: *******
|_SHA-1: *******
| ssl-enum-ciphers:
| SSLv3:
| ciphers:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
| TLSv1.0:
| ciphers:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
|_ least strength: strong
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds
</pre>

====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====
openssl [30] can be used for testing manually SSL/TLS. In this example we try to initiate a renegotiation by client [m] connecting to server with openssl - writing the fist line of an HTTP request, in a new line typing “R”, waiting for renegotiaion and completing the HTTP request - and check if secure renegotiaion is supperted looking server output. Using manual request it is also possible to see if Compression is enabled for TLS in order to check for CRIME [13], check for ciphers and other vulnerabilities.

<pre>
$ openssl s_client -connect www2.example.com:443
CONNECTED(00000003)
depth=2 ******
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:******
i:******
1 s:******
i:******
2 s:******
i:******
---
Server certificate
-----BEGIN CERTIFICATE-----
******
-----END CERTIFICATE-----
subject=******
issuer=******
---
No client certificate CA names sent
---
SSL handshake has read 3558 bytes and written 640 bytes
---
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DES-CBC3-SHA
Session-ID: ******
Session-ID-ctx:
Master-Key: ******
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: ******
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
</pre>
Now we can write the first line of an HTTP request and then R in a new line.
<pre>
HEAD / HTTP/1.1
R
</pre>
Server is renegotiating
<pre>
RENEGOTIATING
depth=2 C******
verify error:num=20:unable to get local issuer certificate
verify return:0
</pre>
And we can complete our request, checking for response.
<pre>
HEAD / HTTP/1.1

HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )
Connection: close
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 1792

read:errno=0
</pre>
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.

====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====
TestSSLServer [32] is a script which permits to check cipher suite and also BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that sould be disabled. It is really interesting a first fix for BEAST was the usage of RC4, but this is discouraged due to a crypto-analytical attack to RC4 [15].

An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].

<pre>
$ java -jar TestSSLServer.jar www3.example.com 443
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
Deflate compression: no
Supported cipher suites (ORDER IS NOT SIGNIFICANT):
SSLv3
RSA_WITH_RC4_128_SHA
RSA_WITH_3DES_EDE_CBC_SHA
DHE_RSA_WITH_3DES_EDE_CBC_SHA
RSA_WITH_AES_128_CBC_SHA
DHE_RSA_WITH_AES_128_CBC_SHA
RSA_WITH_AES_256_CBC_SHA
DHE_RSA_WITH_AES_256_CBC_SHA
RSA_WITH_CAMELLIA_128_CBC_SHA
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
RSA_WITH_CAMELLIA_256_CBC_SHA
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_SEED_CBC_SHA
TLS_DHE_RSA_WITH_SEED_CBC_SHA
(TLSv1.0: idem)
(TLSv1.1: idem)
TLSv1.2
RSA_WITH_RC4_128_SHA
RSA_WITH_3DES_EDE_CBC_SHA
DHE_RSA_WITH_3DES_EDE_CBC_SHA
RSA_WITH_AES_128_CBC_SHA
DHE_RSA_WITH_AES_128_CBC_SHA
RSA_WITH_AES_256_CBC_SHA
DHE_RSA_WITH_AES_256_CBC_SHA
RSA_WITH_AES_128_CBC_SHA256
RSA_WITH_AES_256_CBC_SHA256
RSA_WITH_CAMELLIA_128_CBC_SHA
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
DHE_RSA_WITH_AES_128_CBC_SHA256
DHE_RSA_WITH_AES_256_CBC_SHA256
RSA_WITH_CAMELLIA_256_CBC_SHA
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_SEED_CBC_SHA
TLS_DHE_RSA_WITH_SEED_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
----------------------
Server certificate(s):
******
----------------------
Minimal encryption strength: strong encryption (96-bit or more)
Achievable encryption strength: strong encryption (96-bit or more)
BEAST status: vulnerable
CRIME status: protected

</pre>

====Example 6. Testing SSL/TLS vulnerabilities with sslyze====
sslyze [33] is a python script which permits also mass scan and XML output. Follows an example of a regular scan. Is one of the most complete and versatile tool for SSL/TLS testing.

<pre>
./sslyze.py --regular example.com:443

REGISTERING AVAILABLE PLUGINS
-----------------------------

PluginHSTS
PluginSessionRenegotiation
PluginCertInfo
PluginSessionResumption
PluginOpenSSLCipherSuites
PluginCompression

CHECKING HOST(S) AVAILABILITY
-----------------------------

example.com:443 => 127.0.0.1:443

SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443
---------------------------------------------------

* Compression :
Compression Support: Disabled

* Session Renegotiation :
Client-initiated Renegotiations: Rejected
Secure Renegotiation: Supported

* Certificate :
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate
Hostname Validation: MISMATCH
SHA1 Fingerprint: ******

Common Name: www.example.com
Issuer: ******
Serial Number: ****
Not Before: Sep 26 00:00:00 2010 GMT
Not After: Sep 26 23:59:59 2020 GMT

Signature Algorithm: sha1WithRSAEncryption
Key Size: 1024 bit
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}

* OCSP Stapling :
Server did not send back an OCSP response.

* Session Resumption :
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).
With TLS Session Tickets: Supported

* SSLV2 Cipher Suites :

Rejected Cipher Suite(s): Hidden

Preferred Cipher Suite: None

Accepted Cipher Suite(s): None

Undefined - An unexpected error happened: None

* SSLV3 Cipher Suites :

Rejected Cipher Suite(s): Hidden

Preferred Cipher Suite:
RC4-SHA 128 bits HTTP 200 OK

Accepted Cipher Suite(s):
CAMELLIA256-SHA 256 bits HTTP 200 OK
RC4-SHA 128 bits HTTP 200 OK
CAMELLIA128-SHA 128 bits HTTP 200 OK

Undefined - An unexpected error happened: None

* TLSV1_1 Cipher Suites :

Rejected Cipher Suite(s): Hidden

Preferred Cipher Suite: None

Accepted Cipher Suite(s): None

Undefined - An unexpected error happened:
ECDH-RSA-AES256-SHA socket.timeout - timed out
ECDH-ECDSA-AES256-SHA socket.timeout - timed out

* TLSV1_2 Cipher Suites :

Rejected Cipher Suite(s): Hidden

Preferred Cipher Suite: None

Accepted Cipher Suite(s): None

Undefined - An unexpected error happened:
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out

* TLSV1 Cipher Suites :

Rejected Cipher Suite(s): Hidden

Preferred Cipher Suite:
RC4-SHA 128 bits Timeout on HTTP GET

Accepted Cipher Suite(s):
CAMELLIA256-SHA 256 bits HTTP 200 OK
RC4-SHA 128 bits HTTP 200 OK
CAMELLIA128-SHA 128 bits HTTP 200 OK

Undefined - An unexpected error happened:
ADH-CAMELLIA256-SHA socket.timeout - timed out

SCAN COMPLETED IN 9.68 S
------------------------
</pre>

===Testing SSL certificate validity – client and server===
Firstly upgrade your browser because also CA certs expire and, in every release of the browser, these are been renewed.
Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match namewise with the site to which they should refer. By clicking on the padlock which appears in the browser window when visiting an HTTPS site, you can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, you probably have installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates.
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services.

Some tools, as in previous examples, check also for certificate validity.

====Example 7. Testing for certificate validity (manually)====
Rather than providing a fictitious example, we have inserted an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming.
The following screenshots refer to a regional site of a high-profile IT company.

We are visiting an .it site and the certificate was issued to a .com site! Internet Explorer warns that the name on the certificate does not match the name of the site.

[[Image:SSL Certificate Validity Testing IE Warning.gif]]
''Warning issued by Microsoft Internet Explorer''

The message issued by Firefox is different – Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come preloaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.

[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]
''Warning issued by Mozilla Firefox''

===Testing for other vulnerabilities===
As mentioned previously there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. A part from others discussed in other parts of the Guide, the another one is possible when the server provide the website both with the HTTP and HTTPS protocols, and permit to an attacker to force a victim into using a non-secure channel instead of a secure one.

====Surf Jacking====
Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.
The following is a scenario of how the attack can take place:

The following is a scenario of how the attack can take place:
* Victim logs into the secure website at https://somesecuresite/.
* The secure site issues a session cookie as the client logs in.
* While logged in, the victim opens a new browser window and goes to http:// examplesite/
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing cookie in the HTTP header in clear text
* The attacker sees this traffic and logs the cookie for later (ab)use.
To test if a website is vulnerable is sufficient to proceed like follow:
# Check if website supports both HTTP and HTTPS protocol
# Check if cookies do not have the “Secure” flag

====SSL Strip====
Often applications supports both HTTP and HTTPS. As for usability or because users do not use to type “https://www.example.com”. Often users go into an HTTPS website from link or a redirect. Typically also home banking site have a similar configuration with an iframed login or a form with action attribute over HTTPS but the page under HTTP.
An attacker in a privileged position - as described in SSL strip [8] - can incercept traffic when user is into HTTP and manipulate it to get a Man-In-The-Middle attack under HTTPS.
To test if application is vulnerable is sufficient the website supports both HTTP and HTTPS.

===Testing via HTTP proxy===

Inside corporate environment you can see services that are not directly accessible and you can access them only via HTTP proxy using CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to desired tcp port in order to start SSL/TLS handshake. With the help of relaying software such as socat [37] you can re-enable those tools for use with services behind HTTP proxy.

====Example 8. Testing via HTTP proxy====

To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:
<pre>
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128
</pre>

Then you can target all other tools to localhost:9999:
<pre>
$ openssl s_client -connect localhost:9999
</pre>

All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.

== Gray Box testing and example ==

===Testing for Weak SSL/TLS Cipher Suites===
Check the configuration of the web servers which provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well.

====Example 9. Windows Server====
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre>
which has some sub-keys like Ciphers, Protocols and KeyExchangeAlgorithms.

====Example 10: Apache====
To check the cipher suites and protocols supported by Apache2 web server open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.

===Testing SSL certificate validity – client and server===
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level; however, there may be additional communication paths protected by SSL (for example, towards the DBMS). You should check the application architecture to identify all SSL protected channels.

==References==
'''OWASP Resources'''
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)]
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]
* [6] [OWASP Testing |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)]
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]

'''Whitepapers'''
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]

'''Tools'''
* [21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner
* [27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.
* [32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST
* [33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.
* [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.
* [29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.
* [31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.
* [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services
* [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)
* [37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay

[[Category:Cryptographic Vulnerability]]
[[Category:SSL]]

Test RIA cross domain policy (OTG-CONFIG-008)

2013-09-05T22:06:05Z

Eduardo Castellanos:

Test RIA cross domain policy (OTG-CONFIG-008)

2013-09-05T21:52:57Z

Eduardo Castellanos:

Test RIA cross domain policy (OTG-CONFIG-008)

2013-09-05T17:02:11Z

Eduardo Castellanos:

Test RIA cross domain policy (OTG-CONFIG-008)

2013-09-03T06:49:10Z

Eduardo Castellanos:

Test RIA cross domain policy (OTG-CONFIG-008)

2013-09-03T06:47:40Z

Eduardo Castellanos:

Test RIA cross domain policy (OTG-CONFIG-008)

2013-09-03T06:43:21Z

Eduardo Castellanos:

Test RIA cross domain policy (OTG-CONFIG-008)

2013-09-03T06:42:43Z

Eduardo Castellanos:

Test RIA cross domain policy (OTG-CONFIG-008)

2013-02-19T22:49:33Z

Eduardo Castellanos:

Test RIA cross domain policy (OTG-CONFIG-008)

2013-02-19T22:23:34Z

Eduardo Castellanos:

Test RIA cross domain policy (OTG-CONFIG-008)

2013-02-19T18:05:46Z

Eduardo Castellanos:

OWASP Testing Guide v4 Table of Contents

2012-11-28T00:06:37Z

Eduardo Castellanos:

__NOTOC__

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

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

'''Updated: 26th November 2012'''

[[ 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 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 ''']] [Andrew Muller]

[[Testing for Web Server Fingerprint (OWASP-IG-010)|4.2.10 Testing for Web Server Fingerprint (OWASP-IG-010)]]

[[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|4.2.1 Spiders, Robots and Crawlers (OWASP-IG-001)]] [Modify! rename to "Review Webserver Metafiles" - could also be considered a Configuration Management test]

[[Testing for Application Discovery (OWASP-IG-005)|4.2.5 Application Discovery (OWASP-IG-005)]] [Modify! - rename to "Enumerate Applications on Webserver"]

[[Testing Review webpage comments and metadata(OWASP-IG-007)|4.2.7 Review webpage comments and metadata(OWASP-IG-007)]]

[[Testing: Identify application entry points (OWASP-IG-003)|4.2.3 Identify application entry points (OWASP-IG-003)]]

[[Testing Identify application exit/handover points (OWASP-IG-008)|4.2.8 Identify application exit/handover points (OWASP-IG-008)]]

[[Testing Map execution paths through application (OWASP-IG-009)|4.2.9 Map execution paths through application (OWASP-IG-009)]]

[[Testing for Web Application Fingerprint (OWASP-IG-004)|4.2.4 Testing for Web Application Fingerprint (OWASP-IG-004)]]

[[Testing for Error Code (OWASP-IG-006)|4.2.6 Analysis of Error Codes (OWASP-IG-006)]]

[[Testing: Search engine discovery/reconnaissance (OWASP-IG-002)|4.2.2 Search Engine Discovery/Reconnaissance (OWASP-IG-002)]]

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

[[Testing for infrastructure configuration management (OWASP-CM-003)|4.3.1 Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)]]

[[Testing for application configuration management (OWASP-CM-004)|4.3.2 Testing for Application Configuration Management weakness (OWASP-CM-002)]]

[[Testing for file extensions handling (OWASP-CM-005)|4.3.3 Testing for File Extensions Handling (OWASP-CM-003)]]

[[Testing for Old, Backup and Unreferenced Files (OWASP-CM-006)|4.3.4 Old, Backup and Unreferenced Files (OWASP-CM-004) ]]

[[Testing for Admin Interfaces (OWASP-CM-007)|4.3.5 Infrastructure and Application Admin Interfaces (OWASP-CM-005)]]

[[Testing for HTTP Methods and XST (OWASP-CM-008)|4.3.6 Testing for Bad HTTP Methods (OWASP-CM-006)]][new - Abian Blome]

> Informative Error Messages [MAT NOTE: in info gathering]<br>

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

[[Testing for Content Security Policy weakness|4.3.8 Testing for Content Security Policy weakness (OWASP-CM-008)]][New! - Simone Onofri]

[[Testing for Missing HSTS header|4.3.9 Testing for Missing HSTS header (OWASP-CM-009)]][New! Juan Manuel Bahamonde ]

[[Testing for RIA policy files weakness|4.3.10 Testing for RIA policy files weakness (OWASP-CM-010)]] [New! - Eduardo Castellanos]

> Incorrect time[New! MAT NOTE: explain the test in detail please]

> Unpatched components and libraries (e.g. JavaScript libraries)[New! NOTE: tu discuss it][Note: this can be covered inside OWASP-CM-001/OWASP-CM-002]

> Test data in production systems (and vice versa)[New! MAT NOTE: this is not a particular test that could find a vulnerability]<br>

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

[[Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|4.4.1 Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)]] [Robert Winkel]

[[Testing for User Enumeration and Guessable User Account (OWASP-AT-002)|4.4.2 Testing for User Enumeration and Guessable User Account (OWASP-AT-002)]] [Robert Winkel]

[[Testing for default credentials (OWASP-AT-003)|4.4.3 Testing for default credentials (OWASP-AT-003)]]

[[Testing for Weak lock out mechanism (OWASP-AT-004)|4.4.4 Testing for Weak lock out mechanism (OWASP-AT-004)]] [New! - Robert Winkel]

> Account lockout DoS [New! - Robert Winkel - we can put it in the 4.4.4]

[[Testing for Bypassing Authentication Schema (OWASP-AT-005)|4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)]]

[[Testing for Vulnerable Remember Password (OWASP-AT-006)|4.4.6 Testing for vulnerable remember
password functionality (OWASP-AT-006)]] [Robert Winkel]

[[Testing for Browser cache weakness (OWASP-AT-007)|4.4.7 Testing for Browser cache weakness (OWASP-AT-007)]] [New! - Abian Blome]

[[Testing for Weak password policy (OWASP-AT-008)|4.4.8 Testing for Weak password policy (OWASP-AT-008)]] [New! - Robert Winkel]

[[Testing for Weak or unenforced username policy (OWASP-AT-009)|4.4.9 Testing for Weak or unenforced username policy (OWASP-AT-009)]] [New! - Robert Winkel]

> Weak security question/answer [New! - Robert Winkel - MAT Note: same as AT-006]<br>

[[Testing for failure to restrict access to authenticated resource(OWASP-AT-010)|4.4.10 Testing for failure to restrict access to authenticated resource (OWASP-AT-010)]] [New! - This seems better suited to the Authorization test cases (Andrew Muller)]<br>

[[Testing for weak password change or reset functionalities (OWASP-AT-011)|4.4.11 Testing for weak password change or reset functionalities (OWASP-AT-011)]] [New! - Robert Winkel]<br>

[[Testing for Captcha (OWASP-AT-012)|4.4.12 Testing for CAPTCHA (OWASP-AT-012)]] [Note: Andrew Muller - CAPTCHA's objective is not authentication but to test humanness. This could be moved to Business Logic or the now deleted Denial of Service section]

> Weaker authentication in alternative channel (e.g. mobile app, IVR, help desk) [New!: MAT Note: to explain better the kind of test to perform please]<br>

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

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

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

[[Testing for Session Fixation (OWASP-SM-003)|4.5.3 Testing for Session Fixation (OWASP-SM-003)]]

[[Testing for Exposed Session Variables (OWASP-SM-004)|4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)]]

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

> Weak Session Token (MAT NOTE included in 4.5.1)

[[Testing for Session token not restricted properly (OWASP-SM-006)|4.5.6 Testing for Session token not restricted properly (such as domain or path not set properly) (OWASP-SM-006)]] [New! - Abian Blome]<br>

> Session passed over http (NOTE: included in SM-004) [New!] <br>

[[Testing for logout functionality (OWASP-SM-007)|4.5.7 Testing for logout functionality (OWASP-SM-007)]]

>Session token not removed on server after logout [New!: NOTE included in the above test]<br>

> Logout function not properly implemented (NOTE:same above)<br>

> Persistent session token [New! NOTE: this is not a vulnerability if session time out is correctly performed]<br>

[[Testing for Session puzzling (OWASP-SM-008)|4.5.8 Testing for Session puzzling (OWASP-SM-008)]] [New! - Abian Blome]

> Missing user-viewable log of authentication events [NOTE: needs more details: which test perform?]

> Establishment of multiple sessions with same credentials [New! - Andrew Muller]

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

[[Testing for Path Traversal (OWASP-AZ-001)|4.6.1 Testing Directory traversal/file include (OWASP-AZ-001) [Juan Galiana] ]]

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

[[Testing for Privilege escalation (OWASP-AZ-003)|4.6.3 Testing for Privilege Escalation (OWASP-AZ-003) [Irene Abezgauz]]]

[[Testing for Insecure Direct Object References (OWASP-AZ-004)|4.6.4 Testing for Insecure Direct Object References (OWASP-AZ-004) [Irene Abezgauz] ]]

[[Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)|4.6.5 Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005) [New!] ]]

> Server component has excessive privileges (e.g. indexing service, reporting interface, file generator)[New!]<br>
> Lack of enforcement of application entry points (including exposure of objects)[New!]<br>

[[Testing for business logic (OWASP-BL-001)|'''4.7 Business Logic Testing (OWASP-BL-001)''']] [To review--> contributor here]
Business Logic<br>

Business logic data validation[New!] NOTE MAT: to discuss this section<br>
Ability to forge requests[New!]<br>
Lack of integrity checks (e.g. overwriting updates) [New!]<br>
Lack of tamper evidence[New!]<br>
Use of untrusted time source[New!]<br>
Lack of limits to excessive rate (speed) of use[New!]<br>
Lack of limits to size of request[New!]<br>
Lack of limit to number of times a function can be used[New!]<br>
Bypass of correct sequence[New!]<br>
Missing user-viewable log of activity[New!]<br>
Self-hosted payment cardholder data processing[New!]<br>
Lack of security incident reporting information[New!]<br>
Defenses against application mis-use[New!]<br>

[[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 (OWASP-DV-001) ]]

[[Testing for Stored Cross site scripting (OWASP-DV-002) |4.8.2 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 [Brad Causey] ]]

[[Testing for HTTP Parameter pollution (OWASP-DV-004)|4.8.4 Testing for HTTP Parameter pollution [Luca Carettoni, Stefano Di Paola, Brad Causey] ]]

[[Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)|4.8.5 Testing for Unvalidated Redirects and Forwards [Brad Causey] ]]

[[Testing for SQL Injection (OWASP-DV-005)| 4.8.5 Testing for SQL Injection (OWASP-DV-005) [Ismael Gonçalves](Ismael NOTE: ready to be reviewed)]]

[[Testing for Oracle|4.8.5.1 Oracle Testing]]

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

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

[[Testing for MS Access |4.8.5.4 MS Access Testing]]

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

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

[[Testing for LDAP Injection (OWASP-DV-006)|4.8.6 Testing for LDAP Injection (OWASP-DV-006)]]

[[Testing for ORM Injection (OWASP-DV-007)|4.8.7 Testing for ORM Injection (OWASP-DV-007)]]

[[Testing for XML Injection (OWASP-DV-008)|4.8.8 Testing for XML Injection (OWASP-DV-008)]]

[[Testing for SSI Injection (OWASP-DV-009)|4.8.9 Testing for SSI Injection (OWASP-DV-009)]]

[[Testing for XPath Injection (OWASP-DV-010)|4.8.10 Testing for XPath Injection (OWASP-DV-010)]]

[[Testing for IMAP/SMTP Injection (OWASP-DV-011)|4.8.11 IMAP/SMTP Injection (OWASP-DV-011)]]

[[Testing for Code Injection (OWASP-DV-012)|4.8.12 Testing for Code Injection (OWASP-DV-012)]]

[[Testing for Command Injection (OWASP-DV-013)|4.8.13 Testing for Command Injection (OWASP-DV-013) [Juan Galiana]]]

[[Testing for Buffer Overflow (OWASP-DV-014)|4.8.14 Testing for Buffer overflow (OWASP-DV-014)]]

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

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

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

[[Testing for Incubated Vulnerability (OWASP-DV-015)|4.8.15 Testing for incubated vulnerabilities (OWASP-DV-015)]]

[[Testing for HTTP Splitting/Smuggling (OWASP-DV-016)|4.8.16 Testing for HTTP Splitting/Smuggling (OWASP-DV-016) [Juan Galiana] ]]

> Regular expression DoS[New!] note: to understand better<br>

> XML DoS [New! - Andrew Muller]

[[Data Encryption (New!)]]

[[Testing for Insecure encryption usage (OWASP-EN-001)| 4.9.1 Testing for Insecure encryption usage (OWASP-EN-001]]

[[Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)| 4.9.2 Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)]]

[[Testing for Padding Oracle (OWASP-EN-003)| 4.9.3 Testing for Padding Oracle (OWASP-EN-003) [Giorgio Fedon]]]

> [[Testing for Cacheable HTTPS Response | x.x.3 Testing for Cacheable HTTPS Response<br>
Cache directives insecure<br>
> Testing for Insecure Cryptographic Storage [put in x.x.1]<br>
[[Testing for Sensitive information sent via unencrypted channels | x.x.4<br>

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

[[Scoping a Web Service Test (OWASP-WS-001)|4.10.1 Scoping a Web Service Test (OWASP-WS-001)]]

[[WS Information Gathering (OWASP-WS-002)|4.10.2 WS Information Gathering (OWASP-WS-002)]]

[[WS Authentication Testing (OWASP-WS-003)|4.10.3 WS Authentication Testing (OWASP-WS-003)]]

[[WS Management Interface Testing (OWASP-WS-004)|4.10.4 WS Management Interface Testing (OWASP-WS-004)]]

[[Weak XML Structure Testing (OWASP-WS-005)|4.10.5 Weak XML Structure Testing (OWASP-WS-005)]]

[[XML Content-Level Testing (OWASP-WS-006)|4.10.6 XML Content-Level Testing (OWASP-WS-006)]]

[[WS HTTP GET Parameters/REST Testing (OWASP-WS-007)|4.10.7 WS HTTP GET Parameters/REST Testing (OWASP-WS-007)]]

[[WS Naughty SOAP Attachment Testing (OWASP-WS-008)|4.10.8 WS Naughty SOAP Attachment Testing (OWASP-WS-008)]]

[[WS Replay/MiTM Testing (OWASP-WS-009)|4.10.9 WS Replay/MiTM Testing (OWASP-WS-009)]]

[[WS BEPL Testing (OWASP-WS-010)|4.10.10 WS BEPL Testing (OWASP-WS-010)]]

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

[[Testing for DOM-based Cross site scripting (OWASP-DV-003)|4.11.1 Testing for DOM based Cross Site Scripting (OWASP-CS-001) [Stefano Di Paola] ]]

[[Testing for HTML5 (OWASP CS-002)|4.11.2 Testing for HTML5 (OWASP CS-002) [Juan Galiana] ]]<br/>

[[Testing for Cross site flashing (OWASP-DV-004)|4.11.3 Testing for Cross Site Flashing (OWASP-CS-003)]]

[[Testing for Testing for ClickHijacking (OWASP-CS-004)|4.11.4 Testing for Testing for ClickHijacking (OWASP-CS-004) ]]<br>

==[[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. We need only tools for webapp testing]

==[[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--> contributor here]

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==

[To review--> contributor here]

----

[[Category:OWASP Testing Project]]

Test RIA cross domain policy (OTG-CONFIG-008)

2012-11-28T00:05:13Z

Eduardo Castellanos:

Test RIA cross domain policy (OTG-CONFIG-008)

2012-11-27T23:55:42Z

Eduardo Castellanos:

Test RIA cross domain policy (OTG-CONFIG-008)

2012-11-27T23:43:04Z

Eduardo Castellanos:

Test RIA cross domain policy (OTG-CONFIG-008)

2012-11-27T23:09:40Z

Eduardo Castellanos:

Test RIA cross domain policy (OTG-CONFIG-008)

2012-11-27T22:00:38Z

Eduardo Castellanos:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
<br>
Rich Internet Applications (RIA) have adopted Adobe's crossdomain.xml policy files in order to allow for controlled cross domain access to data and service consumption using technologies such as Oracle Java, Silverlight, and Adobe Flash. Therefore, a domain can grant remote access to its services from a different domain. However, often the policy files that describe the access restrictions are poorly configured. Poor configuration of the policy files enables Cross-site Request Forgery attacks, and may allow third parties to access sensitive data meant for the user.

<br>
== Description of the Issue ==
<br>
...here: Short Description of the Issue: Topic and Explanation
<br>
== Black Box testing and example ==
'''Testing for Topic X vulnerabilities:''' <br>
...<br>
'''Result Expected:'''<br>
...<br><br>
== References ==
'''Whitepapers'''<br>
http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
<br>
'''Tools'''<br>
...<br>

User:Eduardo Castellanos

2010-06-25T16:38:21Z

Eduardo Castellanos:

Former Web Application Developer.

Graduated from Universidad del Valle de Guatemala in 2009.
Obtained the title of: Licenciatura en Ingeniería en Ciencias de la Computación.

Working as a Security Analyst for Sistemas Aplicativos S.A. / Verizon Business Security Solutions.