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

151–160 of 366 posts

Re: Developers don't understand CORS

#151

Post by zek »

takinola wrote: post #128
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…

| Also, the author makes a good point that `Access-Control-Allow-Origin: *` is pretty dangerous. But what is the alternative when you have a script that is going to be deployed on multiple sites that you do not control? Which origin do you specify? This is the scenario which always trips me up and results in kludgy workarounds.

I think the generally accepted solution to this is to set the allowed origin dynamically (IIRC nginx can do this) by looking at the request host header on the options request. If the origin is in some allowed list then you return that origin in `Access-Control-Allow-Origin`

Re: Developers don't understand CORS

#152

Post by tgsovlerkhgsel »

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…

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 using CORS, they could have tried to build their own custom solution that allows ournewbankapp.com. The attacker would have to analyze how it works, and would then most likely find a way to exploit it to perform the attack, while legitimate users with privacy extensions would make the support hotline despair due to countless people complaining "I can't send money".

- instead of adding the custom header, they could have decided to check if "origin" is present, and if so, assume it's a cross-site request and check the origin against a whitelist. This still relies on standard-compliant browsers but isn't the worst idea AS LONG AS YOU REQUIRE AN ORIGIN VALUE, AND TREAT LACK OF AN ORIGIN HEADER AS A FATAL ERROR, BEFORE TAKING ANY ACTION (e.g. the money transfer) BASED ON THE REQUEST. I think can force same-origin requests to include the origin header with some option on fetch(). But if you treat a missing (or "null") header as ok, the attacker will likely find a way to make some browsers send no header, and steal money again. Sending "null" (or some other default value, been a while since I played with it) is easy, I think with some iframe trickery.

- they could have used plain HTTP, exposing them to DNS rebinding attacks even from remote attackers who cannot sniff their user's traffic.

- they could have an XSS vulnerability somewhere on the main site or the whitelisted marketing site, allowing the attacker to proxy his malicious requests through that site (and thus make them use a whitelisted origin). Maybe some long-forgotten kludge designed to proxy requests to third parties that don't support CORS...

Re: Developers don't understand CORS

#153

Post by metafunctor »

aaronharnly wrote: post #147
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…

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…

How hard is it to trigger a regular HTTP POST instead of an xhr POST?

Re: Developers don't understand CORS

#154

Post by greenshackle2 »

dfox wrote: post #131
dillonmckay wrote: post #39

Earlier quoted context omitted.

So, that is not my understanding, but I could definitely be wrong. So, the one domain will attempt to communicate, the other domain will receive the request and return a response. If the client doesn’t ‘like’ the response, it will error.

This only holds for indempotent requests (so in practice GET). Non-indempotent requests are "preflighted" and don't happen at all when the policy does not allow them. So in fact CORS without any server-side configuration allows one to do arbitrary GET requests with cookies and authentication through XHR, but you could always just dynamically create IMG (as in the Zoom kludge) or SCRIPT (and the response will be execu…

Not quite, POST requests with standard headers and one of the following content types are not preflighted:

application/x-www-form-urlencoded

multipart/form-data

text/plain

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simpl...

Re: Developers don't understand CORS

#155

Post by jrochkind1 »

why-el wrote: post #124
chpmrc wrote: post #92

How does not allowing CORS make any sense if any other application running on my system can bypass it except the browser? The technique to bypass it is to have a proxy, either local, or remote. Wouldn't it make more sense to simply allow the browser to make any request the app wants?

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 are there, you haven't even started.

Re: Developers don't understand CORS

#156

Post by mderazon »

zer0faith wrote: post #81

Rarely does a application actually need to enable CORS. If all of your webcalls are from the same domain YOU DONT NEED CORS. (Chatbots/socket.io) You only need CORS if you need the browser to act as a middleman to pass information back. IE: Credit Card Payment IFRAME If you screw up CORS implementation it just means that anyone can read any information set by your website. https://www.moesif.com/blog/technical/cors/A…

Not so rarely. It's pretty common to serve the js frontend code on one domain the apis on a different domain

Re: Developers don't understand CORS

#157

Post by jonstaab »

jrochkind1 wrote: post #149
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…

> But if malicious client code got a hold of a user's session (using XSS or what have you), I'd be open to them steering my user's session I think the point of this stuff is that, if the user's session is stored in a cookie, and malicious javascript can send HTTP requests to your site (that will use whatever cookie is already present) and read the responses -- they can steer your session without needing to get a hold…

I guess that's what I meant; XSS would give them the user's session implicitly on my domain, regardless of CORS. CORS prevents them from using that from another domain, which is valuable, but moot if you already have a breach.

Re: Developers don't understand CORS

#159

Post by superasn »

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…

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's a rabbithole :)

Re: Developers don't understand CORS

#160

Post by duncans »

z3t4 wrote: post #90

Just tried and I get CORS errors when trying to access localhost in Firefox, also on images via xmlHttp ... Edit: It works with image elements! img = document.createElement("img") img.src = "http://localhost:1337/service" Btw, CORS is a PITA when doing pure web apps, apps that doesn't requre a server. I recently made a RSS reader web app, but had to use a CORS proxy. I wonder if there is any way I can use an image el…

A little shortcut for this is:

    new Image(1,1).src = 'http://localhost:1337/service'
Post reply on HN