4 ms·

Article's summary of what this means for webdevs: 1. Decide when (not!) to respond to requests by examining incoming headers, paying special attention to the O

by jefftk 6y ago

Article's summary of what this means for webdevs: 1. Decide when (not!) to respond to requests by examining incoming headers, paying special attention to the Origin header on the one hand, and various Sec-Fetch- prefixed headers on the other, as described in [resource-isolation-policy]. 2. Restrict attackers' ability to load your data as a subresource by setting a cross-origin resource policy (CORP) of same-origin (opening up to same-site or cross-origin only when necessary). 3. Restrict attackers' ability to frame your data as a document by opt-ing into framing protections via X-Frame-Options: SAMEORIGIN or CSP’s more granular frame-ancestors directive (frame-ancestors 'self' https://trusted.embedder https://trusted.embedder, for example). 4. Restrict attackers' ability to obtain a handle to your window by setting a cross-origin opener policy (COOP). In the best case, you can default to a restrictive same-origin value, opening up to same-origin-allow-popups or unsafe-none only if necessary. 5. Prevent MIME-type confusion attacks and increase the robustness of passive defenses like cross-origin read blocking (CORB) / opaque response blocking ([ORB]) by setting correct Content-Type headers, and globally asserting X-Content-Type-Options: nosniff.

jeffbee 6y ago
Am I the only English speaker who finds "more granular" to be ambiguous? Does the writer of this want "finer grained"?
- thom 6y ago
  Yeah, I’ve seen several modern style guides acknowledge this point and embrace exactly what you suggest.
- nawgz 6y ago
  In general maybe, but in this certain circumstance I felt it was clear. On a second read I hear your point though
moron4hire 6y ago
This is... annoying. This sounds like Chromium team throwing up their hands, "We can't keep attackers out, so don't be giving out any data attackers can use." Which is basically going to mean, "don't give out data". This is going to cause roadblocks that frustrate legitimate users. Cross-origin policies are a clusterfuck of bad design with defaults that assume things that are frequently not true. They seem more like a darkhorse to enforce DRM rules than true security features. I mean, what's really going to happen? A legitimate user, using a browser app to try to link to a resource, can't access the resource because of CORS, then blames the app for being broken. An attacker, finding they can't access a resource because of CORS, writes a script to spoof the HTTP headers and gets access regardless. Maybe I'm wrong. Someone explain it to me. I miss the weird web, CORS broke the weird web, but I've yet to see any explanation for how it actually prevents malicious behavior.
- akersten 6y ago
  > This is... annoying. This sounds like Chromium team throwing up their hands, "We can't keep attackers out, so don't be giving out any data attackers can use." It's actually the correct approach to realize that side-channels on shared processors are inevitable, and it's much easier to reason through the model of "anything your process can access, a malicious script running in that process can access too," instead of "well, maybe we'll patch HighResTimer to give a reduced precision, and change SharedArrayBuffer a little, to prevent the one known Spectre-like attack we've seen, and keep spaghetti-and-meatballing patches when more attacks surface." > A legitimate user, using a browser app to try to link to a resource, can't access the resource because of CORS, then blames the app for being broken. Yes, if your web app can't load a resource for legitimate user, it is broken. > An attacker, finding they can't access a resource because of CORS, writes a script to spoof the HTTP headers and gets access regardless. CORS rules are enforced by the browser, not the server, so that isn't a possible attack. > Maybe I'm wrong. Someone explain it to me. I miss the weird web, CORS broke the weird web You'll have to be more specific. What's broken? > but I've yet to see any explanation for how it actually prevents malicious behavior. Things like CORS and Frame-options prevent a malicious site from embedding your bank's login page beneath an innocent-looking button and clickjacking your session cookie to transfer money, for example. There's a lot more information about these measures readily available on MDN etc.
  - thu2111 6y ago
    They mean a script outside the browser.
    - akersten 6y ago
      If malicious code is running outside of your browser, that is well beyond the scope of anything the web development guidance here will prevent.
      - thu2111 6y ago
        Yes, but his point is that when you write a server (any server), you still have to consider non-browser connections on top of browser connections, thus any security policy that handles the former can subsume the latter.

by jefftk 6y ago

jeffbee 6y ago

Am I the only English speaker who finds "more granular" to be ambiguous? Does the writer of this want "finer grained"?

thom 6y ago
Yeah, I’ve seen several modern style guides acknowledge this point and embrace exactly what you suggest.
nawgz 6y ago
In general maybe, but in this certain circumstance I felt it was clear. On a second read I hear your point though

moron4hire 6y ago

This is... annoying. This sounds like Chromium team throwing up their hands, "We can't keep attackers out, so don't be giving out any data attackers can use." Which is basically going to mean, "don't give out data". This is going to cause roadblocks that frustrate legitimate users. Cross-origin policies are a clusterfuck of bad design with defaults that assume things that are frequently not true. They seem more like a darkhorse to enforce DRM rules than true security features. I mean, what's really going to happen? A legitimate user, using a browser app to try to link to a resource, can't access the resource because of CORS, then blames the app for being broken. An attacker, finding they can't access a resource because of CORS, writes a script to spoof the HTTP headers and gets access regardless. Maybe I'm wrong. Someone explain it to me. I miss the weird web, CORS broke the weird web, but I've yet to see any explanation for how it actually prevents malicious behavior.

akersten 6y ago
> This is... annoying. This sounds like Chromium team throwing up their hands, "We can't keep attackers out, so don't be giving out any data attackers can use." It's actually the correct approach to realize that side-channels on shared processors are inevitable, and it's much easier to reason through the model of "anything your process can access, a malicious script running in that process can access too," instead of "well, maybe we'll patch HighResTimer to give a reduced precision, and change SharedArrayBuffer a little, to prevent the one known Spectre-like attack we've seen, and keep spaghetti-and-meatballing patches when more attacks surface." > A legitimate user, using a browser app to try to link to a resource, can't access the resource because of CORS, then blames the app for being broken. Yes, if your web app can't load a resource for legitimate user, it is broken. > An attacker, finding they can't access a resource because of CORS, writes a script to spoof the HTTP headers and gets access regardless. CORS rules are enforced by the browser, not the server, so that isn't a possible attack. > Maybe I'm wrong. Someone explain it to me. I miss the weird web, CORS broke the weird web You'll have to be more specific. What's broken? > but I've yet to see any explanation for how it actually prevents malicious behavior. Things like CORS and Frame-options prevent a malicious site from embedding your bank's login page beneath an innocent-looking button and clickjacking your session cookie to transfer money, for example. There's a lot more information about these measures readily available on MDN etc.
- thu2111 6y ago
  They mean a script outside the browser.
  - akersten 6y ago
    If malicious code is running outside of your browser, that is well beyond the scope of anything the web development guidance here will prevent.
    - thu2111 6y ago
      Yes, but his point is that when you write a server (any server), you still have to consider non-browser connections on top of browser connections, thus any security policy that handles the former can subsume the latter.