CSP hash verification of inline content is based upon transformed content
Reported by
skuldw...@gmail.com,
Apr 5 2018
|
|||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Steps to reproduce the problem:
See attached zip for a full PHP/JS/CSS/HTML demonstration.
What is the expected behavior?
The engine should calculate the hash on the original inline style or script (or other inline) content.
What went wrong?
The engine calculates the hash after having transformed newlines and possibly other transformations of the inline content.
Did this work before? N/A
Chrome version: 65.0.3325.181 Channel: stable
OS Version: 10.0
Flash Version:
To avoid the need to download the attachment here is a minimal amount of PHP code to demonstrate the bug workaround.
----code start---
$css = file_get_contents(TEST_CSS);
$css = str_replace("\r\n", "\n", $css); //Bug workaround
$css_sha256 = base64_encode(hash('sha256', $css, true));
----code end---
Without the bug workaround there is a hash mismatch. See the attached zip for a functional example (should work on PHP 5.3 and later).
By default the test will show "Script not working, style is working."
By commenting/un-commenting two lines in the PHP script this will change.
(Issue 487510 and Issue 627966 seems to be related.)
I also tested with Edge (16), and Firefox (59), their behaviour is the same. It is unlikely all three engines happen to have the same bug, so this might be a specification flaw/bug.
I do not know if this constitute a security vulnerability, I do not have the knowledge or means to test for this.
A fix would most likely require a spec correction or clarification, which would impact all vendors. Do note that I have no examined the specs to see what it says regarding transforming the content before hashing it and doing hash comparisons.
All I know is that transforming the content and then doing the hash is the wrong way to do it as this would mean that a web server (or scripts) would need to know how browsers (and each version of a browser) transforms contents before hashing.
Unfortunately fixing this bug would also break a lot of scripts, but not fixing it also makes inline hashing unreliable or excessively difficult to implement if web developers are unaware of this bug.
If the bug is unfixeable then information must be provided in dev console inform the developer how to fix their hashing so it works, currently you only have a hashes that are mysteriously wrong despite all obvious logic.
,
Apr 5 2018
,
Apr 5 2018
Mike-- I had a quick look around the specs and couldn't find if/where they specify what normalization is done for inline blocks before hashing. Thoughts on this?
,
Apr 12 2018
,
Apr 12 2018
Assigning to mkwst@ as he owns the other related issues as well. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by elawrence@chromium.org
, Apr 5 2018