Issue metadata
Sign in to add a comment
|
Unicode characters in title element may cause file overwriting on page save
Reported by
lightlyf...@gmail.com,
Mar 10 2016
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.97 Safari/537.36 Steps to reproduce the problem: 0. WARNING: Verify that your Downloads folder does not contain a file named "_html.html". The following steps will cause any such file to be overwritten. 1. Find or create two HTML documents that use UTF-8 character sequences or Unicode entity names in their <title> elements. The two documents need to be different enough that you can tell them apart. For convenience, a minimal copy-paste: <!doctype html> <html> <head> <title>123 ⚡ abc</title> </head> <body>Test</body> </html> Perhaps the body of the 2nd document could read "Test 2". 2. Load the first of the two documents. This can be via file:// or a Web server. 3. Go to save the page. 4. Observe that the file picker prompts you with a name of "_html". 5. Hit OK/Enter. 5. Optionally verify Downloads/_html.html contains the contents of the first document. 6. Load the second document. 7. Go to save again. 8. Observe that the file picker again prompts you with a file name of "_html". 9. Hit OK/Enter again AND NOTE THAT YOU ARE NOT SHOWN AN OVERWRITE PROMPT. 10. Observe that "_html.html" contains the contents of the second document, and that the old copy was successfully overwritten with no warning. What is the expected behavior? That an appropriate filename is generated for pages containing Unicode character sequences or entity names. What went wrong? Two things: 1. It looks like a Unicode conversion process failed somewhere, and punted out some sort of stub string as a result. (Minor quibble) 2. For whatever reason I'm not being given an overwrite prompt, and Chrome is erasing my data without warning as a result. (Fairly critical issue) Did this work before? No Chrome version: 48.0.2564.97 Channel: stable OS Version: slackware-current Flash Version: Shockwave Flash 20.0 r0 I've reported this as a Security issue because I believe overwriting files in the filesystem without prompting could potentially be unfairly exploited in certain circumstances or situations. In my own case, I tend to hit CTRL+S then hit Enter the moment the file picker appears on the screen... meaning that I've had several instances where "_html.html" has been inadvertently and very unintentionally overwritten. At the very least a frustration. If "Security" is canonically not the correct category (or primary category) for this report I apologize and hope it can be recategorized without too much hassle.
,
Mar 11 2016
I just thought to check something extra, and I think I've found something. Most Linux systems are configured for use with UTF-8 soon after installation, if it's not already set up out-of-the-box. I haven't needed a UTF-8 locale for my work, however, so I never got around to setting it up. It seems that the lack of Unicode is what is triggering this bug. The simplest way to temporarily disable Unicode is to set LC_ALL=C. For example, with bash/zsh: $ LC_ALL=C google-chrome-stable --user-data-dir=/tmp/chrometmp When I start Chrome in this way I experience the issue initially described. Conversely, I just tried starting Chrome with $ LC_ALL=en_US.UTF-8 google-chrome-stable ... and everything worked perfectly: 1. The file save box prompted me with a Unicode filename based on the title of the page, and 2. Trying to save the file twice gave me an overwrite prompt. I would strongly suggest/recommend/request launching Chrome with UTF-8 disabled as described (ie, setting LC_ALL=C) and then retrying the steps in the above report. I also want to say that I have been experiencing this issue for several months, and that I can reproduce it consistently on all of my systems. If the steps above are not sufficient to reproduce it, I'll want to follow up. If screenshots or short videos would be of assistance, I can supply those too.
,
Jun 17 2016
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
,
Oct 1 2016
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
,
Oct 2 2016
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
,
Oct 2 2016
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by infe...@chromium.org
, Mar 10 2016Status: WontFix (was: Unconfirmed)