4 ms·
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
by thezilch 13y ago
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.
- tomvangoethem 13y agoA PoC was produced (see the part of the guy named `</a><a id=a href=http://goo.gl/CQtK5F><link http://goo.gl/CQtK5F><link rel=stylesheet href="http://tomvglabs.be/css.php">` http://tomvglabs.be/css.php">`), and was sent to the Google Security Team in the initial report.
- thezilch 13y agoUnderstood; 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."
- pudquick 13y agoI 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.
- Nitramp 13y agoNote 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.