tomvangoethem

It would be very useful if you could point us to such examples! (I'm an author of the paper)

The main reason why the issue isn't present in Firefox is because their PDF reader (PDF.js) does not have an API to trigger requests (it does execute JS included within the PDF though)

The bug still seems to be present. You can use the testing on our website: navigate a Chrome browser with an ad-blocking extension to e.g. https://wholeftopenthecookiejar.eu/data/extensions/AdBlock/c... and click pdf-iframe-submitForm. If the result shows cookies, it has not been fixed.

Attaching cookies to third-party requests is the source of many issues. In a similar demonstration [0], I showed that browser-based timing attacks (which can probably be considered as wont-fix as well) can be used to extract more specific information from social networks (e.g. one's political preference based on who they're following).

[0]: https://labs.tom.vg/browser-based-timing-attacks/

The attack on Facebook (or any other website for that matter) works regardless of any Access-Control-Allow-Origin headers. The Fetch API has a mode "no-cors", which does not require CORS. Also: the cache being used is a programmable cache, which is distinct from the regular cache in the sense that any website can place any resource in it, regardless of the headers sent along with the response.

(I'm one of the researchers mentioned in the presentation.)

The email address is used to send you the link where the results for your domain are shown. If you keep track of this URL yourself, feel free to enter a bogus email.

(domain verification is not related to the email address)

For anyone interested in similar issues: here you can find a report for a vulnerability in Phabricator with exactly the same cause (truncation by MySQL), and pretty much the same result: https://hackerone.com/reports/2224

If Bugzilla would allow non-ASCII characters in the email address, MySQL's truncation behaviour with astral symbols (e.g. 𝌆) would probably have lead to a similar vulnerability as well. (It did so in Phabricator: https://hackerone.com/reports/2233)

Colleague of the author here.

I guess that 4450 requests/s to one IP, or even spread across multiple IPs, could trigger some alarms if the victim is alert. Unfortunately, I'm not that familiar with IDS/IPS's to answer that with much confidence.

In any case, an attacker has a lot of options. The requests do not need to be made sequentially, so an attacker could basically start and resume his attack whenever he wants, e.g. when the victim is away from keyboard (which he can estimate based on the network traffic someone usually generates). An attacker could also simply slow down the number of requests/s, although this results in a larger number of hours required for a successful attack.

As for energy/CPU consumption, I don't think that'd be a big concern. When the practical attack was performed, the CPU usage went up to around 75%, still allowing one to visit other websites without noticing anything. So unless one would closely monitor the CPU/network usage, I don't think the average victim would notice it.

If you're curious on how he "finds out", check out his other video (Quickjack - Hacking Facebook likes with Clickjacking): https://www.youtube.com/watch?v=bCkSVGhIEb4#t=217

Cool, comes in quite handy!

You may want to up your security-game though. Check the ~/FIXME file on your sever for more info :-)

When you are redirected from Facebook - either after clicking "Accept" or in an implicit flow - to the page with the next parameter, and that page redirects to attacker.com, then attacker.com will have access to the referer header†, which contains the access token. Using this access token, an attacker could extract the sensitive information from the victim's Facebook account.

† there are a few exception when referer header isn't shown, e.g. HTTPS->HTTP redirect, but an attacker could make sure that the referer header would be sent for the majority of victims

Yes, I was. I extracted access-log entries from 23 unique IPs in a few hours, though most came from a single IP

Note that by visiting, your IP and referer become accessible by anyone running an heartbleed exploit:

  93.142.x.x - - [11/Apr/2014:10:44:36 -0400] "GET /heartbleed HTTP/1.1" 200 1148 "https://news.ycombinator.com/" "Mozilla/5.0 (Windows NT 6.1; WOW64)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36"