Console shows inline style Content-Security-Policy message on empty pages with Content-Length:0
Reported by
mark.rog...@powermapper.com,
Sep 20 2017
|
||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
Steps to reproduce the problem:
1. Find (or construct) an empty page that returns the following headers:
Cache-Control:private
Content-Length:0
Content-Security-Policy:default-src 'self'
Strict-Transport-Security:max-age=15768000
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-XSS-Protection:1; mode=block2.
2. Display in Chrome with console open
3. Console displays: "Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-4Su6mBWzEIFnH4pAGMOuaeBrstwJN4Z3pq/s1Kn4/KQ='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.
What is the expected behavior?
Not displaying a Content-Security-Policy violation on empty pages with no content.
What went wrong?
Misleading CSP message displayed
This may be fairly harmless in isolation, but could point to deeper problems. It's not obvious what chrome is using to calculate the sha256 hash in the message.
Did this work before? N/A
Chrome version: 60.0.3112.113 Channel: stable
OS Version: OS X 10.12.6
Flash Version:
I do have a reproduction URL, but don't want this to become public
,
Sep 20 2017
The string 4Su6mBWzEIFnH4pAGMOuaeBrstwJN4Z3pq/s1Kn4/KQ= is the base64 hash of this CSS: word-wrap: break-word; white-space: pre-wrap; That gets injected by InsertFakePreElement: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/parser/TextDocumentParser.cpp?l=48&rcl=e50f1465ee3c02b15e4c2dabbda010c664b028a1 We could prevent that by ensuring that length is >0 here: void TextDocumentParser::AppendBytes(const char* data, size_t length) { if (!have_inserted_fake_pre_element_ /* NEW TEST */ && (length > 0)) InsertFakePreElement(); ...although it's not clear to me whether this is a worthwhile change to make.
,
Oct 5 2017
,
Oct 5 2017
Notably, the length check proposed in #2 is an incomplete hack, in that we'd still inject the CSS (and still trigger the CSP warning) if the content was a non-empty plaintext document.
,
Oct 9 2017
Another approach would be to add a UA stylesheet for this kind of page. That would be more robust against CSP, and would avoid hard-coding style information in C++. Still, low priority.
,
Nov 10 2017
,
Feb 18 2018
,
Mar 9 2018
I can confirm this bug in Chromium, Version 64.0.3282.119 (Developer Build) built on Debian 9.3, running on Debian 9.3 (64-bit). What bothers me is that loading a plain text page will create a false-positive CSP report (that is how I discovered this). I tested with the latest Firefox as well and there it doesn't happen because no style attribute is inserted in the pre tag. I wonder what the benefit of inserting this is, because the text/plain content is rendered the same in Firefox and Chromium. Aren't contents of pre tags displayed using an acceptable style by default anyway?
,
Jan 5
This issue is a bit annoying and forcing us to add exceptions on the CSP report endpoint to ignore these false-reports. In fact, browser-generated DOMs should never trigger CSP. |
||||
►
Sign in to add a comment |
||||
Comment 1 by elawrence@chromium.org
, Sep 20 2017Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug
Status: Untriaged (was: Unconfirmed)
670 bytes
670 bytes Download