Hacking Google for Fun and Profit
blog.andrewcantino.com
Hacking Google for Fun and Profit
1–10 of 17 posts
Re: Hacking Google for Fun and Profit
#2Re: Hacking Google for Fun and Profit
#3That 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?
Re: Hacking Google for Fun and Profit
#4That 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?
Re: Hacking Google for Fun and Profit
#5Great 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
#6Well 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
#7Just 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
#8Re: Hacking Google for Fun and Profit
#9I 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?
Re: Hacking Google for Fun and Profit
#10Awesome 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?
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.