Open Bug 1855854 Opened 1 year ago Updated 8 months ago

Bypass window pop up notification/alert lead to spoof

Categories

(Core :: DOM: Navigation, defect)

defect

Tracking

()

People

(Reporter: sas.kunz, Unassigned)

References

Details

(Keywords: reporter-external, Whiteboard: [reporter-external] [client-bounty-form] [verif?])

Attachments

(2 files, 1 obsolete file)

Attached file moz.html (obsolete) —

I found a vulnerability where when two popup windows are opened at the same time, only one window should open and the other one does not appear and the allow block window pop up notification appears, but in this bug the allow window pop up notification does not appear. I have tried this bug in Chrome and only one window appears.

The impact of this is a spoof, the victim believes that what is open from another window is an open window from Google

steps to reproduce:

  1. open moz.html or http://103.186.0.20/moz.html
  2. click login
Flags: sec-bounty?

i tested on windows OS and firefox nightly version: 119.0b2 (64-bit)

Thanks for the report. The behavior does look a little weird, but I'm not sure how much of a spoof it really is. It feels like one of these spoofs where the user has to be both very alert and very unalert for it to be achieving anything.

The user sees the Google page appear, but only for about a second, so how much of a confusing effect is that? Is the user supposed to be seeing the valid URL bar and decide to trust the page in that window, but then not bother looking at the URL bar in the actual final page they are entering their credentials into? I guess you are saying that because the fake login page appears after Google the user will assume it came from Google, but pages appear to the right of the page that opened them, so if they look at the position of the tabs it seems fairly clear that the original page opened it, and not Google.

Keywords: csectype-spoof
Attached file moz.html
Attachment #9355730 - Attachment is obsolete: true

i have updated the poc to 3 seconds.

I guess the behavior here falls under DOM: Navigation or maybe DOM: Core so I'll move it over here.

Group: firefox-core-security → dom-core-security
Component: Security → DOM: Navigation
Product: Firefox → Core

bug 675574 limited the number of explicit window.open() that could happen in one activation. Technically target=__blank isn't a window.open, but the effect is basically the same. But then which do we block? In this case clearly the link happens first, and blocking the window.open() would not be a surprise. But what if the onclick immediately opens a window? Blocking the link even though the even wasn't consumed is a little odd. Then again, if two windows open nearly simultaneously it's pretty clear where it came from, and "2" pop ups aren't all that abusive compared to unlimited.

I really want to know why the "user activation" still counts 3 seconds later though. We should stop that abuse regardless of how many windows. The whole point of the user activation is so the user can associate the originator of the action and don't have mysterious popunder ads without a web site they can blame for them.

In addition to the time length, if the originating site isn't the one with focus then the user activation shouldn't count for that, either.

This is an anti-abuse feature... it doesn't need to be hidden

Group: dom-core-security
Keywords: csectype-spoof
See Also: → 675574
Severity: -- → S3

I really want to know why the "user activation" still counts 3 seconds later

Per spec it is supposed to last "a few seconds", both us and Chromium use 5 seconds internally.

Duplicate of this bug: 1858255
Flags: sec-bounty? → sec-bounty-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: