third_party/WebKit/LayoutTests/external/wpt/content-security-policy/script-src/script-src-sri_hash.html - Issue 2784753003: CSP: Enable whitelisting of external JavaScript via hashes

Unified Diff: third_party/WebKit/LayoutTests/external/wpt/content-security-policy/script-src/script-src-sri_hash.html

Issue 2784753003: CSP: Enable whitelisting of external JavaScript via hashes (Closed)

Patch Set: unit_tests++ Created 3 years, 8 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View side-by-side diff with in-line comments

« third_party/WebKit/LayoutTests/external/wpt/content-security-policy/script-src/externalScript.js ('K') | « third_party/WebKit/LayoutTests/external/wpt/content-security-policy/script-src/externalScript.js ('k') | third_party/WebKit/LayoutTests/external/wpt/content-security-policy/script-src/script-src-sri_hash.html.headers » ('j') | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

Index: third_party/WebKit/LayoutTests/external/wpt/content-security-policy/script-src/script-src-sri_hash.html

diff --git a/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/script-src/script-src-sri_hash.html b/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/script-src/script-src-sri_hash.html

new file mode 100644

index 0000000000000000000000000000000000000000..b9541c7c4c55d332b1a31797ea70b4363843a6f9

--- /dev/null

+++ b/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/script-src/script-src-sri_hash.html

@@ -0,0 +1,52 @@

+<!DOCTYPE HTML>

+<html>

+<head>

+ <title>External scripts with matching SRI hash should be allowed.</title>

+ <script src='/resources/testharness.js' nonce='dummy'></script>

+ <script src='/resources/testharnessreport.js' nonce='dummy'></script>

+

+</head>

+<body>

+ <h1>External scripts with matching SRI hash should be allowed.</h1>

+ <div id='log'></div>

+ <script nonce='dummy'>

+ window.addEventListener('securitypolicyviolation', function(e) {

+ assert_unreached('No CSP violation report has fired.');

+ });

+ var externalRan = false;

+ </script>

+ <script src='externalScript.js'

+ integrity="sha256-wIc3KtqOuTFEu6t17sIBuOswgkV406VJvhSk79Gw6U0="></script>

+ <script nonce='dummy'>

+ test(function() {

+ assert_true(externalRan, 'External script ran.');

+ }, 'External script in a script tag with matching SRI hash should run.');

+ </script>

+ <script nonce='dummy'>

+ externalRan = false;

+ async_test(function(t) {

+ var e = document.createElement('script');

+ e.id = 'appendChild';

+ e.src = 'externalScript.js';

+ e.setAttribute(

+ 'integrity',

+ 'sha256-wIc3KtqOuTFEu6t17sIBuOswgkV406VJvhSk79Gw6U0=');

+ e.onload = t.step_func_done(function(e) {

+ assert_true(externalRan, 'External script ran.');

+ });

+ e.onerror = t.unreached_func('Error should not be triggered.');

+ document.body.appendChild(e);

+ }, "Dynamically-inserted external script with matching SRI hash should run.");

+ </script>

Mike West 2017/04/06 10:26:35 While I think this test doesn't actually run into

Marc Treib 2017/04/06 12:26:30 Thanks! With my (lack of) JS skills, it would've p

Thanks! With my (lack of) JS skills, it would've probably taken me hours to piece together something like this. I think it's not really possible to test non-dynamically-inserted scripts this way though, so I've left that part in. I tried rewriting it to the postMessage style too, but there I don't know how to verify that the script *didn't* run, so in the error case that test will time out rather than properly fail :( Any ideas? Or should I just stick with the global variable there? (Now there'd be only the one test that uses it.)

(Not done yet; I'm looking into how to do that exactly.)

Marc Treib 2017/04/06 16:21:41 Done now, PTAL!

On 2017/04/06 12:26:30, Marc Treib wrote: > On 2017/04/06 10:26:35, Mike West (OOO until 4th) wrote: > > While I think this test doesn't actually run into race conditions, it reads as > > pretty racy due to the way you're using the same variable for everything. > Rather > > than setting a property on the global object, how about listening for a > message? > > You could include > > `.../content-security-policy/script-src/simpleSourcedScript.js` (which should > > also be in `.../support/` :( ), add an `id` attribute on the script, and wait > > for a message. Something like: > > > > ``` > > var test_cases = [ > > [ 'matching integrity', 'sha256-abc', true ], > > [ 'multiple matching integrity', 'sha256-abc sha512-abcdef', true ], > > [ 'no integrity', '', false ], > > [ 'mismatched integrity', 'sha256-xyz', false ], > > [ 'multiple mismatched intgerity', 'sha256-xyz sha256-zyx', false ], > > [ 'partially matching integrity', 'sha256-abc sha256-xyz', false ], > > ]; > > > > test(_ => { > > for (item of test_cases) { > > async_test(t => { > > var s = document.createElement('script'); > > s.id = item[0].replace(' ', '-'); > > s.src = './support/simpleSourcedScript.js'; > > s.integrity = item[1]; > > > > if (item[2]) { > > s.onerror = t.unreached_func("Script should load!"); > > window.addEventListener('message', t.step_func(e => { > > if (e.data == s.id) > > t.done(); > > })); > > } else { > > s.onerror = t.step_func_done(); > > window.addEventListener('message', t.step_func(e => { > > if (e.data == s.id) > > assert_unreached("Script should not execute!"); > > })); > > } > > > > document.body.appendChild(s); > > }, item[0]); > > } > > }, "Load all the tests."); > > ``` > > Thanks! With my (lack of) JS skills, it would've probably taken me hours to > piece together something like this. > > I think it's not really possible to test non-dynamically-inserted scripts this > way though, so I've left that part in. I tried rewriting it to the postMessage > style too, but there I don't know how to verify that the script *didn't* run, so > in the error case that test will time out rather than properly fail :( > Any ideas? Or should I just stick with the global variable there? (Now there'd > be only the one test that uses it.) > > > We should also verify that a policy that contains an origin allows scripts > from > > that origin to execute even if the integrity attribute doesn't match the > policy, > > etc. > > (Not done yet; I'm looking into how to do that exactly.)

Done now, PTAL!

+</body>

+</html>