Closed
Bug 1313437
Opened 8 years ago
Closed 8 years ago
Firefox user can unknowingly become part of DDOS attack by clicking link of HTML file
Categories
(Firefox :: Untriaged, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: cs.anurag.jain, Unassigned)
Details
Attachments
(1 file)
1.31 KB,
text/html
|
Details |
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.
Comment 1•8 years ago
|
||
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
Closed: 8 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•