1491452 - Web pages can add themselves to the "Top Sites" on your New Tab page by abusing window.history

Status: RESOLVED FIXED

(Toolkit :: Places, defect, P2)

Description

[Ajedi32]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180913141435

Steps to reproduce:

Visit an HTML page with the following contents:

```
<script>
  for(let i=0; i<10000; ++i) {
    document.location.href="#";
    window.history.back();
    window.history.forward();
  }
</script>
```

Live example: https://cdn.rawgit.com/Ajedi32/f59485360e6e7f27d8c7ed1dc2dec75a/raw/2c180a8d09787f3345b1f8717647c085484d489d/dos.html


Actual results:

Firefox freezes for about 30 seconds, then the page loads and everything returns to normal. However, the "Top Sites" section of New Tab page now displays this malicious page in a prominent spot, even above sites I visit far more frequently.


Expected results:

I'd expect the tab to freeze for maybe a few seconds, but other than that nothing should happen.

Additional notes:

Sites being able to automatically add themselves to the user's Top Sites list with just a bit of JavaScript seems pretty abusable, so even though this is debatably not a "security" issue I've decided to mark the bug as hidden for now.

I discovered this issue via the following Tweet from another developer (though the stated goal of the attack in that Tweet was DOS on Chrome, not anything related to Firefox's New Tab page): https://twitter.com/pwnsdx/status/1038821975089664001

Comment 1

[Johann Hofmann [:johannh]]

I can reproduce getting onto the top sites after a restart. Combined with bug 1453395 this is a potentially severe threat to our user base. Please do not open this up. I'll try to post a full POC in bug 1453395.

Thank you for the report.

Comment 2

[Ed Lee :Mardak]

Top sites is getting pages by frecency, which is computed from visit count. Looks like visit count increases for the "#" url, e.g., copy/pasting the script to web console on mozilla.org with 100 instead as well as the live example:

SELECT url, frecency, visit_count FROM moz_places;

https://www.mozilla.org/en-US/|2000|1
https://www.mozilla.org/en-US/#|10000|100
https://cdn.rawgit.com/Ajedi32/f59485360e6e7f27d8c7ed1dc2dec75a/raw/2c180a8d09787f3345b1f8717647c085484d489d/dos.html|2000|1
https://cdn.rawgit.com/Ajedi32/f59485360e6e7f27d8c7ed1dc2dec75a/raw/2c180a8d09787f3345b1f8717647c085484d489d/dos.html#|1000000|10000

I would guess a fix could be similar to bug 399606, which addressed same url / reload.

(Separately, after restarting, I seem to run into JavaScript error: resource://gre/modules/PlacesUtils.jsm, line 1852: NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsINavBookmarksService.tagsFolder] for database locked, but that might be related to sqlite open, which also complained about database locked.)

Comment 3

[Ed Lee :Mardak]

More recently, bug 1261386 improves "anti-flooding system" for reloads.

Comment 4

[Mark Banner (:standard8)]

I believe bug 661590 is also highly related to this.

Comment 5

[Daniel Veditz [:dveditz]]

As a "security" problem I think we have to go with a low rating because this isn't giving anyone malware, and to be affected you've already visited an "evil" site. But it's definitely bad for our users! Clearly a spam magnet which will eventually make the feature useless. Could also help phishing or similar attacks if you can spam a fake-Facebook or fake-Bank (but you have to guess the right bank) to the top of the list.

Comment 6

[:Gijs (he/him)]

FWIW, I suspect the WIP patch in bug 1314912 would help here, too, as the #ref back/forward changes effectively count as SAME_PAGE document navigations. If someone with the relevant expertise could drive that over the line that'd be useful.

Comment 8

[Marco Bonardo [:mak]]

There is now a protection on session history api, that will fail with "Too many calls to Location or History APIs within a short timeframe.", plus Bug 1891145 implemented an additional protection in global history, though it won't ever be perfect, as the risk of dropping real visits is high if we act too strictly.
The bug as-is is no longer reproducible for me.
Let's continue tracking Bug 661590 for further improvements on the history flooding matter.

Comment 9

[Daniel Veditz [:dveditz]]

(In reply to Marco Bonardo [:mak] from comment #8)

There is now a protection on session history api, that will fail with "Too many calls to Location or History APIs within a short timeframe."

It looks like you must mean bug 1913000, which was shipped in Firefox 132?

The other one you mention, bug 1891145, is shipping in Firefox 135 via bug 1915404

Comment 10

[Marco Bonardo [:mak]]

(In reply to Daniel Veditz [:dveditz] from comment #9)

It looks like you must mean bug 1913000, which was shipped in Firefox 132?

The other one you mention, bug 1891145, is shipping in Firefox 135 via bug 1915404

yes, that's right.