AVOIDING THE TOP 10 SOFTWARE SECURITY DESIGN FLAWS Iván Arce, Kathleen Clark-Fisher, Neil Daswani, Jim DelGrosso, Danny Dhillon, Christoph Kern, Tadayoshi Kohno, Carl Landwehr, Gary McGraw, Brook Schoenfield, Margo Seltzer, Diomidis Spinellis, Izar Tarandach, and Jacob West CONTENTS Introduction ..................................................................................................................................................... 5 Mission Statement ..........................................................................................................................................6 Preamble ........................................................................................................................................................... 7 Earn or Give, but Never Assume, Trust ...................................................................................................9 Use an Authentication Mechanism that Cannot be Bypassed or Tampered With .................... 11 Authorize after You Authenticate ...........................................................................................................13 Strictly Separate Data and Control Instructions, and Never Process Control Instructions Received from Untrusted Sources ........................................................................................................... 14 Define an Approach that Ensures all Data are Explicitly Validated .............................................16 Use Cryptography Correctly ..................................................................................................................... 19 Identify Sensitive Data and How They Should Be Handled .............................................................. 21 Always Consider the Users ........................................................................................................................22 Understand How Integrating External Components Changes Your Attack Surface................25 Be Flexible When Considering Future Changes to Objects and Actors ........................................28 Get Involved .................................................................................................................................................... 31 2014 2 IEEE Computer Society Center for Secure Design Participants Iván Arce, Sadosky Foundation Neil Daswani, Twitter Jim DelGrosso, Cigital Danny Dhillon, RSA Christoph Kern, Google Tadayoshi Kohno, University of Washington Carl Landwehr, George Washington University Gary McGraw, Cigital Brook Schoenfield, McAfee, Part of Intel Security Group Margo Seltzer, Harvard University Diomidis Spinellis, Athens University of Economics and Business Izar Tarandach, EMC Jacob West, HP Staff Kathleen Clark-Fisher, Manager, New Initiative Development Jennie Zhu-Mai, Designer 2014 3 Public Access Encouraged Because the authors, contributors, and publisher are eager to engage the broader community in open discussion, analysis, and debate regarding a vital issue of common interest, this document is distributed under a Creative Commons BY-SA license. The full legal language of the BY-SA license is available here: http://creativecommons.org/licenses/by-sa/3.0/legalcode. Under this license, you are free to both share (copy and redistribute the material in any medium or format) and adapt (remix, transform, and build upon the material for any purpose) the content of this document, as long as you comply with the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may use any reasonable citation format, but the attribution may not suggest that the authors or publisher has a relationship with you or endorses you or your use. “ShareAlike” — If you remix, transform, or build upon the material, you must distribute your contributions under the same BY-SA license as the original. That means you may not add any restrictions beyond those stated in the license, or apply legal terms or technological measures that legally restrict others from doing anything the license permits. Please note that no warranties are given regarding the content of this document. Derogatory use of the content of this license to portray the authors, contributors, or publisher in a negative light may cancel the license under Section 4(a). This license may not give you all of the permissions necessary for a specific intended use. About the IEEE Computer Society The IEEE Computer Society is the world’s leading computing membership organization and the trusted information and career-development source for a global workforce of technology leaders. The Computer Society provides a wide range of forums for top minds to come together, including technical conferences, publications, and a comprehensive digital library, unique training webinars, professional training, and the TechLeader Training Partner Program to help organizations increase their staff’s technical knowledge and expertise. To find out more about the community for technology leaders, visit http://www.computer.org. Published by the IEEE Computer Society. 2014 4 INTRODUCTION Most software that has been built and released typically comes with a set of defects—implementation bugs and de- sign flaws. To date, there has been a larger focus on find- ing implementation bugs rather than on identifying flaws. In 2014, the IEEE Computer Society, the leading association for computing professionals, launched a cybersecurity ini- tiative with the aim of expanding and escalating its ongo- ing involvement in the field of cybersecurity. The first step for the initiative was to launch the IEEE Computer Society Center for Secure Design. The Center intends to shift some of the focus in security from finding bugs to identifying common design flaws in the hope that software architects can learn from others’ mistakes. To achieve this goal, the Center brought people together from different organiza- tions at a workshop in early 2014. At the workshop, participants discussed the types of flaws they either identified in their own internal design reviews, or that were available from external data. They arrived at a list they felt were the top security design flaws. Many of the flaws that made the list have been well known for decades, but continue to persist. In this document is the result of that discussion—and how to avoid the top 10 security flaws. 2014 5 MISSION STATEMENT The IEEE Computer Society’s Center for Secure Design (CSD) will gather software security expertise from industry, academia, and government. The CSD provides guidance on: • Recognizing software system designs that are likely vulnerable to compromise. • Designing and building software systems with strong, identifiable security properties. The CSD is part of the IEEE Computer Society’s larger cybersecurity initiative, launched in 2014. 2014 6 PREAMBLE The goal of a secure design is to enable in a fielded system with major con- a system that supports and enforces sequences. A bug is an implemen- the necessary authentication, autho- tation-level software problem. Bugs rization, confidentiality, data integ- may exist in code but never be exe- rity, accountability, availability, and cuted. A flaw, by contrast, is a prob- non-repudiation requirements, even lem at a deeper level. Flaws are often when the system is under attack. much more subtle than simply an off- by-one error in an array reference or While a system may always have use of an incorrect system call. A flaw implementation defects or “bugs,” we might be instantiated in software have found that the security of many code, but it is the result of a mistake systems is breached due to design or oversight at the design level. For flaws or “flaws.” We believe that if example, a number of classic flaws organizations design secure systems, exist in error-handling and recovery which avoid such flaws, they can systems that fail in an insecure or significantly reduce the number and inefficient fashion. impact of security breaches. In this document, a group of software While bugs and flaws are both differ- security professionals have contrib- ent types of defects, we believe there uted both real-world data and ex- has been quite a bit more focus on pertise to identify some of the most common bug types than there has significant design flaws that have led been on secure design and the avoid- to security breaches over the past ance of flaws. Before we discuss our several years. The list of issues pre- contribution in this document, we sented here is focused entirely on the briefly discuss the differences be- most widely and frequently occurring tween bugs and flaws. design flaws as compiled from data Both bugs and flaws are types of provided by the member organiza- defects. A defect may lie dormant in tions of the IEEE Computer Society software for years only to surface Center for Secure Design (CSD). 2014 7 2014 8 EARN OR GIVE EARN OR GIVE, BUT NEVER ASSUME, TRUST Software systems comprising more than just a automobiles, pacemakers, gaming systems, or single monolithic component rely on the compo- home appliances. Even calls into your APIs from sition and cooperation of two or more software business partners could be considered client tiers or components to successfully accomplish software in some sense. their purpose. These designs often depend on When untrusted clients send data to your sys- the correct functioning of the existing parts. tem or perform a computation on its behalf, the They will be inherently insecure