OR HOW TO MAKE DEVELOPERS EVEN MORE LAZIER
Do not work at a Big 4
One of the 3 OWASP Bangalore chapter leaders
Same Origin Policy
So you own http://banana.com
Code from http://potato.com should not be able to access data from
Browser’s sandbox and Origin protection
XSS to bypass SOP
For the love of XSS
Reflected, Stored, DOM based
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.
I had you at Header
Content Security Policy (CSP) defines the Content-Security-Policy
Whitelist script sources of trusted content
Even if vulnerable to XSS, injected script will not trigger due to header
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'
The default-src is the default
policy for loading content
CSS, fonts, AJAX requests,
Frames and HTML5 Media
Defines valid sources of
Defines valid sources of css
Defines valid sources of
Defines sources to which
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
Defines valid source for
workers and embedded
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)
When script-src or style-src are declared, inline script tags and css
You can specify 'unsafe-inline' to execute inline script but that is
precisely what CSP was designed to prevent!
To enable this explicitly, add 'unsafe-eval' to a script-src directive
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,
Sources: caniuse.com/contentsecuritypolicy & Mozilla
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'
I read the following to make this