Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AppSec California 2017 CSP: The Good, the Bad and the Ugly

180 views

Published on

Content Security Policy, CSP, CSP2, Web Application Security

Published in: Internet
  • Be the first to comment

AppSec California 2017 CSP: The Good, the Bad and the Ugly

  1. 1. Content Security Policy: The Good, the Bad and the Ugly Ilya Nesterov, Shape Security
  2. 2. Agenda
  3. 3. What does CSP stand for? Content Security Policy (CSP) - a mechanism that web applications can use to mitigate a broad class of content injection vulnerabilities, such as XSS.
  4. 4. CSP Level 1
  5. 5. CSP Level 1 • Policy delivery via HTTP header only • Multiple CSP headers allowed • Sandbox directive is optional • script-src governs workers
  6. 6. CSP Level 2
  7. 7. New in CSP Level 2 • Policy delivery via <meta> • New directives: child-src, form-action, frame- ancestors, base-uri, plugin-types • Source-expression supports hash and nonce • host-source can use path for matching • SecurityPolicyViolationEvent • Extended violation report • child-src governs workers
  8. 8. CSP Level 3 (draft 13 Sep 2016)
  9. 9. New in CSP Level 3 • New directives: manifest-src, worker-src, report-to, block-mixed-content, upgrade- insecure-requests, require-sri-for • frame-src undeprecated • New in source-expression: 'strict-dynamic' • Changes in url and source-expression matching algorithms • Additional changes to violation reports
  10. 10. Browser compatibility CSP level 1
  11. 11. Browser compatibility CSP level 2
  12. 12. CSP directives compatibility matrix
  13. 13. I want CSP, what should I do? Where not to use CSP: –Static website with public information –Large application with many XSS Understand what triggers a CSP violation
  14. 14. CSP violations • object-src and default-src is not defined • usage of unsafe-inline • path restriction and redirect
  15. 15. CSP violations due to SOP • CSP only on some pages
  16. 16. Strict CSP • Define default-src or script-src • Prevent fetching and executing plugin resources embedded: object-src ‘none’ • Use nonce/hash to whitelist inline scripts • Do not use 'unsafe-eval' unless you use eval() • Tighten your source expression
  17. 17. CSP adoption steps • Refactor, refactor, refactor –nonce for inlined scripts –inline event handlers and javascript: –document.write -> document.createElement –strict-dynamic • Delivery mechanism (header vs <meta>) • Start with report-only • Test, test, test • Analyze violation reports • Make you policy backward compatible
  18. 18. CSP Backward compatibility object-src 'none'; script-src 'nonce-{random}' 'unsafe-inline' 'strict- dynamic' https: ; • CSP3 browser view: object-src 'none'; script-src 'nonce-{random}' 'strict-dynamic' ; • CSP2 browser view: object-src 'none'; script-src 'nonce-{random}' https: ; • CSP1 browser view object-src 'none'; script-src 'unsafe-inline' https: ;
  19. 19. Deployment into production • Prepare CSP collector • Start with report only • A/B testing • Continuously analyse CSP reports
  20. 20. CSP reports are not easy • How to: –identify different versions –report only vs enforced –filter noise –filter what is important –find if someone is trying to break in • There is no one simple solution
  21. 21. Alexa top 1 000 000 data
  22. 22. CSP policies closer look
  23. 23. CSP policies closer look (continued)
  24. 24. Alexa top 1 000 000 data XSS protection vs Strict XSS protection policies
  25. 25. Alexa top 1 000 000 data Common errors found by Shape Security salvation library
  26. 26. Resources: • https://cspvalidator.org • https://csp-evaluator.withgoogle.com/ • https://csp.withgoogle.com • https://github.com/shapesecurity/salvation • https://report-uri.io • https://www.w3.org/TR/CSP3/ • https://www.w3.org/2011/webappsec/ • public-webappsec@w3.org
  27. 27. Questions? mailto: ilya.nesterov@gmail.com mailto: ilya@shapesecurity.com twitter: @ilya_online

×