1590340 - violation of CORS “preflight” request for POST request

Status: RESOLVED INVALID

(Core :: DOM: Networking, task)

Description

[Naor Hemed]

Attachment: cors_poc.rar

I was able to perform POST request with body, without triggering the “preflight” request. I tested the two apis XMLHttpRequest and fetch, in both of them I was able to post data to unaware CORS site. the XMLHttpRequest even allowed to put the user credential on request (the cookie)

Comment 1

[Naor Hemed]

the rar archive contains client side code, and full bug report

Comment 2

[Naor Hemed]

official mozzila docs with defintions can be found here
https://developer.mozilla.org/en-US/docs/Glossary/CORS
https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request

the cross origin resource sharing designed to load resource that are foreign to your origin.
it does so by looking at the header "Access-Control-Allow-Origin" and watch for correct value.

because the browser need to send a request before receiving the header POST request make a problem.
the body of the post request should be sent to without knowing whether the foreign origin is actually CORS aware ?
of course not!!!. for that the "preflight" mechanism exists.

the "preflight" request sends an OPTIONS request to the foreign origin to check if it aware that another origin client make request to it.
only if the headers mentioned in mozzila docs appears the browser know that the remote origin is aware of CORS.
than the browser sends the full POST request with the content after checking the remote origin is aware of that.
the bug i mentioned shows that the browser will not always send "preflight" request;
therefore a XSS attack can POST authenticated requests to unaware CORS site and make actions with the user creds.
everything that is protected with csrf token will not be affected because we dont know the token.

when I tried to put some headers, i found that the browser will trigger the "preflight" request, and than the attack will fail.
but in default state this will not happen

Comment 3

[Daniel Veditz [:dveditz]]

There are a handful of allowed content-types for POST that do not get pre-flight. Anything that could have come from an HTML <form> doesn't need a pre-flight because that's historical behavior, and XHR/Fetch are just a convenience. CORS offers no protection in that case.

Comment 4

[Naor Hemed]

the docs says :
"A CORS preflight request is a CORS request that checks to see if the CORS protocol is understood and a server is aware using specific methods and headers."
this policy should be enforced in the browser logic, and not programmer setting some headers on his request.
think about the following attack senario :
assumption : attacker can execute javascript on the user dom
the attacker submit an HTML form to "http://bank-forgot-csrf.com/corsWhatIsThat?" to make some transaction
the request is executed and the attack goal achieved

think about all the home wifi routers that are exposed to this kind of attack when someone visit some site which has some stored xss. in our modern day, in my opinion, this historical support should end

Comment 5

[Daniel Veditz [:dveditz]]

Your testcase doesn't ever specify the Content-Type so it defaults to text/plain. This is one of the three MIME types that are allowed in a POST without a preflight. This is intentional CORS behavior because there's no point in adding the inefficient extra request when an HTML <form> can already do this. In this scenario the server already has to be prepared for a malicious POST of this form, so all the browser needs to do is check the CORS headers on the response to see whether the fetch/xhr can access it.

As your testcase notes in comments, if you change Content-Type to something else (application/json in your code) then the preflight does happen, as it should. Please see the description of Simple Requests (meaning preflight is not required) in MDN: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests