41

Currently I'm defining Content Security Policy (CSP) as below;

Header set Content-Security-Policy: "default-src 'self' data:; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;"

Considering the CSP definition above, I have a challenge with inline JavaScript as it can be over-ridden at any time.

What is the use of unsafe-inline if it virtually does not protect?

nyedidikeke
  • 6,899
  • 7
  • 44
  • 59
Zernel
  • 1,487
  • 2
  • 15
  • 27

2 Answers2

43

The unsafe-inline option is to be used when moving or rewriting inline code in your current site is not an immediate option but you still want to use CSP to control other aspects (such as object-src, preventing injection of third-party js etc.). You are correct in that unsafe-inline does not offer much security as it allows execution of unsafe in-page scripts and event handlers.

Google's CSP Evaluator is a nifty tool to determine if your policy is strong.

A use case where the unsafe-inline option is used can be found in Google's Web Developer documentation on Content Security Policy:

A wedding-ring discussion forum admin wants to ensure that all resources are only loaded via secure channels, but doesn't really write much code; rewriting large chunks of the third-party forum software that's filled to the brim with inline script and style is beyond his abilities. The following policy would be effective:

Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'

Even though https: is specified in default-src, the script and style directives don't automatically inherit that source. Each directive completely overwrites the default for that specific type of resource.

Community
  • 1
  • 1
Anand Bhat
  • 5,591
  • 26
  • 30
  • 4
    There is a good explanation on Google Developers: https://developers.google.com/web/fundamentals/security/csp/#inline_code_is_considered_harmful – Tobi G. Apr 10 '18 at 20:31
19

Whilst I agree it doesn't protect from much, the classic exploitation of XSS is Browser Exploitation framework, where you have a server on the internet, and when you get a XSS hole you drop in "http://bad.example.com/hook.js"> and now you can control the victim's browser from that server. You tell it to open a hidden window to persist access, and then you have bidirectional comms to their browser.

A CSP with "unsafe-inline" still potentially allows all the same exploitation (assuming the exploits fit into the space you can inject), but it is marginally harder to connect to the outside world to receive instruction, or to exfiltrate data.

That said I think that it is still possible to do most of the same attacks via other channels if you can inject a sophisticated enough client part into a web page.

With my attacker hat on "self unsafe-inline" is harder to exploit than no CSP at all. I expect the attack tools to adapt to weak CSPs, but it will mean a lot of common exploits are immediately off the cards, or harder.

Simon
  • 291
  • 2
  • 3