5 ms·

Post-Spectre Web Development, Editor's Draft, 2021-03-10

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.
oezi 6y ago
Can someone knowledgeable on the topic comment if the general premise is sufficiently plausible that an attacker can access all browser memory in one process? Have Spectre-class attacks been observed in the wild?
- Tuna-Fish 6y ago
  It takes an afternoon to build a proof of concept. It absolutely works.
- titzer 6y ago
  This is the conclusion of our 2019 paper: https://arxiv.org/abs/1902.05178 https://arxiv.org/abs/1902.05178 Side-channel vulnerabilities are too numerous and too hard to defend against. In the limit, the entire process address space is up for grabs.
qbasic_forever 6y ago
Is this all solved by just spawning a new process for each browser tab? If so do it and spawn a single process for the browser window UI. Communicate between the browser window and tab processes with whatever flavor of IPC you desire, and secure it with whatever security layer you trust (TLS 1.3+ for example). We've basically reinvented the operating system desktop, which isn't that far off from how we treat browsers and the web today anyways...
- saagarjha 6y ago
  Creating processes ain’t cheap.
  - qbasic_forever 6y ago
    Meh, my three year old phone has 8GB of DDR4 RAM and 8x cores clocked at over 2ghz. In the time it takes my brain to send signals to move my muscles to move my mouse to a different tab my computer has lived multiple lifetimes of operations. For handling unbelievable load at scale, sure processes will kill scaling. But for handling a user clicking and touching their inputs of dozens or hundreds of tabs.. I doubt anyone will notice on today's machines.
    - saagarjha 6y ago
      Processes use RAM, and a lot of people use a lot of tabs. This isn't to say that each website couldn't have a separate process (and this is true if you browse different websites already), but memory usage isn't something you can just freely ignore even on today's hardware.
  - SilasX 6y ago
    Isn't it cheap compared to the typical browser bloat though?
    - saagarjha 6y ago
      What bloat are you talking about?

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.

oezi 6y ago

Can someone knowledgeable on the topic comment if the general premise is sufficiently plausible that an attacker can access all browser memory in one process? Have Spectre-class attacks been observed in the wild?

Tuna-Fish 6y ago
It takes an afternoon to build a proof of concept. It absolutely works.
titzer 6y ago
This is the conclusion of our 2019 paper: https://arxiv.org/abs/1902.05178 https://arxiv.org/abs/1902.05178 Side-channel vulnerabilities are too numerous and too hard to defend against. In the limit, the entire process address space is up for grabs.

qbasic_forever 6y ago

Is this all solved by just spawning a new process for each browser tab? If so do it and spawn a single process for the browser window UI. Communicate between the browser window and tab processes with whatever flavor of IPC you desire, and secure it with whatever security layer you trust (TLS 1.3+ for example). We've basically reinvented the operating system desktop, which isn't that far off from how we treat browsers and the web today anyways...

saagarjha 6y ago
Creating processes ain’t cheap.
- qbasic_forever 6y ago
  Meh, my three year old phone has 8GB of DDR4 RAM and 8x cores clocked at over 2ghz. In the time it takes my brain to send signals to move my muscles to move my mouse to a different tab my computer has lived multiple lifetimes of operations. For handling unbelievable load at scale, sure processes will kill scaling. But for handling a user clicking and touching their inputs of dozens or hundreds of tabs.. I doubt anyone will notice on today's machines.
  - saagarjha 6y ago
    Processes use RAM, and a lot of people use a lot of tabs. This isn't to say that each website couldn't have a separate process (and this is true if you browse different websites already), but memory usage isn't something you can just freely ignore even on today's hardware.
- SilasX 6y ago
  Isn't it cheap compared to the typical browser bloat though?
  - saagarjha 6y ago
    What bloat are you talking about?