New issue
Advanced search Search tips

Issue 693924 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Feb 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Security: Keywords entered into CTRL+F can be sniffed.

Reported by benhcg...@gmail.com, Feb 18 2017

Issue description

VULNERABILITY DETAILS
By designing a special webpage which contains a list of invisible dictionary or brute force keywords behind the page content, a malicious page can determine the text already within the "find" box from previous "finds" using a script to determine where the user is on the webpage. The malicious agent can also find out what is being typed into the find box. By calculating the position of the user using javascript (I have not included this in the demo) on the webpage the text in the find box can be determined.

This is similar to clickjacking however the site visited is the malicious one. Rather than hiding another site behind the content the dictionary is hidden and triggered when the "find on page" option is used in Chrome.

This could be placed on normal news websites to sniff for data or could be part of a larger phishing attack exploiting the user's trust in the fact that the content within the find textbox cannot be determined by the visited site.

VERSION
Chrome Version: Current Stable Release
Operating System: Mac OS

REPRODUCTION CASE
SHOWS KEYWORDS TO BE HIDDEN
http://nettleteabenefits.com/trackfindpage.php

KEYWORDS ARE NOW HIDDEN on this blank page and invisble when searched
http://nettleteabenefits.com/trackfindpagewhite.php

view the source to further demonstrate this.

Thanks!
 

Comment 1 by benhcg...@gmail.com, Feb 18 2017

Note: the text is not fully invisible once searched for using the find option in my demo though it could be made like this through positioning and overlaying with other content.

Comment 2 by raymes@chromium.org, Feb 19 2017

Components: Privacy
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam OS-All Pri-2 Type-Bug
Owner: msramek@chromium.org
Status: Assigned (was: Unconfirmed)
Hi, thanks for the report. It seems to me that the only way a website could potentially find out what text was in the find box is if the user actively searched for that text, e.g. by hitting "enter" in the find box. A find won't automatically happen when a user brings up the find box on a new page and so the website can't automatically know what existing text was in the find box.

I don't think this is a security issue but it could be a privacy issue. However there are so many mitigating factors:
-The user has to actively search for the text on the page
-Even after the user has actively searched for it, the website can't know exactly what is being searched for because many words form the part of other words
-The website must construct its page in a very particular way in order to try to determine this data. Other content the website places on the page is going to interfere with them trying to determine this data.

Assigning to msramek to triage from a privacy perspective.
Status: WontFix (was: Assigned)
Thanks for the report. I agree with raymes@'s assessment. I would also add that the keyword in the search field is pre-selected, so pressing any character key will overwrite it completely and start a new search.

That said, I would not be opposed to clearing the search field on a per-website basis either, but at this point I think it's more of a UX question. Since the current treatment allows the user to both search for the previous text and start a new search easily, I assume that this is why it was chosen.

Note also that the search field text is not carried over from Incognito to the regular mode.

Sign in to add a comment