Site isolation

[Sjord]

Sites can set headers to ensure that they never share a browser process with another site. This prevents an attacker from loading sensitive data into memory and then reading it with a side-channel attack or browser exploit.

I propose to add a set of requirements that have the effect of enforcing site isolation, such as requiring Cross-Orgin-Resource-Policy (CORP), Cross-Origin-Opener-Policy (COOP), Cross-Origin-Embedder-Policy (COEP) response headers.

• Post-Spectre Web Development
• Site Isolation
• tabnabbing · Issue #1602 · OWASP/ASVS

[elarlang]

It feels very much like a follow-up for issue #1602.

We discussed and closed it, #1602 (comment). If you think that provided arguments are not valid and we need to have new requirements, then I would like to see opposite arguments.

[randomstuff]

So I've started looking at this topic and I'm currently deep down the XS leaks rabbit hole… 😨

[tghosth]

I's be interested to see strong arguments for this but I am going to mark it as nonblocker for now

[elarlang]

ping @Sjord

[randomstuff]

but I am going to mark it as nonblocker for now

Would it make sense to include of list of topics not (yet) covered somewhere in the document?

"Hey, we didn't say anything on this topic yet so you're on your own for that but that does not mean it's not relevant."

[elarlang]

but I am going to mark it as nonblocker for now

Would it make sense to include of list of topics not (yet) covered somewhere in the document?

"Hey, we didn't say anything on this topic yet so you're on your own for that but that does not mean it's not relevant."

My personal feeling is that it is not a widespread problem to have a separate solution for that. We can reference to opened or closed issues if it is already discussed somewhere, this is the case also here.

[Sjord]

If you think that provided arguments are not valid and we need to have new requirements, then I would like to see opposite arguments.

I pretty much agree with that comment by @ryarmst you linked. That issue was about tabnabbing though, not about site isolation or XS-leaks in general.

[elarlang]

Do you have more precise attack scenario(s) in mind? Then I could validate, is it already covered by requirements or not.

Related requirements most likely are located in V50.

[ryarmst]

I think if there is a practical attack scenario, it can probably found in the XS leak content that @randomstuff is looking into, but it is indeed a rabbit hole.

[elarlang]

Do you have more precise attack scenario(s) in mind? Then I could validate, is it already covered by requirements or not.

Related requirements most likely are located in V50.

ping @Sjord

[Sjord]

I think the sites I linked do a good job of explaining the attack scenarios:

1. the attacker's site loads some sensitive content from the victim's site.
2. they read this with a browser exploit or side channel attack.

The first step can often be prevented with same-site cookies. With lax samesite, it is still possible to perform authenticated cross-site GET requests, which is often sufficient to request sensitive information. With strict samesite cookies this is not possible. Also, there can be cases where same-site cookies don't help:

• the attacker has control over a domain that is same-site but not same-origin, or
• the sensitive resource is not protected by cookies, but by basic auth or firewall.

[elarlang]

I asked:

Do you have more precise attack scenario(s) in mind? Then I could validate, is it already covered by requirements or not.

Related requirements most likely are located in V50.

And I still have the same question - what scenario is not covered by requirement below?

• V50.3.6 Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header field is validated against an allowlist of trusted origins. When "Access-Control-Allow-Origin: *" needs to be used, verify that the responses do not include any sensitive information.
• V50.4.3 Verify that the Origin header field is validated against a defined list of allowed origins to match the desired Cross-Origin Resource Sharing (CORS) policy.
• V50.5.1 Verify that JSONP functionality is not enabled anywhere across the application to avoid Cross-Site Script Inclusion (XSSI) attacks.
• V50.5.2 Verify that data requiring authorization is not included in script resource responses, like JavaScript files, to prevent Cross-Site Script Inclusion (XSSI) attacks.

they read this with a browser exploit or side channel attack.

browser exploit I consider to be out of scope for ASVS.