7 ms·

The blog post author doesn't understand CORS either! Their advice on how to fix the problem is wrong: > So what would a secure implementation of this feature

The blog post author doesn't understand CORS either! Their advice on how to fix the problem is wrong: > So what would a secure implementation of this feature look like? The webserver listening in on "localhost:19421" should implement a REST API and set a "Access-Control-Allow-Origin" header with the value "https://zoom.us" https://zoom.us". This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver. "Access-Control-Allow-Origin" doesn't block the request from going through, it just prevents wrong-origin Javascript from accessing the response. The original vulnerability actually just a slight variant of cross-site request forgery (CSRF) -- "wrong site request forgery" :-) For the localhost server to detect wrong-site requests, there are two simple options: 1. Use a CSRF token. This requires a shared secret between the localhost server and the Zoom website. 2. Check the "Origin" header. This requires that the request be an HTTP POST, which is what they should be. (Note: If you're determined to use some CORS machinery, you could build something more complicated based on pre-flight requests, but there's no point.)

ChrisCinelli 7y ago
> "Access-Control-Allow-Origin" doesn't block the request from going through, it just prevents wrong-origin Javascript from accessing the response." On a GET request (like the one generated by a IMG tag) and all the other cases that do not require a pre-flight request ( https://www.w3.org/TR/cors/#preflight-request https://www.w3.org/TR/cors/#preflight-request ) this is correct. Are we clear on the thread model and what Zoom is trying to do? As far as I know, Zoom wants to make "joining a meeting" as easy as clicking a link. I do not think Zoom wants people to be logged in a zoom account in order to join. And what Zoom should try to avoid is to have random people joining meetings and website forcing actions on the laptop of the people. A simple fix is to use a GUID or any other long not-guessable string for the meeting id. And, of course, do not expose any other potentially dangerous endpoints beside the one that starts the meeting. In general it should not be about either CORS or CSRF. There are better ways to start a video call communicating with a plugin than exposing a port on localhost and using <img src="localhost:12345/a-command?aParameter=12345" /> to communicate with it.
- kortilla 7y ago
  I’m not sure you understand the threat model either. Even if the meeting ID is a GUID, you’re still leaving an avenue for people to have their visitors join arbitrary meetings.
  - ChrisCinelli 7y ago
    Well, I guess I need to explicitly say that having the Zoom client asking something like: "www.visited-site.com" wants to start a meeting with you. Do you want to join? is (uncommon?) common sense that the Zoom app should follow.
    - TazeTSchnitzel 7y ago
      They seem to have engineered this just to avoid such a prompt, because Safari brings up one when navigating to a protocol that launches an external app.
- Thorrez 7y ago
  The threat model seems to have 2 requirements: 1. Only if the top level url bar says zoom.us is it allowed to cause any noticeable change to the zoom native app. This means some arbitrary website cannot cause any noticeable change to the zoom native app without redirecting you to zoom.us . This also means that a sandboxed iframe, such as an embedded web ad, has no possible way to cause a noticeable change to the zoom native app, because it is not able to do top level navigation to zoom.us . 2. When the zoom native app is triggered, the user must click yes on a confirmation button before joining the meeting. I don't see people advocating that you need to be logged in to zoom.us . Achieving requirement 1 without requirement 2 is still bad, because some website could redirect to zoom.us and force you into a meeting. Achieving requirement 2 without requirement 1 is not too bad, but is annoying, because some sandboxed ad in a website could cause the zoom native app to pop up, annoying you, and could maybe almost be a DOS.
- deleted 7y ago
  [deleted]
cpitman 7y ago
Is this true if the request is a POST? Shouldn't a POST lead to a preflight request, and then the browser refusing to send the real request?
- greenshackle2 7y ago
  POST requests are not necessarily preflighted. If they used non-standard headers or content-type it would be. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simpl...
- shiado 7y ago
  The designers of CORS kept the previous security for certain types of POST requests because they are basically equivalent to how forms work, which operate at a much worse security standard and are a source of a great number of CSRF problems. The simplest way to remember it is that most things which break the legacy behavior of POST triggers the preflight. Speaking of form problems last I checked HN has a login CSRF.
- paulddraper 7y ago
  It will trigger preflight if POST and not a form content type. (E.g. a POST application/json)
deleted 7y ago
[deleted]
avodonosov 7y ago
> "Access-Control-Allow-Origin" doesn't block the request from going through, it just prevents wrong-origin Javascript from accessing the response. If the server only reacts to POST, then Access-Control-Allow-Origin may be enough, because the browser will fist do a preflight OPTIONS, and if Access-Control-Allow-Origin is not set, the POST will not be made by the browser.
- edaemon 7y ago
  There are some exceptional cases where a POST is allowed without a preflight check: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simpl...
  - avodonosov 7y ago
    You are right, and reading this the cases are not really exceptional but rather usual; so yes, it's better to not rely on CORS for protection in this case.
    - oefrha 7y ago
      Not really, you can just check that Content-Type is application/json and refuse to do anything if it’s not. That effectively shuts down application/x-www-url-encoded or multipart/form-data CSRFs. In fact, parsing POST payload as JSON without checking Content-Type first is frowned upon, and some frameworks refuse to do that by default.
      - zaroth 7y ago
        (Throws up hands) But this is ridiculous! The security of the API can’t rely on strict validation of the content-type, how is that code supposed to make any sense to the 3rd generation of developers who are tasked to maintain it 5 years from now? CORS is clearly not designed as a means of access control to ensure the POST request will never be made. Therefore, it is fairly catastrophic that an article prognosticating about how nobody bloody well understands CORS has also gotten it terribly wrong. What this tells me is that there is probably big money in bug bounties for finding sites which use CORS for access control, and almost certainly are not checking the content-type.
chrisfosterelli 7y ago
The advice isn't wrong, but you did misunderstand it. The CORS header will definitively block the request to an AJAX REST API from going through, because it will be a POST request with an `application/json` Content-Type, which will trigger a preflight request. You're assuming the API will remain identical, just with new headers. I didn't advise this, what they have now is not a semantically RESTful API. What they have now is a mess made to fit within their image-hack's constraints, there's no sensible reason to keep the same GET pattern without that.
- comex 7y ago
  You shouldn’t assume that a post titled “Developers don’t understand CORS” will only be read by people that understand all the intricacies of CORS. :) For everyone else, the need for a POST request [edit2: as well as a non-form Content-Type] may not be immediately apparent. (Edit: It’s true that a proper RESTful API shouldn’t be using GET for operations with side effects anyway, but that’s different from knowing that avoiding it is mandatory for security.)
  - chrisfosterelli 7y ago
    Haha true! It's tricky to find a balance between a short post that nails home a point and a complete guide that hits all the nuances. I definitely intended the former here but I think this is good evidence there is room for the later.
    - spydum 7y ago
      i think the tragedy of web security is that, it's become too complicated to provide simple guidance to developers who are feature-focused. They don't want to become experts in security-header-machinery and crazy amount of domain knowledge needed, but there aren't many other options. Just look at all the security options a dev has to contend with: HSTS CORS (with it's myriad of headers.. ACAO, ACAH, ACAC, etc.) CSRF XSS CSP SRI .. That doesn't even count the other fun stuff like SQLi, XXE, LFI, RFI, SSRF, and on and on. It's become real obvious to me, that if the framework or language they develop with doesn't provide it enabled by default AND the most commonly searchable/referenced docs don't explictly tell you to disable it - it's likely not going to happen.
tootie 7y ago
Is all of that worthless if the calls to localhost aren't encrypted?
- Thorrez 7y ago
  All of what worthless? The advice that cakoose gives seems quite valid to me without any encryption to localhost. What do you mean encrypt calls to localhost? Encrypt with https? That sounds hard since you can't get a real CA to issue you such a cert. I don't see much point in encrypting with https because people off your machine can't sniff or intercept your connection to localhost. Is your goal to protect yourself from other programs or users on your same machine? That might be a valid concern on a machine with multiple users, but definitely makes the problem harder. Or do you want some custom application-level encryption? I can't think of a good way to implement that either, but maybe it's possible. But since I don't know what attacks you're trying to protect against, I can't tell whether there's any benefit at all to encryption.
eranation 7y ago
Worth mentioning that according to OWASP's latest recommendation #1 is considered as a first line of defense and #2 is considered more as a defense in depth technique (e.g. in addition to #1, not as a replacement): https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...) The SameSite=Strict is also an honorable mention as an up and coming technique once all browsers support it.
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]

ChrisCinelli 7y ago

> "Access-Control-Allow-Origin" doesn't block the request from going through, it just prevents wrong-origin Javascript from accessing the response." On a GET request (like the one generated by a IMG tag) and all the other cases that do not require a pre-flight request ( https://www.w3.org/TR/cors/#preflight-request https://www.w3.org/TR/cors/#preflight-request ) this is correct. Are we clear on the thread model and what Zoom is trying to do? As far as I know, Zoom wants to make "joining a meeting" as easy as clicking a link. I do not think Zoom wants people to be logged in a zoom account in order to join. And what Zoom should try to avoid is to have random people joining meetings and website forcing actions on the laptop of the people. A simple fix is to use a GUID or any other long not-guessable string for the meeting id. And, of course, do not expose any other potentially dangerous endpoints beside the one that starts the meeting. In general it should not be about either CORS or CSRF. There are better ways to start a video call communicating with a plugin than exposing a port on localhost and using <img src="localhost:12345/a-command?aParameter=12345" /> to communicate with it.

kortilla 7y ago
I’m not sure you understand the threat model either. Even if the meeting ID is a GUID, you’re still leaving an avenue for people to have their visitors join arbitrary meetings.
- ChrisCinelli 7y ago
  Well, I guess I need to explicitly say that having the Zoom client asking something like: "www.visited-site.com" wants to start a meeting with you. Do you want to join? is (uncommon?) common sense that the Zoom app should follow.
  - TazeTSchnitzel 7y ago
    They seem to have engineered this just to avoid such a prompt, because Safari brings up one when navigating to a protocol that launches an external app.
Thorrez 7y ago
The threat model seems to have 2 requirements: 1. Only if the top level url bar says zoom.us is it allowed to cause any noticeable change to the zoom native app. This means some arbitrary website cannot cause any noticeable change to the zoom native app without redirecting you to zoom.us . This also means that a sandboxed iframe, such as an embedded web ad, has no possible way to cause a noticeable change to the zoom native app, because it is not able to do top level navigation to zoom.us . 2. When the zoom native app is triggered, the user must click yes on a confirmation button before joining the meeting. I don't see people advocating that you need to be logged in to zoom.us . Achieving requirement 1 without requirement 2 is still bad, because some website could redirect to zoom.us and force you into a meeting. Achieving requirement 2 without requirement 1 is not too bad, but is annoying, because some sandboxed ad in a website could cause the zoom native app to pop up, annoying you, and could maybe almost be a DOS.
deleted 7y ago
[deleted]

cpitman 7y ago

Is this true if the request is a POST? Shouldn't a POST lead to a preflight request, and then the browser refusing to send the real request?

greenshackle2 7y ago
POST requests are not necessarily preflighted. If they used non-standard headers or content-type it would be. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simpl...
shiado 7y ago
The designers of CORS kept the previous security for certain types of POST requests because they are basically equivalent to how forms work, which operate at a much worse security standard and are a source of a great number of CSRF problems. The simplest way to remember it is that most things which break the legacy behavior of POST triggers the preflight. Speaking of form problems last I checked HN has a login CSRF.
paulddraper 7y ago
It will trigger preflight if POST and not a form content type. (E.g. a POST application/json)

deleted 7y ago

[deleted]

avodonosov 7y ago

> "Access-Control-Allow-Origin" doesn't block the request from going through, it just prevents wrong-origin Javascript from accessing the response. If the server only reacts to POST, then Access-Control-Allow-Origin may be enough, because the browser will fist do a preflight OPTIONS, and if Access-Control-Allow-Origin is not set, the POST will not be made by the browser.

edaemon 7y ago
There are some exceptional cases where a POST is allowed without a preflight check: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simpl...
- avodonosov 7y ago
  You are right, and reading this the cases are not really exceptional but rather usual; so yes, it's better to not rely on CORS for protection in this case.
  - oefrha 7y ago
    Not really, you can just check that Content-Type is application/json and refuse to do anything if it’s not. That effectively shuts down application/x-www-url-encoded or multipart/form-data CSRFs. In fact, parsing POST payload as JSON without checking Content-Type first is frowned upon, and some frameworks refuse to do that by default.
    - zaroth 7y ago
      (Throws up hands) But this is ridiculous! The security of the API can’t rely on strict validation of the content-type, how is that code supposed to make any sense to the 3rd generation of developers who are tasked to maintain it 5 years from now? CORS is clearly not designed as a means of access control to ensure the POST request will never be made. Therefore, it is fairly catastrophic that an article prognosticating about how nobody bloody well understands CORS has also gotten it terribly wrong. What this tells me is that there is probably big money in bug bounties for finding sites which use CORS for access control, and almost certainly are not checking the content-type.

chrisfosterelli 7y ago

The advice isn't wrong, but you did misunderstand it. The CORS header will definitively block the request to an AJAX REST API from going through, because it will be a POST request with an `application/json` Content-Type, which will trigger a preflight request. You're assuming the API will remain identical, just with new headers. I didn't advise this, what they have now is not a semantically RESTful API. What they have now is a mess made to fit within their image-hack's constraints, there's no sensible reason to keep the same GET pattern without that.

comex 7y ago
You shouldn’t assume that a post titled “Developers don’t understand CORS” will only be read by people that understand all the intricacies of CORS. :) For everyone else, the need for a POST request [edit2: as well as a non-form Content-Type] may not be immediately apparent. (Edit: It’s true that a proper RESTful API shouldn’t be using GET for operations with side effects anyway, but that’s different from knowing that avoiding it is mandatory for security.)
- chrisfosterelli 7y ago
  Haha true! It's tricky to find a balance between a short post that nails home a point and a complete guide that hits all the nuances. I definitely intended the former here but I think this is good evidence there is room for the later.
  - spydum 7y ago
    i think the tragedy of web security is that, it's become too complicated to provide simple guidance to developers who are feature-focused. They don't want to become experts in security-header-machinery and crazy amount of domain knowledge needed, but there aren't many other options. Just look at all the security options a dev has to contend with: HSTS CORS (with it's myriad of headers.. ACAO, ACAH, ACAC, etc.) CSRF XSS CSP SRI .. That doesn't even count the other fun stuff like SQLi, XXE, LFI, RFI, SSRF, and on and on. It's become real obvious to me, that if the framework or language they develop with doesn't provide it enabled by default AND the most commonly searchable/referenced docs don't explictly tell you to disable it - it's likely not going to happen.

tootie 7y ago

Is all of that worthless if the calls to localhost aren't encrypted?

Thorrez 7y ago
All of what worthless? The advice that cakoose gives seems quite valid to me without any encryption to localhost. What do you mean encrypt calls to localhost? Encrypt with https? That sounds hard since you can't get a real CA to issue you such a cert. I don't see much point in encrypting with https because people off your machine can't sniff or intercept your connection to localhost. Is your goal to protect yourself from other programs or users on your same machine? That might be a valid concern on a machine with multiple users, but definitely makes the problem harder. Or do you want some custom application-level encryption? I can't think of a good way to implement that either, but maybe it's possible. But since I don't know what attacks you're trying to protect against, I can't tell whether there's any benefit at all to encryption.

eranation 7y ago

Worth mentioning that according to OWASP's latest recommendation #1 is considered as a first line of defense and #2 is considered more as a defense in depth technique (e.g. in addition to #1, not as a replacement): https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...) The SameSite=Strict is also an honorable mention as an up and coming technique once all browsers support it.

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]