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

The presentation discusses the concept of inductive weaknesses in software architecture and how they can induce others to write vulnerable code. The focus is on server-side request forgery (SSRF) vulnerabilities and the potential consequences of not addressing them.

• Inductive weaknesses are design flaws that encourage multiple parties to write vulnerable code with a similar exploit pattern across differing software sets.
• SSRF vulnerabilities are a type of inductive weakness that can be exploited to access or harm internal systems.
• Popular cloud environments have default settings that make them vulnerable to SSRF attacks.
• Documentation is not an excuse for bad architecture and more scrutiny is needed to address security weaknesses.
• Developers should scrutinize their example code and place more emphasis on defensive coding around URLs.

The speaker provides an example of how an attacker can use an SSRF vulnerability to access private storage buckets or other sensitive information by exploiting default settings in popular cloud environments. This highlights the potential consequences of not addressing inductive weaknesses in software architecture.

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.