Developers don't understand CORS • Hacker News Board

Re: Developers don't understand CORS

#161

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

anderspitman wrote: post #134

jonstaab wrote: post #2

Totally agree. Something about CORS and the resources out there makes newcomers think that it's something the client has to do differently. I thought this when first doing cross-origin stuff, and thought it was just me until my dad (programmer for 30 years) got stuck on it the exact same way. Also, the author makes a good point that `Access-Control-Allow-Origin: *` is pretty dangerous. I hadn't really worried about i…

> Something about CORS and the resources out there makes newcomers think that it's something the client has to do differently I think that "something" is the fact that the client does the blocking. Generally the servers are perfectly willing to provide the data. Heck, if you sniff the packets, you could even look at the data blocked by CORS (assuming you're working around TLS). It's especially confusing at first that…

Yes, that's definitely a big part of it. Test it all with curl or your language's http client, then put it in the browser and it breaks? Must be the client's fault! Which it sorta is. But only because it's a client that doesn't belong to you — you're controlling it on the user's behalf. It doesn't help that when you're developing on your own machine, you're user and the developer, and you of course trust yourself.

Re: Developers don't understand CORS

#162

Post by jonstaab » Wed, Jul 10, 2019, 9:11 PM UTC

theturtletalks wrote: post #130

jonstaab wrote: post #66

Earlier quoted context omitted.

CORS is really pretty simple, it's getting the threat model that is tricky. Some docs on Allow-Origin here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac... and a more complete walkthrough here: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS Dynamic allow-origin sounds magical, but is really straightforward. You just look at the `Origin` header of a request (e.g., in express `req.headers['Origi…

Yes so the users will be users of ours. The users won't have their own users per se, but will be able to customize the app. So if I understand correctly, I can turn off CORS, have each user that wants their own backend URL to enter this URL in our system, we whitelist this URL and check for it when a request is made?

Yes, though you wouldn't turn it off, you would put their domain in the header the response sends back to the client.

Re: Developers don't understand CORS

#163

Post by zenexer » Wed, Jul 10, 2019, 9:12 PM UTC

chrisfosterelli wrote: post #41

zenexer wrote: post #31

The author suggests that using CORS to allow https://zoom.us with http://localhost:19421 is possible. This is factually incorrect. Mixed content policies prevent the http: origin from communicating with the https: origin. "For very intentional reasons, the browser explicitly ignores any CORS policy for servers running on localhost." That last sentence is incorrect – Chrome does respect CORS headers for localhost webs…

This is discussed in the post text, but happy to elaborate here in more detail here! Here is the patch links from Firefox[0] and from Chrome[1] which they specify that active mixed content policies do not apply to the localhost, because the w3c specification was updated to specifically allow this behaviour[2]. You might have to use 127.0.0.1 directly. So yes, it is possible and not factually incorrect. If for some re…

I'm fairly certain that these patches didn't land until recently, at which point the design decisions were probably already made at Zoom. (I don't know much about Zoom, but that seems like a reasonable assumption.) Additionally, these changes aren't likely to apply to Firefox ESR or IE for a while.

In Zoom's case, I highly doubt CORS on its own was a viable solution. Maybe in 2026, a decade after the patch, sure, but in the current climate, it's not reasonable to expect that all users will be using browsers that have adopted these changes in 2019.

Re: Developers don't understand CORS

#164

Post by jrochkind1 » Wed, Jul 10, 2019, 9:12 PM UTC

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?

Re: Developers don't understand CORS

#165

Post by DGAP » Wed, Jul 10, 2019, 9:12 PM UTC

This article is a great illustration to me as well of how hard it is to do security right even if you're a professional, much less a developer who's mostly responsible for implementing features not building secure systems. The internet is rife with self-proclaimed experts, all offering directly contradictory advice as loudly as possible on best practices for security.

Re: Developers don't understand CORS

#166

Post by giaour » Wed, Jul 10, 2019, 9:13 PM UTC

superasn wrote: post #146

tgsovlerkhgsel wrote: post #132

Earlier quoted context omitted.

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…

It certainly won't allow me to make xhr POST requests without sending an OPTIONS request first. Are you sure about that?

Yes, you can send some POST requests without a preflight OPTIONS request: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simpl...

Re: Developers don't understand CORS

#167

Post by jonstaab » Wed, Jul 10, 2019, 9:13 PM UTC

politician wrote: post #126

jonstaab wrote: post #123

Earlier quoted context omitted.

The single-value constraint seems like a feature rather than a bug; if you included your full list of whitelisted domains every time, not only would your HTTP header size be unnecessarily heavy, but you'd be leaking private details about who else is using your service. This isn't an inherent problem, but it could give an attacker some ideas of who to target.

Maybe, but the CORS spec says otherwise. https://www.w3.org/TR/cors/#access-control-allow-origin-resp... See the note.

Interesting that the spec disagrees with the implementation. Maybe the multi-origin leakage was filed as a bug somewhere and fixed post-spec?

Re: Developers don't understand CORS

#168

Post by quickthrower2 » Wed, Jul 10, 2019, 9:14 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…

Another option is to use a secure token (https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...) this is a PITA but frameworks like ASP.NET have this baked in so it's not really much of a hassle in practice.

Re: Developers don't understand CORS

#169

Post by giaour » Wed, Jul 10, 2019, 9:14 PM UTC

_eht wrote: post #135

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…

This context was incredibly useful; thank you. Am I missing something or is this transaction actually a browser being the deciding factor for whether or not the request gets sent? If that’s true, couldn’t a nefarious browser decide when to push a request and completely ignore the OPTIONS header?

Safari used to let you turn off CORS checks in the developer tools menu.

Re: Developers don't understand CORS

#170

Post by tgsovlerkhgsel » Wed, Jul 10, 2019, 9:15 PM UTC

aaronharnly wrote: post #147

tgsovlerkhgsel wrote: post #132

Earlier quoted context omitted.

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…

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.example.com', {method: 'POST', body: 'blah'})

You will see two things. In the console:

    Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://otherorigin.example.com/. (Reason: CORS request did not succeed).

In the network tab, a HTTP request.

Replace with a URL of a server you control, or run `nc -lnvp 9999` and replace the URL with http://127.0.0.1:9999, to see that the request is indeed being made.

As the author said... few people understand CORS.