SlideShare a Scribd company logo

Csp july2015

•Download as PPTX, PDF•
•
n|u - The Open Security Community
n|u - The Open Security Community

This document discusses Content Security Policy (CSP), which defines an HTTP header to whitelist approved sources of content like scripts to prevent XSS attacks. It describes how CSP directives like script-src restrict where code can be loaded from to enhance security. The speaker then demonstrates how to construct CSP policies and explains options like 'unsafe-inline' that disable the protection CSP is meant to provide. In the end, resources on CSP that informed the presentation are listed.

Related slideshows

XSS - Presented at EPiServer Meetup in Oslo 25th May 2011
XSS - Presented at EPiServer Meetup in Oslo 25th May 2011XSS - Presented at EPiServer Meetup in Oslo 25th May 2011
XSS - Presented at EPiServer Meetup in Oslo 25th May 2011
 
Exploiting publically exposed Version Control System
Exploiting publically exposed Version Control SystemExploiting publically exposed Version Control System
Exploiting publically exposed Version Control System
 
Ruby and Framework Security
Ruby and Framework SecurityRuby and Framework Security
Ruby and Framework Security
 
1 of 19
Content Security Policy OR HOW TO MAKE DEVELOPERS EVEN MORE LAZIER RIYAZ WALIKAR
whoami  Security evangelist  Do not work at a Big 4  One of the 3 OWASP Bangalore chapter leaders  Extremely talkative
Same Origin Policy  So you own http://banana.com  Code from http://potato.com should not be able to access data from http://banana.com  Browser’s sandbox and Origin protection  XSS to bypass SOP
For the love of XSS  Reflected, Stored, DOM based
Csp july2015
Content Security Policy
The core issue exploited by XSS attacks is the browser’s inability to distinguish between script that’s intended to be part of your application, and script that’s been maliciously injected by a third-party. http://www.html5rocks.com/en/tutorials/security/content-security-policy/
I had you at Header  Content Security Policy (CSP) defines the Content-Security-Policy HTTP header  Whitelist script sources of trusted content  Even if vulnerable to XSS, injected script will not trigger due to header definition
Building the policy  So you trust scripts only from http://banana.com and your own domain (non inline) Content-Security-Policy: script-src 'self' http://banana.com  So you want to load images only from http://potato.com and flash content from your own domain. Also, absolutely no scripts. Content-Security-Policy: script-src 'none'; img-src http://potato.com; object-src 'self'
CSP Directives  default-src  script-src  style-src  img-src  connect-src  font-src  object-src  media-src  child-src  sandbox  report-uri The default-src is the default policy for loading content such as JavaScript, Images, CSS, fonts, AJAX requests, Frames and HTML5 Media Defines valid sources of JavaScript Defines valid sources of css (stylesheets) Defines valid sources of images Defines sources to which XMLHTTPRequest (AJAX), WebSocket or EventSource can fetch data from Defines valid sources of fontsDefines valid sources of plugins (for example: flash, embed tag, applet etc.) Defines valid source of audio and video Defines valid source for workers and embedded frame contents. frame-src is deprecated. child-src should be used. More about this laterInstructs the browser to POST a reports of policy failures to a specified URI.
CSP Source Declarations Source Value Meaning * Wildcard, allows all origins. 'self' Allow same origin (current origin). 'none' Don't allow any resources of this directive to load. domain.example.com Allow a domain (explicit declaration) *.example.com Allow all subdomains on a domain. Exclude TLD. https://example.com Exact match including protocol https: Load from any domain but https data: Allow data uri (eg: Base64 encoded image)
unsafe-inline  When script-src or style-src are declared, inline script tags and css are disabled  You can specify 'unsafe-inline' to execute inline script but that is precisely what CSP was designed to prevent!
unsafe-eval  CSP disables the JavaScript function eval() by design  To enable this explicitly, add 'unsafe-eval' to a script-src directive  Not advised!
sandbox  If present, browser treats the page as if it loaded inside an iframe with a sandbox attribute  The browser severely restricts the page’s functionality, disabling JS, form submissions, plugins and objects  You can keep the sandbox value empty to keep all restrictions in place, or add values: allow-forms allow-same-origin allow-scripts, and allow-top-navigation
DEMO TIME
Sources: caniuse.com/contentsecuritypolicy & Mozilla
CSP 2.0!  Several new enhancements including support for inline scripts in combination with a cryptographic nonce or hash sharing of the script itself Content-Security-Policy: script-src 'nonce-AY778asa229b2DEADBEEF' http://www.w3.org/TR/CSP2/
I read the following to make this presentation  http://www.w3.org/TR/2012/CR-CSP-20121115/  http://www.html5rocks.com/en/tutorials/security/content-security- policy/  http://content-security-policy.com/  http://caniuse.com/#feat=contentsecuritypolicy  https://html.spec.whatwg.org/multipage/browsers.html#sandboxin g-flag-set  http://www.w3.org/TR/CSP2/
Riyaz Walikar http://www.riyazwalikar.com @riyazwalikar @wincmdfu

More Related Content

Csp july2015

  • 1. Content Security Policy OR HOW TO MAKE DEVELOPERS EVEN MORE LAZIER RIYAZ WALIKAR
  • 2. whoami  Security evangelist  Do not work at a Big 4  One of the 3 OWASP Bangalore chapter leaders  Extremely talkative
  • 3. Same Origin Policy  So you own http://banana.com  Code from http://potato.com should not be able to access data from http://banana.com  Browser’s sandbox and Origin protection  XSS to bypass SOP
  • 4. For the love of XSS  Reflected, Stored, DOM based
  • 7. The core issue exploited by XSS attacks is the browser’s inability to distinguish between script that’s intended to be part of your application, and script that’s been maliciously injected by a third-party. http://www.html5rocks.com/en/tutorials/security/content-security-policy/
  • 8. I had you at Header  Content Security Policy (CSP) defines the Content-Security-Policy HTTP header  Whitelist script sources of trusted content  Even if vulnerable to XSS, injected script will not trigger due to header definition
  • 9. Building the policy  So you trust scripts only from http://banana.com and your own domain (non inline) Content-Security-Policy: script-src 'self' http://banana.com  So you want to load images only from http://potato.com and flash content from your own domain. Also, absolutely no scripts. Content-Security-Policy: script-src 'none'; img-src http://potato.com; object-src 'self'
  • 10. CSP Directives  default-src  script-src  style-src  img-src  connect-src  font-src  object-src  media-src  child-src  sandbox  report-uri The default-src is the default policy for loading content such as JavaScript, Images, CSS, fonts, AJAX requests, Frames and HTML5 Media Defines valid sources of JavaScript Defines valid sources of css (stylesheets) Defines valid sources of images Defines sources to which XMLHTTPRequest (AJAX), WebSocket or EventSource can fetch data from Defines valid sources of fontsDefines valid sources of plugins (for example: flash, embed tag, applet etc.) Defines valid source of audio and video Defines valid source for workers and embedded frame contents. frame-src is deprecated. child-src should be used. More about this laterInstructs the browser to POST a reports of policy failures to a specified URI.
  • 11. CSP Source Declarations Source Value Meaning * Wildcard, allows all origins. 'self' Allow same origin (current origin). 'none' Don't allow any resources of this directive to load. domain.example.com Allow a domain (explicit declaration) *.example.com Allow all subdomains on a domain. Exclude TLD. https://example.com Exact match including protocol https: Load from any domain but https data: Allow data uri (eg: Base64 encoded image)
  • 12. unsafe-inline  When script-src or style-src are declared, inline script tags and css are disabled  You can specify 'unsafe-inline' to execute inline script but that is precisely what CSP was designed to prevent!
  • 13. unsafe-eval  CSP disables the JavaScript function eval() by design  To enable this explicitly, add 'unsafe-eval' to a script-src directive  Not advised!
  • 14. sandbox  If present, browser treats the page as if it loaded inside an iframe with a sandbox attribute  The browser severely restricts the page’s functionality, disabling JS, form submissions, plugins and objects  You can keep the sandbox value empty to keep all restrictions in place, or add values: allow-forms allow-same-origin allow-scripts, and allow-top-navigation
  • 17. CSP 2.0!  Several new enhancements including support for inline scripts in combination with a cryptographic nonce or hash sharing of the script itself Content-Security-Policy: script-src 'nonce-AY778asa229b2DEADBEEF' http://www.w3.org/TR/CSP2/
  • 18. I read the following to make this presentation  http://www.w3.org/TR/2012/CR-CSP-20121115/  http://www.html5rocks.com/en/tutorials/security/content-security- policy/  http://content-security-policy.com/  http://caniuse.com/#feat=contentsecuritypolicy  https://html.spec.whatwg.org/multipage/browsers.html#sandboxin g-flag-set  http://www.w3.org/TR/CSP2/