1738470 - possible to overwhelm user with huge stack of alerts before the page can be stopped

Status: UNCONFIRMED

(Toolkit :: Content Prompts, defect)

Description

[[e-mail]]

Attachment: 1.jpg

User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

hi Team during testing some website I noticed new Firefox pop Behavior looks a little strange.The color around pop frame after pop they change frame color for black.

I see this first time .Old version do not behavior that strange .This is something interesting .

Actual results:

I attach screenshot and file with payload from website to see it .

Expected results:

I think the pop do not should change color .

Comment 1

[[e-mail]]

Attachment: 2.html

Comment 2

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Andre Klapper]

How is this an XSS?

Comment 4

[[e-mail]]

You are asking me .This website just execute payload.

Comment 5

[Emilio Cobos Álvarez [:emilio]]

This is because there are multiple dialogs stacked and the shadow becomes darker, but I don't think it's an issue or something... That said, isn't alert supposed to block? If so how is the site managing to alert so much at the same time?

Comment 6

[[e-mail]]

OK But for example Firefox 82 do not do that .Pop is clear and react properly.

Comment 7

[Daniel Veditz [:dveditz]]

There are about 50 onerror=alert(document.domain) in this document. Assuming they all fire, they're asynchronous and all pile up. As Emilio said, we actually show that with a drop-shadow effect now, but in older versions (I tried ESR-78.15 because it was handy) we don't use that effect so the stacking is not evident. Maybe it'd be noticeable if the later dialogs used progressively longer strings? Notice that if you check the box to say you don't want to see any more alerts from the page you still see a bunch more. It's not that the checkbox is broken (new alerts after that point won't create a dialog), but that all the asynchronous alerts have already been shown in a stack and you still have to clear those out. If you mash the ESC button to get rid of them you will see that executing alert(123) in the DevTools console has now been prevented.

This is a Denial of Service attack by the page, but really it's against itself and not the user or the browser: the user can still switch to other pages and close the evil page with no harm done. In theory we could create a queue for async alerts/prompts outside the page and then make sure the "don't show" checkbox is applied to this queue and not just back to the document's runtime for future prompts, but that effort would be taken away from working on positive features merely to slightly soften the effects of a malicious (or run-away) page. Not worth it IMHO when you can simply walk away and not give jerks any more attention.

The testcase looks like an error page from some site. Assuming you're the one who supplied the onerror text--because SQL statements with fragments like

    AND `books`.`title` LIKE '%onerror=alert(document.domain)>%'

make no sense otherwise--then THAT SITE has an XSS bug in it. This is not a Firefox bug; any modern browser should give similar results.

Comment 8

[Daniel Veditz [:dveditz]]

by "walk away" I meant users could "close the page", and the "jerks" would be anyone intentionally using this trick to annoy people. In the attached example it appears a common technique to test pages for XSS inadvertently led to more replication of the probe than was expected.

Comment 9

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:tspurway, could you have a look please?

For more information, please visit auto_nag documentation.