7 ms·

This isn't fully accurate -- you can never prevent cross-site POST requests from being initiated, with or without CORS. For example, CORS is never involved in r

This isn't fully accurate -- you can never prevent cross-site POST requests from being initiated, with or without CORS. For example, CORS is never involved in requests from <form> submissions (which can be triggered via JavaScript). Really CORS cannot be used to lock anything down. The behavior of a server not implementing CORS has the same end result as a server trying to be as restrictive as possible. Both would not send any CORS headers in responses and would simply ignore pre-flight requests.

jrockway 5y ago
Yup. CORS has so many loopholes that you should pretend like it doesn't exist. My favorite is... imagine I routinely port-forward an app's debug port to my workstation for debugging. It has a useful /email-debug-info?address=example@example.com endpoint. You can then call that over the Internet by serving me a web page that contains <img src="http://localhost:1234/email-debug-info?address=example@example.com http://localhost:1234/email-debug-info?address=example@examp...">. CORS doesn't care. My browser doesn't care. It will just silently leak information. (Also great for other things on your network. Log into your router at 192.168.1.1 recently? Someone can make a web page with a form that submits to http://192.168.1.1/enable-port-forwarding http://192.168.1.1/enable-port-forwarding or whatever, and you can forward whatever ports you want.) What's hilarious to me is that CORS seems burdensome in the opposite direction too. It breaks peoples applications somehow! While writing this comment, I did a search to see if I could remember the standards-track proposal for fixing the two "bugs" I mention above... but all the search results are people asking how to disable CORS rules because their app is broken. Sigh! The web is a mess.
- dividuum 5y ago
  > My browser doesn't care. It soon will https://web.dev/cors-rfc1918-feedback/ https://web.dev/cors-rfc1918-feedback/
- deleted 5y ago
  [deleted]
- accept-apply 5y ago
  Isn't this a CSRF issue?
- JanSt 5y ago
  Apart from the misunderstanding that CORS protects you, you are describing two scenarios. I don't really understand the first one or why you think SOP should protect you in that case. Could you restate that problem? The second one is a CSRF issue, as noted by another user. The third thing you describe is not people who disable CORS but actually use CORS to the max (usally things like Access-Control-Allow-Origin: *), because they don't understand what it does. It's a huge problem...
- Mavvie 5y ago
  As mentioned, CORS isn't designed to protect against requests where the response isn't read by another origin's JS. Even with fetch I think you could "bypass" CORS to the same extent as this example by passing the "no-cors" mode. This is just a CSRF issue, which is well understood and easily fixed with a CSRF/authenticity token. Also, GET requests should not have side effects like sending an email. A reasonable default seen in some frameworks is GET requests have no side effects and don't require CSRF tokens, while all other verbs do.
hoppla 5y ago
Form Posts are limited to few content types, and application/json is not one of them. I have however found some CSRFs against POST endpoints that did not care that the request was text/plain
goto11 5y ago
> Really CORS cannot be used to lock anything down. Lets say you have a legitimate website with uses form POST's or GET's to implement cross-site requests to some service on a different domain, authenticated through a cookie. This is vulnerable to cross-site request forging. Changing this to use fetch with CORS can protect against this kind of attack, since the service can now ensure the request is initiated from a legitimate origin. It is just important to understand what CORS protect against and what it doesn't protect against. You can always forge a request to look exactly like a CORS-compliant request from a legitimate origin - but you still wouldn't have the necessary authentication cookie. If the attacker have somehow gotten access to the users cookie, then there is no need for request-forging in the first place, the attacker can just directly log into the service. If the users browser is compromised it is the same. So CORS protect against the specific scenario where a malicious site visited by a legitimate user forges a request to a legitimate site, misusing the authentication cookie associated with the legitimate domain. In this scenario, the CORS header will indicate the origin of the malicious site, and the server will be able to reject the request.
- Xylakant 5y ago
  AFAIR it’s never the server that rejects the request in a CORS scenario: The server indicates what origins are allowed to call the API and the browser cancels the request on behalf of the user if called on a website that’s not on the allowed list. The server canceling the request based on a header would be insecure since the client can send arbitrary headers.
  - goto11 5y ago
    JavaScript in an uncompromized browser cannot send arbitrary headers. See: https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_... Otherwise a malicious site could just forge the Origin header in the preflight request.
    - iancarroll 5y ago
      This is true, but there have been a lot of browser bugs in the past with Origin/Referer headers. Relying on those is not as foolproof as a CSRF token, which would require a more severe UXSS-type issue to leak. I wouldn’t advise it.
mmis1000 5y ago
> Really CORS cannot be used to lock anything down. yep, that's what Cross-Origin Resource Policy (CORP) for. It is designed to seal the last loop hole in same-origin policy. (img and scripts don't require cors at all) But there is a big gotcha, the old browser that don't know about it simply don't care. So it isn't strictly useful for now.

jrockway 5y ago

Yup. CORS has so many loopholes that you should pretend like it doesn't exist. My favorite is... imagine I routinely port-forward an app's debug port to my workstation for debugging. It has a useful /email-debug-info?address=example@example.com endpoint. You can then call that over the Internet by serving me a web page that contains <img src="http://localhost:1234/email-debug-info?address=example@example.com http://localhost:1234/email-debug-info?address=example@examp...">. CORS doesn't care. My browser doesn't care. It will just silently leak information. (Also great for other things on your network. Log into your router at 192.168.1.1 recently? Someone can make a web page with a form that submits to http://192.168.1.1/enable-port-forwarding http://192.168.1.1/enable-port-forwarding or whatever, and you can forward whatever ports you want.) What's hilarious to me is that CORS seems burdensome in the opposite direction too. It breaks peoples applications somehow! While writing this comment, I did a search to see if I could remember the standards-track proposal for fixing the two "bugs" I mention above... but all the search results are people asking how to disable CORS rules because their app is broken. Sigh! The web is a mess.

dividuum 5y ago
> My browser doesn't care. It soon will https://web.dev/cors-rfc1918-feedback/ https://web.dev/cors-rfc1918-feedback/
deleted 5y ago
[deleted]
accept-apply 5y ago
Isn't this a CSRF issue?
JanSt 5y ago
Apart from the misunderstanding that CORS protects you, you are describing two scenarios. I don't really understand the first one or why you think SOP should protect you in that case. Could you restate that problem? The second one is a CSRF issue, as noted by another user. The third thing you describe is not people who disable CORS but actually use CORS to the max (usally things like Access-Control-Allow-Origin: *), because they don't understand what it does. It's a huge problem...
Mavvie 5y ago
As mentioned, CORS isn't designed to protect against requests where the response isn't read by another origin's JS. Even with fetch I think you could "bypass" CORS to the same extent as this example by passing the "no-cors" mode. This is just a CSRF issue, which is well understood and easily fixed with a CSRF/authenticity token. Also, GET requests should not have side effects like sending an email. A reasonable default seen in some frameworks is GET requests have no side effects and don't require CSRF tokens, while all other verbs do.

hoppla 5y ago

Form Posts are limited to few content types, and application/json is not one of them. I have however found some CSRFs against POST endpoints that did not care that the request was text/plain

goto11 5y ago

> Really CORS cannot be used to lock anything down. Lets say you have a legitimate website with uses form POST's or GET's to implement cross-site requests to some service on a different domain, authenticated through a cookie. This is vulnerable to cross-site request forging. Changing this to use fetch with CORS can protect against this kind of attack, since the service can now ensure the request is initiated from a legitimate origin. It is just important to understand what CORS protect against and what it doesn't protect against. You can always forge a request to look exactly like a CORS-compliant request from a legitimate origin - but you still wouldn't have the necessary authentication cookie. If the attacker have somehow gotten access to the users cookie, then there is no need for request-forging in the first place, the attacker can just directly log into the service. If the users browser is compromised it is the same. So CORS protect against the specific scenario where a malicious site visited by a legitimate user forges a request to a legitimate site, misusing the authentication cookie associated with the legitimate domain. In this scenario, the CORS header will indicate the origin of the malicious site, and the server will be able to reject the request.

Xylakant 5y ago
AFAIR it’s never the server that rejects the request in a CORS scenario: The server indicates what origins are allowed to call the API and the browser cancels the request on behalf of the user if called on a website that’s not on the allowed list. The server canceling the request based on a header would be insecure since the client can send arbitrary headers.
- goto11 5y ago
  JavaScript in an uncompromized browser cannot send arbitrary headers. See: https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_... Otherwise a malicious site could just forge the Origin header in the preflight request.
  - iancarroll 5y ago
    This is true, but there have been a lot of browser bugs in the past with Origin/Referer headers. Relying on those is not as foolproof as a CSRF token, which would require a more severe UXSS-type issue to leak. I wouldn’t advise it.

mmis1000 5y ago

> Really CORS cannot be used to lock anything down. yep, that's what Cross-Origin Resource Policy (CORP) for. It is designed to seal the last loop hole in same-origin policy. (img and scripts don't require cors at all) But there is a big gotcha, the old browser that don't know about it simply don't care. So it isn't strictly useful for now.