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

171–180 of 366 posts

Re: Developers don't understand CORS

#171

Post by tgsovlerkhgsel »

superasn wrote: post #146
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…

It certainly won't allow me to make xhr POST requests without sending an OPTIONS request first. Are you sure about that?

Don't trust, verify: https://news.ycombinator.com/item?id=20406633

Re: Developers don't understand CORS

#172

Post by jrochkind1 »

jonstaab wrote: post #157
jrochkind1 wrote: post #149

Earlier quoted context omitted.

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

OK, I think I was confused about what "XSS" means or how you meant it or I was thinking about it differently.

The important point though: You don't need any pre-existing vulnerability on your site in order for "Access-Control-Allow-Origin: *" to create a vulnerability.

This stuff is sure is confusing to talk/think about though.

Re: Developers don't understand CORS

#173

Post by Beldin »

The webserver listening on localhost:19421 should [...] set a[n] 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.

If you create a single-purpose webserver, you can really handle this better than asking the client to play nice via an HTTP header.

Re: Developers don't understand CORS

#174

Post by tgsovlerkhgsel »

_eht wrote: post #135
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…

This context was incredibly useful; thank you. Am I missing something or is this transaction actually a browser being the deciding factor for whether or not the request gets sent? If that’s true, couldn’t a nefarious browser decide when to push a request and completely ignore the OPTIONS header?

Of course, anyone can use netcat to send any kind of request.

However, this attack is most useful if you can get the victim's browser to send the request for you, because that way, you can get it to include the victim's authentication cookies.

If you as the attacker send the request yourself, you don't have the cookies.

If you make the victim's browser send it, you either can't make them use a nefarious browser, or you already won since you have code execution on the victim's machine.

Re: Developers don't understand CORS

#175

Post by reda-alaoui »

badamp wrote: post #58
edejong wrote: post #19

The reason the developers didn't use CORS is because active mixed content isn't allowed. You simply cannot call ' http://localhost' from a https domain. For a medical SaaS application which needed to communicate via USB I created a self-signed certificate during installation and added it to the trust store to be able to call active content on localhost. Previously, we used NPAPI (which, when used correctly was more s…

> You simply cannot call ' http://localhost' from a https domain. That’s simply wrong. You have outdated information. Unless you don’t consider Firefox, Chrome, IE, and Edge to matter. https://chromium.googlesource.com/chromium/src.git/+/130ee68... https://developer.microsoft.com/en-us/microsoft-edge/platfor... Safari still has an open issue I think. But that’s no surprise since Apple has demonstrated they’re suckitu…

This is not true. We tested this on April 2019. Chrome works with http://localhost. Firefox does not => https://bugzilla.mozilla.org/show_bug.cgi?id=1488740

Oddely, the issue was updated today after months of inactivity. Maybe they became aware of their part of responsibility in what happened to Zoom?

Re: Developers don't understand CORS

#176

Post by arendtio »

EGreg wrote: post #101
nathan_long wrote: post #42

Earlier quoted context omitted.

How many people can you have in a single meeting?

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.

Re: Developers don't understand CORS

#177

Post by jchw »

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…

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.)

Re: Developers don't understand CORS

#178

Post by aaronharnly »

tgsovlerkhgsel wrote: post #170
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…

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…

Thank you, I stand corrected! Editing :-)

Re: Developers don't understand CORS

#179

Post by garganshum »

This is my high level overview of CORS.

1. The website JS is served from a domain say "website.co" to the browser when you visit it.

2. If this JS tries to make a XHR to a domain that is NOT "website.co"(not the origin of JS) the browser first sends a preflight request (OPTIONS) asking for "guidance" from this second domain.

3. The Web Server on second domain responds with "a request" to block/allow XHR calls from JS served from certain domains.

4. The browser chooses (by default) to not make the GET/POST call if the JS domain(website.co/*) is not in "Access-Control-Allow-Origin" header.

There are other nuances but that is it really. Things to note

1. The browser enforces CORS. Not the web server. You can disable this enforcement with a flag in both Chrome and FireFox.

2. Since only browsers enforce CORS, other tools(cURL, PostMan) will successfully make GET POST request regardless CORS config on the webserver.

3. If you could intercept (using a proxy) and change headers in response to preflight request you can bypass CORS on browsers. 3.

Re: Developers don't understand CORS

#180

Post by aaronharnly »

tgsovlerkhgsel wrote: post #152
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…

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

Variant of #1 that I've seen not infrequently:

They set it to check a regex for `bank.com` to also allow `subdomain.bank.com`, but inadvertently also allow `bank.com.evil.com`, `evilbank.com`, or similar.

Post reply on HN