tl;dr

• From this PR forward, to get full security by Snow you must use CSP so that:
  • unsafe-inline is not allowed!
    • Can be achieved by specifying the script-src directive to anything as long as it doesn't include the phrase unsafe-inline
  • object-src to self is not allowed!
    • Can be achieved by specifying the object-src directive to anything as long as it doesn't include the phrase self

Motivation

• This attempts to address the question raised in Is Snow useless without CSP? #109 (visit it for further info on the topic)
  • Too many vulnerabilities were found in Snow's current approach, making us realize we might not be able to keep up without some help from CSP
• After some research, it seems to come down into 2 specific CSP directives we'd like help from
  • unsafe-inline & unsafe-eval - These 2 are allowing most of the vulns that are too hard to patch, string-JS based attacks are difficult to hermetically defend against.
  • object-src - objects and embeds are also very problematic in their behaviour around contentWindow access and load event emitters
• Both being very reasonable directives to have installed in a web app are a baseline we feel comfortable with requiring for better Snow protection (especially comparing to the amount of work and energy needed to defend Snow otherwise)

In this PR

• Update README to make sure it is clear that starting next version this is the case
• Update demo app to enforce script-src 'self'; object-src 'none';
• Significant changes to the testing infra:
  • Update WDIO to support switching WDIO to puppeteer in runtime
  • Switch to puppeteer for Chrome tests
  • Use puppeteer to register to the securitypolicyviolation event in all realms by default
  • Set the event listener to report to the test that it has passed thanks to sufficient CSP protection
    • example, test running document.body.innerHTML = '<iframe src="javascript:alert()" />' will pass with CSP-script-src-elem detected
  • We're using puppeteer because it's the only way to register this event to all realms automatically BEFORE Snow
  • For tests that use document.write we have to integrate a static check instead of expecting the event listener to fire - this is because document.write kills event listeners on the document by definition, including securitypolicyviolation
  • Because of us being dependent on puppeteer for this, the CSP test only applies to Chrome - for FireFox and Safari we run the same tests as before without CSP applied
  • In order to apply CSP dynamically on demand we moved from example.com as the same origin to a new app https://weizman.github.io/CSPer/ which accepts a query param csp and sets its value as the CSP of the document using the meta tag.

Notes

• In Is Snow useless without CSP? #109 it was discussed to adopt a more flexible approach regarding CSP by allowing all sorts of directive and allowing users to test and experiment with the security of Snow based on a given set of CSP directives to their liking,
  • For example, if facebook.com want to use Snow, provide them with an easy way to take their current CSP and test it with Snow's current tests to see if it cuts it.
• After realizing it really all comes down to just 2 very specific and very legitimate to have CSP directive, we no longer see a need for that.
  • In other words - (1) Use Snow; (2) forbid unsafe-inline and unsafe-eval attacks; (3) forbid object-src by pointing it to either none or to any domain that isn't the same domain as your app
  • As simple as that - a very reasonable request for potential Snow users.