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"

Except for causing annoyances, the truncation of data may also have security implications. Last year, I found that WordPress (which has the utf8 character set by default), was vulnerable to PHP object injection because their filter could be bypassed by (ab)using the truncation of strings in MySQL. For more details: http://vagosec.org/2013/09/wordpress-php-object-injection/

Make that `<link rel=stylesheet href=http://ø.xx>` as JavaScript won't execute in recent mail clients.

How would you describe a well-behaved e-mail client with regards to this vulnerability?

The phishing attack I described in my blog post affects all e-mail clients that are able to render HTML and CSS. As for rendering remotely included CSS, this was not necessary, as one might as well include a <style> element.

If you are referring to just GMail as a well-behaved e-mail client, you are most likely correct that it wouldn't be possible to create a legit-looking phishing e-mail (as GMail only allows in-line styles). I think that most other e-mail clients allow the use of <style> or <link> in e-mails. The screenshot of the "phishing e-mail" in the blog post came from Mail.app (version 6.5)

I intentionally did not classify this vulnerability as "Cross-Site Scripting", although XSS vulnerabilities also rely on injecting HTML content, as the main impact here was not the execution of Javascript code in the user's e-mail client, but rather changing the visual output of an e-mail so it can be used for phishing.

Seems there is some misconception here:

1. I was not complaining that I did not get paid for this bug, but that different Bug Bounty programs have different thresholds on whether a vulnerability qualifies for a monetary reward. This seems like useful information for someone who would like to make a living out of bounty-hunting.

2. Even though I participate in these bounty programs as a hobby, which is about 1-2 days per month, I was already awarded generously. If I did this full-time, I would expect to earn a great deal more than when I would be working directly for Google (unless they have crazy wages)

I don't think that giving me some money would have refrained me from writing this blog post. The main issue here is that it was not recognized as security sensitive, and would most likely not be fixed if I didn't insist on it.

I agree on the subject line (which is "Verify your email address") and that the mail is sent from "Google Scholar Citations", but as it was possible to include arbitrary CSS files, the content could be changed to pretty much anything... Although there was a length-restriction on the user's name, there were two other fields that weren't escaped properly and thus could be used to insert more HTML-content.

A PoC was produced (see the part of the guy named `</a><a id=a href=http://goo.gl/CQtK5F><link rel=stylesheet href="http://tomvglabs.be/css.php">`), and was sent to the Google Security Team in the initial report.

Not quite, if you were the attacker, you'd update your own name to `Mr Test<!--BAD STUFF HERE` and then try to change your e-mail to victim@some.edu and perform the phishing attack on the victim

or yes, as pudquick put it more nicely :)

I was expecting them to put my name up there by the time I posted the blog, should be there in the near future though...