search

mikewest / securer-contexts

Secure Contexts, but with _more_ secureness!
19 stars 2 forks source link

Insecure context might be able to gain timer from Securer context #6

Closed shhnjk closed 5 months ago

shhnjk commented 4 years ago

Securer context will be able to gain high-precision timers. The way Securer context prevent abuse of such timer is currently focused on only loading opt-in resources inside Securer context (process).

However, I do not see anything in the doc that's preventing same-origin communication between Insecure context and Securer context. For example, BroadcastChannel or SharedWorker can be used to build communication channel between Insecure context and Securer context (at least in Chromium, because those are built using IPC).

Once communication channel has been set up, Insecure context can ask for current timestamp (in whatever form) from Securer context.

Any thoughts on this?

shhnjk commented 4 years ago

Any thoughts @mikewest?

mikewest commented 4 years ago

The secure context spec generally breaks the link between "secure enough" SharedWorker instances. See https://www.w3.org/TR/secure-contexts/#example-2829bc67 and https://www.w3.org/TR/secure-contexts/#monkey-patching-shared-workers. Presumably we'd update that to include these types of secureness as well.

BroadcastChannel is more of a risk, called out in https://www.w3.org/TR/secure-contexts/#isolation. With regard to timing, I'm not sure it's much of a risk, given the noise generated via the latency involved in routing messages cross-process.

(Note that COOP should prevent two same-origin pages from obtaining references to each other if they aren't both covered by the same COOP rule, and therefore allows browsers to put them into distinct processes. I think we can reasonably assume that boundary will exist.)

shhnjk commented 4 years ago

With regard to timing, I'm not sure it's much of a risk, given the noise generated via the latency involved in routing messages cross-process.

Yes, I agree to this. Hopefully, latency varies every time so that attack would not work.

mikewest commented 4 years ago

Great. I'll mark this as a documentation bug to make sure we incorporate it into the security considerations section of whatever spec we end up writing.

mikewest commented 5 months ago

I'm archiving this repo. I'm not entirely sure where I'd direct you for this issue. Perhaps https://www.w3.org/TR/post-spectre-webdev/?