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

Do You Really Know CORS?

performantcode.com

Post reply on HN
Print view View original

31–40 of 127 posts

Re: Do You Really Know CORS?

#31

Post by ubernostrum »

rnotaro wrote: post #19
paulddraper wrote: post #15

Earlier quoted context omitted.

The alternative is for the idea agent to send the Origin header on all requests. Then the server responds with 200 or 403.

The origin could still be falsified client-side.

This is kind of like the reports I see every so often to Django's security address, where someone demonstrates that they can CSRF their own session.

The reply is always "yes, you can CSRF yourself, because it's not supposed to protect against that; it's supposed to protect you from other people". In exactly the same way, CORS is there to protect you from other people. You can always hack your own user-agent to disregard CORS, but the only person you can harm that way is yourself.

Re: Do You Really Know CORS?

#32

Post by stockkid »

very nice article. I thought I understood CORS but learned some new things:

* not all cross origin requests need to be preflighted * to use credentials, server needs to explicitly allow credentials to be sent from client

Re: Do You Really Know CORS?

#33

Post by JepZ »

I never really understood why we have CORS. I mean, the problem with CSRF is that some random page can trick your browser into adding its authentication token to a request which does not originate from the authenticated page. So why the do we need the server to tell the browser that it should not send requests from other origins?

In my opinion, it would have been much better to improve the browsers to not include cookies in 3rd party requests automatically (only when they are explicitly specified via JS for example). It should have solved the issue equally well, without introducing some bulky server-side security feature to remote control browsers.

Re: Do You Really Know CORS?

#35

Post by zackmorris »

JepZ wrote: post #33

I never really understood why we have CORS. I mean, the problem with CSRF is that some random page can trick your browser into adding its authentication token to a request which does not originate from the authenticated page. So why the do we need the server to tell the browser that it should not send requests from other origins? In my opinion, it would have been much better to improve the browsers to not include coo…

Ya I generally think CORS is a waste of time. It would have been better to provide a hash of the file we're linking to and trust that rather than where it came from. Which is precisely what Subresource Integrity (SRI) does:

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

Sadly even though this is an obvious concept and trivial to implement, it took them over 20 years since the web came out to get it in most browsers. The cost to society of having thousands of copies of the same commonly used files (like jQuery) hosted locally on countless servers rather than having a centrally hosted version already cached from previously visited sites is staggering to contemplate. I'd really like to know who was behind the holdup on deploying SRI.

Re: Do You Really Know CORS?

#36

Post by crooked-v »

edoceo wrote: post #30
crooked-v wrote: post #27

Earlier quoted context omitted.

That kind of crapware is why I'm increasingly glad that the http specs are moving towards being completely illegible to middleware boxes.

How would http be any harder for middleware than app-layer? If both linked to libhttp.c, couldn't they each get the full parsing/reading/writing - wether proxy or server?

Being able to parse HTTP doesn't get anywhere when you can't actually get at the contents because they're encrypted (as with all major HTTP2 implementations).

Re: Do You Really Know CORS?

#37

Post by guscost »

CORS is a technical subsidy granted to (sloppy) users of cookie authentication. I’ve never worked on a project where it was anything other than an annoying hoop to jump through.

Re: Do You Really Know CORS?

#39

Post by iancarroll »

zackmorris wrote: post #35
JepZ wrote: post #33

I never really understood why we have CORS. I mean, the problem with CSRF is that some random page can trick your browser into adding its authentication token to a request which does not originate from the authenticated page. So why the do we need the server to tell the browser that it should not send requests from other origins? In my opinion, it would have been much better to improve the browsers to not include coo…

Ya I generally think CORS is a waste of time. It would have been better to provide a hash of the file we're linking to and trust that rather than where it came from. Which is precisely what Subresource Integrity (SRI) does: https://en.wikipedia.org/wiki/Subresource_Integrity Sadly even though this is an obvious concept and trivial to implement, it took them over 20 years since the web came out to get it in most brows…

CORS is about a lot more than just static assets. SRI does not replace CORS.

Re: Do You Really Know CORS?

#40

Post by jtokoph »

JepZ wrote: post #33

I never really understood why we have CORS. I mean, the problem with CSRF is that some random page can trick your browser into adding its authentication token to a request which does not originate from the authenticated page. So why the do we need the server to tell the browser that it should not send requests from other origins? In my opinion, it would have been much better to improve the browsers to not include coo…

CORS is really for the opposite problem. Browsers do block requests from other origins by default (mostly). CORS is used to let the server decide which origins are allowed to request data and how it can be requested. If the client was allowed to decide via javascript, then attacker.com could make a request via javascript to facebook.com telling the browser to send cookies and return the user's data. This is actually what the client JS has to do anyway with CORS (using credentials: true), but the server side needs to be able to allow/deny it.
Post reply on HN