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

211–220 of 366 posts

Re: Developers don't understand CORS

#211

Post by yyyk »

abstractbarista wrote: post #148
superasn wrote: post #141

Earlier quoted context omitted.

You're welcome. Yes you still can make GET requests from evil.com to bank.com/transfer.php by setting the image src or script src or form submission though you won't be able to read the response. This is probably the reason that any url that makes changes to user data like logout.php , transfer.php , etc must be a POST request (with csrf token to protect again requests created via form submissons) Also it's still pos…

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…

"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"?"

There is, it's relatively new though:

https://blog.mozilla.org/security/2018/04/24/same-site-cooki...

Re: Developers don't understand CORS

#212

Post by justinclift »

whatshisface wrote: post #116
iforgotpassword wrote: post #103

Earlier quoted context omitted.

Studies funded by companies selling Teflon products say 300 degrees. Others conclude it happens at temperatures as low as 200 which you can easily reach while cooking. Anyways I'm almost always using plain old steel pans and pots. There are very few things that stick so badly I resort to the one Teflon pan I have.

Watch out: some types of stainless steel can leech enough nickel to approach the safety line.

Which safety line? :)

Re: Developers don't understand CORS

#213

Post by ChrisCinelli »

kortilla wrote: post #208
ChrisCinelli wrote: post #198

Earlier quoted context omitted.

> "Access-Control-Allow-Origin" doesn't block the request from going through, it just prevents wrong-origin Javascript from accessing the response." On a GET request (like the one generated by a IMG tag) and all the other cases that do not require a pre-flight request ( https://www.w3.org/TR/cors/#preflight-request ) this is correct. Are we clear on the thread model and what Zoom is trying to do? As far as I know, Zo…

I’m not sure you understand the threat model either. Even if the meeting ID is a GUID, you’re still leaving an avenue for people to have their visitors join arbitrary meetings.

Well, I guess I need to explicitly say that having the Zoom client asking something like:

"www.visited-site.com" wants to start a meeting with you. Do you want to join?

is (uncommon?) common sense that the Zoom app should follow.

Re: Developers don't understand CORS

#214

Post by gmfawcett »

jefftk wrote: post #82
davidw wrote: post #32

Earlier quoted context omitted.

Back in the day, we used to use some Apache redirect magic to redirect to, say, an image of our choosing when the Referrer header was wrong. I had a relatively polite 'hey, you can see this image here:' message. Other people redirected to less friendly things.

You can still do this. The Referer header is sent by default on requests, and you can make your server interpret it to do anything you want.

This is true unless the referring URL is secured (HTTPS), and the destination URL is not. In that case a conformant user-agent will leave Referer out.

https://tools.ietf.org/html/rfc7231#section-5.5.2

Re: Developers don't understand CORS

#215

Post by klodolph »

hn23 wrote: post #88
klodolph wrote: post #67

Earlier quoted context omitted.

But Teflon is non-toxic and biocompatible. You can eat it, your body is unable to process it or break it down and it will pass through your digestive system. You can coat surgical instruments and medical implants with Teflon. (Above 300°C Teflon will generate toxic fumes, but then again, so will wood.)

I have read $somewhere that it accumulates in testicles. And why would I coat surgical instruments? Edit: Just one article how healthy Teflon is: https://fortune.com/longform/teflon-pollution-north-carolina...

That is an article about byproducts of Teflon manufacture.

Re: Developers don't understand CORS

#216

Post by chrisfosterelli »

cakoose wrote: post #187

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 localhos…

The advice isn't wrong, but you did misunderstand it. The CORS header will definitively block the request to an AJAX REST API from going through, because it will be a POST request with an `application/json` Content-Type, which will trigger a preflight request.

You're assuming the API will remain identical, just with new headers. I didn't advise this, what they have now is not a semantically RESTful API.

What they have now is a mess made to fit within their image-hack's constraints, there's no sensible reason to keep the same GET pattern without that.

Re: Developers don't understand CORS

#217

Post by WhitneyLand »

Bypassing it all (be careful) with no-cors?

Relatively recent Chrome debug messages about a no-cors "opaque" option, suggest the client has the ability to bypass the server rules without using any kind of proxy.

Is this true? Maybe I didn't notice it got added as an option when fetch was added in addition to the old style XHR requests?

Re: Developers don't understand CORS

#218

Post by avodonosov »

edaemon wrote: post #207
avodonosov wrote: post #201

Earlier quoted context omitted.

> "Access-Control-Allow-Origin" doesn't block the request from going through, it just prevents wrong-origin Javascript from accessing the response. If the server only reacts to POST, then Access-Control-Allow-Origin may be enough, because the browser will fist do a preflight OPTIONS, and if Access-Control-Allow-Origin is not set, the POST will not be made by the browser.

There are some exceptional cases where a POST is allowed without a preflight check: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simpl...

You are right, and reading this the cases are not really exceptional but rather usual; so yes, it's better to not rely on CORS for protection in this case.

Re: Developers don't understand CORS

#219

Post by chpmrc »

jrochkind1 wrote: post #155
why-el wrote: post #124

Earlier quoted context omitted.

That's certainly true, you are making the leap of faith that your customers are running standard compliant browsers, which, all considered, is true. All the techniques you mention require you to break either the customers or some element along the network chain to the server, and once you do, well, CORS is the least of your problems.

Yes. CORS is not so much a protection of your site against malicious user-agents; It is a protection of your site's users , using good non-malicious browsers, against malicious other JS on the web. I think this is one of the most basic misunderstood things about CORS. Once you understand that, you can start actually trying to understand the threat model... which is still pretty confusing, to me anyway. But until you…

If a native app can request any resource why shouldn't a web app be able to do that too? Does it matter whether that app runs in my browser, Electron (which can easily bypass CORS policies) or whatever other runtime? If it does then CORS restrictions should be put in place at the OS level, if it doesn't they should be removed altogether. There are a ton of other ways to make sure you don't "give your stuff" to unauthorized parties: authentication, CRSF tokens, hash validation.

Seriously, if it gets to the point of having to write "{Class of professionals} don't understand {Obscure restriction that doesn't make much sense nowadays}" it's likely not a security issue anymore, it's a UX issue (with the developers being the users). At the very least prompt the user to (dis)allow CORS when a request is being made, similarly to how the user is warned when running an unsigned executable on macOS.

Re: Developers don't understand CORS

#220

Post by comex »

chrisfosterelli wrote: post #216
cakoose wrote: post #187

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 localhos…

The advice isn't wrong, but you did misunderstand it. The CORS header will definitively block the request to an AJAX REST API from going through, because it will be a POST request with an `application/json` Content-Type, which will trigger a preflight request. You're assuming the API will remain identical, just with new headers. I didn't advise this, what they have now is not a semantically RESTful API. What they hav…

You shouldn’t assume that a post titled “Developers don’t understand CORS” will only be read by people that understand all the intricacies of CORS. :) For everyone else, the need for a POST request [edit2: as well as a non-form Content-Type] may not be immediately apparent.

(Edit: It’s true that a proper RESTful API shouldn’t be using GET for operations with side effects anyway, but that’s different from knowing that avoiding it is mandatory for security.)

Post reply on HN