Auto-open downloaded files feature should have a domain whitelist
Reported by
tgu...@gmail.com,
Apr 8 2016
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36 Steps to reproduce the problem: Hi, Like many I have to regularly open downloaded files for work purposes. I just realized we can still opt to auto-open specific files, however it's lacking domain whitelist like many of the other web content options. Even the plugin api used to have a domain whitelist, so for instance when I wanted to open ICA files I would only enable the ICA plugin on the trusted sites I open them from. Now that plugins have been disabled, I can still auto-open the .ica files but I have to enable it globally with no restriction to the web sites than can send me .ica files. In other words, any vulnerability present in the ICA application can be exploited by untrusted sites with no control over it. What is the expected behavior? I think chrome should have the options to auto-open on either current site or all sites, and should default to current site. These site whitelists should be manageable from the preferences page like many other content types. What went wrong? Nothing yet, but enabling auto-open on .ica files makes me vulnerable to any security issue in the ICA client, which doesn't even update itself. Same applies for any other trusted file type. Furthermore, I believe untrusted file types could be enabled on a trusted-site basis (right now they're permanently disabled because of the obvious security risks). Did this work before? N/A Chrome version: 48.0.2564.116 Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 21.0 r0
,
Nov 1 2016
,
Nov 2 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 8 2018
,
Mar 1 2018
,
May 10 2018
While looking at bug 560809 I wondered; should this also apply to protocol handlers? When I use one application/protocol from one site only (ex. Citrix from work intranet) I don't want to expose vulnerabilities in Citrix receiver for the whole world to exploit, and it doesn't mater if the application is launched from a downloaded file or through a protocol handler (probably even worse as an AV software won't be able to catch a known file signature if it's directly downloaded by the vulnerable application!) Right now I don't think it concerns me as protocol handlers doesn't seem to register under Linux, but it would be a problem for Windows users or if protocol handlers gets a fix in Linux. Regards
,
Jul 25
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by kenrb@chromium.org
, Apr 8 2016Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Feature