Bypass unsafe-inline mode CSP
Reported by
adm1n...@gmail.com,
Dec 20 2017
|
||||
Issue descriptionChrome Version : 63.0.3239.108 OS Version: OS X 10.11.6 Please provide any additional information below. Attach a screenshot if possible. UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36 exploit url : http://adm1nkyj.kr/csp_bypass_poc.php?a=var%20tmp=%22javascript:var%20a=%27cccc%27;%20alert(a)%22;eval(location.href=tmp);
,
Dec 20 2017
,
Dec 21 2017
there's a typo in the PoC, instead of eval(location.href=tmp) I guess you intended eval("location.href=tmp") which indeed would have been a CSP bypass
,
Dec 21 2017
Thanks for the report! That said, it looks like this is working as intended. `eval()` has no effect in the document (it's blocked, as per the console message), but the assignment to `location.href` is allowed as you've specified `'unsafe-inline'` in the page's policy. We treat assignment to `location.href` as inline script, which is a little convoluted in the spec (it hops from https://html.spec.whatwg.org/#navigating-across-documents:should-navigation-request-of-type-from-source-in-target-be-blocked-by-content-security-policy in HTML's navigation algorithm to step 3 of https://w3c.github.io/webappsec-csp/#should-block-navigation-request in CSP, eventually to https://w3c.github.io/webappsec-csp/#script-src-inline in CSP (see the note in that last algorithm)). I've attempted to clarify that in https://github.com/w3c/webappsec-csp/commit/7a4577c7975c8afdac0c0fc5a5493059b5660742. Closing this out accordingly. Thanks again for poking at Chrome! I appreciate it!
,
Mar 29 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
||||
►
Sign in to add a comment |
||||
Comment 1 by krajshree@chromium.org
, Dec 20 2017