Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] How can we steer away from relying on CSP for security? #137

Closed
weizman opened this issue Sep 7, 2023 · 0 comments
Closed

[WIP] How can we steer away from relying on CSP for security? #137

weizman opened this issue Sep 7, 2023 · 0 comments

Comments

@weizman
Copy link
Member

weizman commented Sep 7, 2023

Again with CSP?!

A surprising take, considering #133, I know, so let me make things clear:

I'm not saying "hi, let's stop using CSP and make Snow unsafe again on purpose", I'm saying "can we block uncommonly used patterns to achieve the same level of security in Snow without relying on CSP?"

For that, there are some questions to be answered:

List of specific concerns Snow relies on CSP for

  • Throughout the tests infra you can see we refer to CSP testing via an env var called CSP.
    • When it's set to 1, tests that rely on specific directives of CSP are skipped.
      • Currently we address 2 directives: unsafe-inline and object-src.
    • When it's set to 0, those tests won't skip and therefore will fail, because atm Snow counts on CSP to be there and therefore doesn't even try.
  • Therefore, we can go through those skipped tests and learn from them which patterns Snow gives up on.
    • IMPORTANT NOTE: this is a list of things Snow gives up on TODAY. Before that, when we tried to handle these scenarios, new concerns had surfaced (discussed below).

unsafe-inlines (test @ https://lavamoat.github.io/snow/demo/?disable_csp)

String-based attacks made things really complicated for Snow, these are the vectors Snow 2.0.1 loses to when CSP is turned off:

  1. javascript: URIs - these allow some wacky scenarios which make things rather complicated for Snow, for example I can't think of good protection against TAGarxenix great finds:
// https://github.com/LavaMoat/snow/issues/80
// leverages the ability to establish a new tab with sync power to harm the opening realm
(function(){
    testdiv.innerHTML = `<form id="pwn" method="GET" target="lolpwnd" action="javascript:opener.bypass([window])">`;
    document.querySelector("#pwn").submit();
}());
(function(){
// https://github.com/LavaMoat/snow/issues/80
// leverages the ability to establish a new tab with sync power to harm the opening realm
    testdiv.innerHTML = `<a id="pwn" target="lolpwnd" href="javascript:opener.bypass([window])">`;
    document.querySelector("#pwn").click();
}());

What makes these two complicated is that fact they can be formed via HTML, which means Snow must deal with all sort of new DOM APIs in order to win this (for example, the need to start hooking into DOM nodes attribute setting :kill-me:)

  1. srcdoc attribute - Also a lot of pain, srcdoc introduces a lot of problems, mainly around its ability to introduce nesting documents which can be used to harm Snow, some great former examples by TAGmmndaniel :
@weizman weizman closed this as completed Sep 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant