[therusher]

Honestly, the vast majority of people will not notice an increase in traffic, no matter how big it is (this is what, a 285kb/s increase in net traffic?).

I think the bigger issue with this exploit is just the fact that so many submissions need to be sent. I don't really see someone sitting there for 75 hours while this takes place without closing the browser/window/tab.

EDIT: If you're already injecting JS, you're probably better off just phishing the user for their credentials. Faster, easier, and will work more often than relying on the user staying active enough to send traffic for the next 75h.

EDIT 2: Not saying this isn't a valid vulnerability, just not one that can be practically executed currently without much simpler alternatives.

[gipsies]

> I don't really see someone sitting there for 75 hours while this takes place without closing the browser/window/tab.

But that's not a problem. If the user closes the browser or tab, the attack can continue at a later point in time. It doesn't need to be collected all at once. As a concrete example, if you leave your computer at work running during the weekend, the attacker has enough time. Or if you leave it running during the night, the attack can be spread out over a few nights. I'm sure there are even more scenarios than just these two examples: there's room for quite some flexibility when performing the attack.

[therusher]

Correct me if I'm wrong here, but:

That's assuming the attacker regains control, so you'd have to visit a malicious page every time the attack needs to be re-initiated. EDIT: I'm dumb, somehow I managed to forget mid conversation that this was assuming MitM and not a compromised site. Disregard this point.

Also, while this method can be used for other, static data, pretty much all of the stuff you would want / have access to through doing this will be time-sensitive. Even a straight 72h most "secure" things such as cookies will be changed, forcing a restart of this process. Extending this even longer just gives a bigger window for the cookie/whatever to timeout.

EDIT: though I guess if the cookie you're trying to crack doesn't expire, then this could be an issue. I still think there are vastly easier methods if you can arbitrarily inject into http pages though.

[t0mas88]

Note that the "malicious page" could also be embedded / injected in another page. Basically any non-https page opened over public WiFi would be enough. And conveniently users on public wifi are also the easiest to sniff, so the group on which breaking encryption makes most sense.

[cesarb]

> That's assuming the attacker regains control, so you'd have to visit a malicious page every time the attack needs to be re-initiated.

Every non-HTTPS page can be considered malicious, if the attacker can do a MITM.

Since the attacker can capture the encrypted traffic, he most probably is in the middle and can do a MITM.

Therefore, if you are under this attack, every non-HTTPS page is malicious.