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

181–190 of 366 posts

Re: Developers don't understand CORS

#181

Post by greenshackle2 »

superasn wrote: post #159
abstractbarista wrote: post #148

Earlier quoted context omitted.

Wow that makes more sense too. Basically, don't implement GET in any remotely-sensitive API that actually causes changes in the remote system/service? EDIT: Why isn't there a header that web servers can give out to browsers basically saying "Don't use the cookie/session I'm giving you ever, unless you're literally on this site" ? I could see this being very useful for banks or other origins where they expect no reque…

Yes also see my comment about csrf token too. If the request changes user data it must be a POST request with csrf protection. You can't make POST requests with ajax as CORS will protect you, but evil.com can create a fake form submission (with bank.com/transfer.php as the form's action) which can be a POST request. So in this case you match the csrf token which only you know and which is unique for the form/session.…

It seems you can make a POST request from javascript, as long as it doesn't have non-standard headers or content-type.

Try it yourself: https://news.ycombinator.com/item?id=20406633

Re: Developers don't understand CORS

#183

Post by Waterluvian »

I'm in this semi-special place in web dev where almost everything I make is for a captive audience on local networks. So it feels like there's entire segments of web dev that I've only learned to subvert. CORS is one of them.

All I really learned is that you can't make calls to services on another domain unless that service allows it via CORS.

Eg. Every robot I want to websocket to has to be cool that the web application originally loaded off of (and in a way is owned by) the central server.

Re: Developers don't understand CORS

#184

Post by EGreg »

arendtio wrote: post #176
EGreg wrote: post #101

Earlier quoted context omitted.

It’s up to WebRTC and TURN server. Can be any number in theory. The layouts support 100 people, but each participant would have 100 peer to peer connections. Perhaps one advantage of Zoom is that it rebalances things onto servers it owns eg via websockets? Is there documentation on this?

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?

Re: Developers don't understand CORS

#185

Post by mderazon »

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?

The server responsibility of CORS is also about making sure the browser accepts the cross origin request (in case it's a valid origin). If it won't send the correct headers back, the browser will drop the request

Yes, the server can drop the request or return an error, but that's just half of it. If it wants the browser to accept the request, it has to explicitly say it by using the CORS headers.

Re: Developers don't understand CORS

#186

Post by tgsovlerkhgsel »

mehrdadn wrote: post #25
dillonmckay wrote: post #17

Earlier quoted context omitted.

So, it depends on the request type, GET vs POST and others. Before the client does the request for data, it does a preflight request via OPTIONS to determine what is allowable (is this domain allowed, this type of call). If it is allowed, it can send and request cookies on the requested domain in the current standard. However, this is not supported in older browsers, so the request will just work. In newer browsers,…

I'm aware of OPTIONS but it still seems like the same exact stupid browser security hole (edit: or perhaps I should say HTTP protocol flaw?) being half-patched on the server side. Like, I'm saying that -- independent of the HTTP method -- there should be no communication of privileged information in the first place by default. If a website really wants other arbitrary websites to send e.g. a cookie along, then there…

You can mark a cookie as samesite:

https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...

(as you mentioned, backwards compatibility requires that this is opt-in when the cookie is set, not opt-out)

Re: Developers don't understand CORS

#187

Post by cakoose »

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 localhost webserver.

"Access-Control-Allow-Origin" doesn't block the request from going through, it just prevents wrong-origin Javascript from accessing the response.

The original vulnerability actually just a slight variant of cross-site request forgery (CSRF) -- "wrong site request forgery" :-)

For the localhost server to detect wrong-site requests, there are two simple options:

1. Use a CSRF token. This requires a shared secret between the localhost server and the Zoom website.

2. Check the "Origin" header. This requires that the request be an HTTP POST, which is what they should be.

(Note: If you're determined to use some CORS machinery, you could build something more complicated based on pre-flight requests, but there's no point.)

Re: Developers don't understand CORS

#188

Post by reda-alaoui »

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…

We tested this on Fifefox on April 2019.

It is still blocked.

Re: Developers don't understand CORS

#189

Post by arendtio »

phkahler wrote: post #6

Not a web dev. Can anyone tell me what CORS is ultimately used for? Not the literal technical details, the higher level what does it enable sites to do? And is that for them or their visiters?

CORS can be used to define exceptions to the same-origin-policy.

By default, the same-origin-policy doesn't allow all requests to other origins (domains/websites/ports). But if you want to allow another website to send requests to your site you can use CORS to do so.

So for example, if you have a contact form on one page (example.com) and the API for processing the submitted forms on another domain (processing.com; different origin), the receiving server tells the browsers via CORS that submissions from example.com are allowed.

Re: Developers don't understand CORS

#190

Post by tgsovlerkhgsel »

jchw wrote: post #177
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…

Actually they can do better than just a custom header with an XSRF token, which is fairly standard nowadays for requests that are authenticated via Session Cookies (Django for example strongly enforces this by default.)

Indeed, this is the canonical way of avoiding CSRF (= XSRF) attacks. I intentionally only explained the header method because I didn't want to confuse readers with another concept, and because it's a really nice example to explain CORS.

https://github.com/OWASP/CheatSheetSeries/blob/master/cheats... is probably one of the best documents discussing this, including the drawbacks of the header method that I used (and warned against) in my example:

https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...

Post reply on HN