Hacker News Reader

Comment by pudquick | Hacker News Reader

What you're missing is that the email was generated and sent by Google to the new email address that the author of the article was changing his account to - and this email was the one that he was able to inject arbitrary HTML content into it, including a link to a third-party domain.

He could have entered ANY email address into the "change my email to" form - and Google would send an email there.

With suitable preparation work on his profile name, he could essentially have Google send a custom crafted HTML email to his intended victim - complete with verified domain sender information (and hiding the actual 'click here to verify your email' link so that the email address never actually gets changed).

Getting Google to send phishing emails on your behalf is a pretty big deal.

View on HN

Chinese spammers are abusing Picasa galleries to spam people now. Couldn't find a way to report that and never heard back from them on Twitter. Marking the emails as spam doesn't stop more making it through. (Actually, marking as spam seems to do SFA.)

I just got spam via a Google calendar event. Basic 419, location in Syria and lots of weapons and money was involved. Followed the link through Sandboxie, ended up actually at Google Calendar, marked as spam and went on with my day.

It's not obvious, from the article, that ANY HTML entities will work -- be unescaped -- for the name display; the article is worded as if the vulnerability was only theorized and not physically tested. Perhaps just a very naive "regex" that is looking for "<[A-z]" start of a token before escaping, which won't pick up "<!". Granted, it is a flawed product, but the article did not describe testing or producing such a PoC, which may be why Google was not willing to award the reporter -- no security threat, only parts of an email could be commented out.

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.

Understood; from the article, I read "Here's an example of what an email [...] might look like" and understood it to be hypothetical. That's fairly damning, as it's not at all a tricky sequence -- standard, low-hanging "XSS."

I will agree with you here, I thought it was only conceptual as well and that he had not verified the Google team wasn't stripping HTML entities in profile names, etc.

Considering that they missed one though and with the amazing things I've seen done with limited characters and Javascript, I would be surprised if it was not exploitable in some fashion.

Note that your HTML email client is responsible to prevent XSS from mail, so while this is a bit ugly, it's not a security issue comparable to XSS in a web page.

Reply on news.ycombinator.com