0

I'm trying to verify the CORS settings of a website using cURL. The following command should let me check whether the CORS settings can be considered as secure or if requests may be made across origins.

I'm performing a preflight check, but the same should work with normal request and the origin header.

Preflight:

curl -H "Origin: https://example.local" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: X-Requested-With" \
  -X OPTIONS -D - -o /dev/null\
  -x http://127.0.0.1:8080/\
  https://example.com

GET with Origin:

  curl -H "Origin: https://example.local"\
  -D - -o /dev/null\
  https://example.com

Now what I do not understand, is that the target application simply answers with the content as usual. No Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers headers.

So I effectively can't decide on whether the CORS settings are secure or not. I tried to proxy the requests through Burp (with the two methods below), but something's wrong there and the request never reaches Burp.

Method 1 cURL:

curl [...] -x http://127.0.0.1:8080/ [...]

Method 2 CLI:

export https_proxy='https://127.0.0.1:8080/'
export http_proxy='http://127.0.0.1:8080/'

curl [...]

export https_proxy=''
export http_proxy=''

What may cause the odd behavior of the web application with my OPTIONS pre-flight requests and the GET request with the origin header. How can I successfully proxy the request through Burp to verify the request itself?

SaAtomic
  • 989
  • 2
  • 15
  • 27
  • I'm not really sure what your problem is. If the site does not provide any specific CORS settings then the default CORS settings are used, i.e. no cross-origin read access is allowed etc. Access-Control-* headers are only needed to define exceptions from the strict default policy. – Steffen Ullrich Nov 15 '17 at 15:30
  • I cringe when i see CORS and security in the same place; CORS is not about security. – dandavis Nov 15 '17 at 22:17
  • @SteffenUllrich but if the default CORS are used, shouldn't the preflight request or the request with the explicitly different origin fail? – SaAtomic Nov 16 '17 at 06:40
  • @dandavis Why? I've had multiple occasions where vulnerabilities could only be exploited due to CORS misconfiguration. I'm quite confident that this can be filed as security relevant. – SaAtomic Nov 16 '17 at 06:41
  • 3
    @SaAtomic: The idea of CORS is that the client (browser) interprets the servers response and acts accordingly. It is not a restriction enforced at the server but at the client. The server only sends the policy the client should enforce. – Steffen Ullrich Nov 16 '17 at 07:24

1 Answers1

4

You should only specify the origin header in your request. The application will respond with the Access-Control-* headers. Try only specifying the origin header and see what the result looks like.

As far as if the headers are not returned at all, the web server doesn't have to respond with a CORS policy. If it doesn't then the browser will not allow cross origin requests as per usual. CORS allows the server to enable cross origin requests given certain criteria.

The main issue that I find when doing testing for CORS issues is that the Access-Control-Allow-Origin header is populated by what is sent in via the Origin header in the request. This defeats the entire purpose of CORS. An attacker shouldn't be able to define allowed origins.

There are several different Burp extensions that will report on CORS related misconfigurations and security issues. There is also this post on the Portswigger blog detailing some common misconfigurations.

http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html

Joshua Gimer
  • 290
  • 1
  • 5