81–90 of 285 posts
It was pretty amusing reading the comment section so I'll chime in: SOP protects you (the browser) from leaking information to websites that should not be able to access that information and CORS allows you to weaken it. Example: SOP stops example.com from fetching the list of subscriptions on youtube.com. But CORS allows example.com to access youtube.com/public/*. This is also not the sole use-case, it also stops yo…
Earlier quoted context omitted.
It’s not that hard to understand… in the cors threat model an attacker gets one your users to take an action on your site by visiting their site.
> in the cors threat model an attacker gets one your users to take an action on your site by visiting their site This is really oversimplifying things, incorrectly IMO, and that sentence makes it sound like you're confusing a CSRF vulnerability with CORS protections. Normally when you write a backend server you implement some sort of authentication and access control, and in that scenario the threat model that lets "…
Assuming the web client plays nicely. I commonly bypass CORS for playwright unit/E2E testing.
It was pretty amusing reading the comment section so I'll chime in: SOP protects you (the browser) from leaking information to websites that should not be able to access that information and CORS allows you to weaken it. Example: SOP stops example.com from fetching the list of subscriptions on youtube.com. But CORS allows example.com to access youtube.com/public/*. This is also not the sole use-case, it also stops yo…
I understand CORS and I don't. TL;DR: It's a restriction your browser gives itself . If it's on Domain A and it sees a request going out to Domain B, unless Domain B responds saying that it's expecting traffic from Domain A, the browser prevents itself from making the call. I think the part about it that is off/silly to most people is that it's not a normal security threat model, because a malicious client could simp…
> […] the browser prevents itself from making the call. That's not strictly correct, by the way. The request is made, but the JavaScript code on Domain A is not allowed to read the response. This matters when a request is destructive on its own, for example.
[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...
Even TFA seemingly doesn't understand CORS. Or at least misreprents it grossly: > 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 localhost webserver. No, that does not do that. JavaScript from any other website can still talk to lo…
> Further, native apps can generate a unique self-signed certificate.
Just creating a certificate will not work, unless it's installed as root CA certificates in all browser trust-stores on the machine. And if the private key of the root CA is not secured correctly, one could MitM any websites. So at least you want it name constrained (https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....), but at least in Chrome until 2023 (v112) that did not work on root CA's (https://alexsci.com/blog/name-non-constraint/), so you had to add an intermediate CA and add the constrain there. Of course, you should also just throw away the key of the root CA.
I will admit I once added basic constrains in some project with a local root CA (2020-2022), but 'incorrectly' to the root CA, and did not test it in all browsers.
It's not just CORS that's hard to understand. Many (most?) developers don't really understand the threat model. And even when it's explained it hard to see why it's a big deal. Part of this is that backend developers usually have to configure CORS and it's not an access privilege protection. From the point of view of the backend it doesn't seem to matter. Bad guys can't get it. From the point of view of the front-end…
CORS is amazing for when you want to prevent people from (easily) stealing your bandwidth and hosting resources. Thieves have to stand up their own proxies, which makes them very easily blocked.
I still don't understand the threat model and, obviously, it's not explained here either. I log in to social.net. I click on scam.org and change sites. I'm on scam.org and it triggers a request to social.net/friends. No cookies are sent, no JWT. I'm not logged in and get a "Needs login" HTTP error. Nothing bad happens. I thought that's how it works without CORS already.
> 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 localhost webserver.
First of all, its not CORS that protects. CORS is an anti-security feature. What does protect is the SOP (same origin policy). The SOP (or SOPs rather, it's not really one feature but more of a paradigm in the standards) blocks documents from one origin, from reading data that belongs to another origin. This is the reason why `let w = window.open("https://example.com"); console.dir(w.document.body);` will work when it is ran from example.com, but not wikipedia.org. Only when protocol, host and port match, can documents access each others data (there is an interesting differential with cookies here, their SOP only looks at protocol and host, not port).
Importantly, the SOP only blocks reading data from other origins, not writing! So while example.com won't be able to read the response of a post request it sends to wikipedia.org, the request is sent and processed nontheless!
CORS now is a feature that allows sites to loosen up the SOP. This allows documents to read cross origin data nontheless. Namely, HTTP responses. (Standards for reading other kinds of data cross origin exist, but are not related to CORS).
[flagged]
100% - although it is stunning to see since most LLMs get CORS questions right (which is surprising since they trained on all sorts of incorrect data).