1255267 - delayed CSRF attack from the closed page

Status: RESOLVED DUPLICATE of bug 1255270

(Firefox :: Tabbed Browser, defect)

Description

[Toni Huttunen]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160303134406

Steps to reproduce:

tldr; would it be nice to hide CSRF-attacks on the victim's browser and launch them later after user has moved laptop to the internal network? Welcome to the reality.

The CSRF Delay Attack is contructed by introducing thousands of favicons and filling browser connection limit by serving those files slowly. The favicons are added to the download queue which is not tied to the single tab/window of the browser. Thus, the user could be redirected to the third party site after filling the queue. After reaching connection limit an attacker may wait random time and close one socket which leads Firefox to issue a new connection to retrieve next favicon. The new connection leads to a new socket which leaks the fresh IP address of the user. 

Furthermore, the attacker may later control and redirect favicon request to the another service using regular 302 redirect response. The request is done with the fresh cookie which makes possible to perform CSRF attack on the future cookies! 



Actual results:

I performed CSRF Delay Attack, then closed all browser windows except my google search homepage, then changed wifi access point from guest network to internal home network. 

After 30 min I logged in to the third party service and got instantly PWNED by the CSRF. Think situation where user brings laptop from insecure wifi to the internal network. The attack works as long as the browser is open and even recovers from short network drops. The following attack vector is tested and it really works. 

No javascript is required, all logic could be handled on the HTML page and server side. Favicon network traffic can not be seen from the Firefox developer view. Firefox does not show any signs of the requests flowing in the background.

hh:mm:ss - 
20:50:00 - visit favicon attack page
20:50:10 - closed all pages, except http://google.fi
20:51:00 - disconnected laptop from guest network wifi and connected to home network wifi (different IP)
21:21:00 - logged in to the third party site 
21:22:00 - got PWNED by the CSRF


Expected results:

disconnection of the favicon connections after webpage change

Comment 1

[Toni Huttunen]

Attachment: delayCSRF.zip

The following attachment is POC for delayed CSRF attack. Package contains html page and python server required for testing vulnerability.

Comment 2

[Daniel Veditz [:dveditz]]

This appears to be a practical example of bug 1255270 rather than a separate issue and would be fixed by fixing that bug.

CSRF is a flaw in a web application and this bug does not create a CSRF. If you know of a CSRF-vulnerable web site it does allow you to delay the attack until a later time

Comment 3

[Toni Huttunen]

I saw them as separate bugs because 1255270 handles timeout issue (privacy) while this 1255267 handles a possibility to create new connections after page close. They both can make delayed CSRF attack but only this survives network drops which could happen for example when you change your connection to trusted network. You are right that a single fix could fix these both bugs.

Comment 4

[Al Billings [:abillings - ex-MoCo]]

Minusing for bounty in favor of activity in other bug.