Uploaded December 2019 | Updated September 2026, 2 hours ago
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.
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.
