Web Hacking 101: How to Make Money Hacking Ethically PDF

|||||||||||||||||||| NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| Web Hacking 101 How to Make Money Hacking Ethically Peter Yaworski This book is for sale at http://leanp...

|||||||||||||||||||| NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| Web Hacking 101 How to Make Money Hacking Ethically Peter Yaworski This book is for sale at http://leanpub.com/web-hacking-101 This version was published on 2018-11-30, This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do. © 2015 - 2018 Peter Yaworski, NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| Tweet This Book! Please help Peter Yaworski by spreading the word about this book on Twitter! The suggested tweet for this book is: Can’t wait to read Web Hacking 101: How to Make Money Hacking Ethically by @yaworsk #bugbounty The suggested hashtag for this book is #bugbounty. Find out what other people are saying about the book by clicking on this link to search for this hashtag on Twitter: #bugbounty NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| To Andrea and Ellie, thank you for supporting my constant roller coaster of motivation and confidence. Not only would I never have finished this book without you, my journey into hacking never would have even begun. To the HackerOne team, this book wouldn’t be what it is if it were not for you, thank you for all the support, feedback and work that you contributed to make this book more than just an analysis of 30 disclosures. Lastly, while this book sells for a minimum of $9.99, sales at or above the suggested price of $19.99 help me to keep the minimum price low, so this book remains accessible to people who can’t afford to pay more. Those sales also allow me to take time away from hacking to continually add content and make the book better so we can all learn together. While I wish I could list everyone who has paid more than the minimum to say thank you, the list would be too long and I don’t actually know any contact details of buyers unless they reach out to me. However, there is a small group who paid more than the suggested price when making their purchases, which really goes a long way. I’d like to recognize them here. They include: 1. @Ebrietas0 2. Mystery Buyer 3. Mystery Buyer 4. @nahamsec (Ben Sadeghipour) 5. Mystery Buyer 6. @Spam404Online 7. @Danyl0D (Danylo Matviyiv) 8. Mystery Buyer 9. @arneswinnen (Arne Swinnen) If you should be on this list, please DM me on Twitter. To everyone who purchased a copy of this, thank you! NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| Contents 1. Foreword............................................ 1 2. Introduction.......................................... 3 How It All Started..................................... 3 Just 30 Examples and My First Sale.......................... 4 Who This Book Is Written For............................. 6 Chapter Overview..................................... 7 Word of Warning and a Favour............................ 9 3. Background.......................................... 10 4. Open Redirect Vulnerabilities.............................. 13 Description........................................... 13 Examples............................................. 14 1. Shopify Theme Install Open Redirect....................... 14 2. Shopify Login Open Redirect............................ 14 3. HackerOne Interstitial Redirect.......................... 16 Summary............................................. 17 5. HTTP Parameter Pollution................................. 19 Description........................................... 19 Examples............................................. 22 1. HackerOne Social Sharing Buttons........................ 22 2. Twitter Unsubscribe Notifications......................... 23 3. Twitter Web Intents.................................. 24 Summary............................................. 27 6. Cross-Site Request Forgery................................ 28 Description........................................... 28 Examples............................................. 32 1. Shopify Twitter Disconnect............................. 32 2. Change Users Instacart Zones........................... 34 3. Badoo Full Account Takeover............................ 35 Summary............................................. 37 NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| CONTENTS 7. HTML Injection........................................ 38 Description........................................... 38 Examples............................................. 38 1. Coinbase Comments................................. 38 2. HackerOne Unintended HTML Inclusion..................... 40 3. Within Security Content Spoofing......................... 41 Summary............................................. 43 8. CRLF Injection......................................... 44 Description........................................... 44 1. Twitter HTTP Response Splitting.......................... 45 2. v.shopify.com Response Splitting......................... 47 Summary............................................. 49 9. Cross-Site Scripting..................................... 50 Description........................................... 50 Examples............................................. 55 1. Shopify Wholesale................................... 55 2. Shopify Giftcard Cart................................. 57 3. Shopify Currency Formatting............................ 59 4. Yahoo Mail Stored XSS................................ 60 5. Google Image Search................................. 62 6. Google Tagmanager Stored XSS.......................... 63 7. United Airlines XSS.................................. 64 Summary............................................. 69 10. Template Injection...................................... 70 Description........................................... 70 Server Side Template Injections............................ 70 Client Side Template Injections............................ 71 Examples............................................. 72 1. Uber Angular Template Injection......................... 72 2. Uber Template Injection............................... 73 3. Rails Dynamic Render................................ 76 Summary............................................. 77 11. SQL Injection......................................... 78 Description........................................... 78 SQL Databases....................................... 78 Countermeasures Against SQLi............................ 80 Examples............................................. 80 1. Drupal SQL Injection................................. 80 2. Yahoo Sports Blind SQL............................... 83 3. Uber Blind SQLi.................................... 86 NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| CONTENTS Summary............................................. 89 12. Server Side Request Forgery............................... 90 Description........................................... 90 HTTP Request Location................................. 90 Invoking GET Versus POST Requests......................... 91 Blind SSRFs......................................... 91 Leveraging SSRF...................................... 92 Examples............................................. 93 1. ESEA SSRF and Querying AWS Metadata..................... 93 2. Google Internal DNS SSRF.............................. 94 3. Internal Port Scanning................................ 98 Summary............................................. 100 13. XML External Entity Vulnerability............................ 101 Description........................................... 101 Examples............................................. 106 1. Read Access to Google................................ 106 2. Facebook XXE with Word............................... 107 3. Wikiloc XXE....................................... 110 Summary............................................. 113 14. Remote Code Execution.................................. 114 Description........................................... 114 Examples............................................. 114 1. Polyvore ImageMagick................................ 114 2. Algolia RCE on facebooksearch.algolia.com................... 116 3. Foobar Smarty Template Injection RCE...................... 118 Summary............................................. 122 15. Memory............................................. 123 Description........................................... 123 Buffer Overflow...................................... 123 Read out of Bounds................................... 124 Memory Corruption................................... 126 Examples............................................. 127 1. PHP ftp_genlist().................................... 127 2. Python Hotshot Module............................... 128 3. Libcurl Read Out of Bounds............................. 129 4. PHP Memory Corruption............................... 130 Summary............................................. 131 16. Sub Domain Takeover.................................... 132 Description........................................... 132 NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| CONTENTS Examples............................................. 132 1. Ubiquiti Sub Domain Takeover........................... 132 2. Scan.me Pointing to Zendesk............................ 133 3. Shopify Windsor Sub Domain Takeover..................... 134 4. Snapchat Fastly Takeover.............................. 135 5. api.legalrobot.com.................................. 137 6. Uber SendGrid Mail Takeover............................ 140 Summary............................................. 143 17. Race Conditions........................................ 144 Description........................................... 144 Examples............................................. 146 1. Starbucks Race Conditions............................. 146 2. Accepting HackerOne Invites Multiple Times.................. 147 3. Exceeding Keybase Invitation Limits....................... 150 4. HackerOne Payments................................. 151 Summary............................................. 153 18. Insecure Direct Object References........................... 154 Description........................................... 154 Examples............................................. 155 1. Binary.com Privilege Escalation.......................... 155 2. Moneybird App Creation............................... 156 3. Twitter Mopub API Token Stealing......................... 158 Summary............................................. 160 19. OAuth.............................................. 161 Description........................................... 161 Examples............................................. 165 1. Swiping Facebook Official Access Tokens.................... 165 2. Stealing Slack OAuth Tokens............................ 166 3. Stealing Google Drive Spreadsheets....................... 167 Summary............................................. 170 20. Application Logic Vulnerabilities............................ 171 Description........................................... 171 Examples............................................. 172 1. Shopify Administrator Privilege Bypass..................... 172 2. HackerOne Signal Manipulation.......................... 173 3. Shopify S3 Buckets Open.............................. 174 4. HackerOne S3 Buckets Open............................ 175 5. Bypassing GitLab Two Factor Authentication.................. 177 6. Yahoo PHP Info Disclosure............................. 179 7. HackerOne Hacktivity Voting............................ 180 NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| CONTENTS 8. Accessing PornHub’s Memcache Installation.................. 183 9. Bypassing Twitter Account Protections...................... 185 Summary............................................. 186 21. Getting Started........................................ 188 Reconnaissance........................................ 188 Subdomain Enumeration................................ 189 Port Scanning....................................... 190 Screenshotting...................................... 190 Content Discovery.................................... 191 Previous Bugs....................................... 192 Testing the Application.................................... 193 The Technology Stack.................................. 193 Functionality Mapping.................................. 194 Finding Vulnerabilities.................................. 195 Going Further.......................................... 196 Summary............................................. 198 22. Vulnerability Reports.................................... 199 Read the disclosure guidelines................................ 199 Include Details. Then Include More............................. 199 Confirm the Vulnerability.................................. 200 Show Respect for the Company.............................. 200 Bounties............................................. 202 Don’t Shout Hello Before Crossing the Pond...................... 202 Parting Words.......................................... 203 23. Tools............................................... 205 Burp Suite............................................ 205 ZAP Proxy............................................ 205 Knockpy............................................. 206 HostileSubBruteforcer.................................... 206 Sublist3r............................................. 206 crt.sh............................................... 206 IPV4info.com.......................................... 207 SecLists.............................................. 207 XSSHunter............................................ 207 sqlmap.............................................. 207 Nmap............................................... 208 Eyewitness............................................ 208 Gowitness............................................ 209 Gobuster............................................. 209 Meg................................................ 209 Shodan.............................................. 209 NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| CONTENTS Censys.............................................. 210 What CMS............................................ 210 BuiltWith............................................. 210 Nikto............................................... 210 Recon-ng............................................. 211 GitRob.............................................. 211 CyberChef............................................ 211 OnlineHashCrack.com.................................... 212 idb................................................. 212 Wireshark............................................ 212 Bucket Finder.......................................... 212 Race the Web.......................................... 212 Google Dorks.......................................... 213 JD GUI............................................... 213 Mobile Security Framework................................. 213 Ysoserial............................................. 213 Firefox Plugins......................................... 214 FoxyProxy.......................................... 214 User Agent Switcher................................... 214 Firebug........................................... 214 Hackbar........................................... 214 Websecurify........................................ 214 Cookie Manager+..................................... 215 XSS Me........................................... 215 Offsec Exploit-db Search................................ 215 Wappalyzer......................................... 215 24. Resources............................................ 216 Online Training......................................... 216 Web Application Exploits and Defenses....................... 216 The Exploit Database................................... 216 Udacity........................................... 216 Bug Bounty Platforms..................................... 216 Hackerone.com...................................... 216 Bugcrowd.com...................................... 217 Synack.com......................................... 217 Cobalt.io.......................................... 217 Video Tutorials....................................... 217 youtube.com/yaworsk1................................. 217 Seccasts.com........................................ 217 How to Shot Web..................................... 217 Further Reading........................................ 218 OWASP.com........................................ 218 NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| CONTENTS Hackerone.com/hacktivity............................... 218 https://bugzilla.mozilla.org............................... 218 Twitter #infosec and #bugbounty.......................... 218 Twitter @disclosedh1.................................. 218 Web Application Hackers Handbook......................... 218 Bug Hunters Methodology............................... 219 Recommended Blogs..................................... 219 philippeharewood.com................................. 219 Philippe’s Facebook Page - www.facebook.com/phwd-113702895386410. 219 fin1te.net.......................................... 219 NahamSec.com...................................... 219 blog.it-securityguard.com............................... 220 blog.innerht.ml...................................... 220 blog.orange.tw...................................... 220 Portswigger Blog..................................... 220 Nvisium Blog........................................ 220 blog.zsec.uk........................................ 220 brutelogic.com.br..................................... 220 lcamtuf.blogspot.ca................................... 221 Bug Crowd Blog...................................... 221 HackerOne Blog...................................... 221 Cheatsheets........................................... 221 25. Glossary............................................. 222 Black Hat Hacker..................................... 222 Buffer Overflow...................................... 222 Bug Bounty Program................................... 222 Bug Report......................................... 222 CRLF Injection....................................... 222 Cross Site Request Forgery............................... 223 Cross Site Scripting.................................... 223 HTML Injection...................................... 223 HTTP Parameter Pollution............................... 223 HTTP Response Splitting................................ 223 Memory Corruption................................... 223 Open Redirect....................................... 224 Penetration Testing.................................... 224 Researchers........................................ 224 Response Team...................................... 224 Responsible Disclosure................................. 224 Vulnerability........................................ 224 Vulnerability Coordination............................... 225 Vulnerability Disclosure................................. 225 NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| CONTENTS White Hat Hacker..................................... 225 26. Appendix A - Take Aways.................................. 226 Open Redirects......................................... 226 HTTP Parameter Pollution.................................. 227 Cross Site Request Forgery................................. 227 HTML Injection......................................... 228 CRLF Injections......................................... 229 Cross-Site Scripting...................................... 229 SSTI................................................ 231 SQL Injection.......................................... 232 Server Side Request Forgery................................. 232 XML External Entity Vulnerability.............................. 233 Remote Code Execution................................... 234 Memory............................................. 235 Sub Domain Takeover..................................... 236 Race Conditions........................................ 237 Insecure Direct Object References............................. 238 OAuth............................................... 239 Application Logic Vulnerabilities.............................. 240 27. Appendix B - Web Hacking 101 Changelog...................... 242 NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| 1. Foreword The best way to learn is simply by doing. That is how we - Michiel Prins and Jobert Abma - learned to hack. We were young. Like all hackers who came before us, and all of those who will come after, we were driven by an uncontrollable, burning curiosity to understand how things worked. We were mostly playing computer games, and by age 12 we decided to learn how to build software of our own. We learned how to program in Visual Basic and PHP from library books and practice. From our understanding of software development, we quickly discovered that these skills allowed us to find other developers’ mistakes. We shifted from building to breaking and hacking has been our passion ever since. To celebrate our high school graduation, we took over a TV station’s broadcast channel to air an ad congratulating our graduating class. While amusing at the time, we quickly learned there are consequences and these are not the kind of hackers the world needs. The TV station and school were not amused and we spent the summer washing windows as our punishment. In college, we turned our skills into a viable consulting business that, at its peak, had clients in the public and private sector across the entire world. Our hacking experience led us to HackerOne, a company we co-founded in 2012. We wanted to allow every company in the universe to work with hackers successfully and this continues to be HackerOne’s mission today. If you’re reading this, you also have the curiosity needed to be a hacker and bug hunter. We believe this book will be a tremendous guide along your journey. It’s filled with rich, real world examples of security vulnerability reports that resulted in real bug bounties, along with helpful analysis and review by Pete Yaworski, the author and a fellow hacker. He is your companion as you learn, and that’s invaluable. Another reason this book is so important is that it focuses on how to become an ethical hacker. Mastering the art of hacking can be an extremely powerful skill that we hope will be used for good. The most successful hackers know how to navigate the thin line between right and wrong while hacking. Many people can break things, and even try to make a quick buck doing so. But imagine you can make the Internet safer, work with amazing companies around the world, and even get paid along the way. Your talent has the potential of keeping billions of people and their data secure. That is what we hope you aspire to. We are grateful to no end to Pete for taking his time to document all of this so eloquently. We wish we had this resource when we were getting started. Pete’s book is a joy to read with the information needed to kickstart your hacking journey. NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| Foreword 2 Happy reading, and happy hacking! Remember to hack responsibly. Michiel Prins and Jobert Abma Co-Founders, HackerOne NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| 2. Introduction Thank you for purchasing this book, I hope you have as much fun reading it as I did researching and writing it. Web Hacking 101 is my first book, meant to help you get started hacking. I began writing this as a self-published explanation of 30 vulnerabilities, a by-product of my own learning. It quickly turned into so much more. My hope for the book, at the very least, is to open your eyes to the vast world of hacking. At best, I hope this will be your first step towards making the web a safer place while earning some money doing it. How It All Started In late 2015, I stumbled across the book, We Are Anonymous: Inside the Hacker World of LulzSec, Anonymous and the Global Cyber Insurgency by Parmy Olson and ended up reading it in a week. Having finished it though, I was left wondering how these hackers got started. I was thirsty for more, but I didn’t just want to know WHAT hackers did, I wanted to know HOW hackers did it. So I kept reading. But each time I finsihed a new book, I was still left with the same questions: How do other Hackers learn about the vulnerabilities they find? Where are people finding vulnerabilities? How do Hackers start the process of hacking a target site? Is Hacking just about using automated tools? How can I get started finding vulnerabilities? But looking for more answers, kept opening more and more doors. Around this same time, I was taking Coursera Android development courses and keeping an eye out for other interesting courses. The Coursera Cybersecurity specialization caught my eye, particularly Course 2, Software Security. Luckily for me, it was just starting (as of February 2016, it is listed as Coming Soon) and I enrolled. A few lectures in, I finally understood what a buffer overflow was and how it was exploited. I fully grasped how SQL injections were achieved whereas before, I only knew the danger. In short, I was hooked. Up until this point, I always approached web security NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| Introduction 4 from the developer’s perspective, appreciating the need to sanitize values and avoid using user input directly. Now I was beginning to understand what it all looked like from a hacker’s perspective. I kept looking for more information on how to hack and came across Bugcrowd’s forums. Unfortunately they weren’t overly active at the time but there someone mentioned HackerOne’s hacktivity and linked to a report. Following the link, I was amazed. I was reading a description of a vulnerability, written to a company, who then disclosed it to the world. Perhaps more importantly, the company actually paid the hacker to find and report this! That was a turning point, I became obsessed. Especially when a homegrown Canadian company, Shopify, seemed to be leading the pack in disclosures at the time. Checking out Shopify’s profile, their disclosure list was littered with open reports. I couldn’t read enough of them. The vulnerabilities included Cross-Site Scripting, Authentication and Cross-Site Request Forgery, just to name a few. Admittedly, at this stage, I was struggling to understand what the reports were detailing. Some of the vulnerabilities and methods of exploitation were hard to understand. Searching Google to try and understand one particular report, I ended on a GitHub issue thread for an old Ruby on Rails default weak parameter vulnerability (this is detailed in the Application Logic chapter) reported by Egor Homakov. Following up on Egor led me to his blog, which includes disclosures for some seriously complex vulnerabilities. Reading about his experiences, I realized, the world of hacking might benefit from plain language explanations of real world vulnerabilities. And it just so happened, that I learn better when teaching others. And so, Web Hacking 101 was born. Just 30 Examples and My First Sale I decided to start out with a simple goal, find and explain 30 web vulnerabilities in easy to understand, plain language. I figured, at worst, researching and writing about vulnerabilities would help me learn about hacking. At best, I’d sell a million copies, become a self-publishing guru and retire early. The latter has yet to happen and at times, the former seems endless. Around the 15 explained vulnerabilities mark, I decided to publish my draft so it could be purchased - the platform I chose, LeanPub (which most have probably purchased through), allows you to publish iteratively, providing customers with access to all updates. I sent out a tweet thanking HackerOne and Shopify for their disclosures and to tell the world about my book. I didn’t expect much. NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| Introduction 5 But within hours, I made my first sale. Elated at the idea of someone actually paying for my book (something I created and was pouring a tonne of effort into!), I logged on to LeanPub to see what I could find out about the mystery buyer. Turns out nothing. But then my phone vibrated, I received a tweet from Michiel Prins saying he liked the book and asked to be kept in the loop. Who the hell is Michiel Prins? I checked his Twitter profile and turns out, he’s one of the Co-Founders of HackerOne. Shit. Part of me thought HackerOne wouldn’t be impressed with my reliance on their site for content. I tried to stay positive, Michiel seemed supportive and did ask to be kept in the loop, so probably harmless. Not long after my first sale, I received a second sale and figured I was on to something. Coincidentally, around the same time, I got a notification from Quora about a question I’d probably be interested in, How do I become a successful Bug bounty hunter? Given my experience starting out, knowing what it was like to be in the same shoes and with the selfish goal of wanting to promote my book, I figured I’d write an answer. About half way through, it dawned on me that the only other answer was written by Jobert Abma, one of the other Co-Founders of HackerOne. A pretty authoritative voice on hacking. Shit. I contemplated abandoning my answer but then elected to rewrite it to build on his input since I couldn’t compete with his advice. I hit submit and thought nothing of it. But then I received an interesting email: Hi Peter, I saw your Quora answer and then saw that you are writing a book about White Hat hacking. Would love to know more. Kind regards, Marten CEO, HackerOne Triple Shit. A lot of things ran through my mind at this point, none of which were positive and pretty much all were irrational. In short, I figured the only reason Marten would email me was to drop the hammer on my book. Thankfully, that couldn’t have been further from the truth. I replied to him explaining who I was and what I was doing - that I was trying to learn how to hack and help others learn along with me. Turns out, he was a big fan of the idea. He explained that HackerOne is interested in growing the community and supporting hackers as they learn as it’s mutually beneficial to everyone involved. In short, he offered to help. And man, has he ever. This book probably wouldn’t be where it is today or include half the content without his and HackerOne’s constant support and motivation. Since that initial email, I kept writing and Marten kept checking in. Michiel and Jobert reviewed drafts, provided suggestions and even contributed some sections. Marten even NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| Introduction 6 went above and beyond to cover the costs of a professionally designed cover (goodbye plain yellow cover with a white witches’ hat, all of which looked like it was designed by a four year old). In May 2016, Adam Bacchus joined HackerOne and on his 5th day working there, he read the book, provided edits and was explaining what it was like to be on the receiving end of vulnerability reports - something I’ve now included in the report writing chapter. I mention all this because throughout this journey, HackerOne has never asked for anything in return. They’ve just wanted to support the community and saw this book was a good way of doing it. As someone new to the hacking community, that resonated with me and I hope it does with you too. I personally prefer to be part of a supportive and inclusive community. So, since then, this book has expanded dramatically, well beyond what I initially envi- sioned. And with that, the target audience has also changed. Who This Book Is Written For This book is written with new hackers in mind. It doesn’t matter if you’re a web developer, web designer, stay at home mom, a 10 year old or a 75 year old. I want this book to be an authoritative reference for understanding the different types of vulnerabilities, how to find them, how to report them, how to get paid and even, how to write defensive code. That said, I didn’t write this book to preach to the masses. This is really a book about learning together. As such, I share successes AND some of my notable (and embarrassing) failures. The book also isn’t meant to be read cover to cover, if there is a particular section you’re interested in, go read it first. In some cases, I do reference sections previously discussed, but doing so, I try to connect the sections so you can flip back and forth. I want this book to be something you keep open while you hack. On that note, each vulnerability type chapter is structured the same way: Begin with a description of the vulnerability type; Review examples of the vulnerability; and, Conclude with a summary. Similarly, each example within those chapters is structured the same way and includes: My estimation of the difficulty finding the vulnerability The url associated with where the vulnerability was found A link to the report or write up NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| Introduction 7 The date the vulnerability was reported The amount paid for the report An easy to understand description of the vulnerability Take aways that you can apply to your own efforts Lastly, while it’s not a prerequisite for hacking, it is probably a good idea to have some familiarity with HTML, CSS, Javascript and maybe some programming. That isn’t to say you need to be able to put together web pages from scratch, off the top of your head but understanding the basic structure of a web page, how CSS defines a look and feel and what can be accomplished with Javascript will help you uncover vulnerabilities and understand the severity of doing so. Programming knowledge is helpful when you’re looking for application logic vulnerabilities. If you can put yourself in the programmer’s shoes to guess how they may have implemented something or read their code if it’s available, you’ll be ahead in the game. To do so, I recommend checking out Udacity’s free online courses Intro to HTML and CSS and Javacript Basics, links to which I’ve included in the Resources chapter. If you’re not familiar with Udacity, it’s mission is to bring accessible, affordable, engaging and highly effective higher education to the world. They’ve partnered with companies like Google, AT&T, Facebook, Salesforce, etc. to create programs and offer courses online. Chapter Overview Chapter 2 is an introductory background to how the internet works, including HTTP requests and responses and HTTP methods. Chapter 3 covers Open Redirects, an interesting vulnerability which involves exploiting a site to direct users to visit another site which allows an attacker to exploit a user’s trust in the vulnerable site. Chapter 4 covers HTTP Parameter Pollution and in it, you’‘ll learn how to find systems that may be vulnerable to passing along unsafe input to third party sites. Chapter 5 covers Cross-Site Request Forgery vulnerabilities, walking through examples that show how users can be tricked into submitting information to a website they are logged into unknowingly. Chapter 6 covers HTML Injections and in it, you’ll learn how being able to inject HTML into a web page can be used maliciously. One of the more interesting takeaways is how you can use encoded values to trick sites into accepting and rendering the HTML you submit, bypassing filters. Chapter 7 covers Carriage Return Line Feed Injections and in it, looking at examples of submitting carriage return, line breaks to sites and the impact it has on rendered content. NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| Introduction 8 Chapter 8 covers Cross-Site Scripting, a massive topic with a huge variety of ways to achieve exploits. Cross-Site Scripting represents huge opportunities and an entire book could and probably should, be written solely on it. There are a tonne of examples I could have included here so I try to focus on the most interesting and helpful for learning. Chapter 9 covers Server Side Template Injection, as well as client side injections. These types of vulnerabilities take advantage of developers injecting user input directly into templates when submitted using the template syntax. The impact of these vulnerabilities depends on where they occur but can often lead to remote code executions. Chapter 10 covers structured query language (SQL) injections, which involve manipulat- ing database queries to extract, update or delete information from a site. Chapter 11 covers Server Side Request Forgery which allows an attacker to user a remote server to make subsequent HTTP requests on the attacker’s behalf. Chapter 12 covers XML External Entity vulnerabilities resulting from a sites parsing of extensible markup language (XML). These types of vulnerabilities can include things like reading private files, remote code execution, etc. Chapter 13 covers Remote Code Execution, or the ability for an attacker to execute arbitrary code on a victim server. This type of vulnerability is among the most dangerous since an attacker can control what code is executed and is usually rewarded as such. Chapter 14 covers memory related vulnerabilities, a type of vulnerability which can be tough to find and are typically related to low level programming languages. However, discovering these types of bugs can lead to some pretty serious vulnerabilities. Chapter 15 covers Sub Domain Takeovers, something I learned a lot about researching this book and should be largely credited to Mathias, Frans and the Dectectify team. Essentially here, a site refers to a sub domain hosting with a third party service but never actually claims the appropriate address from that service. This would allow an attacker to register the address from the third party so that all traffic, which believes it is on the victim’s domain, is actually on an attacker’s. Chapter 16 covers Race Conditions, a vulnerability which involves two or more processes performing action based on conditions which should only permit one action to occur. For example, think of bank transfers, you shouldn’t be able to perform two transfers of $500 when your balance is only $500. However, a race condition vulnerability could permit it. Chapter 17 covers Insecure Direct Object Reference vulnerabilities whereby an attacker can read or update objections (database records, files, etc) which they should not have permission to. Chapter 18 covers application logic based vulnerabilities. This chapter has grown into a catch all for vulnerabilities I consider linked to programming logic flaws. I’ve found these types of vulnerabilities may be easier for a beginner to find instead of looking for weird and creative ways to submit malicious input to a site. NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| Introduction 9 Chapter 19 covers the topic of how to get started. This chapter is meant to help you consider where and how to look for vulnerabilities as opposed to a step by step guide to hacking a site. It is based on my experience and how I approach sites. Chapter 20 is arguably one of the most important book chapters as it provides advice on how to write an effective report. All the hacking in the world means nothing if you can’t properly report the issue to the necessary company. As such, I scoured some big name bounty paying companies for their advice on how best to report and got advice from HackerOne. Make sure to pay close attention here. Chapter 21 switches gears. Here we dive into recommended hacking tools. The initial draft of this chapter was donated by Michiel Prins from HackerOne. Since then it’s grown to a living list of helpful tools I’ve found and used. Chapter 22 is dedicated to helping you take your hacking to the next level. Here I walk you through some awesome resources for continuing to learn. Again, at the risk of sounding like a broken record, big thanks to Michiel Prins for contributing to the original list which started this chapter. Chapter 23 concludes the book and covers off some key terms you should know while hacking. While most are discussed in other chapters, some aren’t so I’d recommend taking a read here. Word of Warning and a Favour Before you set off into the amazing world of hacking, I want to clarify something. As I was learning, reading about public disclosures, seeing all the money people were (and still are) making, it became easy to glamorize the process and think of it as an easy way to get rich quick. It isn’t. Hacking can be extremely rewarding but it’s hard to find and read about the failures along the way (except here where I share some pretty embarrassing stories). As a result, since you’ll mostly hear of peoples’ successes, you may develop unrealistic expectations of success. And maybe you will be quickly successful. But if you aren’t, keep working! It will get easier and it’s a great feeling to have a report resolved. With that, I have a favour to ask. As you read, please message me on Twitter @yaworsk and let me know how it’s going. Whether successful or unsuccessful, I’d like to hear from you. Bug hunting can be lonely work if you’re struggling but its also awesome to celebrate with each other. And maybe your find will be something we can include in the next edition. Good luck!! NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| 3. Background If you’re starting out fresh like I was and this book is among your first steps into the world of hacking, it’s going to be important for you to understand how the internet works. Before you turn the page, what I mean is how the URL you type in the address bar is mapped to a domain, which is resolved to an IP address, etc. To frame it in a sentence: the internet is a bunch of systems that are connected and sending messages to each other. Some only accept certain types of messages, some only allow messages from a limited set of other systems, but every system on the internet receives an address so that people can send messages to it. It’s then up to each system to determine what to do with the message and how it wants to respond. To define the structure of these messages, people have documented how some of these systems should communicate in Requests for Comments (RFC). As an example, take a look at HTTP. HTTP defines the protocol of how your internet browser communicates with a web server. Because your internet browser and web server agreed to implement the same protocol, they are able to communicate. When you enter http://www.google.com in your browser’s address bar and press return, the following steps describe what happens on a high level: Your browser extracts the domain name from the URL, www.google.com. Your computer sends a DNS request to your computer’s configured DNS servers. DNS can help resolve a domain name to an IP address, in this case it resolves to 216.58.201.228. Tip: you can use dig A www.google.com from your terminal to look up IP addresses for a domain. Your computer tries to set up a TCP connection with the IP address on port 80, which is used for HTTP traffic. Tip: you can set up a TCP connection by running nc 216.58.201.228 80 from your terminal. If it succeeds, your browser will send an HTTP request like: GET / HTTP/1.1 Host: www.google.com Connection: keep-alive Accept: application/html, **;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br DNT: 1 Referer: https://moneybird.com/user/applications/new Cookie: _moneybird_session=XXXXXXXXXXXXXXX; trusted_computer= Connection: close Content-Type: application/x-www-form-urlencoded Content-Length: 397 utf8=%E2%9C%93&authenticity_token=REDACTED&doorkeeper_application%5Bname%5D=TWDApp&t\ oken_type=access_token&administration_id=ABCDEFGHIJKLMNOP&scopes%5B%5D=sales_invoice\ s&scopes%5B%5D=documents&scopes%5B%5D=estimates&scopes%5B%5D=bank&scopes%5B%5D=setti\ ngs&doorkeeper_application%5Bredirect_uri%5D=&commit=Save As you can see, the call includes an administration_id, which turns out to be the account id for the businesses users are added to. Even more interesting was the fact that despite the account number being a 18 digit number (at the time of my testing), it was immediately disclosed to the added user to the account after they logged in via the URL. So, when User B logged in, they (or rather I) were redirected to Account A at https://moneybird.com/ABCDEFGHIJKLMNOP (based on our example id above) with ABCDEFGHIJKLMOP being the administration_id. With these two pieces of information, it was only natural to use my invitee user, User B, to try and create an application for User A’s business, despite not being given explicit permission to do so. As a result, with User B, I created a second business which User B owned and was in total control of (i.e., User B had full permissions on Account B and could create apps for it, but was not supposed to have permission to create apps for Account A). I went to the settings page for Account B and added an app, intercepting the POST call to replace the administration_id with that from Account A’s URL and it worked. As User B, I had an app with full permissions to Account A despite my user only having limited permissions to invoicing. Turns out, an attacker could use this vulnerability to bypass the platform permissions and create an app with full permissions provided they were added to a business or compromised a user account, regardless of the permissions for that user account. Despite having just gone live not long before, and no doubt being inundated with reports, Moneybird had the issue resolved and paid within the month. Definitely a great team to work with, one I recommend. NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| Insecure Direct Object References 158 Takeaways Testing for IDORs requires keen observation as well as skill. When reviewing HTTP requests for vulnerabilities, be on the lookout for account identifiers like the administration_id in the above. While the field name, administration_id is a little misleading compared to it being called account_id, being a plain integer was a red flag that I should check it out. Additionally, given the length of the parameter, it would have been difficult to exploit the vulnerability without making a bunch of network noise, having to repeat requests searching for the right id. If you find similar vulnerabilities, to improve your report, always be on the lookout for HTTP responses, urls, etc. that disclose ids. Luckily for me, the id I needed was included in the account URL. 3. Twitter Mopub API Token Stealing Difficulty: Medium Url: https://mopub.com/api/v3/organizations/ID/mopub/activate Report Link: https://hackerone.com/reports/955523 Date Reported: October 24, 2015 Bounty Paid: $5,040 Description: In October 2015, Akhil Reni (https://hackerone.com/wesecureapp) reported that Twit- ter’s Mopub application (a Twitter acquisition from 2013) was vulnerable to an IDOR bug which allowed attackers to steal API keys and ultimately takeover a victim’s account. Interestingly though, the account takeover information wasn’t provided with the initial report - it was provided 19 days after via comment, luckily before Twitter paid a bounty. According to his report, this vulnerability was caused by a lack of permission validation on the POST call to Mopub’s activate endpoint. Here’s what it looked like: 3 https://hackerone.com/reports/95552 NEWOUTLOOK.IT Technet24 |||||||||||||||||||| |||||||||||||||||||| Insecure Direct Object References 159 POST /api/v3/organizations/5460d2394b793294df01104a/mopub/activate HTTP/1.1 Host: fabric.io User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate X-CSRF-Token: 0jGxOZOgvkmucYubALnlQyoIlsSUBJ1VQxjw0qjp73A= Content-Type: application/x-www-form-urlencoded; charset=UTF-8 X-CRASHLYTICS-DEVELOPER-TOKEN: 0bb5ea45eb53fa71fa5758290be5a7d5bb867e77 X-Requested-With: XMLHttpRequest Referer: https://fabric.io/img-srcx-onerrorprompt15/android/apps/app.myapplication/m\ opub Content-Length: 235 Cookie: Connection: keep-alive Pragma: no-cache Cache-Control: no-cache company_name=dragoncompany&address1=123 street&address2=123&city=hollywood&state=cal\ ifornia&zip_code=90210&country_code=US&link=false Which resulted in the following response: {"mopub_identity":{"id":"5496c76e8b15dabe9c0006d7","confirmed":true,"primary":false,\ "service":"mopub","token":"35592"},"organization":{"id":"5460d2394b793294df01104a","\ name":"test","alias":"test2","api_key":"8590313c7382375063c2fe279a4487a98387767a","e\ nrollments":{"beta_distribution":"true"},"accounts_count":3,"apps_counts":{"android"\ :2},"sdk_organization":true,"build_secret":"5ef0323f62d71c475611a635ea09a3132f037557\ d801503573b643ef8ad82054","mopub_id":"33525"}} In these calls, you’ll see that the organization id was included as part of the URL, similar to example 2 above. In the response, Mopub confirms the organization id and also provides the api_key. Again, similar to the example above, while the organization id is an unguessable string, it was being leaked on the platform, details of which unfortunately weren’t shared in this disclosure. Now, as mentioned, after the issue was resolved, Akhil flagged for Twitter that this vul- nerability could have been abused to completely take over the victim’s account. To do so, the attacker would have to take the stolen API key and substitute it for the build secret in the URL https://app.mopub.com/complete/htsdk/?code=BUILDSECRET&next=%2d. After doing so, the attacker would have access to the victim’s Mopub account and all apps/organizations from Twitter’s mobile development platform, Fabric. NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| Insecure Direct Object References 160 Takeaways While similar to the Moneybird example above, in that both required abusing leaked organization ids to elevate privileges, this example is great because it demonstrates the severity of being able to attack users remotely, with zero interaction on their behalf and the need to demonstrate a full exploit. Initially, Akhil did not include or demonstrate the full account takeover and based on Twitter’s response to his mentioning it (i.e., asking for details and full steps to do so), they may not have considered that impact when initially resolving the vulnerability. So, when you report, make sure to fully consider and detail the full impact of the vulnerability you are reporting, including steps to reproduce it. Summary IDOR vulnerabilities occurs when an attacker can access or modify some reference to an object which should actually be inaccessible to that attacker. They are a great vulnerability to test for and find because their complexity ranges from simple, exploiting simple integers by adding and subtracting, to more complex where UUIDs or random identifiers are used. In the event a site is using UUIDs or random identifiers, all is not lost. It may be possible to guess those identifiers or find places where the site is leaking the UUIDs. This can include JSON responses, HTML content responses and URLs as a few examples. When reporting, be sure to consider how an attacker can abuse the vulnerability. For example, while my Moneybird example required a user being added to an account, an attacker could exploit the IDOR to completely bypass the platform permissions by compromising any user on the account. NEWOUTLOOK.IT Technet24 |||||||||||||||||||| |||||||||||||||||||| 19. OAuth Description According to the OAuth site, it is an open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications. In other words, OAuth is a form of user authentication which allows users to permit websites or applications to access their information from another site without disclosing or sharing their password. This is the underlying process which allows you to login to a site using Facebook, Twitter, LinkedIn, etc. There are two versions of OAuth, 1.0 and 2.0. They are not compatible with each other and for the purposes of this Chapter, we’ll be working with 2.0. Since the process can be pretty confusing and the implementation has a lot of potential for mistakes, I’ve included a great image from Philippe Harewood’s1 blog depicting the general process: 1 https://www.philippeharewood.com NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| OAuth 162 Philippe Harewood - Facebook OAuth Process Let’s break this down. To begin, you’ll notice there three titles across the top: User’s Browser, Your App’s Server-side Code and Facebook API. In OAuth terms, these are actually the Resource Owner, Client and Resource Server. The key takeaway is that your browser will be performing and handling a number of HTTP requests to facilitate you, as the Resource Owner, instructing the Resource Server to allow the Client access to your personal information, as defined by the scopes requested. Scopes are like permissions and they control access to specific pieces of information. For example, Facebook scopes include email, public_profile, user_friends, etc. So, if you only granted the email scope, a site could only access that Facebook information and not your friends, profile, etc. That said, let’s walk through the steps. Step 1 You can see that the OAuth process all begins the User’s browser and a user clicking “Login with Facebook”. Clicking this results in a GET request to the site you are. The path usually looks something like www.example.com/oauth/facebook. NEWOUTLOOK.IT Technet24 |||||||||||||||||||| |||||||||||||||||||| OAuth 163 Step 2 The site will response with a 302 redirect which instructs your browser to perform a GET request to the URL defined in the location header. The URL will look something like: https://www.facebook.com/v2.0/dialog/oauth?client_id=123 &redirect_uri=https%3A%2F%2Fwww.example.com%2Foauth%2Fcallback &response_type=code&scope=email&state=XYZ There are a couple of important pieces to this URL. First, the client_id identifies which site you are coming from. The redirect_uri tells Facebook where to send you back to after you have permitted the site (the client) to access the information defined by the scope, also included in the URL. Next, the response_type tells Facebook what to return, this can be a token or a code. The difference between these two is important, a code is used by the permitted site (the client) to call back to the Resource Server, or Facebook in our example, again to get a token. On the other hand, requesting and receiving a token in this first stop would provide immediate access to the resource server to query account information as long as that token was valid. Lastly, the state value acts as a type of CSRF protection. The requesting site (the client) should include this in their original call to the resource server and it should return the value to ensure that a) the original request was invoked by the site and b) the response has not be tampered with. Step 3 Next, if a user accepts the OAuth dialog pop up and grants the client permissions to their information on the resource server, or Facebook in our example, it will respond to the browser with a 302 redirect back to the site (client), defined by the redirect_uri and include a code or token, depending on the response_type (it is usually code) in the initial URL. Step 4 The browser will make a GET request to the site (client), including the code and state values provided by the resource server in the URL. Step 5 The site (client) should validate the state value to ensure the process wasn’t tampered with and use the code along with their client_secret (which only they know) to make a GET request to the resource server, or Facebook here, for a token. NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| OAuth 164 Step 6 The resource server, or Facebook in this example, responds to the site (client) with a token which permits the site (client) to make API calls to Facebook and access the scopes which you allowed in Step 3. Now, with that whole process in mind, one thing to note is, after you have authorized the site (client) to access the resource server, Facebook in this example, if you visit the URL from Step 2 again, the rest of the process will be performed completely in the background, with no required user interaction. So, as you may have guessed, one potential vulnerability to look for with OAuth is the ability to steal tokens which the resource server returns. Doing so would allow an attacker to access the resource server on behalf of the victim, accessing whatever was permitted via the scopes in the Step 3 authorization. Based on my research, this typically is a result of being able to manipulate the redirect_uri and requesting a token instead of a code. So, the first step to test for this comes in Step 2. When you get redirected to the resource server, modify the response_type and see if the resource server will return a token. If it does, modify the redirect_uri to confirm how the site or app was configured. Here, some OAuth resource servers may be misconfigured themselves and permit URLs like www.example.ca, [email protected], etc. In the first example, adding.ca actually changes the domain of the site. So if you can do something similar and purchase the domain, tokens would be sent to your server. In the second example, adding @ changes the URL again, treating the first half as the user name and password to send to attacker.com. Each of these two examples provides the best possible scenario for you as a hacker if a user has already granted permission to the site (client). By revisiting the now malicious URL with a modified response_type and redirect_uri, the resource server would recognize the user has already given permission and would return the token to your server automatically without any interaction from them. For example, via a malicious with the src attribute pointing to the malicious URL. Now, assuming you can’t redirect directly to your server, you can still see if the resource server will accept different sub domains, like test.example.com or different paths, like www.example.com/attacker-controlled. If the redirect_uri configuration isn’t strict, this could result in the resource server sending the token to a URL you control. However, you would need to combine with this another vulnerability to successfully steal a token. Three ways of doing this are an open redirect, requesting a remote image or a XSS. With regards to the open redirect, if you’re able to control the path and/or sub domain which being redirected to, an open redirect will leak the token from the URL in the referrer header which is sent to your server. In other words, an open redirect will allow you to send a user to your malicious site and in doing so, the request to your server will NEWOUTLOOK.IT Technet24 |||||||||||||||||||| |||||||||||||||||||| OAuth 165 include the URL the victim came from. Since the resource server is sending the victim to the open redirect and the token is included in that URL, the token will be included in the referrer header you receive. With regards to a remote image, it is a similar process as described above except, when the resource server redirects to a page which includes a remote image from your server. When the victim’s browser makes the request for the image, the referrer header for that request will include the URL. And just like above, since the URL includes the token, it will be included in the request to your server. Lastly, with regards to the XSS, if you are able to find a stored XSS on any sub domain / path you are redirect to or a reflected XSS as part of the redirect_uri, an attacker could exploit that to use a malicious script which takes the token from the URL and sends it to their server. With all of this in mind, these are only some of the ways that OAuth can be abused. There are plenty of others as you’ll learn from the examples. Examples 1. Swiping Facebook Official Access Tokens Difficulty: High Url: facebook.com Report Link: Philippe Harewood - Swiping Facebook Official Access Tokens2 Date Reported: February 29, 2016 Bounty Paid: Undisclosed Description: In his blog post detailing this vulnerability, Philippe starts by describing how he wanted to try and capture Facebook tokens. However, he wasn’t able to find a way to break their OAuth process to send him tokens. Instead, he had the ingenious idea to look for a vulnerable Facebook application which he could take over. Very similar to the idea of a sub domain takeover. As it turns out, every Facebook user has applications authorized by their account but that they may not explicitly use. According to his write up, an example would be “Content Tab of a Page on www” which loads some API calls on Facebook Fan Pages. The list of apps is available by visiting https://www.facebook.com/search/me/apps-used. 2 http://philippeharewood.com/swiping-facebook-official-access-tokens NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| OAuth 166 Looking through that list, Philippe managed to find an app which was misconfigured and could be abused to capture tokens with a request that looked like: https://facebook.com/v2.5/dialog/oauth?response_type=token&display=popup&client_id=A\ PP_ID&redirect_uri=REDIRECT_URI Here, the application that he would use for the APP_ID was one that had full permissions already authorized and misconfigured - meaning step #1 and #2 from the process described in the OAuth Description were already completed and the user wouldn’t get a pop up to grant permission to the app because they had actually already done so! Additionally, since the REDIRECT_URI wasn’t owned by Facebook, Philippe could actually take it over. As a result, when a user clicked on his link, they’ll be redirected to: http://REDIRECT_URI/access_token_appended_here Philippe could use this address to log all access tokens and take over Facebook accounts! What’s even more awesome, according to his post, once you have an official Facebook access token, you have access to tokens from other Facebook owned properties, like Instagram! All he had to do was make a call to Facebook GraphQL (an API for querying data from Facebook) and the response would include an access_token for the app in question. Takeaways When looking for vulnerabilities, consider how stale assets can be exploited. When you’re hacking, be on the lookout for application changes which may leave resources like these exposed. This example from Philippe is awesome because it started with him identifying an end goal, stealing OAuth tokens, and then finding the means to do so. Additionally, if you liked this example, you should check out Philippe’s Blog3 (included in the Resources Chapter) and the Hacking Pro Tips Interview he sat down with me to do - he provides a lot of great advice!. 2. Stealing Slack OAuth Tokens Difficulty: Low Url: https://slack.com/oauth/authorize Report Link: https://hackerone.com/reports/25754 3 https://www.philippeharewood.com 4 http://hackerone.com/reports/2575 NEWOUTLOOK.IT Technet24 |||||||||||||||||||| |||||||||||||||||||| OAuth 167 Date Reported: May 1, 2013 Bounty Paid: $100 Description: In May 2013, Prakhar Prasad5 reported to Slack that he was able to by-pass their redirect_uri restrictions by adding a domain suffix to configured permitted redirect domain. So, in his example, he created a new app at https://api.slack.com/applications/new with a redirect_uri configured to https://www.google.com. So, testing this out, if he tried redirect_uri=http://attacker.com, Slack denied the request. However, if he sub- mitted redirect_uri=www.google.com.mx, Slack permitted the request. Trying redirect_- uri=www.google.com.attacker.com was also permitted. As a result, all an attacker had to do was create the proper sub domain on their site matching the valid redirect_uri registered for the Slack app, have the victim visit the URL and Slack would send the token to the attacker. Takeaways While a little old, this vulnerability demonstrates how OAuth redirect_uri vali- dations can be misconfigured by resource servers. In this case, it was Slack’s implementation of OAuth which permitted an attacker to add domain suffixes and steal tokens. 3. Stealing Google Drive Spreadsheets Difficulty: Medium Url: https://docs.google.com/spreadsheets/d/KEY Report Link: https://rodneybeede.com6 Date Reported: October 29, 2015 Bounty Paid: Undisclosed Description: In October 2015, Rodney Beede found an interesting vulnerability in Google which could have allowed an attacker to steal spreadsheets if they knew the spreadsheet ID. This was the result of a combination of factors, specifically that Google’s HTTP GET requests did not include an OAuth token, which created a CSRF vulnerability, and the response was 5 https://hackerone.com/prakharprasad 6 https://www.rodneybeede.com/Google_Spreadsheet_Vuln_-_CSRF_and_JSON_Hijacking_allows_data_theft.html NEWOUTLOOK.IT |||||||||||||||||||| |||||||||||||||||||| OAuth 168 a valid Javascript object containing JSON. Reaching out to him, he was kind enough to allow the example to be shared. Prior to the fix, Google’s Visualization API enabled developers to query Google Sheets for information from spreadsheets stored in Google Drive. This would be accomplished a HTTP GET request that looked like: https://docs.google.com/spreadsheets/d/ID/gviz/tq?headers=2&range=A1:H&sheet\ =Sheet1&tqx=reqId%3A0 The details of the URL aren’t important so we won’t break it down. What is important is when making this request, Google did not include or validate a submitted OAauth token, or any other type of CSRF protection. As a result, an attacker could invoke the request on behalf of the victim via a malicious web page (example courtesy of Rodney): 1 2 3 4 var google = new Object(); 5 google.visualization = new Object(); 6 google.visualization.Query = new Object(); 7 google.visualization.Query.setResponse = function(goods) { 8 google.response = JSON.stringify(goods, undefined, 2); 9 } 10 11 12 13 16 17 18 function smuggle(goods) { 19 document.getElementById('cargo').innerText = goods; 20 document.getElementById('hidden').submit(); 21 } 22 23 24 25 26 27 28 NEWOUTLOOK.IT Technet24 |||||||||||||||||||| |||||||||||||||||||| OAuth 169 29 30 31 Let’s break this down. According to Google’s documentation7 , JSON response include the data in a Javascript object. If a request does not include a responseHandler value, the default value is google.visualization.Query.setResponse. So, with these in mind, the script on line 3 begins creating the objects we need to define an anonymous function which will be called for setResponse when we receive our data with the Javascript object from Google. So, on line 8, we set the response on the google object to the JSON value of the response. Since the object simply contains valid JSON, this executes without any problem. Here’s an example response after it’s been stringified (again, courtesy of Rodney): { "version": "0.6", "reqId": "0", "status": "ok", "sig": "405162961", "table": { "cols": [ { "id":"A", "label": "Account #12345",... Now, at this point, astute readers might have wondered, what happed to Cross Origin Resource Sharing protections? How can our script access the response from Google and use it? Well, turns out since Google is returning a Javascript object which contains a JSON array and that obj