Firefox user can unknowingly become part of DDOS attack by clicking link of HTML file

RESOLVED INVALID

Status

()

Firefox
Untriaged
RESOLVED INVALID
2 years ago
2 years ago

People

(Reporter: Anurag, Unassigned)

Tracking

49 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8805221 [details]
firefox.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

Steps to reproduce:

1) Use a HTTP intercepter like Burp to record network logs
2) Open the attached firefox.html
3) Click on Open facebook
4) Dialog box comes asking to print.
5) Wait for 30 seconds and then click on cancel
4) Facebook will open but if you check your network logs in burp you will see Firefox called twitter 22 times instead of once (22 can be increased to very large value by extending number of iframe in the script)


Actual results:

Facebook will open but if you check your network logs in burp you will see Firefox called twitter 22 times instead of once (22 can be increased to very large value by extending number of iframe in the script)


Expected results:

When i clicked on the link, I was making call to 22 frames with twitter and also asking for redirection to facebook.
Under normal circumstances, firefox would be safe and would send me instantly to facebook thus saving the user from being part of attack.
But I used print method as workaround. When I called print firefox was not able to move to facebook and thus the 22 twitter link got to network and got loaded.

I think the navigation should not stop even when a function like print is called.
DDOS is a red herring. If you got a user to your malicious page and wanted to DDOS twitter then just include as many twitter frames as you want right off the bat. Why would you hide it behind a link click, _especially_ if your expectation is that clicking that link shouldn't then work to run that script?

The heart of this report is that you seem to expect that window.print() be asynchronous--that is, trigger the printing dialog but keep executing the script. That's simply not how it's defined in the spec. It could be changed if you want to make that argument, but that would be at the HTML5 (or WHATWG) spec level. It's not a Firefox bug, nor is it a security problem.
Group: firefox-core-security
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.