We welcome all reports of security vulnerabilities, we try to fix them quickly, and we credit the researchers - but we offer rewards only for higher-impact flaws. You can check out this page for more info:
In this context, phishing issues are tricky. Because many of our products simply have to do things such as displaying snippets of potentially attacker-controlled text and multimedia, we try to evaluate phishing concerns on a case-by-case basis. In essence, we ask ourselves how easy it would be to exploit a particular behavior to mount a convincing attack.
My take on this bug is that the attack vector is severely constrained in well-behaved e-mail clients; and that in badly-behaved clients, the existing exposure is already considerably worse than any incremental hazard caused by this flaw. It's valid and worth fixing - but does not quite meet the bar for the reward tiers set up for higher-impact bugs.
So chuck him a C note and move on. I don't think it's worth the bad PR to quibble over what is clearly a security bug no matter how minor. HTML injection is sort of like the bike shed of security vulnerabilities, every web developer understands it, so you'll get a perverse amount of attention and discussion on it.
In essence, we have a reward structure that we think is internally consistent, attracts the right sorts of research, and makes an optimal use of our resources - and we try to apply it fairly.
Here, we handled the communications poorly, and I think it's OK to call us out on that. In fact, I think it would be wrong to offer a reward in hopes of buying silence from the reporter :-)
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.
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.
We welcome all reports of security vulnerabilities, we try to fix them quickly, and we credit the researchers - but we offer rewards only for higher-impact flaws. You can check out this page for more info:
http://www.google.com/about/appsecurity/reward-program/
In this context, phishing issues are tricky. Because many of our products simply have to do things such as displaying snippets of potentially attacker-controlled text and multimedia, we try to evaluate phishing concerns on a case-by-case basis. In essence, we ask ourselves how easy it would be to exploit a particular behavior to mount a convincing attack.
My take on this bug is that the attack vector is severely constrained in well-behaved e-mail clients; and that in badly-behaved clients, the existing exposure is already considerably worse than any incremental hazard caused by this flaw. It's valid and worth fixing - but does not quite meet the bar for the reward tiers set up for higher-impact bugs.