The 2016 WWDC saw the dawn of Apple Pay Web, an API that lets websites embed an Apple Pay button within their web-facing stores. Supporting it required a complex request flow, complete with client certificates and a custom session server. This proved detrimental, since Apple failed to caution against important side effects of taking in untrusted URLs. As a result, many new SSRF vulnerabilities entered the world. Worse yet, while they were exploitable and discoverable in similar ways, they were spread across distinct codebases in several programming languages, so could not be patched in any generic way.
Apple is not alone - in the process of gluing the web together, Twilio, Salesforce, and others have all created similarly broad attack surfaces. When companies fail to take an honest, empathetic look at how clients will use a product, they shove along hidden security burdens. Those who integrate with an API have less context than those who create it, so are in a worse position to recognize these risks.
Engineers have been talking about defensive programming for decades, but top companies still have trouble practicing it. In this talk, we explore these mistakes with demos of affected software, and propose actionable ways of rethinking API security.
Joshua Maddux started out as a software engineer. After a few years, having introduced his share of bugs to the world, he turned his life around and started hunting for vulnerabilities. Now at PKC Security he does a mix of software development and white-box penetration testing, with a focus on helping startups move fast without breaking too many things. Aside from pentesting for clients, Joshua is also active in the bug bounty world. His past research has led to security updates in Java, Gitlab, United Airlines, Zapier, and others.