6

I'm reading Chrome extension document "Content Security Policy (CSP)". It says:

Inline JavaScript, as well as dangerous string-to-JavaScript methods like eval, will not be executed. This restriction bans both inline blocks and inline event handlers (e.g. <button onclick="...">).

...

There is no mechanism for relaxing the restriction against executing inline JavaScript. In particular, setting a script policy that includes unsafe-inline will have no effect. This is intentional.

Why are inline <script> blocks unsafe? Can anyone explain it? It will be better if you can give examples.

Thank you.

weilou
  • 4,419
  • 10
  • 43
  • 56

1 Answers1

9

As the page says:

The first restriction wipes out a huge class of cross-site scripting attacks by making it impossible for you to accidentally execute script provided by a malicious third-party.

Basically any script you load needs to be in a separate file accessible locally to the extension. This prevents you from loading 3rd party scripts that get injected into your page or including them like:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>

An example of this is if you have a form a user can fill out. The user can enter a script tag with some JS in it. Let's say it's like a discussion forum. I go in and make a topic but it has some hidden JS in it. Let's also assume you don't clean that out before posting it. Now my post has JS that will execute every time somebody views it. This prevents that script from being executed.

sachleen
  • 30,730
  • 8
  • 78
  • 73
  • 1
    I'm trying to understand how these inline ` – weilou Aug 11 '12 at 16:06
  • 1
    In my case, I transform any text entered in a form or in the URL into a safe form before rendering it. According to this answer, my websites are safe. So why must the browsers protect me when I am already safe? Why can't I just tell CSP that my inline scripts are okay and have the browsers honor it? – David Spector Aug 31 '18 at 21:11
  • @DavidSpector you can tell the browser that your inline script should be executed in multiple ways, provided you control the page's content, or the headers with which the page will be served. You need to either set a header or include an equivalent meta element on the page. The header must be named content-security-policy and assign one of the policies that mark inline scripts as allowed for execution to script-src: 'unsafe-inline', 'sha256-....' or 'nonce-...' - more info here: https://content-security-policy.com/, – user625488 Jan 28 '21 at 18:02
  • @user625488 I think you are answering the question "how do I mark inline scripts as executable", not the question I asked, which was, "Why must the browsers protect me when I am already safe?". In other words, since inline css and scripts are the same as included (external) css and scripts, why are only inline css and scripts considered unsafe by standards people and CSP? Any inline code that uses injection can be preprocessed to eliminate attempts at injection. No? – David Spector Jan 29 '21 at 20:58
  • The browser doesn't protect the site/page publisher, if protects the browser user. Suppose the ISP or the hoster of your web site, or an advertiser for whom you publish ads, injects script into your page. If that script is in a separate file, the implicit same origin policy makes sure you're safe - the advertiser can't download script that you, as the page owner, haven't authorized or published yourself. If it's inline, there's no way of telling. Since the page server cannot sanitize ads loaded from ad servers in advance, the browser cannot trust inline script. – user625488 Jan 31 '21 at 08:52
  • "In my case, I transform any text entered in a form or in the URL into a safe form before rendering it." — Traditional escaping / filtering of content before inserting it into a page is good, generally effective, and something you should do. A CSP adds an extra layer of protection if that escaping / filtering fails for some reason (such as not handling an obscure edge case (there are a [surprising number of vectors](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html)) or just not be applied in one particular place. – Quentin Jul 24 '23 at 08:28