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

291–300 of 366 posts

Re: Developers don't understand CORS

#291

Post by recursive »

james_s_tayler wrote: post #266
lacampbell wrote: post #260

Earlier quoted context omitted.

I think it's 100% because you don't like Javascript. You resent having to learn it. I feel the exact same way about Git, I've never been able to stomach it, I'm bewildered as to why the entire programming community have decided it's the one VCS to rule them all, and I resent having to grok its UI. The Javascript ecosystem is huge. It's also the wild west, completely non-curated, open to anyone, and you have to treat…

Git is amazing, beautiful piece of software. But... sigh I feel exactly how you feel about Git about Vim. It's the one editor everyone has decided despite it's arcane and bizarre UX that you aren't a real programmer if you don't know. Refuse to learn it. Absolutely refuse. I think everyone has one of those things.

I have at least 2. Git and vim. It seems fitting then, that vim should be the default editor for git's commit messages.

Re: Developers don't understand CORS

#292

Post by andrewflnr »

csours wrote: post #12

I certainly don't understand CORS. I've read about it several times and I don't remember what I read. It's like CORS has a teflon coating that prevents it from sticking in my mind. I know what CORS is for and why you need it, but I have no idea how, where, and when to use it.

I love that we're not alone in this. CORS is an antimeme, confirmed: http://www.scp-wiki.net/antimemetics-division-hub

Re: Developers don't understand CORS

#293

Post by Thorrez »

pixelperfect wrote: post #202
tgsovlerkhgsel wrote: post #170

Earlier quoted context omitted.

Even a JavaScript initiated POST request will go through. Blocking it would not make a lot of sense, because the attacker could just use the FORM (possibly in an iframe to keep it invisible to the victim). It is possible that XHR, or common XHR libraries, default to adding some header that makes it a non-standard request, but a fetch() call works. In Firefox, open a debug console and run fetch('https://otherorigin.ex…

But for XHR only POST requests that meet a lot of constraints (defined here https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simpl... ) will work, right? Nothing with a Cookie header for example...

That page says that the Cookie header cannot be "manually set". Headers can still be automatically sent, and the browser can automatically send cookies from the cookie jar. So for example this will not send a request with the manually set cookie:

    r = new XMLHttpRequest();
    r.withCredentials = true;
    r.addEventListener('load', function(e) {console.log('loaded: ', this, e);});
    r.addEventListener('error', function(e) {console.log('error: ', this, e);});
    r.open('GET', 'https://www.google.com');
    r.setRequestHeader('Cookie', 'somecookie=somecookievalue')
    r.send();
But this will send a request with the automatically set cookies just fine:

    r = new XMLHttpRequest();
    r.withCredentials = true;
    r.addEventListener('load', function(e) {console.log('loaded: ', this, e);});
    r.addEventListener('error', function(e) {console.log('error: ', this, e);});
    r.open('GET', 'https://www.google.com');
    r.send();
Assuming the user is already logged in to bank.com , the user's cookies will be automatically sent on the request, and the transfer will go through assuming there is no CSRF protection.

Re: Developers don't understand CORS

#294

Post by Thorrez »

metafunctor wrote: post #153
aaronharnly wrote: post #147

Earlier quoted context omitted.

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?

Not hard. Just make an html form with the values you want, then with javascript call

    document.getElementById("myForm").submit();

Re: Developers don't understand CORS

#295

Post by Twisell »

My point of view as a SQL developer reading a article about something front-end by curiosity:

Yet another article about some ranting about usage and misconceptions about without even caring to explain in the first 20 paragraphs what the hell mean or is supposed to achieve in the first place.

You are free to re-use and adapt this sentence for each new like feature trending at any point in time.

PS: My bad it was actually described in the last sentence of the citation inserted in the third paragraph.

Re: Developers don't understand CORS

#296

Post by Thorrez »

danShumway wrote: post #254
tgsovlerkhgsel wrote: post #138

Earlier quoted context omitted.

Because you used to be able to host your web site on www.compsci.tech.youruniversity.edu, and put a HTML element in there, that would send the result to myawesomeguestbook.com. Thus, cross-origin POST requests were allowed, and changing it was impossible without breaking the web. Likewise you can include images or iframes of other origins, allowing GET requests. However, you cannot read the responses! The JavaScript…

My reading, feel free to correct if I'm missing something. This is a compatibility feature that can never change, and shouldn't change, because we can't break the web. But my reading is that CORS is mostly a band-aid on what was a bad security policy to begin with. The problem isn't that a browser might let a web page on a separate domain send and read any arbitrary request to another domain without permission -- wit…

>The problem isn't that a browser might let a web page on a separate domain send and read any arbitrary request to another domain without permission

That's not fully correct. Even without cookies it's bad if a.com can read a response from b.com . Why? Because b.com might be hosted on a private network, and contain private information. We don't want a.com to steal that information. Even if cookies aren't sent, there can be other types of ambient authority, and connectivity to a private network is one of those types of ambient authority. Another similar type is if a website is protected using a whitelist of user IPs. Side note: any website that uses this type of ambient authority that isn't associated with a hostname must also check the Host header to protect against DNS rebinding.

Of course if the web was built from the start such that a.com can read b.com just without cookies, then such websites that rely on non-host-associated ambient authority (hopefully) wouldn't be built and you would be right.

Just because a native program can do something doesn't mean a website should be able to. A native program can delete all my files without asking me. A website can't.

Re: Developers don't understand CORS

#297

Post by Thorrez »

tcheard wrote: post #137
abstractbarista wrote: post #129

Earlier quoted context omitted.

Thanks for this; it helped me. Very naively, I don't understand why evil.com origin was allowed to make any request to other domains using any cookies/session/identity of the browser/user in the first place. Why was this accepted standard? I was blown away when I first learned that a request made to xyz.com while in a browser tab showing abc.com would actually complete the request using my identity on xyz.com.

By default, under the same origin policy, a browser won't allow requests cross origin. But there are valid situations where you want a request from 1 domain to be made to other domains. This is where CORS comes in. CORS is a mechanism to loosen security, not increase it. It allows a server to say, these are the domains (outside my own domain) who can make requests. CORS headers should be set carefully so that you are…

> By default, under the same origin policy, a browser won't allow requests cross origin.

Cross origin requests are allowed (as long as they're simple). Reading the response is what's blocked.

Re: Developers don't understand CORS

#298

Post by MrBuddyCasino »

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…

This is the first comprehensible, and more importantly memoizable, description of CORS I have read. Hope it sticks this time.

Re: Developers don't understand CORS

#299

Post by Thorrez »

squiggleblaz wrote: post #262
tcheard wrote: post #137

Earlier quoted context omitted.

By default, under the same origin policy, a browser won't allow requests cross origin. But there are valid situations where you want a request from 1 domain to be made to other domains. This is where CORS comes in. CORS is a mechanism to loosen security, not increase it. It allows a server to say, these are the domains (outside my own domain) who can make requests. CORS headers should be set carefully so that you are…

> CORS is a mechanism to loosen security, not increase it. Or we could call it CORB instead (Cross origin request blocking), and then we see it's a mechanism to tighten security. Since fundamentally, what we have is an agreement against major web browser vendors that blocks cross origin requests unless the web server authors have used CORS. I mean, how many people have encountered a problem with CORS? Almost no-one,…

I think you have a bad acronym collision with Cross-Origin Read Blocking.

https://fetch.spec.whatwg.org/#corb

Re: Developers don't understand CORS

#300

Post by Thorrez »

oefrha wrote: post #283
zaroth wrote: post #277

Earlier quoted context omitted.

(Throws up hands) But this is ridiculous! The security of the API can’t rely on strict validation of the content-type , how is that code supposed to make any sense to the 3rd generation of developers who are tasked to maintain it 5 years from now? CORS is clearly not designed as a means of access control to ensure the POST request will never be made. Therefore, it is fairly catastrophic that an article prognosticatin…

application/x-www-form-urlencoded and multipart/form-data POSTs predate CORS. They have to be whitelisted, or large swaths of the existing web would be broken.

Yes, but that doesn't mean we should build a website that has its CSRF security depend on the Content-Type header. There are other mechanisms to gain this security that are less confusing.
Post reply on HN