You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
String-based attacks made things really complicated for Snow, these are the vectors Snow 2.0.1 loses to when CSP is turned off:
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 realmtestdiv.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:)
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 :
The text was updated successfully, but these errors were encountered:
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
CSP
.1
, tests that rely on specific directives of CSP are skipped.unsafe-inline
andobject-src
.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.String-based attacks made things really complicated for Snow, these are the vectors Snow 2.0.1 loses to when CSP is turned off:
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: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:)
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 :The text was updated successfully, but these errors were encountered: