Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
The idea of CORS is to allow some sort of client side defense against cases where a 3rd party can control an element on the regular served page.
Think Github issue, with an html block in it, that was created by a malicious party. CORS will prevent the injected html from loading a resource from the attacker server.
However - nothing prevents the attacker to include the attack directly in the html.
Developers hate CORS - it is not helpful for them during the dev process.
netikras29617253dMost of such algorithms protect from bots scanning the internet looking for known vulns. They do not protect from targeted elaborate attacks.
How does that even make sense? CORS is the relaxing mechanism for SOP so that without CORS, you'd only have SOP.
@magicMirror Of course dropping any securty makes things easier for devs - unfortunately, also for black hat ones.
Like, being logged in to a banking site, also visiting an unrelated site that was hacked, and presto, the hacked site can use a malicious script to read any data from the banking site. Well, actually not, because the banking server did not put the unrelated site in the CORS list so that SOP applies.
"Like, being logged in to a banking site, also visiting an unrelated site that was hacked, and presto, the hacked site can use a malicious script to read any data from the banking site." - How would it read any information from banking site? It does not have access to login tokens. Banking site server will reject conenctions with 401
@Argos Let me use something you perhaps understand:
@Argos: "port fowards are stupid. They are a hasle and don't protect against any attack"
Me/@Fast-Nope: "well actually a firewall is the security mechanism that blocks ports. Forwarding is a solution to allow exceptions"
CORS is not a security measure it is an explicit relaxation. It allows to break same origin policy. So CORS will never prevent any attack...
Please read up on same origin policy to see the host of XSS attacks it prevents.
"As long as you're logged in to the banking site, the browser sends the required cookies"
Do you mean that if I have cookies for a.site and script on b.site in other tab sends request for a.site, browser will automatically add all cookies set by a.site to request actually sent from another tab?
If that is thuth - then this is what should be disabled in browser, not actually sending the request. It is stupid to block tool made for sending requests(browser) from doing its job. It's also stupid to attach auth tokens to request that was sent not from the tab that received that tokens.
Also it sounds more sound that server should examine request origin and decide to send sensitive data back or not rather than rely on that browser will not try to access that data.
@Argos Yes, that's how it works with the cookies. Note that the browser does actually block that because of SOP. CORS in turn is what can override SOP, but that would require a.site to use CORS to allow the browser to give read access to a script from b.site.
The a.site server in turn cannot block that because it has no way to discern that the script is from b.site, given that it is running client-side and not on the b.site server.
I think you should read up on the basics of cookies, SOP, and CORS. While you're at it, also on CSRF because CORS doesn't capture everything, by design.
netikras29617253d@Argos backend and frontend are complementary. Through frontend you are accessing the backend. Frontend knows how exactly to access BE (what headers to send, what Origin to supply, etc.). FE is publicly available, hence that info is also publicly available.
However, if you are scanning the internet and you come across some BE server, you have no clue where its FE is, nor how to find it. Even though it's public. And w/o FE server you don't know how to access the BE API properly.
"The a.site server in turn cannot block that because it has no way to discern that the script is from b.site, given that it is running client-side and not on the b.site server."
- But server can access headers.origin to determine that, can't it?
- That is sad, isolating cookies to tab could protect from CSRF better than everything else I think. What about localStorage? It is tab related, thus I think it could be better to store tokens there and manually attach them when needed, rather than trust that to cookies that are auto attached, thus can be used for actions that require authentication on a.site by scripts running on b.site. Which sounds really bad.
"I think you should read up on the basics of cookies, SOP, and CORS."
- Already done it on MDN, still has a lot of questions, can you suggest any good article/book/video about it?
Thanks for the reasonable replies.
@Argos The main problem with the origin header check is that this is "opt-in" security, server-side. SOP/CORS, on the other hand, provides "opt-out" security.
If you mess up "opt-in" security, you won't notice until you get hacked. However, messing up "opt-out" security gives a clear indication that more work is required because things simply don't work.
Also, there are much fewer browsers around than servers, so it's a lot easier to put it in the browsers. Plus that the point is protecting the user, so it makes sense that the user's software does that part. A user won't want to rely on random website operators.
Relating cookies to a tab would mean that your shopping cart would be gone if the browser crashes or you accidentally close the tab. Not good. You couldn't shop with several tabs in the same shop, either.
I usually start with Wikipedia to get a first overview, then MDN, then searching e.g. for SO threads.
arekxv1050252dCORS is a setting servers send to tell browsers that they allow the specific request. Its client side protection and solely depends on web browsers to implement it and there is no other way to do this kind of protection.
Without it, I can make a specific JS code on my web site for every person which visits that I can harvest their facebook info if they are logged in it with their cookies (as it was the case before) and store it on my web server and they would never know.
Without it, if you are admin on a wordpress website for example, I can make a request to create an user with admin privileges which browser will happily do using your cookies and you wont have any idea.
These are examples of CSRF which were possible before CORS was added.
@Argos localStorage is not tab based. It is website domain based, similar to cookies. You can have multiple tabs sharing one same localStorage access as long as they are on the same domain. It is sometimes used for communication between tabs.
Why cookies can not be isolated by domain then? Like if I am in a tab that is displaying b.site it is impossible to attach any cookies that were saved by a.site to any requests that tab makes.
Looks like perfect protection to me. We still can load images and other not secure stuff from cross-origin, but no sensitive data that requires authentication can be received from a.site by scripts running on b.site.
Rather than completely blocking browser from making requests we can block it from sending cookies.
CORS is not the solution for all web attacks. JS exploitation still exists, expolit kits are still out there, the log4j crap is here to stay, along with many other unpatched security holes.
Also - there are many attack scenarios where CORS is not relevant.
The important take away here is to make sure you do not disable security when developing/testing your work.
Why just don't block browser from sending cookies to cross domain requests rather than completely blocking it from sending any request?
The CSRF attacks you describe could be completely avoided if browser would not attach cookies aquired from a.site to requests made in tab that is showing b.site.
Like it works with local storage, if I never save login information into cookies and store it in localStorage instead, let's consider your example with website that tries to steal facebook information. How can it steal it if facebook auth token is in localStorage of facebook domain and is manually attached to requests made by facebook scripts rather than rely on browser cookies? Isn't that better than inventing SOP that blocks everything even harmless requests?
arekxv1050252d@Argos Mostly because of legacy apps, browsers and hardware using the cookies that way. Also new browsers added a solution for that already. Google chrome forced it two years ago with SameSite property in cookies. All cookies without anything set default to SameSite=Lax. Meaning cookies are only sent with the request if the user is actually navigating to it. It would effectively prevent the exploits I mentioned, unless you do SameSite=None.
Its a product of its time and there still are some ok uses for it, but I think its on its way out.
Fast-Nop40024252d@Argos We're getting there, but third party cookies are still used. Mostly for cross-website tracking, i.e. the ads cancer.
Google wants to kill third party cookies, but there's resistance because the ad fuckers fear that Google might abuse that transition to further its own position.
On the other hand, data protection activists fear that whatever Google might introduce would be even worse than third party cookies because you can disable them completely already, right now.
"Also new browsers added a solution for that already. Google chrome forced it two years ago with SameSite property in cookies"
- Yeah I've read about that, looks much better than SOP. Why don't they replace SOP with SameSite property? It solves all of the problems the SOP does, but without so much restrictions. (Why blocking requests that don't send cookies)
I wanna say thx to you all guys for the talk esppecially for
@Fast-Nop and @arekxv
Now I understand that it should be called SOP (and CORS is a mechanism to bypass SOP if needed) and its main idea is that legit browser and legit server can protect the data of a user, that visits "bad" webpage running malicious scripts, from being acessed.
Fast-Nop40024249d@Argos Btw., in the old days, domain sharding was hot because splitting one's stuff over several domains improved performance. That's mostly gone now with HTTP/2 of course and will be completely removed with HTTP/3.
However, it still makes sense to put data with cookie requirement on a different subdomain so that generic assets (CSS, company logo etc.) can be loaded without cookies. That saves mobile data volume.
The consequence is that limiting the tab loading permissions to exactly that full domain including the subdomain wouldn't make sense. At the very least, you need to allow non-cookie data.