logoalt Hacker News

yaurtoday at 4:28 AM3 repliesview on HN

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.


Replies

hn_throwaway_99today at 4:58 AM

> 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 "an attacker gets one your users to take an action on your site by visiting their site" is a CSRF vulnerability, unrelated to CORS.

The scenario presented in TFA is actually a very special case, because the bug is with a webserver running on localhost that doesn't (apparently) implement access control - not something most web apps entail.

In fact, one of the parts that confuses a lot of people is that CORS rules only prevent the JavaScript web client from reading the response from a remote endpoint - if the endpoint is available on the public Internet then anyone can still make a request to it.

The other thing that is confusing about CORS is that browsers already let you load lots of resources from cross origin servers - you can load images (as TFA points out that Zoom did as a workaround), scripts, stylesheets, form submissions, etc. The one thing you can't do, unless the server implements the appropriate CORS headers, is make a cross origin fetch request from JavaScript.

show 3 replies
ronbentontoday at 10:13 AM

No? CORS is about preventing an unauthorized third party from _accessing_ data. That’s the meaning of “resource sharing.” If you want to prevent action-taking, there are other mechanisms. For example, using a header-based CSRF token if your auth scheme relies on cookies.

harralltoday at 4:34 AM

It’s easy to understand but most people don’t naturally think of ways people try to break in. Without thinking about that, the importance of security is low.

It isn’t a knowledge thing (though it could be), or a capability thing, or intelligence. It’s pure mindset.

Ask yourself: is the average person noticing holes in fences and trying random doorknobs… probably not.

But on the other hand, most security people don’t think of product or UX (but some might) so that’s why you have roles.

show 1 reply