Securing Multiparty Online Services via Certification of Symbolic Transactions Eric Y. Chen Carnegie Mellon University Moffett Field, CA, USA eric.chen@sv.cmu.edu Shuo Chen, Shaz Qadeer, Rui Wang Microsoft Research Redmond, WA, USA {shuochen, qadeer, ruiwan}@microsoft.com Abstract— The prevalence of security flaws in multiparty online services (e.g., single-sign-on, third-party payment, etc.) calls for rigorous engineering supported by formal program verification. However, the adoption of program verification faces several hurdles in the real world: how to formally specify logic properties given that protocol specifications are often informal and vague; how to precisely model the attacker and the runtime platform; how to deal with the unbounded set of all potential transactions. We introduce Certification of Symbolic Transaction (CST), an approach to significantly lower these hurdles. CST tries to verify a protocol-independent safety property jointly defined over all parties, thus avoids the burden of individually specifying every party’s property for every protocol; CST invokes static verification at runtime, i.e., it symbolically verifies every transaction on-the-fly, and thus (1) avoids the burden of modeling the attacker and the runtime platform, (2) reduces the proof obligation from considering all possible transactions to considering only the one at hand. We have applied CST on five commercially deployed applications, and show that, with only tens (or 100+) of lines of code changes per party, the original implementations are enhanced to achieve the objective of CST. Our security analysis shows that 12 out of 14 logic flaws reported in the literature will be prevented by CST. We also stress-tested CST by building a gambling system integrating four different services, for which there is no existing protocol to follow. Because transactions are symbolic and cacheable, CST has near-zero amortized runtime overhead. We make the source code of these implementations public, which are ready to be deployed for real-world uses. Keywords-multiparty protocol; symbolic transaction; CST; verification; online payment; single-sign-on I. INTRODUCTION Modern web applications are often multiparty systems that integrate third-party services, e.g., single sign-on (SSO), payment, social networking, from different companies. These applications have significant security requirements. For example, a merchant website that integrates Amazon Simple Pay must ensure that an item is shipped only if it has been paid for. Similarly, an application that integrates Facebook SSO must ensure that only a properly authenticated user should be allowed to log into the application. To implement secure multiparty applications, developers typically follow protocol standards provided by organizations such as OAuth Working Group and OpenID Foundation or API specifications provided by companies such as Amazon, PayPal, and Facebook. However, there is ample evidence that deployed multiparty services are rife with security vulnerabilities. An attacker can purchase without paying [25][27], sign into other people’s accounts without passwords [4][28], or get unintended authorizations [29]. The Cloud Security Alliance cites these logic flaws in online services as “Insecure Interfaces and APIs”, the No.4 cloud computing threat [10]. We believe that the prevalence of security flaws in multiparty online services calls for rigorous engineering supported by formal program verification. However, despite being advocated by researchers for years, program verification is rarely put in actual engineering practice. This paper presents an approach that significantly lowers the hurdles for real developers to apply formal verifications on online services. Protocol-independent security goal. The first hurdle in verification is to understand what security goal to verify. This is hard for developers because protocol documentation and API specifications are, for practical considerations and limitations, often informal, jargon-laden and incomprehen- sive. It is unclear what exactly each party is supposed to achieve. For example, an Amazon payment protocol was not explicit about whether the payee’s identity was ensured by the cashier or the merchant [27]; many Facebook’s relying party websites did not know which piece of Facebook data should be obtained to securely authenticate a user [29]. We realize that security is much more intuitive to be defined as a global property (rather than per-party properties) inde- pendent of specific protocols. For example, no matter what a payment protocol instructs a merchant and a cashier to do individually, the two parties should jointly ensure an intuitive global property: for any order to be checked out from the merchant, it must have been paid for on the cashier. This property applies to all payment protocols. We will show concretely that such protocol-independent properties can be defined for various scenarios, which guard an implementation against logic flaws in the protocol and developers’ misunderstandings of the protocol. Certification of Symbolic Transaction (CST). Once a developer has the property, the next hurdle is how to verify it. Traditional approaches perform verification offline (see Figure 1 (upper)) and face two challenges: (1) the adversary and the system platform need to be modeled precisely (over- or under-permissiveness will lead to false positives or false negatives). The modeled adversary should be able to make arbitrary calls to the web methods on all the parties, with all 2015 IEEE Symposium on Security and Privacy © 2015, Eric Y. Chen. Under license to IEEE. DOI 10.1109/SP.2015.56 833 2015 IEEE Symposium on Security and Privacy © 2015, Eric Y. Chen. Under license to IEEE. DOI 10.1109/SP.2015.56 833