Issue metadata
Sign in to add a comment
|
Content Security Policy "connect-src" no longer accepts wildcard after last "/"
Reported by
dror.ozg...@gmail.com,
Apr 26 2017
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36 Steps to reproduce the problem: 1. Create a Content Security Policy with "connect-src https://www.foo.com/bar/*" 2. Attempt to go to https://www.foo.com/bar/foobar 3. Receive an error (Violating the Content Security Policy) 4. Change #1 to "connect-src https://www.foo.com/bar/" 5. Works What is the expected behavior? "connect-src https://www.foo.com/bar/*" "connect-src https://www.foo.com/bar/" Should both work What went wrong? Related to: https://chromium.googlesource.com/chromium/src/+/1b6330fb76698a0866f0232fdb3cac7b426f5df1/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/blink-contrib/connect-src-eventsource-allowed.sub.html New commit starting in Chrome v.58 causes "/*" at the end of "connect-src" urls not to work anymore. A Content Security Policy violation is returned instead. Did this work before? Yes Anything before Chrome v.58 Does this work in other browsers? Yes Chrome version: 58.0.3029.81 Channel: stable OS Version: 6.3 Flash Version: Shockwave Flash 25.0 r0 Some other browsers seem to require the "/*" wildcard at the end of the "connect-src" urls to work properly. This is a breaking change.
,
Apr 26 2017
Can you say which browsers/versions seem to require the /* wildcard? I think this is the relevant part of the CSP3 specification: https://www.w3.org/TR/CSP3/#match-url-to-source-expression If expression contains a non-empty path-part, and redirect count is 0, then: Let exact match be false if the final character of expression’s path-part is the U+002F SOLIDUS character (/), and true otherwise. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Let path list be the result of strictly splitting expression’s path-part on the U+002F SOLIDUS character (/). If path list has more items than url’s path, return "Does Not Match". If exact match is true, and path list does not have the same number of items as url’s path, return "Does Not Match". For each expression piece in path list: Let url piece be the next item in url’s path. Percent decode expression piece. Percent decode url piece. If expression piece is not a case-sensitive match for url piece, return "Does Not Match". Return "Matches".
,
Apr 26 2017
Do you have a live test page that we could bisect against? CSPSource::PathMatches doesn't seem to have any relevant changes here in the last few releases.
,
Apr 26 2017
Unfortunately, I do not have a live test page. We found this error on an internal website. I ran some more tests on a subset of browsers and I stand corrected. It seems like both "/*" and "/" work correctly on all of them except for Chrome Version 58+.
,
Apr 26 2017
Testing with this simple markup: <!DOCTYPE html><html><head> <meta http-equiv="Content-Security-Policy" content="connect-src https://example.com/test/*"></head> <body><script>try { var es = new EventSource("http://example.com/test/One");} catch (e) { alert('Failure: \n'+e); }</script></body></html> In Chrome 56/57/58, I get "Failure: SecurityError: Failed to construct 'EventSource': Refused to connect to 'http://example.com/test/One' because it violates the document's Content Security Policy." Testing in Firefox nightly, the console shows: Content Security Policy: The page’s settings blocked the loading of a resource at http://example.com/test/One (“connect-src https://example.com/test/*”).
,
Apr 26 2017
You made a typo:
<body><script>try { var es = new EventSource("http****s****://example.com/test/One");}
Fixing this line reproduces the issue
,
Apr 26 2017
You're right, apologies, there was a typo in the markup above, but the test result is the same. Chrome 56/57/58/59/60 and Firefox nightly all behave the same. The Firefox console message changes to: Content Security Policy: The page’s settings blocked the loading of a resource at http://example.com/test/One (“connect-src http://example.com/test/*”).
,
Apr 26 2017
Try this: "connect-src https://*:*/test/*;" Works correctly in Firefox and Chrome 57. Fails in Chrome 58.
,
Apr 26 2017
Indeed, if the host and port are wildcarded, the path was ignored until the bug was fixed in Chrome 58. Bisect returns https://chromium.googlesource.com/chromium/src/+log/2d1fb814fa87086d59397ecdd5de5fac6c386f81..8b5f579b8bc31056113b37096a19b05b1cee32ee And of these, https://chromium.googlesource.com/chromium/src/+/8a8b6c2b28a210ca37a500d7e95572ce6126994d explains the change. Prior to that fix, if the host part was "*", Chrome would not enforce restrictions on the port or path. That bug was fixed in Chrome 58 and now Chrome is compliant with the spec. Firefox 54 matches the Chrome 57 bug.
,
Apr 26 2017
Gotcha. Thanks for looking into this.
,
Apr 26 2017
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1359964 against Firefox. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Apr 26 2017