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

Demystifying CORS

frontendian.co

Post reply on HN
Print view View original

41–50 of 50 posts

Re: Demystifying CORS

#41

Post by bzbarsky »

matharmin wrote: post #30
bzbarsky wrote: post #20

Earlier quoted context omitted.

That's really odd. There are shared tests for all this stuff, and browsers should really be doing it identically. Did you happen to report bugs on this to browsers? If not, do you happen to have a link to a page that shows the behavior difference?

Nope, never got around to debug in depth. Will do that when I have some time again.

Thank you! Even just a page that shows the behavior differences, without much debugging, would be really helpful; this sort of thing is something browsers very much aim to have working identically.

Re: Demystifying CORS

#42

Post by stealthmodeclan »

If you set CORS, you'll see option request on every request. You can set a cache expiration header on option request to prevent it on each request and potential denial of service or slow frontend. It's shocking how few developers know this.

Re: Demystifying CORS

#43

Post by lostcolony »

ThePhysicist wrote: post #36
lostcolony wrote: post #31

Earlier quoted context omitted.

There isn't, though. It really is just the same origin policy at work (or, if you mean more abstractly, the website flagging them differently; you can still construct it into a curl call that will be indistinguishable, barring something like a varying CSRF token that requires the page to be loaded, but again, that can still be faked by loading the page, grabbing the token, and using it in the resulting cURL call). Bu…

That's not entirely correct, as you can still create a form on page Y and have it submit a POST request to site X even if CORS is enabled, as CORS does only govern asynchronously triggered requests. So you still need CSRF to fully protect against malicious form submissions from third-party domains.

Well, yes. POSTs of the right MIME type also work, not just GETs, due to, again, the way the web worked prior to AJAX and APIs and all that lovely goodness requiring some rethinking the web's security model (back when we had 'submit' forms and that was it).

So, technically accurate WRT where the same origin policy applies, but not really relevant to the parent's base statement that you can differentiate between what is and is not user triggered (since you can send a payload in code with the same MIME type and etc so that it looks identical to what a form would send).

Re: Demystifying CORS

#44

Post by zackmorris »

My biggest frustration with CORS is that none of it is technically needed.

We could have skipped the whole thing if subresource integrity (SRI) had been implemented much earlier, possibly in HTTP 1.0, which makes its absence one of the great blunders of the web:

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

On top of that, SRI would have allowed us to use standardized versions of libraries like jQuery and Angular from their home URLs, which would have reduced the initial load size of single page applications by megabytes via caching (because those libraries would have already been loaded long ago from other sites).

Which naturally would have led to content-addressable data, Merkle trees, etc which would have given us performance more in line with BitTorrent (at least for commonly used files/scripts).

On top of that, I'm not completely convinced that CORS avoids IP address spoofing, DNS poisoning etc. It probably needs to piggyback on HTTPS to be sure, which is a common way to avoid that can of worms so I can't criticize it too badly for that.

I should add that SRI has one critical flaw in that it's still vulnerable to user-posted content (like comments) trying to embed a tag containing a fake hash in the body. I haven't been deep enough in SRI to know if it's possible to specify hashes off page, maybe someone knows? Otherwise we may still need something like CORS, or better yet, something that blocks further includes altogether rather than conflating the issue with focusing on where they came from.

Re: Demystifying CORS

#45

Post by sonnyblarney »

zeusly wrote: post #12
sonnyblarney wrote: post #10

What I find perplexing is that for this and every other web technology, there doesn't seem to be a central comprehensive resource that explains it all in great detail. It's like we have to pick things up as we go along, from tidbits and articles here and there, not of it complete or comprehensive, and often there'll be little mistakes or misleading bits.

I think MDN is doing a great job of becoming the go-to resource for everything: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

It's the best surely, and that article is decent, but there are so many areas wherein information is lacking or incomplete. One-line examples for entire modules or lack of explanation for specific parameters etc..

It's amazing that Google and Apple rely so much on browser use but they can't publish comprehensive information on them.

Re: Demystifying CORS

#46

Post by fjsolwmv »

ThePhysicist wrote: post #32
jjnoakes wrote: post #28

Earlier quoted context omitted.

If you need CSRF tokens for forms, etc, then what does CORS give you above CSRF tokens?

CSRF tokens are usually only used for state-altering requests (POST, GET etc.), though one could use them for GET requests as well. The reason people don't do use CSRF for GET is that there's usually no risk involved when calling a GET endpoint from your browser, as it's not supposed to change the state of a resource in any way. And since an HTML form submission or included link will take the user directly to your AP…

You meant "POST, PUT, etc"

Re: Demystifying CORS

#47

Post by pejrich »

ThePhysicist wrote: post #32
jjnoakes wrote: post #28

Earlier quoted context omitted.

If you need CSRF tokens for forms, etc, then what does CORS give you above CSRF tokens?

CSRF tokens are usually only used for state-altering requests (POST, GET etc.), though one could use them for GET requests as well. The reason people don't do use CSRF for GET is that there's usually no risk involved when calling a GET endpoint from your browser, as it's not supposed to change the state of a resource in any way. And since an HTML form submission or included link will take the user directly to your AP…

But what if one website wanted user data from another website. Couldn't b.com make a GET request to a.com(assuming the user is on b.com now, and was on a.com previously, with a cookie), using the cookie for a.com in the browser and get the user's info from a.com, then send that to b.com? All without the user or a.com knowing?

Re: Demystifying CORS

#49

Post by teh_klev »

valgaze wrote: post #9

Alex Hopperman talks about XMLHttpRequest starting as an initiative to port exchange/outlook email to a browser: http://www.alexhopmann.com/xmlhttp.htm XMLHTTP actually began its life out of the Exchange 2000 team. I had joined Microsoft in November 1996 and moved to Redmond in the spring of 1997 working initially on some Internet Standards stuff as related to the future of Outlook […] I don’t recall exactly when we…

Looks like his site is a bit clobbered, there's an archive.is copy here:

http://archive.is/7i5l

You'll likely need to do an "inspect element" over the annoying AdChoices bar on the left and delete its containing div.

Back in 2000-2002 I was lucky to work with a team that leveraged XMLHttpRequest (it was an internal corporate thing for a customer so we could get away with only supporting IE) to build single page apps before much of this stuff had a name.

Re: Demystifying CORS

#50

Post by ThePhysicist »

fjsolwmv wrote: post #46
ThePhysicist wrote: post #32

Earlier quoted context omitted.

CSRF tokens are usually only used for state-altering requests (POST, GET etc.), though one could use them for GET requests as well. The reason people don't do use CSRF for GET is that there's usually no risk involved when calling a GET endpoint from your browser, as it's not supposed to change the state of a resource in any way. And since an HTML form submission or included link will take the user directly to your AP…

You meant "POST, PUT, etc"

Yes, GET doesn't make any sense there.
Post reply on HN