1416761 - Prevent websites from opening modal dialogs in rapid succession

Status: REOPENED

(Firefox :: Security, enhancement)

Description

[Marco Castelluccio [:marco]]

There are several cases where evil websites open modal dialogs in rapid succession to make it impossible for users to use the browser.

We should impose a limit on the rate of modal dialogs opened. I can't see any reasonable use case where it is needed to open so many modal dialogs so often.

Comment 1

[Johann Hofmann [:johannh]]

I think it's important to differentiate between the kind of modal dialog here. It's pretty obvious to everyone that, in theory, no tab should be able to block the browser for a longer period of time, but the different dialogs have different constraints.  E.g. we just resolved bug 1412559 because that one had less constraints than, say, the basic auth dialog. There are lots of examples how this problem gets abused in bug 432687.

Unless you have a concrete example we should dupe or INCOMPLETE this bug.

Comment 2

[:Gijs (he/him)]

(In reply to Marco Castelluccio [:marco] from comment #0)
> There are several cases where evil websites open modal dialogs in rapid
> succession to make it impossible for users to use the browser.
> 
> We should impose a limit on the rate of modal dialogs opened. I can't see
> any reasonable use case where it is needed to open so many modal dialogs so
> often.

We already do this. Have you investigated why it's not working in whatever cases you're looking at? (There seem to be no links here, so I don't know if there's a specific problem or what...)

Comment 3

[:Gijs (he/him)]

(In reply to :Gijs (slow, PTO recovery mode) from comment #2)
> (In reply to Marco Castelluccio [:marco] from comment #0)
> > There are several cases where evil websites open modal dialogs in rapid
> > succession to make it impossible for users to use the browser.
> > 
> > We should impose a limit on the rate of modal dialogs opened. I can't see
> > any reasonable use case where it is needed to open so many modal dialogs so
> > often.
> 
> We already do this.

Apparently since bug 61098 was fixed 7 years ago.

Comment 4

[Marco Castelluccio [:marco]]

(In reply to Johann Hofmann [:johannh] from comment #1)
> I think it's important to differentiate between the kind of modal dialog
> here. It's pretty obvious to everyone that, in theory, no tab should be able
> to block the browser for a longer period of time, but the different dialogs
> have different constraints.  E.g. we just resolved bug 1412559 because that
> one had less constraints than, say, the basic auth dialog. There are lots of
> examples how this problem gets abused in bug 432687.

Modal dialogs get abused very often. If there's no legit use case where we want multiple modal dialogs to open in rapid succession, it might be worth blocking opening new modal dialogs when a website is opening too many of them too often.

> Unless you have a concrete example we should dupe or INCOMPLETE this bug.

Instead of dealing with modal dialog-related problems as they appear, taking a more proactive approach might be more fruitful.

(In reply to :Gijs (slow, PTO recovery mode) from comment #2)
> (In reply to Marco Castelluccio [:marco] from comment #0)
> > There are several cases where evil websites open modal dialogs in rapid
> > succession to make it impossible for users to use the browser.
> > 
> > We should impose a limit on the rate of modal dialogs opened. I can't see
> > any reasonable use case where it is needed to open so many modal dialogs so
> > often.
> 
> We already do this. Have you investigated why it's not working in whatever
> cases you're looking at? (There seem to be no links here, so I don't know if
> there's a specific problem or what...)

Are we doing this for all dialogs or for dialogs opened via window.alert() only?
I've seen problems with modal dialogs multiple times. Lately with the HTTP auth dialog.
Unfortunately I don't have the URL at hand right now.

Comment 5

[Marco Castelluccio [:marco]]

Bug 1425264 has an example.

Comment 6

[Jonathan Kingston [:jkt] he/him]

This appears also to be a duplicate of Bug 377496, please indicate if that isn't the case. Thanks!

Comment 7

[:Gijs (he/him)]

(In reply to Jonathan Kingston [:jkt] from comment #6)
> This appears also to be a duplicate of Bug 377496, please indicate if that
> isn't the case. Thanks!

Not really. This bug is about rate-limiting dialogs generally (but perhaps particularly app-modal ones like the http auth one). We could do that fairly easily, and indeed have done some of that work (see bug 1312243). We could be more aggressive with that without waiting on moving the http auth dialog to a tab-modal one (which would be a considerable amount of work). So I would actually suggest reopening this and perhaps having the sec team work on this, especially if it's not feasible to move the http auth dialog to tab-modal code "soon" (which has been my impression for the past few years - perhaps that's changed?).

Comment 8

[Jonathan Kingston [:jkt] he/him]

Ah ok this is fine, sorry for closing. I agree this could be simpler than the other bug.

Comment 9

[davy.wybiral]

Here's an example of a page using using endless iframes with data URI's instead of Javascript to cause a modal dialog DOS: http://fan-pages.herokuapp.com/

*** WARNING: Clicking on that link may crash you.

Comment 10

[Daniel Veditz [:dveditz]]

Comment 9 is about the download dialog (also a dupe example, though that one I'm thinking of may have been slurped into a more generic "modal dialogs bad" bug). In that case there are a huge number of iframes (possibly infinite if there's a server script just spitting them out. I didn't stick around to see if it ever ended) each triggering a download prompt. To make things convenient for the user we proactively download files in the background when there's such a prompt on the assumption the user most likely wanted the download and this will save them time (we clean up if the user cancels). So we're creating tons of files and stacking up zillions of prompts.

Even if they weren't modal this would still be a problem, and most likely needs to be attacked independently of any "fix modal dialogs" work. For one thing we probably want to make downloads _more_ modal, or at least serial. Go ahead and pre-download the first, but stick any additional ones in a queue and don't start the download or ask the user until the first one is dealt with. Of course we'd want to make it so the user can close the tab if this is a never-ending abusive case.

Note that some extensions ("DownThemAll") allow users to download all/most links on a page at once so there are cases where multiple downloads are wanted and not abusive. A legacy add-on could easily bypass our restrictions but we should make sure that whatever limits we impose don't apply to Web Extensions. They have a separate download API so that should be fine, just wanted to raise the point so we double-check.

Comment 11

[davy.wybiral]

(In reply to Daniel Veditz [:dveditz] from comment #10)
> Comment 9 is about the download dialog (also a dupe example, though that one
> I'm thinking of may have been slurped into a more generic "modal dialogs
> bad" bug). In that case there are a huge number of iframes (possibly
> infinite if there's a server script just spitting them out.

Yeah, it's infinite.

> To make things convenient for the user we proactively download files in the
> background when there's such a prompt on the assumption the user most likely
> wanted the download and this will save them time (we clean up if the user
> cancels). So we're creating tons of files and stacking up zillions of
> prompts.

Are you saying that these files are being temporarily stored somewhere or held in memory?

Comment 12

[jscher2000]

(In reply to davy.wybiral from comment #11)
> > To make things convenient for the user we proactively download files in the
> > background when there's such a prompt on the assumption the user most likely
> > wanted the download and this will save them time (we clean up if the user
> > cancels). So we're creating tons of files and stacking up zillions of
> > prompts.
> 
> Are you saying that these files are being temporarily stored somewhere or
> held in memory?

They are saved to disk. On Windows, in the system TEMP folder.