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

191–200 of 366 posts

Re: Developers don't understand CORS

#191

Post by JTbane »

stefan_ wrote: post #29
anaphor wrote: post #14

That is because CORS is a kludge to work around the fact that we decided to use session cookies "because developers understand it easily" instead of just re-doing everything. See https://w3c.github.io/webappsec-cors-for-developers/#cors > Enter Cross-Origin Resource Sharing. The challenge when designing CORS was how to enable web applications to request and receive more cross-origin permissions, without exposing exis…

Wrong conclusion. The kludge is making cross origin requests in the first place.

You should be able to make REST requests anywhere, without caring about origin.

Re: Developers don't understand CORS

#192

Post by jusob »

Yet another explanation of CORS.

The basic security in we browsers is based on SoP: Separation of Origins. To simplify, there are number of actions that can be done within an origin (a domain, to simplify) that are prevented across origins (across domains, to simplify). CORS is way for bridge 2 different origins, i.e.e to allow some specific actions between 2 different origins.

One example: by default, XHR requests can only send a specific set of HTTP headers to a different origin. If b.com want to accept the header X-Special-Header from a.com, it has to whitelist it - Access-Control-Allow-Headers: X-Special-Header, Access-Control-Allow-Origin: a.com. On a.com, before the web browser makes an XHR request to b.com that includes the header X-Special-Header, it has to check whether b.com authorizes it or not. I sends an OPTIONS request to b.com and check for the HTTP response headers Access-Control-Allow-Origin and Access-Control-Allow-Headers.

Since CORS is a way to bypass the Separation of Origin basic security model, you should be careful with it. For example, you may allow any site to get read your content, i.e. trigger a CSRF request on behalf of the user logged in to bank.com, and with Javascript be able to read the page content, including the account number because bank.com set the CORS to authorize any remote site to do anything, basically putting bank.com in the same origin as any other domain.

Re: Developers don't understand CORS

#193

Post by mehrdadn »

tgsovlerkhgsel wrote: post #186
mehrdadn wrote: post #25

Earlier quoted context omitted.

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)

Oh wow, 2017. Finally...

Re: Developers don't understand CORS

#194

Post by goto11 »

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

Sure, but then again a nefarious browser could just record and broadcast all your interaction (including password etc) with bank.com directly.

No web standard can protect you from a nefarious browser, since the browser could just decide to not follow the standard.

Re: Developers don't understand CORS

#195

Post by greenshackle2 »

garganshum wrote: post #179

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…

Mostly correct, but the browser may or may not send an OPTIONS request depending on the request type, headers, and more.

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

Re: Developers don't understand CORS

#196

Post by heavenlyblue »

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…

>> I wonder if there is any way I can use an image element to bypass CORS and read RSS xml that way !?

The article in question says they used the image dimensions to encode the error codes returned by the server when making a request.

I can imagine you could simply encode the payload in the dimensions of the image.

Re: Developers don't understand CORS

#197

Post by WhitneyLand »

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.

This Teflon you're talking about, it's a thing. Not just with CORS, not just with you.

For example, I've gotten decent at regular expressions a few times but have to keep relearning it. Adding insult to injury, I might relearn something from Stackoverflow, and realize afterwards I posted the answer!

Not for trivial stuff. But a string of punctuation with capture groups or whatever, forget about it [1].

Any support for this informal draft definition below?

------------------

Teflon tech (draft definition v0.1 [2])

Knowledge that could be learned by most with reasonable effort, but often must be relearned or is never fully grokked.

This can be due to infrequent opportunities to recall the concepts in a particular role, or insufficient need to apply (thereby practicing) the relevant techniques. It may also occur when a tech is used frequently but the foundational theory is hidden by the use of higher level abstractions.

[1] https://stackoverflow.com/questions/1381097/how-do-i-get-the...

[2] content provided under MIT license.

Re: Developers don't understand CORS

#198

Post by ChrisCinelli »

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…

> "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, Zoom wants to make "joining a meeting" as easy as clicking a link. I do not think Zoom wants people to be logged in a zoom account in order to join.

And what Zoom should try to avoid is to have random people joining meetings and website forcing actions on the laptop of the people.

A simple fix is to use a GUID or any other long not-guessable string for the meeting id. And, of course, do not expose any other potentially dangerous endpoints beside the one that starts the meeting.

In general it should not be about either CORS or CSRF. There are better ways to start a video call communicating with a plugin than exposing a port on localhost and using to communicate with it.

Re: Developers don't understand CORS

#199

Post by cpitman »

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…

Is this true if the request is a POST? Shouldn't a POST lead to a preflight request, and then the browser refusing to send the real request?

Re: Developers don't understand CORS

#200

Post by [deleted] »

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…

[deleted]
Post reply on HN