1746302 - XSinator xss browser leak test

Status: NEW

(Core :: DOM: Security, defect, P3)

Description

[jwms]

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

Steps to reproduce:

visit https://xsinator.com/ and run all tests

I just learned about this site on the Security Now podcast episode 848
https://twit.tv/shows/security-now/episodes/848

And figured I would put in a ticket to see if someone has looked at this newer XSS leak research

Actual results:

Firefox leaks on these tests:

Event Handler Leak (Object)
Event Handler Leak (Script)
URL Max Length Leak
Max Redirect Leak
CSP Redirect Detection
WebSocket Leak (FF)
Frame Count Leak
Media Dimensions Leak
Media Duration Leak
Cache Leak (CORS)
Cache Leak (POST)
CSS Property Leak
CORP Leak
CORB Leak
Download Detection
Performance API Download Detection
COOP Leak

Expected results:

hopefully there are no leaks

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 3

[Daniel Veditz [:dveditz]]

I thought we already had this, but our meta bug is kinda empty at the moment. It was supposed to cover that.

Comment 4

[Simon Mainey]

Attachment: results.png

interestingly... vs a (practically) vanilla profile

• browser.link.open_newwindow.restriction = 0 shows changes
  • I remember a bugzilla about iframe counting and I'm almost certain it was in an RFP bug/patch, but I can't find it for the life of me
  • the test was to open a malicious sized new window from JS and grab dimensions (to leak screen dimensions), and at the same time you could count iframes
• and RFP vs vanilla also shows changes

:tjr: RFP without browser.link.open_newwindow.restriction seems to have iframe counts covered, do you remember where we did this

Comment 5

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

(In reply to Simon Mainey from comment #4)

Created attachment 9258646 [details]
results.png

interestingly... vs a (practically) vanilla profile

• browser.link.open_newwindow.restriction = 0 shows changes
  • I remember a bugzilla about iframe counting and I'm almost certain it was in an RFP bug/patch, but I can't find it for the life of me
  • the test was to open a malicious sized new window from JS and grab dimensions (to leak screen dimensions), and at the same time you could count iframes
• and RFP vs vanilla also shows changes

It sounds like one of the bugs off letterboxing - maybe Bug 1556016. Interestnigly that bug references the restriction pref but I don't remember anything about it really.

:tjr: RFP without browser.link.open_newwindow.restriction seems to have iframe counts covered, do you remember where we did this

This pref is really old, it predates me, so I am not sure. I suspect this is not actually doing something specifically about iframe counts but rather intentionally or unintentionally breaking the 'opener' relationship that lets you learn things about the new window. http://kb.mozillazine.org/Browser.link.open_newwindow.restriction has some more detail about that pref... rel=noopener might reproduce this without fiddling prefs?

Comment 6

[Simon Mainey]

This pref is really old

it's going to being deprecated (and replaced) in Bug 1714939, but you're likely right that being set to value 0 (most strict) is simply interfering with that PoC, and besides it's not a universal solution. I mentioned it because I thought we had done something with iframe counts, my bad :-(