1366184 - Search box (CMD+F/CTRL+F) data leak

Status: RESOLVED WONTFIX

(Core :: Find Backend, enhancement)

Description

[kolasinski.bartosz]

This exploit allow to detect what user type to search box in web browsers.
It’s use window scroll to searched element, when user type text.

For example it’s can be used for stealing passwords, credit cards data, social security number – „hey, we have your data, just search it”.

Firefox 53.0.2 (64-bit)
macOS 10.12.4 (16E195)

Comment 1

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

kolasinski.bartosz: thanks for the report, would you mind sharing what website this was for and provide perhaps a proof of concept on how the stealing of data would work?

Comment 2

[kolasinski.bartosz]

(In reply to Jonathan Claudius [:claudijd] (use NEEDINFO) from comment #1)
> kolasinski.bartosz: thanks for the report, would you mind sharing what
> website this was for and provide perhaps a proof of concept on how the
> stealing of data would work?

Stealing data should work with strong social engineering support. It's can be part of site with info: "we have 5 billion facebook passwords, check if yours too". User cannot read everything, so type CTRL+F, search own password, and finding it every time, becaouse script added it on the fly. Attacker should send this data to own server using XHR.

I think not-searchable data like fake passwords list should be presented using images.

Comment 3

[April King [:April]]

It sounds like Kolasinski is maybe trying to say that a website can see what a user is typing into their search box if they bind a JavaScript onkeypress() event to it?  Is my understanding correct?

Comment 4

[kolasinski.bartosz]

(In reply to April King [:April] from comment #3)
> It sounds like Kolasinski is maybe trying to say that a website can see what
> a user is typing into their search box if they bind a JavaScript
> onkeypress() event to it?  Is my understanding correct?

Website can read what user type in browser search box, but it imposible to realise using onkeypress().
I am not sure I added my html/js script correctly, so I send it one more time using Dropbox: https://www.dropbox.com/s/ze0gq4wwnc16yum/searchbug.html?dl=0
Please: download it, open in Firefox, and search anything you want using search box.

Comment 5

[April King [:April]]

Attachment: searchbug.html

Submitter's proof of concept

Comment 6

[April King [:April]]

Okay, I have verified the behavior, but I don't know if it's an unknown bug, a duplicate, or something we already know about.

In any of those cases, this would be a client bug, not a website bug.  So I'm going to move it over and somebody on the client side can triage it.  :)

Comment 7

[kolasinski.bartosz]

(In reply to April King [:April] from comment #6)
> Okay, I have verified the behavior, but I don't know if it's an unknown bug,
> a duplicate, or something we already know about.
> 
> In any of those cases, this would be a client bug, not a website bug.  So
> I'm going to move it over and somebody on the client side can triage it.  :)

I unterstood, thank you

Comment 8

[:Gijs (he/him)]

I don't see any reasonable way to resolve this, so I'm tempted to mark sec-low, open up, and mark WONTFIX. I also have a nagging feeling we have this on file already, but I can't find it. Dan/Al, thoughts?

Comment 9

[kolasinski.bartosz]

(In reply to :Gijs from comment #8)
> I don't see any reasonable way to resolve this, so I'm tempted to mark
> sec-low, open up, and mark WONTFIX. I also have a nagging feeling we have
> this on file already, but I can't find it. Dan/Al, thoughts?

In my opinion you should freeze window scroll position feedback for javascript, when user auto-scrolled using search bar.

Comment 10

[:Gijs (he/him)]

(In reply to kolasinski.bartosz from comment #9)
> (In reply to :Gijs from comment #8)
> > I don't see any reasonable way to resolve this, so I'm tempted to mark
> > sec-low, open up, and mark WONTFIX. I also have a nagging feeling we have
> > this on file already, but I can't find it. Dan/Al, thoughts?
> 
> In my opinion you should freeze window scroll position feedback for
> javascript, when user auto-scrolled using search bar.

This doesn't work for several reasons:
- there is no extant way to distinguish the cause of the scroll from any other reason to scroll the page
- even if there was, we'd then need to selectively hide scroll events
- even if we did that, you could still poll scrollTop or bounding rects of elements off a timeout and detect that the page had scrolled - scroll events aren't the only thing that show the scroll position.
- even if we were somehow able to completely isolate the webpage from the fact that the user was now looking at a different part of the page... that would then likely break 'benign' webpages that depend on the scroll position for functionality (e.g. loading more content, or changing the display properties of various elements, or updating the size of other elements for parallax-style scrolling, or...).

Comment 11

[kolasinski.bartosz]

(In reply to :Gijs from comment #10)
> (In reply to kolasinski.bartosz from comment #9)
> > (In reply to :Gijs from comment #8)
> > > I don't see any reasonable way to resolve this, so I'm tempted to mark
> > > sec-low, open up, and mark WONTFIX. I also have a nagging feeling we have
> > > this on file already, but I can't find it. Dan/Al, thoughts?
> > 
> > In my opinion you should freeze window scroll position feedback for
> > javascript, when user auto-scrolled using search bar.
> 
> This doesn't work for several reasons:
> - there is no extant way to distinguish the cause of the scroll from any
> other reason to scroll the page
> - even if there was, we'd then need to selectively hide scroll events
> - even if we did that, you could still poll scrollTop or bounding rects of
> elements off a timeout and detect that the page had scrolled - scroll events
> aren't the only thing that show the scroll position.
> - even if we were somehow able to completely isolate the webpage from the
> fact that the user was now looking at a different part of the page... that
> would then likely break 'benign' webpages that depend on the scroll position
> for functionality (e.g. loading more content, or changing the display
> properties of various elements, or updating the size of other elements for
> parallax-style scrolling, or...).

I unterstood, thank you

Comment 12

[Daniel Veditz [:dveditz]]

Clever. Works in Chrome, too. Was hit and miss in Safari; mostly miss but enough glimpses of correct detection that suggest the testcase could be adjusted to work. If I change the panel heights I get similarly wrong behavior in Firefox so it's probably something simple like that.

If the user is searching for text the page can always detect their searches by examining the selection range--for successful searches anyway. I don't think this example is leaking anything that wasn't already leaking.

Anne: any thoughts on this?

Comment 13

[Mike de Boer [:mikedeboer]]

(In reply to :Gijs from comment #8)
> I don't see any reasonable way to resolve this, so I'm tempted to mark
> sec-low, open up, and mark WONTFIX. I also have a nagging feeling we have
> this on file already, but I can't find it. Dan/Al, thoughts?

Perhaps because nsITypeAheadFind takes care of scrolling find results into view.

Comment 14

[Anne (:annevk)]

It does not work if you copy-and-paste a password, which is good. Anyone with strong passwords is unlikely to be affected. I can't think of a way to protect against this other than letting the user type for longer before committing. Improving password management to the point passwords are not a thing users have to concern themselves with would also work...