Add a content security policy header to limit arbitrary script execution

[louh]

We can use a Content Security Policy to let browsers help us enforce loading scripts from only approved sources. The preferred way of serving a Content Security Policy is through HTTP headers, but unfortunately we cannot do this with files served through Amazon S3. The CSP meta tag implementation is fairly new in some browsers, so ancient browsers will lack support for it, so this might only be used in conjunction with other guards (TBD).

Theoretically (assuming I did this right) the CSP only permits scripts loaded from Mapzen (any domain, scheme, or port; we assume Mapzen-hosted scripts are safe); the Cloudfront CDN (for Leaflet and Leaflet-hash); and "self". This last one is the experimental one. I'm not sure if CSP is applied for localhost, and if so, whether "self" is permits different ports; I'm more wary of declaring "localhost" in the header specifically, because allowing https://mapzen.com/tangram/view/ to run scripts on localhost seems dangerous to me (but maybe I am being overly cautious?)

[meetar]

Hosted locally, and attempted to open http://localhost:9000/?gist=https://api.github.com/gists/f4aae82a0bd4a0cd985a3e263d5a9057#15/40.7623/-73.9771

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src mapzen.com *.mapzen.com https://cdnjs.cloudflare.com 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-8tXDj/SdNJwafz/cKtaK/MGGQl/fxzE92Gmk3HZfJ1U='), or a nonce ('nonce-...') is required to enable inline execution.

http://localhost:9000/favicon.ico Failed to load resource: the server responded with a status of 404 (Not Found) tangram.min.js:1 Uncaught EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src mapzen.com *.mapzen.com https://cdnjs.cloudflare.com 'self'".

:9000/?>gist=https://api.github.com/gists/f4aae82a0bd4a0cd985a3e263d5a9057#15/40.7623/-73.9771:44 Refused to execute inline event handler because it violates the following Content Security Policy directive: "script-src mapzen.com *.mapzen.com https://cdnjs.cloudflare.com 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution.

[louh]

Ah, okay. I hadn't realized that would come up, but I know why it does. This should be a relatively easy change to make and then we can test it again.

[meetar]

Sounds good – just say the word 💬

On Sun, Aug 21, 2016 at 5:59 PM, Lou Huang notifications@github.com wrote:

Ah, okay. I hadn't realized that would come up, but I know why it does. This should be a relatively easy change to make and then we can test it again.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/tangrams/tangram-frame/pull/18#issuecomment-241284931, or mute the thread https://github.com/notifications/unsubscribe-auth/AAcEwkrXwZa_-BwaA0ZuW5jVcnTqCHAiks5qiMo_gaJpZM4Jmkc9 .

[louh]

@meetar I've made a few changes to deal with the content security policy errors above.

• Removed the inline script that broadcasts hash coordinates to a parent page, if iframed
• Added unsafe-eval to allow for Function constructors in Tangram.js
• Rewrote the script loading process. There is now a generic script injection function, wrapped in a Promise, to control asynchronous loading of libraries.

[meetar]

Repeated the above test – the map now draws (I believe) correctly, though with a new console error:

:9000/?gist=https://api.github.com/gists/f4aae82a0bd4a0cd985a3e263d5a9057#15/40.7623/-73.9771:1 Refused to load the script 'data:application/javascript;base64,KGZ1bmN0aW9uKCkgewoJLy8gaHR0cHM6Ly9kZXZl…07Cgl9OwoJZ2EucmVtb3ZlID0gbm9vcGZuOwoJd2luZG93W2dhTmFtZV0gPSBnYTsKfSkoKTs=' because it violates the following Content Security Policy directive: "script-src mapzen.com *.mapzen.com https://cdnjs.cloudflare.com www.google-analytics.com 'self' 'unsafe-eval'".

[louh]

Any idea where that is coming from?

[meetar]

No! I assumed it was being generated on the fly somewhere, it's not coming from the gist…

[meetar]

closing in favor of #21