Paid Advertising
web application security lab

Google Buzz Security Flaw

Speaking of Google, I got an email from TrainReq (the same fellow who allegedly hacked Miley Cyrus for those who don’t keep up to date on your tween idols). The email was regarding an exploit against Google Buzz. It’s yet another example of bad input validation/output encoding by your favorite advertising overlords at Google. As you can see, nothing up my sleeves:

There’s four things of note here. Firstly it’s on Google’s domain, not some other domain like Google Gadgets or something. So yes, it’s bad for phishing and for cookies. Secondly, it’s over SSL/TLS (so no one should be able to see what’s going on, right?). Third, it could be used to hijack Google Buzz - as if anyone is using that product (or at least you shouldn’t be). And lastly isn’t it ironic that Google is asking to know where I am on the very same page that’s being compromised? Why on earth does Google think its systems are secure enough to trust them with that kind of sensitive information? Yes, bad guys can figure out where you’re located if you allow that function. Chinese dissidents beware! But if you have something to hide, you must be a bad guy, right, Eric?

28 Responses to “Google Buzz Security Flaw”

  1. Studdly Says:


  2. Sam Vilain Says:

    Hmm bashing Google pretty hard for releasing new products seems to be all the rave at the moment.

    But one Question - do you use Facebook? Whose internal systems management do you trust more? Whose crappy API design has resulted in millions of users’ details being harvested by spammers?

  3. Moh Says:

    They (Google) must read your blog. It looks fixed to me.

    Just search in Buzz for lolhax. The scripts are displayed now rather than parsed by the browser.

    A pretty basic mistake for such a company.

  4. RSnake Says:

    @Sam Vilain - Are you saying using Facebook’s API to get email addresses is worse for the Internet than using Google Dorks to own hundreds of thousands of machines? Besides being an incomplete thought, it’s kind of a non sequitur, don’t you think?

  5. t Says:

    I would like to think I trust Googles more. Seeing how they have been pretty good about patching any problems relatively quick. +rep Trainreq.

  6. RSnake Says:

    @t - right, like the redirect holes that are still unfixed 4-5 years later. And the XSS in Blogspot and Gmodules, unfixed for 2 years. They sure are quick!

  7. sirdarckcat Says:

    dude, the are not vulnerabilities.. is like saying or have xss

  8. RSnake Says:

    @sirdarckcat - how is malicious JavaScript being placed on a domain that is supposed to be trustworthy not a vulnerability? Can you phish people with it? Can you deliver malware? I guess those don’t count as holes anymore? Even OWASP top 10 (candidate) counts open redirects as a vuln and I sure as hell can redirect using JavaScript. You of all people can’t seriously believe what you just typed. Come on, stop drinking Google’s kool-aide.

  9. datajunkie Says:

    Well once again google not only proves that it is going to be the arm of big brother but also proves that they are retards.

    and that coy statement about nothing to hide… I suppose I should start taking a crap in the middle of the street because obviously my feces is something I shouldn’t hide…

  10. Tom T. Says:

    I stand by yesterday’s post that everyone should just boycott Google until things improve dramatically, even if that’s “never”.

    Regarding the “if you want privacy, you must be doing something wrong” canard, cryptogeek Bruce Schneier demolished that argument very nicely, almost three years ago. It’s worth reading, and worth saving the link for any time that same argument comes up.

  11. w00t Says:

    How is JavaScript placed on different from JavaScript placed on

    Are you saying that non-sanitized content can never ever be hosted in “sandbox” domains at all, because diligent users who would otherwise be safe online are now at undue risk of confusion?

    If yes, that’s a fair opinion, but keep in mind that this denies the right to exist to broad classes of useful web applications. Certainly not specific to any web app vendor.

  12. est Says:

    A Chinese sends his regards

    Brother spring is true man

  13. sirdarckcat Says:

    serving malicious javascript != xss

    I mean, attack != vulnerability, right? please refer to the examples. both allow you to host “malicious content” but it;s not a xss vulnerability, is an attack abusing the functionality of those services..

    and open redirects are another issue, those are vulnerabilities.. and quite serious in some cases actually :P


  14. TrainReq Says:

    Actually it was a vulnerability with posting. There was a few HTTP post headers you can edit in the correct way and it will post an XSS in the “Location” section. However for some reason, the tags get filtered on regular web, and they don’t on Mobile. However, if you where to just post “” , etc in the update , it will filter no matter what site you go to (mobile or desktop)

  15. RSnake Says:

    @datajunkie - I wish it were that easy. You have the right mindset though. I may do a post at some point about why it’s nearly impossible to get rid of Google or boycott them effectively. A preview: thanks to all you Gmail users who email me! It’s harder than it sounds is the jist. But yes, that is absolutely the only option we have left, it appears. Google is hell bent on ruining all the privacy we have left, and they are unashamed about that fact from what I can tell.

    @Tom T - thanks for the link, and amen! I agree, the concept is entirely foolishness and clearly shows an disconnect between Google executives and the people they hurt. The irony being one Google exec was all annoyed that someone tried to uncover all the details about his life (I can’t remember which). Where are the Google execs on Buzz? Oh, right - it’s a bad idea and only for the idiots who don’t know that it’s hugely unsafe.

    @w00t the difference is that users expect blogspot to be free of vulnerabilities. For unknown reasons they consider it to be a safe domain (a huge miscalculation). gmodules is bad for a different reason. No one has ever heard of it, but other modules are served from that same domain, allowing inter-gadget exploitation. Worse yet they are embedded within Google itself, making them extremely potent at phishing. I never said Gadgets were safe though, on anyone’s site - I actually think the entire concept is flawed.

    @est - Thank for writing! You’re precisely the reason I can’t let Google go on like this - at least not without calling them out on it.

    @sirdarckcat - no, serving malicious content is not necessarily XSS. But doing it on someone else’s domain is. It’s called “persistent XSS”. Go and read the original David Ross/CIRT paper on XSS, - a snippet “Sites that host discussion groups with web interfaces have long guarded against a vulnerability where one client embeds malicious HTML tags in a message intended for another client.” I assume you are using a web based interface to interact with Blogspot and uploading HTML that can include JavaScript - so you are one client, leaving payloads for another client. Hence - persistent XSS. The scope may be limited to intranet port scanning, CSS history hacking, CSRF, delivering malware, blind redirection, and phishing - but I’d call that a vulnerability.

    @TrainReq - thanks again for letting me post your find!

  16. sirdarckcat Says:

    So, you think is vulnerable to xss? is vulnerable to xss as well then..

  17. sirdarckcat Says:

    by the way, my point is that.. “it’s not a bug, it’s a feature”.

  18. RSnake Says:

    @sirdarckcat - Just like all the vulnerability scanning companies put up vulnerable code so people can test them. No one trusts those domains so they are significantly lower risk than a blogspot, which tons of people trust - or worse yet, Google, which embeds Way too many people trust their feature to be secure - which it is not - it’s vulnerable to persistent XSS.

  19. AbiusX Says:

    Cool post dude, Totally agreed :D

  20. Sam Vilain Says:

    @RSnake the point is that Google’s server management and access control is a hell of a lot better than Facebooks, where employees can “just query the database”. And if you’d have done any Facebook API programming you’d know just how easy it is to completely mine a user’s data whenever they click that “Allow Application” button for that silly little quiz application.

  21. Gray Says:


    If this flaw is in the mobile sites post data, does it affect other users? If it can’t be passed via a GET request and be sent to multiple people w/o them initiating it on the mobile site themselves, then it isn’t so much of an exploit?

    For instance, if it was a posting that other users could see / be passed the XSS code, then it would be a major flaw. However if it required postdata to be sent to the mobile site by the user, and it only affected the user sending the data then it’s not really an exploitable hole. Since postdata can’t be sent remotely, via a web browser alone, the flaw is rather minimal damage wise.

    If it could be passed via a get request, this would be a different story, but then again, I don’t know the full context of the exploit.

  22. AppSec Says:

    There’s a significant difference between Facebook and Google.

    If people are going to make comparisons, it should be apples to apples, not apples to oranges.

    Facebook was a social network from the start, Google is trying to build out a social network based on an existing user base.

    Facebook’s API should have been controlled from the beginning, but I don’t think the owners of Facebook considered the future ramifications of it when the API was built. That doesn’t preclude them from being in a position where changes should be made. Just that the original concept was just that: social networking. You put things out on a social environment, it is no longer private it is public. The belief was that you were willing to share that information with anyone. (NOTE: this is a personal belief and speculation not fact).

    Google was a “private” site that is trying to build in social networking. There users belief their data is not publicly available and the communications are intended to be private. Google needs to be more careful in how it delivers a social networking site to existing users. Google needs to be much more careful in how it handles this.

  23. Nos Says:

    @sam, are you trying to make it a contest of ‘worst security’?

    maybe google will win that, maybe not, doesn’t matter, if users asume their data to be secure, then it should be pretty secure,

    100% secure is not possible but fixing leaks that have shown themselves already seems only reasonable (to me, anyway)

    However, ppl will asume their data to be secure way to easy… isn’t this just a big a leak as the medium they are trusting?

  24. Tom T. Says:

    @ RSnake and sirdarckcat: “”One man’s feature is another man’s exploit.” (I don’t know who was the first to say that.)

  25. modakabam Says:

    You can also load an Add-On in Google Wave so… happy crashing, cookie stealing ;)

  26. Jason Says:

    I’m more interested in the fact that some people consider blogspot safe.

    Since when was a site where a user (and if comments are enabled - anonymous users) can post arbitrary content and serve it up to the world ever safe?

  27. AbiusX Says:

    People almost always consider huge .com enterprises safe, And that’s cuz they think millions of others are involved, so if it weren’t safe they would be affected before :D

    btw google is almost the first step in footprinting,so i don’t think this is the first time Google is releasing private information, is it?

  28. Rofles Says:

    Ive known of these flaws the day it came out

    I alerted google immediately - took them a fair while to get onto it.