API-Induced SSRF: How Apple Pay Scattered Vulnerabilities Across the Web

The presentation discusses the concept of inductive weaknesses in software architecture and the importance of scrutinizing example code to prevent vulnerabilities. The speaker also highlights the dangers of hitting externally provided URLs and emphasizes the need for better API design principles.

• Inductive weaknesses are design flaws that encourage multiple parties to write vulnerable code with a similar exploit pattern across differing software sets
• Scrutinizing example code can help prevent vulnerabilities and discover inductive weaknesses
• Hitting externally provided URLs can be dangerous and documentation is not an excuse for bad architecture
• Better API design principles are needed to improve software security

The speaker gives an example of how an attacker can use server-side request forgery (SSRF) to access or harm something internal by relaying a request through a public facing server. This approach has been fruitful due to defaults in popular cloud environments, such as Google Cloud and AWS, which expose credentials by default on certain endpoints. The speaker emphasizes the importance of understanding and preventing vulnerabilities like SSRF.

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 introduce a powerful model for finding broad classes of bugs.