[HN Gopher] Post-Spectre Web Development, Editor's Draft, 2021-0...
___________________________________________________________________
Post-Spectre Web Development, Editor's Draft, 2021-03-10
Author : distortedsignal
Score : 45 points
Date : 2021-03-10 16:56 UTC (6 hours ago)
(HTM) web link (w3c.github.io)
(TXT) w3m dump (w3c.github.io)
| jefftk wrote:
| 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, 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 wrote:
| Am I the only English speaker who finds "more granular" to be
| ambiguous? Does the writer of this want "finer grained"?
| thom wrote:
| Yeah, I've seen several modern style guides acknowledge this
| point and embrace exactly what you suggest.
| moron4hire wrote:
| 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.
| jefftk wrote:
| If you don't have any data that needs to be shared only with
| some users, then none of this advice applies.
|
| But let's say you have
| https://social.example/moron4hire/photos/1234 which should
| only be visible to you and your contacts. If an attacker
| sends a manual HTTPS request, outside the browser, they won't
| have your credentials and so won't be able to view it --
| good!
|
| Now let's say https://evil.example puts in <img
| src="https://social.example/moron4hire/photos/1234">. This
| succeeds, because the browser automatically sends
| credentials, but it wouldn't normally allow evil.example to
| read the image contents. Unfortunately, Spectre etc changes
| this: since the image is getting loaded into an address space
| controlled by JS from evil.com, the contents can probably be
| read.
|
| The recommendation is that if
| https://social.example/moron4hire/photos/1234 is (a) private
| and (b) only intended to be visible on
| https://social.example, then it should be served with
| restrictive CORS headers.
| akersten wrote:
| > 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 wrote:
| 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 wrote:
| It takes an afternoon to build a proof of concept. It
| absolutely works.
| qbasic_forever wrote:
| 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 wrote:
| Creating processes ain't cheap.
| qbasic_forever wrote:
| 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.
| monocasa wrote:
| From reading the threat model though I think the issue they're
| bringing up is that even in browsers that use per tab processes
| (Chrome, Firefox, etc.), they don't ubiquitously use per iframe
| processes in each tab. And there's a non trivial amount of work
| needed to get to a point where you can rely on that.
|
| As an aside, you don't have to protect local IPC with TLS.
| Processes that can tap IPC generally have the tools to do brain
| surgery on the processes and pull the secrets out of their
| memory anyway. Your time is better spent understanding the
| local IPC security mechanisms that the kernel will enforce.
| qbasic_forever wrote:
| Yeah it's more just defense in depth. The browser is already
| going to have a super optimized and battle-hardened TLS
| engine, so might as well use that IMHO. Today we can
| reasonably assume process IPC is secure... but who knows what
| exploits will surface tomorrow.
|
| It also opens up an interesting possibility where the tab
| process isn't on the same machine. That could be handy for
| power users, or even for interesting things like browser
| testing apps on different, remote devices.
| monocasa wrote:
| I'm all about defense in depth, but for speculative
| security stuff like that I like to see a well thought out
| threat model where you actually protected against anything.
| Otherwise you have unbounded amounts of work (both
| human/cognitive and compute time) dedicated to security
| that isn't actually helping your users in a meaningful way.
|
| The issue with not trusting that the kernel can protect IPC
| like it's supposed to is that so many ways to get root are
| ultimately protected by that same IPC protection scheme. If
| you don't trust the kernel, in the general case you've
| already lost with any scheme like TLS that ultimately
| relies on the kernel provided primitives to do stuff like
| hide the secrets in the first place.
___________________________________________________________________
(page generated 2021-03-10 23:01 UTC)