Check for insecure CORS settings with cURL

Question

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?

Answer 1

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