Live data from Hacker News

Hacking Google for Fun and Profit

blog.andrewcantino.com

1–10 of 17 posts

Re: Hacking Google for Fun and Profit

#4

That is very neat. Regarding the choice of charities, did Google let you choose any registered charity, or was it from a list of pre-selected charities?

It's pretty common for people to donate the reward. We're happy to do so for registered charities, and typically increase the amount donated. If a reward goes unclaimed we just make a donation to the International Red Cross.

Re: Hacking Google for Fun and Profit

#5
Well done -- an accomplishment indeed.

Great content aside, I found the tone especially refreshing. Too often, it's "look how smart I am, and how stupid you all are" -- the brilliant jerk archetype.

Thank-you.

Re: Hacking Google for Fun and Profit

#7
Awesome post, love to see that even the great borg is human sometimes like the rest of us :)

Just curious for someone who knows more than me, couldn't all of these have been prevented by requiring all POSTs to the server have an attached CSRF nonce? Is there a downside to having a blanket policy like that?

Re: Hacking Google for Fun and Profit

#9
post #8

I love these type of posts. Thanks for sharing. How do you stumble upon these exploits? Do you purposely go searching for them, or do you just accident upon them?

In this case, I wanted to take Google up on their Vulnerability Reward Program, so I purposely went looking for security holes. I used Firebug and the Chrome inspector to search for issues.

Re: Hacking Google for Fun and Profit

#10
post #7

Awesome post, love to see that even the great borg is human sometimes like the rest of us :) Just curious for someone who knows more than me, couldn't all of these have been prevented by requiring all POSTs to the server have an attached CSRF nonce? Is there a downside to having a blanket policy like that?

Tokens would not have helped for the first two. They were logic errors; the attacker used Google features in ways they were not expected to.

The first was a GET request, not POST. Images have fairly lax cross domain restrictions. So while the attacking website can't see the image loaded from Google they can detect when the image doesn't load. Google was returning a non-200 response code for images the user can't see.

The second wasn't a traditional XSRF. Instead it was making the victim (unknowningly) edit a shared document created by the attacker. The attacker uses the feature of Google docs that shows all current editors to see the victim's Google account name.

Post reply on HN