Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developers don't understand CORS

fosterelli.co

Post reply on HN
Print view View original

341–350 of 366 posts

Re: Developers don't understand CORS

#341

Post by Nasrudith »

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…

Yeah I keep regex syntax pinned up at my desk because it always gets cache-flushed beyond the basics even if I used it yesterday.

Re: Developers don't understand CORS

#342

Post by avisser »

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…

Bad naming strikes again? The message "Request Blocked" means something unambiguous to me. And it doesn't mean "I made the request, but won't let you see the response."

Re: Developers don't understand CORS

#343

Post by martin_a »

At this point I don't want to understand CORS.

Put together a little script package this week, threw in some Vue and a Bootstrap and put it on our fileserver.

Now the Font Awesome icons won't load due to CORS errors.

I don't want to spin up a server for 500 lines of HTML/JS. I don't want to download the fonts, fiddle around in Bootstrap etc.

CORS is broken or the web itself has become broken if we need integrity checks and cross origin protection for using fonts.

Re: Developers don't understand CORS

#344

Post by cooperaustinj »

martin_a wrote: post #343

At this point I don't want to understand CORS. Put together a little script package this week, threw in some Vue and a Bootstrap and put it on our fileserver. Now the Font Awesome icons won't load due to CORS errors. I don't want to spin up a server for 500 lines of HTML/JS. I don't want to download the fonts, fiddle around in Bootstrap etc. CORS is broken or the web itself has become broken if we need integrity chec…

Use a CDN!

Re: Developers don't understand CORS

#345

Post by phdsolutions »

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…

As others have mentioned - thanks for this! I thought I understood CORS, but one thing I apparently wasn't clear on was the conditions on which a pre-flight request was made. Thanks for clarifying!

Re: Developers don't understand CORS

#346

Post by martin_a »

cooperaustinj wrote: post #344
martin_a wrote: post #343

At this point I don't want to understand CORS. Put together a little script package this week, threw in some Vue and a Bootstrap and put it on our fileserver. Now the Font Awesome icons won't load due to CORS errors. I don't want to spin up a server for 500 lines of HTML/JS. I don't want to download the fonts, fiddle around in Bootstrap etc. CORS is broken or the web itself has become broken if we need integrity chec…

Use a CDN!

So my scripts will randomly go down with the rest of the internet? Great idea!

Re: Developers don't understand CORS

#347

Post by anaphor »

mehrdadn wrote: post #322
bzbarsky wrote: post #244

Earlier quoted context omitted.

If cookies were scoped to the (source, target) pair, then that would remove one of the main motivations for CORS, yes: evil.com would not be able to get any information from bank.com by making your browser make the request that they could not get by doing the request server-side. There's a second problem CORS kinda tries to solve, which is the ambient authority problem: services that run behind firewalls and assume t…

Thank you for the reply! I didn't realize this actually gets to another question I've had in another context, which is why can't a browser at least assume 192.168.0.0/16 etc. are private networks and block requests from nominally-public addresses from being sent to those? (Or do they do that already?) This should be possible without needing to detect anything at all, right?

Pretty sure some tools like NoScript already do that, but to protect against DNS rebinding (which can subvert the SOP), not as a protection against cross-origin requests coming from a public site to an internal one.

https://en.wikipedia.org/wiki/DNS_rebinding

> The NoScript extension for Firefox includes ABE, a firewall-like feature inside the browser which in its default configuration prevents attacks on the local network by preventing external webpages from accessing local IP addresses.

Re: Developers don't understand CORS

#348

Post by jillesvangurp »

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…

Depends what you are trying to do. If you are offering an API for third parties to use, Access-Control-Allow-Origin: * is pretty appropriate. It basically communicates "I don't care where you call me from". Same with content on a CDN (fonts, css, etc.). Of course serving executable content like that is a bad idea; but, even so, people seem to trust certain domains with things like jquery.

WIth images, fonts, or other static content the risk is arguably fairly limited except for the fact that browsers tend to have all sorts of nasty bugs with malicious content overflowing buffers thus leading to arbitrary code execution.

But of course the elephant in the room is that doing things with headers adds a lot of friction for developers. Now their simple application has a devops component. E.g. modifying nginx to add that header or trying to make AWS CloudFront forward CORS headers is just a royal pain in the ass. It's also very fragile because these things break easily and are rarely covered by integration tests because these things tend to be specific to infrastructure and environment.

Re: Developers don't understand CORS

#349

Post by blauditore »

tgsovlerkhgsel wrote: post #152
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…

Ways this story could have ended badly for the developers: - instead of hardcoding the allowed value, they set it to always echo the value of the Origin header - browsers are powerless against that much stupidity, and can't distinguish it from a correctly configured server that is allowing the request. evil.com sends the request, bank says "evil.com" is allowed, browser shrugs and sends the request. - instead of usin…

How would one handle the situation of having to respond to (authenticated) requests from a web app running on both localhost and a domain-based website?

I've been in this situation before with web-based cross-platform apps using Cordova. As far as I remember, I ended up echoing the origin domain if it matched a set of allowed domains (basically localhost and example.com), since regular expressions or lists are not supported in allowed-origin headers. For session tracking, I used tokens rather than cookies to avoid CSRF issues. Would there have been any better solution for this? I think not.

Re: Developers don't understand CORS

#350

Post by mehrdadn »

anaphor wrote: post #347
mehrdadn wrote: post #322

Earlier quoted context omitted.

Thank you for the reply! I didn't realize this actually gets to another question I've had in another context, which is why can't a browser at least assume 192.168.0.0/16 etc. are private networks and block requests from nominally-public addresses from being sent to those? (Or do they do that already?) This should be possible without needing to detect anything at all, right?

Pretty sure some tools like NoScript already do that, but to protect against DNS rebinding (which can subvert the SOP), not as a protection against cross-origin requests coming from a public site to an internal one. https://en.wikipedia.org/wiki/DNS_rebinding > The NoScript extension for Firefox includes ABE, a firewall-like feature inside the browser which in its default configuration prevents attacks on the local n…

Yeah but why shouldn't the browser do this itself to provide the cross-origin protection?
Post reply on HN