Developers don't understand CORS • Hacker News Board

Re: Developers don't understand CORS

#201

Post by avodonosov » Wed, Jul 10, 2019, 9:52 PM UTC

cakoose wrote: post #187

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" . This will ensure that only Javascript running on the zoom.us domain can talk to the localhos…

> "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.

Re: Developers don't understand CORS

#202

Post by pixelperfect » Wed, Jul 10, 2019, 9:53 PM UTC

tgsovlerkhgsel wrote: post #170

aaronharnly wrote: post #147

Earlier quoted context omitted.

I know you know this, but to clarify steps 2/3: - Evil tries to make an HTTP request to bank.com/transfer.php If this is a regular HTTP POST (ie submitting a form, and the browser window changes location), the browser will allow it. If this is an xhr POST, the browser, following the same-origin policy, allows the request, but prevents accessing the response (unless allowed with CORS). [EDITED with tgsovlerkhgsel's he…

Even a JavaScript initiated POST request will go through. Blocking it would not make a lot of sense, because the attacker could just use the FORM (possibly in an iframe to keep it invisible to the victim). It is possible that XHR, or common XHR libraries, default to adding some header that makes it a non-standard request, but a fetch() call works. In Firefox, open a debug console and run fetch('https://otherorigin.ex…

But for XHR only POST requests that meet a lot of constraints (defined here https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simpl...) will work, right?

Nothing with a Cookie header for example...

Re: Developers don't understand CORS

#203

Post by greenshackle2 » Wed, Jul 10, 2019, 9:54 PM UTC

cpitman wrote: post #199

cakoose wrote: post #187

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" . This will ensure that only Javascript running on the zoom.us domain can talk to the localhos…

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?

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#Simpl...

Re: Developers don't understand CORS

#204

Post by arve0 » Wed, Jul 10, 2019, 9:55 PM UTC

jrochkind1 wrote: post #164

arve0 wrote: post #8

Zoom does not need CORS-headers to fix the vulnerability, rather make the web server running on localhost drop requests with wrong origin header.

Hmmm.... never thought about this but now thinking about it... does anyone need CORS? Can server-enforced access controls on "Origin" substitute for CORS in all cases?

If you need access to the users data on another service, without having their credentials on the other service, CORS is the correct choice.

> Servers can also notify clients whether "credentials" (including Cookies and HTTP Authentication data) should be sent with requests.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Re: Developers don't understand CORS

#205

Post by justinclift » Wed, Jul 10, 2019, 9:55 PM UTC

WhitneyLand wrote: post #197

csours wrote: post #12

I certainly don't understand CORS. I've read about it several times and I don't remember what I read. It's like CORS has a teflon coating that prevents it from sticking in my mind. I know what CORS is for and why you need it, but I have no idea how, where, and when to use it.

This Teflon you're talking about, it's a thing. Not just with CORS, not just with you. For example, I've gotten decent at regular expressions a few times but have to keep relearning it. Adding insult to injury, I might relearn something from Stackoverflow, and realize afterwards I posted the answer! Not for trivial stuff. But a string of punctuation with capture groups or whatever, forget about it [1]. Any support fo…

Javascript is like this with me. I have no idea why.

Probably my having a super low opinion of it's whole ecosystem doesn't help. ;)

Re: Developers don't understand CORS

#206

Post by edejong » Wed, Jul 10, 2019, 9:58 PM UTC

therein wrote: post #40

edejong wrote: post #28

Earlier quoted context omitted.

I read extensive parts of the CORS specification and it is indeed teflon (and just as toxic as teflon as well). The spec is full of exceptions and leaves many choices to the browser vendors. To truly understand CORS, you have to fundamentally understand 'the origin' as a security and execution context. Sharing means that content normally intended for another origin is shared with the initial origin. Perhaps that is b…

> In that case, I propose to read more of the spec. Ingest more teflon when in doubt about its toxicity.

With regards to the toxicity, I was referring to the Intercept [1] article which appeared last year. It's a long read and details the manufacturing process. Nevertheless, where there is smoke...

[1] https://theintercept.com/2018/07/31/3m-pfas-minnesota-pfoa-p...

Re: Developers don't understand CORS

#207

Post by edaemon » Wed, Jul 10, 2019, 10:01 PM UTC

avodonosov wrote: post #201

cakoose wrote: post #187

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" . This will ensure that only Javascript running on the zoom.us domain can talk to the localhos…

> "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.

There are some exceptional cases where a POST is allowed without a preflight check: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simpl...

Re: Developers don't understand CORS

#208

Post by kortilla » Wed, Jul 10, 2019, 10:01 PM UTC

ChrisCinelli wrote: post #198

cakoose wrote: post #187

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" . This will ensure that only Javascript running on the zoom.us domain can talk to the localhos…

> "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 ) this is correct. Are we clear on the thread model and what Zoom is trying to do? As far as I know, Zo…

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.

Re: Developers don't understand CORS

#209

Post by arendtio » Wed, Jul 10, 2019, 10:01 PM UTC

EGreg wrote: post #184

arendtio wrote: post #176

Earlier quoted context omitted.

Recently, I have come across the so-called signaling server which seems to be another part being used with Nextcloud Talk. For Nextclouds the default signaling server can handle just about 4 participants. So there seems to be a bit more to it than just WebRTC and TURN.

What exactly makes this limit?

I have no idea (maybe PHP). I just saw that they a short info text in the backend and display a warning when you are having a conversation with more than 4 participants. Couldn't find any documentation on what the underlying problem is.

> An external signaling server should optionally be used for larger installations. Leave empty to use the internal signaling server.

> Please note that calls with more than 4 participants without external signaling server, participants can experience connectivity issues and cause high load on participating devices.

Re: Developers don't understand CORS

#210

Post by strictfp » Wed, Jul 10, 2019, 10:02 PM UTC

tgsovlerkhgsel wrote: post #132

superasn wrote: post #118

Earlier quoted context omitted.

I have some basic understanding of it. I'll try to simplify what I know if anyone else is feeling confused about CORS. - You visit evil.com. - Evil tries to makes an HTTP request to bank.com/transfer.php - But before the request goes through the Browser says, hey, wait a minute I first need to make sure if evil.com can access bank.com - Browser asks bank.com, if evil.com (also known as origin) is allowed by sending a…

No. - You visit evil.com - Evil tries to make an HTTP request to bank.com/transfer.php - The browser happily performs the request, authenticated with your cookies, and the bank, having a CSRF vulnerability, happily sends your money to the attacker. - Since 'evil.com' and 'bank.com' are different origins, Browser refuses to provide the response to evil.com, but the attacker doesn't care, he got the money. CORS allows…

Wait. If the resource at bank.com is protected by a CORS filter, the request which is issued at step three will have an origin header, and the CORS implementation is free to issue a 401 at that point. At least as far as I have understood. That would be tightening the restrictions. Am I missing something?