extensions: match_patterns not matching FQDN with trailing dot
Reported by
pdk...@gmail.com,
Dec 15 2016
|
|||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Steps to reproduce the problem:
I am only tentatively filing this as a security bug, as the use case is narrow and may not qualify.
{
"name": "Bug",
"manifest_version": 2,
"version": "1.0",
"content_scripts": [
{
"matches": [
"*://www.chromium.org/"
],
"js": ["bug.js"]
}
]
}
Now go to https://www.chromium.org. (with trailing dot).
What is the expected behavior?
The script is injected.
What went wrong?
It isn't.
Did this work before? No
Chrome version: 55.0.2883.87 Channel: stable
OS Version: Ubuntu 14.04
Flash Version:
Now where is the security bug you might wonder. In an "Enterprise" scenario, which has extensions (with actions on specific URLs) force-installed through ExtensionInstallForcelist, a user may bypass those actions by using a FQDN.
,
Dec 19 2016
CC'ing URL/origin folks. The URL Standard has this noted as https://github.com/whatwg/url/issues/132 - https://www.chromium.org. and https://www.chromium.org are different origins (and meaningfully different URLs), so to one interpretation, this is WAI. Alternatively, extensions might take the security view that certificate validation does - that the hostname expressed in the origin of the policy refers to an absolute, fully canonicalized DNS name, and thus treat them as equivalent for purposes of white/blacklisting. In the case of certificates, this is acceptable because the names expressed in a certificate are known to be fully qualified (ergo, implicit .), and one could argue the same applies here to the hostnames expressed in the origin policies of extensions. It's up to the extensions team to know what promises / non-promises are made here, but as explained above, it's certainly consistent and 'known' that these two are distinct origins.
,
Dec 19 2016
I just want to give an additional related data point for the mentioned "Enterprise" scenario, namely policy URLBlacklist, as to whether this should be expected or not. https://www.chromium.org/administrators/policy-list-3#URLBlacklist "www.chromium.org/" - Blocks both. "www.chromium.org./" - Blocks neither! (Might be a separate bug.) ".www.chromium.org/" - Blocks both. This is mentioned in the docs as an "exact match", which it isn't for FQDNs. (Perhaps a separate bug too.) > ".www.example.com" only matches exactly "www.example.com". https://www.chromium.org/administrators/url-blacklist-filter-format
,
Dec 19 2016
Tentatively marking this as low severity, but I don't have a strong opinion on this (as the current security sheriff).
,
Dec 19 2016
,
Dec 19 2016
The original issue is fixed in M56 by revision 453ab88927c99dc1564b66aaa9003b870f886201 (for crbug.com/606321 ). More generally, we know that there are some security issues here, and have tracked some specifically (issue 664313, issue 664285) and generally (issue 664534). For extensions code, I think we can mark this as a dupe. Should we narrow this to the enterprise case?
,
Dec 20 2016
Yes, it's a duplicate. Sorry, I should've checked a Chrome version more recent than stable.
,
Dec 21 2016
The original issue in #0 is a duplicate, but the enterprise case is still interesting, and I'd still like input on it. :) We might have some holes to patch. atwilson@, I think you've done enterprise work before, or maybe know someone who has? Who's the right point of contact for #3? (assigning to you for triage; feel free to punt along.)
,
Feb 14 2017
Thiemo/Igor, can you guys make sure the documentation at https://www.chromium.org/administrators/url-blacklist-filter-format correctly reflects the actual behavior in the face of leading/trailing dots?
,
Jul 17 2017
,
Jul 17 2017
,
Jul 17 2017
Re #3: I've checked the examples given there, and have different results, specifically any of the following patterns when included in blacklist www.chromium.org www.chromium.org/ www.chromium.org./ .www.chromium.org/ .www.chromium.org blocks both http://www.chromium.org http://www.chromium.org. Also https://www.chromium.org or ftp://www.chromium.org are blocked, but not http://chromium.org Now technically the trailing dot makes it for a different URL, but many URLs have both addresses route to the same server, like google.com(.) and youtube.com(.). I think in this case it makes sense to update the documentation to include this behavior rather than changing the code as it might affect admins that have blacklisted youtube.com for example. pdknsk@ could you please check again with the latest Chrome version and give me the details on how you tested if you still have some functionality different from what I've checked? Thanks.
,
Jul 19 2017
I just tried M60 and can confirm the behaviour changed to what you describe.
,
Jul 19 2017
Thanks, I've updated the documentation to clarify the suffix in the host. As I understand this can be marked as fixed now.
,
Jul 19 2017
,
Oct 25 2017
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
,
Jan 2 2018
,
Jan 6 2018
I'm afraid the VRP panel declined to reward for this bug. Many thanks for the report! |
|||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||
Comment 1 by elawrence@chromium.org
, Dec 15 2016Labels: OS-Chrome OS-Mac OS-Windows
Summary: extensions: match_patterns not matching FQDN with trailing dot (was: extensions: match_patterns not matching FQDN)