1235863 - Security: Contents of in-page Find bar is accessible by web pages

Status: NEW

(Core :: Find Backend, defect)

Description

[Adam Obeng]

Attachment: firefox_find_bar_bug.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36

Steps to reproduce:

Contrary to user expectations, web pages can determine the contents of the in-page find bar (which is triggered by Command-F). This is possible because incremental search scrolls to the first instance of the search string on the page, and the web page knows the scroll location as well as the location of strings on the page. If a user can be tricked into searching a malicious page for a sensitive string, then the page can deduct what text was entered into the search box based on this scrolling behaviour. For example, a user might search for their password on a page pretending to be a list of leaked passwords, thus inadvertently disclosing their password to the web page.



Actual results:

See attached file for proof of concept: summon the find bar with Command-F, type any string (printable ASCII characters only for the demo) into the find bar, and see it displayed on the page.

An implementation of this attack could include every string of a given length on the page, but the attached reproduction is slightly more clever. The page initially contains a purported list of leaked passwords, along with an off-page set of all strings of length 1 (with known and distinct scroll positions). As the user types into the find bar, additional strings are added to the hidden list which contain all characters typed so far plus every possible next character.

Limitations:
- Given that the search is case-insensitive, it cannot be determined what the case of the searched string is.
- If the user types more quickly than the Javascript can create new elements, only part of the searched string is captured.


Expected results:

The page should not be able to determine the contents of the find bar. Actual mitigation strategy TBD.

Comment 1

[Daniel Veditz [:dveditz]]

find text is also selected in page and pages can detect that, too.
https://developer.mozilla.org/en-US/docs/Web/API/Selection

I suspect this is "just the way the web works". In any case we couldn't mitigate it on our own with out breaking standards so it needs a cross-vendor discussion.

Comment 2

[Jeff Walden [:Waldo]]

Selection, find-highlighting, and even find-based scrolling could all be performed in a way hidden from (at the very least untrusted) DOM visibility.  (Perhaps with find-based scrolling notification/observability simply delayed until the find bar was exited.  Although scrolling, at least, seems like something the page possibly *should* be able to observe, because it seems pretty likely to affect what the page displays.)  I'd guess a fair bit of work would have to be done to add non-page-visible versions of all this stuff, probably more work than justifies the relatively minimal gains of not making this observable, at least right now, so attempting to address this is likely pretty low priority.

But as far as doing this to prevent info-leakage goes, I'd bet you're almost certainly out of luck on completely solving that problem.  Anything you might do there, that affects painting, would suffer from the same problems link-visibility painting used to suffer from, before bug 147777 was fixed.  (Note the fix there depends on limitations on visibility-styling that aren't feasible for searched-for content, IMO -- at least not if you're always going to highlight the find-results, which I think users will *really* expect there.)