This informational content is released under the [Creative Commons Attribution License (CC-BY) version 4.0](https://creativecommons.org/licenses/by/4.0/legalcode.txt), so you can reuse it in many ways. We want you to use this information! There are some exceptions: we quote some images (such as from xkcd) which are under their own licenses. Also, to counter cheating we do not release certain testing materials this way at all (so they are not in this repository). Note that we update this material, so you should be prepared for updates if you use a significant portion of it.
+
+If you earn a certificate of completion for the course via the Linux Foundation (LF) Training, you can show off the [digital credentials (badges) you've earned](https://training.linuxfoundation.org/badges-2/). Similarly, if you earn a course certificate or program certificate on edX, you can [show your edX certificates](https://www.edx.org/verified-certificate).
+
+If you want to propose changes to the content, as noted above
+the preferred mechanism is
+to file [issues](https://github.com/ossf/secure-sw-dev-fundamentals/issues) for general suggestions and provide [pull requests](https://github.com/ossf/secure-sw-dev-fundamentals/pulls) for specific changes, in both cases to this
+[secure-sw-dev-fundamentals](https://github.com/ossf/secure-sw-dev-fundamentals)
+project. Changes that are accepted into the Markdown must go through a series of internal steps in coordination with LF Training & Certification so that the changes will be deployed to both the LF Training and edX platforms.
+
+Changes to the markdown must have no errors reported by `markdownlint` using our configuration. This is checked when a pull request is made. You can do this check locally by installing markdownlint (e.g., `brew install markdownlint-cli` or `npm install -g markdownlint-cli`) and running `make`.
+
+You can see a generated [table of contents](toc.md) - rerun `make` to regenerate it. This generated file is included in the repository itself for convenience of those new to the document.
+
+This content was originally converted from Google docs format using
+[gdocs2md](http://github.com/mangini/gdocs2md),
+patched to skip inline drawings.
+That project unfortunately seems to have stalled.
+Alternative converters include
+[lmmx/gdocs2md-html](https://github.com/lmmx/gdocs2md-html)
+and
+[evbacher/gd2md-html](https://github.com/evbacher/gd2md-html!)
+(the last one is most recently active).
+
+This course is one of the results of the
+[Open Source Security Foundation (OpenSSF)](https://openssf.org/)
+[Best Practices working group (WG)](https://github.com/ossf/wg-best-practices-os-developers).
+
+If you want to report vulnerabilities in this project, please see
+[SECURITY.md](./SECURITY.md).
+
+Our thanks to Flavia Cioanca for her work to convert the text into live courses!
+
+# SECURITY
+
+We're *glad* if you want to report a vulnerability!
+
+If you wish to propose text to explain how to detect and prevent a *kind*
+of vulnerability that is already publicly known, please just file a normal
+issue and/or pull request. We don't consider that a "vulnerability report"
+in the sense that many people use the term.
+
+In some cases we're the wrong place to report vulnerabilities to:
+
+* If you wish to report a vulnerability on a specific project that isn't
+ this project, please don't report that here. Instead, please report the
+ vulnerability to that project.
+* If you wish to report a general vulnerability in edX or the
+ Linux Foundation Training & Certification platform, please report the
+ vulnerability to them instead.
+
+However, in some cases we *do* want you to report a vulnerability to us:
+
+* If you wish to report a vulnerability in this *specific* course
+ as supported by the Linux Foundation (via edX or the Linux Foundation
+ Training & Certification platform).
+* If you wish to propose text to explain how to detect and prevent a *kind*
+ of vulnerability that has *never* been publicly announced or
+ discussed anywhere.
+
+If you want to report those kinds of vulnerabilities to us,
+please use the GitHub mechanism [privately reporting a security vulnerability](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability) to this repository.
+
+If you want to propose changes to the content, the preferred mechanisms are
+[issues and pull requests via GitHub](https://github.com/ossf/secure-sw-dev-fundamentals).
+
+# Developing Secure Software
+
+by David A. Wheeler
+
+This is the content of a trio of self-paced courses. Users can learn from it for free, or apply for a certificate of completion for a fee.
+
+To *take* the course, please go to the [OpenSSF web page on Secure Software Development Fundamentals courses](https://openssf.org/training/courses/).
+You can also go directly to its
+["Developing Secure Software" (LFD121)](https://training.linuxfoundation.org/training/developing-secure-software-lfd121/)
+page on the Linux Foundation Training & Certification site, or to its
+[edX page](https://www.edx.org/professional-certificate/linuxfoundationx-secure-software-development-fundamentals).
+To get this content in Markdown format, go to -
+
- Security basics: risk management, the “CIA” triad, and requirements. +
- Secure design principles: what are principles such as “least privilege” and how to apply these principles. +
- Supply chain evaluation: tips on how to choose packages to reuse, and how to reuse them so that you can rapidly be alerted & update. +
-
+
- Implementation: You’ll learn how to implement much more secure software. This includes how to do Input validation, process data securely, call out to other programs, and send output. You’ll also learn about more specialized approaches, including some basics of cryptography and handling problems (such as error-handling code). +
-
+
- Security Verification: How to examine software, include some key tool types, and how to apply them in continuous integration (CI). This includes learning about security code scanners/static application security testing (SAST) tools, software composition analysis (SCA)/dependency analysis tools, fuzzers, and web application scanners. +
- Threat modeling/Attack modeling: How to consider your system from an attacker’s point of view and how to apply a simple design analysis approach called STRIDE. +
- Fielding: How to deploy and operate secure software, handle vulnerability reports, and how to rapidly update when reused components have publicly-known vulnerabilities. +
- Assurance cases & formal methods: The basics of approaches to more strongly analyze and justify that your software is secure. +
+Director of Open Source Supply Chain Security at The Linux Foundation
+Dr. David A. Wheeler is an expert in developing secure software and in open source software (OSS). He is the Director of Open Source Supply Chain Security at the Linux Foundation and teaches graduate courses in developing secure software at George Mason University (GMU) in Fairfax, VA. He has a PhD in Information Technology, a Master's in Computer Science, a certificate in Information Security, a certificate in software engineering, and a B.S. in Electronics Engineering. He is also a Certified Information Systems Security Professional (CISSP) and an IEEE Senior member. He leads the Open Source Security Foundation (OpenSSF) Best Practices Badge project for the Linux Foundation and has served as a lead validator for National Information Assurance Partnership (NIAP) for the (security) Common Criteria. He lives in Northern Virginia. + +# Table of contents + +[[TOC]] + +# Part I: Requirements, Design, and Reuse + +# Course Introduction + +## Introduction + +*Learn the security basics that allow you to develop software that is hardened against attacks, and understand how you can reduce the damage and speed the response when a vulnerability is exploited.* + +Modern software is under constant attack, but many software developers have never been told how to effectively counter those attacks. This course works to solve that problem, by explaining the fundamentals of developing secure software. Geared towards software developers, DevOps professionals, software engineers, web application developers, and others interested in learning how to develop secure software, this course focuses on practical steps that can be taken, even with limited resources, to improve information security. This course will enable software developers to create and maintain systems that are much harder to successfully attack, reduce the damage when attacks are successful, and speed the response so that any latent vulnerabilities can be rapidly repaired. + +The course discusses risks and requirements, design principles, and evaluating code (such as packages) for reuse. It then focuses on key implementation issues: input validation (such as why allowlists and not denylists should be used), processing data securely, calling out to other programs, sending output, cryptography, error handling, and incident response. This is followed by a discussion on various kinds of verification issues, including tests, including security testing and penetration testing, and security tools. It ends with a discussion on deployment and handling vulnerability reports. + +The *Secure Software Development Fundamentals* course was developed by the Open Source Security Foundation (OpenSSF), a project of the Linux Foundation focused on securing the open source ecosystem. The course focuses on practical steps that you (as a developer) can take to counter most common kinds of attacks. + +## A Note from the Author + +Our thanks to the many people who provided helpful commentary and advice. We especially thank Paul E. Black (NIST), Steve Lipner (SAFECode), Dan Lorenc (Google), Sherif Mansour (OWASP), Yannick Moy (AdaCore), and Ashwin Ramaswami for their thoughtful and specific recommendations. + +## Motivation + +### Motivation: Why Is It Important to Secure Software? + +Every day there is news about computer systems being broken into, often via various vulnerabilities in the software. Insecure software may: + +* Release private/secret information (aka *“lose confidentiality”*) + +* Lose or corrupt information (aka “*lose integrity*”) + +* Lose service (aka *“lose availability”*). + +But the problems don’t end there. Any of these can cause *real world* losses. They can cost money, time, trust, and even lives. + +Yet developers are often never told how to develop secure software. We should *expect* that developers who are never told how to do something will have a hard time doing it. + +This course focuses on helping you understand how to practically develop secure software. By *secure software* we mean software: + +* that is much harder for attackers to exploit, + +* that limits damage if an exploitation is successful, and + +* where vulnerabilities can be fixed and exploitations partially recovered from relatively quickly. + +### Motivation: Why Take This course? + +Our primary concern is that you learn how to develop *secure* software. Here are some of the features and advantages of this specific course: + +1. **Quizzes**. We ask quiz questions along the way to help reinforce concepts. It is easy to disengage with traditional books and videos, thinking that you understand the core concepts even when you don’t. In contrast, the quizzes help reinforce the core concepts so you will understand them. + +2. **Free**. If you just want to learn, it doesn’t cost anything! All you need is an internet connection. Many people have limited resources and we want to make sure this information is available to them. + +3. **Open Content**. The main informational material is not just “free” in the sense of “no cost” but also in terms of freedom. In particular, the informational content is released under the [Creative Commons Attribution License (CC-BY) version 4.0](https://creativecommons.org/licenses/by/4.0/), so you can reuse it in many ways. We *want* you to use this information! There are some exceptions; we quote other material (such as from xkcd) which are under their own licenses. + +4. **Evidence of Completion**. If you want to prove that you learned the material (as opposed to simply seeing some text), that is available. Learners taking the course on the Linux Foundation training platform will be required to pass a final exam in order to complete the course; they will obtain a certificate of completion and will also get a digital badge, which can be shared via social media to showcase their knowledge. On edX this evidence of completion is available at a nominal price by enrolling in a verified track. This might really help you communicate what you know to employers, customers, or potential employers. By comparison, just owning a book doesn’t prove that you have read or understood it. + +5. **Accessibility**. We have worked to make this information accessible. We want to make sure that those who are blind, have low vision, color-blindness, and so on can learn from this material. + +6. **Applicable to Open Source Software (OSS)**. Many materials on security don’t spend significant time on OSS, or are difficult to apply when developing OSS. Yet OSS is key to modern software development. We include information specifically for those developing and/or using OSS. + +7. **Independent of organization size**. We don’t require that you be in a large or small software development organization. Some courses implicitly assume you are in a large software development organization. + +8. **Independent of programming language**. Most software developers use multiple programming languages or will switch through their career. With that in mind, this course provides a basic grounding in developing secure software that applies to *many* programming languages. We will use examples from specific programming languages, but we want you to have a firm foundation no matter what you use—now or in the future. You should supplement this information with materials for the specific language or framework you use, but this course will give you the key building blocks to understand and apply those other materials. + +9. **Practical**. This course focuses on *practical* advice for the people developing software. In particular, we recommend specific things to do or avoid, etc. It briefly discusses why this advice applies, but this is not a graduate course; we focus more on *what* to do instead of all the theory or technical details behind it. + +There are other materials that can provide information about software security. Here are a few worthy alternatives and a contrast to them: + +1. The [*Security Engineering*](https://www.cl.cam.ac.uk/~rja14/book.html) book by Ross Anderson focuses on systems as a whole, including hardware and business processes, and focuses on big-picture concerns. However, this book does not cover most of the specifics of how to implement secure software. In contrast, this course (unlike Ross Anderson’s book) takes care to identify and discuss how to counter the most common kinds of security vulnerabilities. + +2. [SAFECode training materials](https://safecode.org/training/). SAFECode has a number of training materials available. Some materials are quite good and are videos (while this course is mostly text). Note that many of their materials are often narrowly focused. For example, their course *“Cross Site Scripting (XSS) 101”* is on a single common kind of vulnerability, and *“Secure Java Programming 101”* only applies to one language. Check the dates, as some materials may be out of date. That said, if their materials match what you want, they are definitely worthy alternatives. + +3. [OWASP Security Knowledge Framework (OWASP-SKF)](https://www.securityknowledgeframework.org/). “OWASP-SKF is an open source web application that explains secure coding principles in multiple programming languages. The goal of OWASP-SKF is to help you learn and integrate security by design in your software development and build applications that are secure by design. OWASP-SKF does this through manageable software development projects with checklists (using [OWASP-ASVS](https://owasp.org/www-project-application-security-verification-standard/)/[OWASP-MASVS](https://owasp.org/www-project-mobile-security-testing-guide/) or custom security checklists) and labs to practice security verification (using SKF-Labs, [OWASP Juice-shop](https://owasp.org/www-project-juice-shop/), and best practice code examples from SKF and the [OWASP-Cheatsheets](https://cheatsheetseries.owasp.org)).” In contrast, this course (unlike OWASP-SKF) doesn’t require software development projects and labs. + +Choose the material that will provide you with the information you want to learn, and you can certainly use them all if you wish. + +With that, let’s begin. + +# Security Basics + +> 🎥 This chapter provides a high-level overview about security concepts, including definitions of security and privacy, requirements, and risk management. We need to know these security basics so we can understand how to develop software that supports these basics. It's hard to implement security and privacy if we don't know what they are, and we must have a basic idea of what the software needs to do before we can implement it. In addition, we should take reasonable steps to *manage* risks so that any risks taken are acceptable. + +Learning Objectives: + +1. Explain what security means and understand common types of security requirements. + +2. Discuss what privacy is, its importance, and privacy requirements. + +3. Discuss risk management. + +4. Discuss defense-in-breadth and how to apply security concepts in different software development processes. + +5. Understand the importance of *Protection, Detection, and Response*. + +6. Explain the basics of handling vulnerabilities. + +## What Do We Need? + +### What Does “Security” Mean? + +To get secure software, we first need to understand what *security* means. Different software has different specific security requirements, but many people divide security requirements into three broad objectives - Confidentiality, Integrity, and Availability: + +* **Confidentiality**
“No unauthorized read” - users are only allowed to read the information they are authorized to read. + +* **Integrity**
“No unauthorized modification (write or delete)” - users are only allowed to modify the information they are authorized to modify; modification includes additions, changes, and deletions. + +* **Availability**
“Keeps working in presence of attack.” - the software keeps working while under attack. A Denial of Service (DoS) attack is an attack that tries to make the software no longer available. + +This set of Confidentiality, Integrity, and Availability (CIA) is sometimes called the CIA triad. + + + +The CIA Triad + +Many add one more security objective: **non-repudiation** or **accountability**. The point of non-repudiation or accountability is that if someone takes certain actions, the system should be able to later prove it, even if the person involved later denies it. Examples of such actions are transferring a large sum of money, deleting something important, sending an important message, or receiving an important message. Some systems do not have such requirements, and even when they do, some people consider this a special case of integrity. Some people add other objectives, too. No matter how you categorize things, it is important to know clearly what the system is supposed to do. Having some simple categories can help you do that. + +These security objectives need some supporting mechanisms. For example, confidentiality and integrity require that there be a way to determine if an action is authorized (unless all requests are authorized). Here are some common supporting mechanisms: + +* **Identification & Authentication (I&A)**
Require users to identify themselves and prove (authenticate) their identity before doing anything that requires authorization. For example, they might use a username or email address as their identity, and use a password or hardware token to authenticate that they really are that user. This is typically done by a login process. + +* **Authorization**
Determine what that user is allowed (authorized) to do before deciding to do it. You can think of authorization as a list of what each user is allowed to do. If it is easy for an attacker to add authorizations, then secure I&A means little. This is critical for implementing confidentiality and/or integrity. Watch out: the words *authentication* and *authorization* sound similar, but they are not the same thing. You may know exactly who someone is (authentication), but still not allow that person to do something (authorization). + +* **Auditing** (aka logging)
Record important events to help detect and recover from attacks. Typically these events include log in, log out, and modifying important information. Auditing is often critical for implementing non-repudiation / accountability requirements. + +What you specifically do depends on the software you are developing. If you are developing a lower-level library, you might not be directly supporting any of these supporting mechanisms, but you still have to make sure that what you are doing will fit into a larger program. + +#### Quiz 1.1: What Does “Security” Mean? + +\>\>Match the terms with the correct definitions.<< + +Confidentiality : Reads must be authorized + +Integrity : Modifications must be authorized + +Availability : Software continues working even while being attacked + +Identity & authentication (I&A) : Users must declare who they are and prove it + +Authorization : Determine what a user is allowed to do + +Auditing : Record important events + +### Security Requirements + +To create software, you need to know what you want it to do. Requirements are simply what a product or service needs to do or be. For our purposes, include in requirements anything required by law or regulation, as well as anything important to its (potential) customers/users. If you are being paid to develop software, requirements are typically recorded somewhere. + +In some cases, software must comply with special laws or regulations. This is especially true in areas where vulnerabilities are more likely to lead to significant harm (such as medical, financial, and military systems). This also arises if you are planning to sell software, or a system with software, in many different legal jurisdictions (so there may be many laws or regulations that apply). Again, for our purposes these are all requirements. + +Requirements might not be recorded in a single formal document. Sometimes each specific new requirement is simply accepted as an issue in an issue/bug tracker. In most software development projects, the requirements are identified over time in discussions with its users. + +Requirements don’t even *have* to be written down to be used, especially for a small project. However, at least in the case of security, it is a good idea to record the high-level security requirements in one place. Then, when someone is thinking about using or modifying your software, they’ll have an idea of what the system is trying to accomplish for security. + +Of course, the actual requirements depend on what you’re trying to accomplish. + +#### Common Security Objectives + +So how can you determine the security requirements for a particular system? One way to identify security requirements is to think about the common security objectives and supporting security functions we have *already* discussed and determine the specific requirements for your system in each category. In particular, think about how each one applies to the kind of information your program will manage. Let’s walk through each security objective and supporting security function, and discuss some things to consider: + +1. **Confidentiality** (“No unauthorized read”)
Identify information that should not be publicly revealed, such as private information about people and systems. Who should be allowed to see that? Can you avoid having that information at all (since you cannot reveal what you do not have)? If you store password information so people can log in to your system (aka “inbound” authentication), you need to store this password information using special algorithms designed for it (such as Argon2id), as we will discuss later. + +2. **Integrity** (“No unauthorized modification”)
Identify information that only some people should be allowed to modify, and who that is. + +3. **Availability** (“Keeps working in presence of attack”)
What is the impact if it does not work for a while - is that serious? Availability is rarely an absolute. If your system is accessible via the internet, availability is very challenging to provide; a well-resourced attacker can always use a Distributed Denial of Service (DDoS) attack to take down a site, at least for a little while. It is possible to work to counter DDoS attacks, but in the end it can turn into a competition between how many resources each side has. + + Even when availability cannot be universally guaranteed, you can still have secure software by focusing on the bigger-risk items ([Not all attackers are equal: understanding and preventing DoS in web applications](https://r2c.dev/blog/2020/understanding-and-preventing-dos-in-web-apps/), by Jacob Kaplan-Moss, 2020). In many cases, focus on developing your software so it is not *easy* to overwhelm or take down with simple inputs; make it possible to temporarily scale up the software by rapidly adding new servers; and implement the software so it quickly recovers when an attack ends. To counter the risk that the system might be destroyed or have its data deleted, design the software so its data is easily backed up, and plan for backups. Ensure that data can be backed up to “cold storage” (where the data cannot be corrupted later if the software is subverted). If the system is routinely backed up in operations, you can recover relatively quickly (at least partially). So yes, you *can* have availability as a requirement, as long as its limitations are clear. + +4. **Non-repudiation** (“Prove someone did something”)
Is there some action that you want to be able to *prove* someone took? In many systems this is not critical, but in some it is. + +5. **Identity & authentication (I&A)**
How will users prove who they are? You want to make sure that someone cannot spoof a legitimate user. You should normally support two-factor authentication (2FA), either directly or by allowing users to prove their identity via some other service that supports it. + +6. **Authorization**
Who is allowed to do what? This is a part of confidentiality and integrity, but if you think about people’s roles in addition to thinking about the information to protect, you will probably get a better picture. + +7. **Auditing/Logging**
What information/events should you record? Typically you at least record login, logout, and important events like user account creation and deletion. Generally a system should record when something happened (date and time), what happened, what system component did it, and who caused it to happen. + +#### Tips for Finding Security Requirements + +You will sometimes see documents that use the security terms “subject” and “object”. A “subject” is something that acts (e.g., a user or process). An “object” is something being acted on (e.g., a file or network port). + +Some developers capture some requirements as *use cases*. Each use case is a list of interactions between actor(s) and a system to achieve a goal. This has led to an interesting security approach, the development of *abuse cases* or *misuse cases*. An abuse case is a list of interactions between actors and a system that are intended to cause harm (e.g., to the system, actor(s), or stakeholders). A very similar term is “misuse case”, a description of a malicious act against a system. Many have found it useful to define abuse cases or misuse cases to then describe how the system must *counter* such abuse/misuse. By thinking about abuse and misuse, and figuring out how to counter them early, a lot of mischief can be prevented. Many developers find it hard to *think like an attacker*, so throughout this course we will focus on techniques to help you find vulnerabilities anyway, for example, by identifying common types of vulnerabilities and explaining how to systematically do threat modeling. + +An important aspect about security requirements is what kind of attackers you expect to counter. Countering targeted attacks by well-resourced nation-states is extremely difficult; you need to know and apply more than this course can cover by itself. However, most people are not trying to develop systems that withstand these kinds of attacks. In this course, we will assume that your software must stand up to attacks that a typical commercial site might need to counter, where the attacker has limited resources and the attacks are often not highly targeted. If you need to defend against attackers with more resources, you will probably need to do much more, but the material in this course will give you a good starting point. + +Note that in this course we focus on attackers, not hackers. In the computer community the term “hacker” is widely used to identify *“a person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular.”* ([IETF RFC 1983](https://tools.ietf.org/html/rfc1983)). By this definition, many hackers never attack computer systems, and many attackers are not hackers. This course focuses on foiling attackers. + +If you are looking for ideas for potential security requirements, one source is the [*Common Criteria for Information Technology Security Evaluation” (CC) part 2*](https://www.commoncriteriaportal.org/), which is freely available. The CC is an international standard for evaluating security that was originally developed in 1994. The vast majority of software developed today does not undergo a CC evaluation, in part because it is often both expensive and time-consuming to have an external lab formally evaluate your software using the CC. However, you can still look at the CC for ideas even if you will not use an evaluation lab. The CC is publicly available and has 3 parts: part 1 is an introduction, part 2 is a list of common security functional requirements, and part 3 is a list of common assurance requirements. Part 2 in particular is a list of *“security functions you might require”*. If you suspect your system will need some special security requirements, but are not sure what those might be, part 2 provides a long list of ideas that might be useful. Some of its terminology is arcane, but it includes a glossary which can help. + +**Finally:** If there is existing software that does something like the software you are developing, look at its security capabilities. They added those capabilities for a reason, and your software might need at least some of them as well. + +#### Key terms: Trust, Trustworthy, and Untrusted + +A *trustworthy* component is worthy of being trusted (for some purpose). + +*Trust*, by contrast, is a *decision* to depend on something for some purpose. +You should only trust things that have adequate evidence of being trustworthy. +Security vulnerabilities occur when trust is given to something not +adequately trustworthy. + +An *untrusted user* is a user you do not completely trust. +Any data from an untrusted user should be handled carefully, because an +untrusted user might be an attacker. + +#### Quiz 1.2: Security Requirements + +\>\>A typical Internet-connected service should try to stay available, but this may be difficult to achieve if the service is the target of a highly-resourced distributed denial-of-service (DDoS) attack. True or False?<< + +(x) True + +( ) False + +[Explanation] + +This is true. It would be great if we could ensure that all Internet-connected services could always stay available. But in most cases, if every device in the world connected to the Internet requested a specific service, that service will be unable to handle the load. At some point, attackers with many resources can usually overwhelm the availability of a defender with few resources. + +Of course, we should not make it easy for an attacker to take down a system. So instead, any Internet-connected services we build should be able to handle some moderate request rate so that an attacker has to at least commit nontrivial resources. You could do this by designing the system so that it can rapidly scale to large request sizes, and using other services like content delivery networks (CDNs) to harden the system against large loads. In addition, a service can use techniques like rapid recovery so that even if it is taken down by an attack, it can quickly recover when the attack ends. + +[Explanation] + +### What Is Privacy and Why It Is Important + +Security and privacy are interrelated, but not the same thing. In this unit we will cover what privacy is, its relationship to security, and why privacy is important. + +#### What Does Privacy Mean? + +The non-profit [International Association of Privacy Professionals (IAPP) defines privacy](https://iapp.org/about/what-is-privacy/) as *“the right to be let alone, or freedom from interference or intrusion”*. More specifically, it says *“Information privacy is the right to have some control over how your personal information is collected and used... various cultures have widely differing views on what a person’s rights are when it comes to privacy and how it should be regulated.”* They also contrast privacy and security: *“Data privacy is focused on the use and governance of personal data—things like putting policies in place to ensure that consumers’ personal information is being collected, shared and used in appropriate ways.”* + +Put another way, privacy is about protecting personal data about individuals from abuse. + +#### Why Is Privacy Important? + +While some have argued that privacy is no longer possible or relevant, many others disagree, and many laws have been put in place around the world to protect privacy. One accessible summary for the widespread position that privacy is important is Glenn Greenwald’s TED Talk [*“Why privacy matters”*](https://www.ted.com/talks/glenn_greenwald_why_privacy_matters) (2014). Here are some of his points (see the talk for details): + +* People who say, *“if you’re doing something that you don’t want other people to know, maybe you shouldn’t be doing it in the first place”* are engaged in extreme self-deprecation; *“What they’re really saying is,"I have agreed to make myself such a harmless and unthreatening and uninteresting person that I actually don’t fear having the government know what it is that I’m doing.’”* + +* Many of these same people [who make these claims] do not actually act in this way, e.g., they will take many steps to gain privacy for themselves. + +* *“There’s a reason privacy is so craved universally and instinctively… when we’re in a state where we can be monitored, where we can be watched, our behavior changes dramatically… There are dozens of psychological studies that prove that when somebody knows that they might be watched, the behavior they engage in is vastly more conformist and compliant.”* + +* *“Mass surveillance creates a prison in the mind that is a much more subtle though much more effective means of fostering compliance with social norms or with social orthodoxy, much more effective than brute force could ever be.”* + +* *“A society in which people can be monitored at all times is a society that breeds conformity and obedience and submission, which is why every tyrant, the most overt to the most subtle, craves that system.”* + +* *“When we allow a society to exist in which we’re subject to constant monitoring, we allow the essence of human freedom to be severely crippled.”* + +* *“A system of mass surveillance suppresses our own freedom in all sorts of ways. It renders off-limits all kinds of behavioral choices without our even knowing that it’s happened.”* + +### Privacy Requirements + +#### Simplest Approach: Don’t Collect Personal Information + +The first step for addressing privacy is acknowledging that privacy is important, and then considering how to ensure your software provides adequate privacy if it collects information about individuals. + +The simplest approach to privacy, and often the best starting point, is to *not* collect information about individuals unless you need it. If you do not collect the information, you cannot divulge it later, and you do not have to determine how to prevent its misuse. Eliminating it is best from a privacy point of view. + +Failing that, minimize personal information to what you absolutely require. If you must collect information about individuals, you must provide a variety of protections for them, at the very least those required by law and regulation. This can be complicated, because many laws and regulations may apply. + +#### Privacy Laws and Regulations + +Laws and regulations about privacy are widespread. Different terms are used for them, including information privacy, data privacy, and data protection. Whether or not these laws and regulations affect your software depends on what kind of data your software collects. In many cases, software does not need to do anything special for privacy. However, in other cases these laws and regulations can matter greatly. + +[Article 17 of the International Covenant on Civil and Political Rights of the United Nations](https://www.ohchr.org/en/professionalinterest/pages/ccpr.aspx) in 1966 is widely ratified and protects privacy. It says, *“No one shall be subjected to arbitrary or unlawful interference with his privacy, family, home or correspondence, nor to unlawful attacks on his honour and reputation. Everyone has the right to the protection of the law against such interference or attacks.”* + +Different countries, and provinces/states within countries, have different laws regarding privacy. Here we will briefly discuss the US and European approaches. + +#### United States + +The United States (US) does not have a comprehensive information privacy law as a whole. Instead, the US federal government has a number of laws that cover specific circumstances. This includes the Family Educational Rights and Privacy Act of 1974 (FERPA) for student education records, the Health Insurance Portability and Accountability Act of 1996 (HIPAA) for health-related data, the Children’s Online Privacy Protection Act of 1998 (COPPA) for data related to children, and the Fair and Accurate Credit Transactions Act of 2003 (FACTA) for some financial data. + +The [US Privacy Act of 1974 (5 U.S.C. 552a)](https://www.govinfo.gov/content/pkg/USCODE-2018-title5/pdf/USCODE-2018-title5-partI-chap5-subchapII-sec552a.pdf) mandates how US federal agencies must maintain records about individuals who are US citizens and lawful permanent resident aliens. For example, they must: + +* collect only relevant and necessary information that is relevant and necessary to carry out an agency function; + +* explain at the time the information is being collected, why it is needed and how it will be used; + +* ensure that the records are used only for the reasons given, or seek the person’s permission when another purpose for the records’ use is considered necessary or desirable; + +* provide adequate safeguards to protect the records from unauthorized access and disclosure; and + +* allow people to see the records kept on them and provide them with the opportunity to correct inaccuracies in their records. + +Some US states have additional laws. For example, the [California Online Privacy Protection Act (OPPA) of 2003](https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=BPC§ionNum=22575) requires operators of commercial web sites or online services *“that collects personally identifiable information through the Internet about individual consumers residing in California who use or visit its [site or service must] conspicuously post its privacy policy…”* and comply with it. More recently, the [California Consumer Privacy Act of 2018 (CCPA)](https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5), which became effective in 2020, gives California residents additional rights to know what personal information has been collected by businesses, and to opt out of the sale of that information. + +Europe *does* have a comprehensive law, and even those outside Europe often must comply with it. So let’s focus on it; it applies to many situations, and understanding it will help you understand other privacy requirements. + +#### European General Data Protection Regulation (GDPR) + +The European General Data Protection Regulation (GDPR) protects the personal data of subjects who are in the European Union (EU). It applies whether or not the data processing occurs within the EU, and it applies whether or not the subjects are European citizens. As a result, the GDPR applies in many circumstances. [The Linux Foundation has a summary of the GDPR](https://www.linuxfoundation.org/wp-content/uploads/2018/05/lf_gdpr_052418.pdf) that highlights issues important to software developers. Below we point out some GDPR basics from the Linux Foundation’s GDPR summary. + +But first: complying with the GDPR is important. Serious infringements can result in a fine of up to €20 million, or 4% of a firm’s worldwide annual revenue from the preceding financial year, whichever amount is *higher*. + +The GDPR defines personal data (requiring protection as such) as *“any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person”*. Note that it is not just data that identifies an individual - it is data that is connected to data that identifies an individual. For example, a person’s mailing address is personal data; details about a person’s skills or preferences are also personal data if they are linked, or reasonably capable of being linked, to other information identifying that individual. + +Under the GDPR some personal data are considered more sensitive, and there are greater restrictions on collecting and processing them. These include: + +* racial or ethnic origin + +* political opinions, religious or philosophical beliefs, or trade union membership + +* genetic data + +* biometric data for the purpose of uniquely identifying a natural person + +* data concerning health + +* data concerning a natural person’s sex life or sexual orientation + +Personal data is *processed* any time an operation is performed on it. This includes collecting, storing, viewing, transmitting, and deleting it, whether or not by automated means. In the GDPR, a “controller” is the person or organization who determines the purpose and means of processing. A “processor” is a third party that processes the data on a controller’s behalf. + +The GDPR defines seven primary principles for processing personal data. These principles inform the purposes of all of the specific provisions of the GDPR. Understanding them goes a long way towards having a good initial insight for whether a particular use of personal data is likely to be acceptable. These are: + +1. **Lawfulness, Fairness and Transparency**
Process personal data in a way that is legal, fair and transparent to the data subject. + +2. **Purpose Limitation**
Only process personal data in ways that are compatible with the legitimate purposes for which it was collected. + +3. **Data Minimization**
Limit the personal data you collect to what’s adequate for those purposes. + +4. **Accuracy**
Keep personal data accurate and up to date, and take every reasonable step to erase or rectify inaccurate data. + +5. **Storage Limitation**
Store personal data in a form which permits identification for no longer than needed for the purposes for which it was collected. + +6. **Integrity and Confidentiality**
Process personal data in a way that ensures appropriate security. + +7. **Accountability**
A controller of personal data is responsible for the above principles, and for demonstrating its compliance with them. + +Six articles in the GDPR lay out specific rights given to individuals regarding their personal data. This gives EU residents the right to contact a data controller and request that it take certain actions (*GDPR requests*). Since EU residents have these rights, software systems and organizational processes must be designed to enable these rights. The types of requests described in the GDPR include the following: + +* **Right of Access** (Art. 15)
Data subjects can ask whether their personal data is being processed. If it is, they can receive “access” to the data (e.g., a copy or screenshot of it) and information regarding the processing. + +* **Right to Rectification** (Art. 16)
Data subjects can have inaccurate data updated and corrected. + +* **Right to Erasure** (a.k.a “Right to be Forgotten”) (Art. 17)
In certain circumstances, data subjects can have their personal data erased. + +* **Right to Restriction of Processing** (Art. 18)
In certain circumstances, data subjects can restrict processing of their personal data. It can still be stored, unless a “Right to Erasure” request was also made. + +* **Right to Data Portability** (Art. 20)
In certain circumstances, data subjects can have their personal data exported (e.g., provided to the data subject or a third party in a structured, commonly used and machine-readable format). + +* **Right to Object** (Art. 21)
In certain circumstances, particularly for direct marketing and profiling purposes, data subjects can object to having their personal data processed. + +To process personal data, it must be lawful, meaning it must fall into at least one of several categories, including the following among others: + +* **Compliance with Law**. Personal data can be processed if it is necessary for compliance with a legal obligation. + +* **Performing a Contract with the Data Subject**. Personal data can be processed if it is necessary to perform a contract that is with that data subject. *Note that this likely does not apply to a contract with somebody other than the data subject, such as their employer.* + +* **Legitimate Business Interests**. Personal data can be processed if doing so is consistent with “legitimate interests,” unless overridden by the data subject’s interests to the contrary. This can be a more ambiguous concept. + +* **Consent**. Personal data can be processed if the data subject gives their consent. + +Note that personal data can be processed if the data subject gives their consent. However, for consent to be valid under the GDPR: + +* it must be *“specific”* and *“informed”* (e.g., it should include a specific description of what data is being collected, and how it will be used); + +* it requires a *“clear affirmative action”* by the data subject (e.g., requiring the participant to check a checkbox, and not having it pre-checked); and + +* it must be freely revocable (e.g., the data subject must be able to withdraw consent at any time). + +Even if consent is granted, you may want to also find another lawful basis for processing the data, especially if you want to retain it. Under the GDPR, you are generally prohibited from retaining personal data without a lawful basis. + +Under the GDPR, *profiling* is any form of automated processing that involves using personal data to evaluate aspects of that person. Profiling will usually require getting explicit consent from the individual, which means also that the individual will be able to withdraw that consent at any time. Therefore, profiling activities will typically require a greater degree of review and protections for the applicable personal data. + +Here are some resources for learning more about the GDPR: + +* The [official EU site for the GDPR text](http://data.europa.eu/eli/reg/2016/679/oj) + +* [*“The Guide to the General Data Protection Regulation (GDPR)”*](https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/) + +* [*“Solutions for a responsible use of the blockchain in the context of personal data”*](https://www.cnil.fr/sites/default/files/atoms/files/blockchain_en.pdf) + +* [*“Security of Personal Data”*](https://www.cnil.fr/sites/default/files/atoms/files/cnil_guide_securite_personnelle_gb_web.pdf) + +* The Linux Foundation, [*“Summary of GDPR Concepts For Free and Open Source Software Projects”*](https://www.linuxfoundation.org/wp-content/uploads/2018/05/lf_gdpr_052418.pdf) + +* [California Online Privacy Protection Act, Chapter 22. Internet Privacy Requirements [22575-22579]](https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=BPC§ionNum=22575) + +#### Telemetry + +Software sometimes includes functionality to collect telemetry data, that is, data about how the software is used or performing. Telemetry data is often collected through a “phone home” mechanism built into the software itself, where the software sends this data elsewhere. + +Telemetry data is especially fraught with privacy and confidentiality issues. End users are typically presented with an option to opt-in to share statistical data with the developers of the software, but that agreement may not be adequate. End users ideally should be given a full awareness of what data may be sent to which parties (including the vendor) when they use the software, and the ability to control that transfer of data. + +The Linux Foundation’s [*“Telemetry Data Collection and Usage Policy”*](https://www.linuxfoundation.org/telemetry-data-policy/) presents a brief discussion of some of the issues that should be considered before implementing telemetry data collection, as well as discussing the Foundation’s approach to managing use of telemetry by its open source project communities. This may be useful to you in other contexts. + +#### Quiz 1.3: Privacy Requirements + +\>\>Which of the following privacy-related statements is true?||Check all of the options below that are true, and do NOT check them otherwise.<< + +[!] There are no privacy laws in the United States. {{ selected: No. The United States does not have a *comprehensive* information privacy law as a whole. Instead, the US federal government has a number of laws that cover different specific circumstances. There are also some state laws. }} + +[ ] The GDPR is irrelevant as long as you process personal data outside Europe. {{ selected: No. The GDPR applies to those processing personal data of those residing in Europe, whether or not it is processed in Europe. Failure to comply with the GDPR may or may not be enforceable depending on a variety of factors, but in many cases it is very relevant. }} + +[x] Under the GDPR, some personal data is considered more sensitive, and there are greater restrictions on collecting and processing them. This includes political opinions, religious or philosophical beliefs, trade union membership, genetic data, and data concerning health. + +[ ] Under the GDPR, once consent is given it cannot be withdrawn. {{ selected: No, the GDPR requires that it be possible for users to be able to revoke consent. If there is no other legal reason that the data can be retained and processed, then the data must be erased. }} + +[ ] Under the GDPR, a prechecked “I agree” checkbox is enough to obtain consent. {{ selected: No, consent requires a “clear affirmative action”. Prechecked boxes do not count. }} + +[x] Under the GDPR, data subjects can, under certain circumstances, demand to have their personal data erased. + +## How Can We Get There? + +### Risk Management + +Risks are *potential problems*. The key to developing adequately secure software is to manage the risks of developing insecure software, *before* they become problems. + +#### The Need for Risk Management + +All of life involves risk. It is unrealistic to expect that there will be no risks in life. In particular, there are risks to anyone using the software you develop because it may have vulnerabilities. When you develop software, you are likely to make mistakes, and some of those mistakes might eventually lead to security vulnerabilities. Someone may even try to intentionally insert vulnerabilities or malicious code into your software, or the software you depend on, during its development. Even very strong techniques for countering vulnerabilities must build on assumptions or can only eliminate *some* security-related risks, so again, it is unrealistic to expect there to be no risks. + +But when you develop software, you should take reasonable steps to *manage* risks so that the risks are so low (both to its developers and users) that they are acceptable. In his book, [*“The Failure of Risk Management: Why It’s Broken and How to Fix It”*](https://onlinelibrary.wiley.com/doi/book/10.1002/9781119198536) (2009), Douglas Hubbard defines risk management as the *“identification, evaluation, and prioritization of risks… followed by coordinated and economical application of resources to minimize, monitor, and control the probability or impact of unfortunate events”*. + +One of the risks when developing and deploying software is that attacker(s) will exploit its vulnerabilities and cause harm to others. You cannot prevent attackers from trying to attack the system. In fact: + +**🚩 If people start using the software you develop, _expect_ that intelligent adversaries will try to attack it.** + +While you cannot prevent attackers from attacking software, you can make it difficult for an attack to succeed, or reduce the impact if an attack succeeds. You can do this by taking steps throughout software development and deployment to reduce the risks to an acceptably low level. If your software is widely-used or depended on for vital tasks, then it is especially important that you work to manage those risks to your users. + +Do *not* wait to think about risks until they happen. Then they are no longer risks - they are *problems*. It is easier and cheaper to address risks *before* they become problems! It is much easier to design the software to minimize risks than to change the software later. It is also better for the user, your professional reputation, the software's reputation, and any related organization's reputation. + +#### Risk Management Process + +Small projects with relatively low impacts can do risk management informally. Large projects with major impacts should be more rigorous. Regardless, risk management can be divided into the following activities (according to the US Department of Defense’s [*Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs*](http://acqnotes.com/wp-content/uploads/2017/07/DoD-Risk-Issue-and-Opportunity-Management-Guide-Jan-2017.pdf), 2017): + +1. **Risk planning**. Determine your project’s risk management process. + +2. **Risk identification**. Identify what *might* go wrong. A good trick is to look for similar projects - what risks and problems did they have? It is a good idea to write this list down so it can be shared. For our purposes, we are concerned about security-related risks. + +3. **Risk analysis**. Determine the two key attributes of a risk: the **likelihood** of the undesirable event and the **severity** of its consequences. A risk becomes increasingly important if its likelihood and/or severity increases. + +4. **Risk handling**. Determine what you will do about the risk. You have several options for each risk: + + 1. **Acceptance (& Monitoring)**: The risk is accepted, but monitored and communicated to its stakeholders (including its users). This is reasonable if the likelihood or severity are low. + + 2. **Avoidance**. The risk is eliminated by making some change. That is, you make its likelihood zero or its severity irrelevant. This is great when you can do it. For example, you might choose to *not* gather some data (then you cannot lose its confidentiality later), or you might choose a programming language where certain kinds of vulnerabilities cannot happen (eliminating the risks from those kinds of vulnerabilities). + + 3. **Transfer**. The risk is transferred to someone else (e.g., buying insurance, or changing the system so that another component has that risk and its developers accept it). For example, instead of taking on the risks of bad identification & authentication (I&A), depend on some existing system to do I&A. + + 4. **Control**. Actively reduce the risk to an acceptable level. Since the importance of a risk depends on its likelihood and severity, this means changing things to make the likelihood and/or severity low (or at least lower). For security-related risks, this is often what you need to do. There is no single way to do this, so instead you have to continuously reduce likelihood and severity through software development and deployment until the risks are acceptable. For example, you might: + + 1. Ensure all developers know about certain kinds of common mistakes that lead to a particular kind of vulnerability (so that they can avoid them), + + 2. Use approaches (such as secure design, specific programming languages, and APIs) that are designed to make those vulnerabilities less likely, + + 3. Use tools & reviews to catch mistakes (including vulnerabilities), and + + 4. Harden the system. Hardening a system means modifying a system so that defects are less likely to become security vulnerabilities. We will discuss hardening later in the course. + +5. **Risk Monitoring**. Determine how the risks have changed over time. Over time, you should “burn down” your risks - that is, the steps you are taking should be continuously reducing the risk likelihood or severity to acceptable levels. + +Risk management is *not* complicated. It is basically common sense. But when you are working on solving the current problems it is easy to forget about risks, which are only *potential* problems. A little thought *ahead* of time can eliminate potential problems before they become real problems. + +#### Identifying Risks + +Note that the first step (beyond planning) is identifying risks. But how do you identify the risks of security vulnerabilities? Clearly many people do *not* notice risks from security vulnerabilities. + +Bruce Schneier has this wonderful story ([*The Security Mindset*](https://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html), 2008): + +> *“Uncle Milton Industries has been selling ant farms to children since 1956. Some years ago, I remember opening one up with a friend. There were no actual ants included in the box. Instead, there was a card that you filled in with your address, and the company would mail you some ants. My friend expressed surprise that you could get ants sent to you in the mail. [Bruce Schneier] replied: ‘What’s really interesting is that these people will send a tube of live ants to anyone you tell them to.’ … Security requires a particular mindset. Security professionals -- at least the good ones -- see the world differently. They can’t walk into a store without noticing how they might shoplift. They can’t use a computer without wondering about the security vulnerabilities. They can’t vote without trying to figure out how to vote twice.”* + +Can this mindset be taught? Our experience is that it can be, at least in part. Checklists, guidance, and tips help remind people to look for certain things, especially when they are built from relevant past experiences. Another technique that helps is working to develop a slightly paranoid mind-set. Not a clinical level of paranoia, but a constant low-level concern that there are many risks and that some people really are out to get you. Remember that some users will intentionally seek to cause rare, unlikely, or unexpected situations, in the hope that such attacks will give them unwarranted privileges. As a result, when writing secure programs, paranoia is a virtue. Talking about risks with others, reviewing plans with others, and continuously looking for risks can all help identify risks so that they can be addressed *before* they become problems. + +#### Security Is A Process, Not A Product + +In his essay, [*The Process of Security*](https://www.schneier.com/essays/archives/2000/04/the_process_of_secur.html) (2000), Bruce Schneier famously explained that + +> *“security is a process not a product… there’s no such thing as perfect security. Interestingly enough, that’s not necessarily a problem. … Security does not have to be perfect, but the risks have to be manageable…”.* + +The world changes. The ways your software is used changes. New vulnerabilities are discovered. The software’s platform and libraries change. Laws, company policies, and goals change. Software that was secure a year or five years ago may not be adequate today. + +Since security is a process, it is not just “fire and forget.” You need to continuously consider security. + +#### Checklists Are Not Security + +Do not equate checklists, guidelines, and tips with security. They are often *useful*, because they can help you identify risks and reasonable ways to handle them. Good checklists, guidelines, and tips can save you a lot of time and trouble, and they are also great aids for helping others evaluate the security of some software. Good ones are built on the experience of others, and you’d be foolish to ignore that experience. + +But they are only aids to the real goal; they are not the goal itself. You can follow checklists, guidelines, and tips, and have terribly insecure software. You can also *disregard* some inappropriate ones and have very secure software. In short: + +**_There is no substitute for thinking._** + +This course will give you a number of tips to help you to reduce risks, focusing on lessons that previous developers have learned. But they are merely tips; they are merely an *aid* to developing secure software. When you are developing software, continuously think about the ways that an attacker might try to exploit your system. Anticipate the potential problems—while they are still risks—and mitigate them. + +#### Quiz 1.4: Risk Management + +\>\>The purpose of developing secure software is to eliminate all possible security risks. True or False?<< + +( ) True + +(x) False + +[Explanation] + +This is false. It would be great if we could eliminate all risks, But that is unreasonable. Instead, our goal is to reduce the probability and severity of all risks, including security vulnerabilities, to acceptable levels. + +[Explanation] + +### Development Processes / Defense-in-Breadth + +There is no single magic mechanism to make secure software. Instead, you have to continuously consider security throughout software development and deployment. Considering security at all times, through all development and deployment processes, is sometimes called “defense in breadth”. So let’s talk about the processes used for software development and deployment. + +#### Individual Software Development & Deployment Processes + +Whenever you develop software there are certain processes that all developers have to do. These include: + +* Determine *requirements* (what the software must do). For security, make sure you know what security requirements it needs to provide. For example, is there data it should keep confidential? + +* Determine *architectural design* (how to divide up the problem into interacting components to solve it). Later in this course we will discuss various secure design principles to help you design a system that is easier to secure. + +* *Select reusable components* (decide what reusable packages/libraries you will use). You need to evaluate the components you will use, since any of their vulnerabilities may become vulnerabilities of the software you are developing. These reused components come from somewhere, and depend transitively on other components. The set of all those dependencies, including where they come from and how they eventually get to you, is your *supply chain*. + +* *Implement* it (write the code). Most security vulnerabilities made during implementation are specific common kinds; once you know what they are, you can avoid them. + +* *Verify* it (write/implement tests and use analyzers to gain confidence that it does what it is supposed to). You should be testing to make sure that your system is secure, and using tools to help you find vulnerabilities before attackers find them. + +* *Deploy* it. You should help ensure that users can get the correct version, that it is secure by default, and that they can easily operate it in a secure way. + +#### Using These Processes Together + +Of course, you need to use these processes together. + +A common mistake is trying to execute these software development processes in a strict sequence (figure out all the requirements, then work out the entire design, then implement the entire system, then verify it). Attempting to create software in this strict sequence is called the *waterfall* model. The waterfall model is beguiling because doing these processes in strict sequence *appears* rigorous and sensible at first. In 1970, Winston W. Royce explained in his essay [*Managing the Development of Large Systems: Concepts and Techniques*](https://dl.acm.org/doi/10.5555/41765.41801) why trying to follow these processes in a strict sequence (a “waterfall”) is extremely risky in most circumstances and should normally be avoided. + +Another common mistake is to implement software components independently and never integrate and test them together until everything is completed independently. This is typically a mistake, because this leads to serious problems getting the components to work together. + +In practice, most software development executes these processes in parallel, bouncing information between the processes as new information is learned. There are many ways to combine processes, which depend on many factors such as the size of the team and how reliable the result needs to be. There are many different different approaches, including the many different Agile, incremental, evolutionary, and waterfall development approaches. For purposes of this course, we will focus on security aspects whenever you choose to apply some process, and not much on these specifics. So you can apply this course’s materials regardless of the approach you use. However, let’s look at a few specific practices and terms that can be important for security. + +A highly recommended practice is to use Continuous Integration (CI), the practice of frequently merging working copies of development into a shared mainline (e.g., once every few days through many times a day). This routine merging reduces the risks of components not working together if integration was delayed until later, and that is a good thing. However, successful CI requires a way to determine if the components are actually working together. This is resolved by using a CI pipeline—a process that runs whenever something is merged to ensure that it builds and passes a set of automated tests and other checks. + +Many organizations want to deploy software/services more rapidly, and have adopted various approaches to do that building on these standard software development processes. Definitions vary, but here are some common terms: + +* Continuous Delivery (CD or CDE) aims to ensure *“an application is always at production-ready state after successfully passing automated tests and quality checks [by employing practices] to deliver software automatically to a production-like environment”* (Mojtaba Shahin, Muhammad Ali Babar, and Liming Zhu, [*Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices*](https://arxiv.org/abs/1703.07019), 2017). Note that the software is not necessarily released or deployed without a separate approval step. + +* Continuous Deployment (CD) *“goes a step further [than continuous delivery] and automatically and continuously deploys the application to production or customer environments”* (Mojtaba Shahin, Muhammad Ali Babar, and Liming Zhu, [*Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices*](https://arxiv.org/abs/1703.07019), 2017). + +* DevOps focuses on coordination and cooperation between the software development (Dev) and IT operations (Ops) teams (Mike Loukides, [*Revisiting “What Is DevOps”*](https://web.archive.org/web/20230429215657/http://radar.oreilly.com/2014/06/revisiting-what-is-devops.html), 2014), e.g., to shorten development and deployment time. In practice, this typically includes Continuous Delivery (CDE) and may include Continuous Deployment (CD). + +* DevSecOps (also called SecDevOps) is DevOps, but specifically integrating security concerns into the development and operations process (Red Hat, [*What Is DevSecOps?*](https://www.redhat.com/en/topics/devops/what-is-devsecops)) + +* GitOps "is a way of implementing Continuous Deployment for cloud native applications. It focuses on a developer-centric experience when operating infrastructure, by using tools developers are already familiar with, including Git and Continuous Deployment tools. The core idea of GitOps is having a Git repository that always contains declarative descriptions of the infrastructure currently desired in the production environment and an automated process to make the production environment match the described state in the repository. If you want to deploy a new application or update an existing one, you only need to update the repository - the automated process handles everything else" per
*“Develop an organizational understanding to manage cybersecurity risk to systems, people, assets, data, and capabilities”.* + +2. **Protect**
*“Develop and implement appropriate safeguards to **ensure** delivery of critical services”.* + +3. **Detect**
*“Develop and implement appropriate activities to identify the occurrence of a cybersecurity event”.* + +4. **Respond**
“Develop and implement appropriate activities to take action regarding a detected cybersecurity incident”. + +5. **Recover**
*“Develop and implement appropriate activities to maintain plans for resilience and to restore any capabilities or services that were impaired due to a cybersecurity incident”.* + +This list of five functions is sometimes simplified to three basic functions: **protect**, **detect**, and **respond**. When using this simplified list of three basic functions, identify is considered part of protect, and recover is considered part of respond. We will use that shortened list of basic functions here. + +None of these three basic functions (protect, detect, and respond) is effective by itself. If you only protect, but don’t detect or recover, then an attacker who breaks through your defenses can do whatever they want. If you only detect or recover, without protecting your system, you will never get any work done; you will instead spend all your time on detection or recovery, and soon no one will trust your system. In addition, recovery is useless without detection, because you often won’t know *when* to recover. + +We will talk a lot about protection measures. It is typically cheaper to prevent problems than deal with them later (old proverbs apply here, e.g., *“an ounce of prevention is worth a pound of cure”*). But we will also discuss measures to detect and respond, because they are also necessary. At the very least, larger applications should include mechanisms like logging (to support detection) and backup (to support recovery), because they are necessary in applications we deploy. + +#### Quiz 1.7: Protect, Detect, Respond + +\>\>Choose the correct answer.<< + +(!) Protection is what matters in security; if your protection is good enough, you don’t need detection or response. {{No, because there is always the possibility of an unanticipated mistake.}} + +( ) Response is what matters in security; you can never protect everything anyway, so just focus on response. {{No, because without good protection you will be overwhelmed with problems.}} + +(x) You need protection, detection, and response in security. + +### Vulnerabilities + +A vulnerability is simply a failure to meet some security requirement. Typically vulnerabilities are unintentional, but vulnerabilities can be intentional. For example, someone may have intentionally inserted malicious code (or at least attempted to do so) in the software you reuse or develop, such as a backdoor (a way to gain unauthorized access) or a logic bomb (code that performs a malicious function when specified conditions are met). This course focuses strictly on software, though of course hardware can also have vulnerabilities. + +Modern society depends on software (and hardware), and as a result, there has been a massive growth in the number of publicly-known vulnerabilities. This has made it difficult to answer simple questions like, *“did you fix this particular vulnerability"*? Next, we will outline some efforts that have been made to identify and address known vulnerabilities. + +#### Reporting and Handling Vulnerabilities - A Brief Summary + +There are many people who have, for one reason or or another, found security vulnerabilities in software. Some people, called security researchers, make finding vulnerabilities part of their career. + +In most cases, these vulnerability finders report the vulnerability to the software supplier(s) through a *“timed coordinated disclosure”* process. The finders privately report the vulnerability to the supplier(s), giving the supplier(s) some limited time (called the *“embargo time”*) to fix the vulnerability. After this embargo time (typically 14-90 days), or when the vulnerability has been fixed and users have had an opportunity to install the upgraded version of the software, the vulnerability is publicly disclosed. Sometimes this process is just called *“coordinated disclosure”*, but we want to make it unambiguously clear that in this process, the vulnerability will be publicly disclosed if the supplier fails to fix it in a timely manner. + +In practice, things are more complicated. Often there are multiple suppliers and other stakeholders involved. It is critically important that you (as a developer/supplier) prepare ahead-of-time so that people can easily report vulnerabilities to you, so that you can privately discuss the issue with trusted parties, and so that you can rapidly fix any issues. Later in this course we will further discuss how to accept and report vulnerabilities, including references to useful documents about it. In addition, there is so much software and so many vulnerabilities that there is a need to track vulnerabilities. This need for tracking led to the creation of something called Common Vulnerabilities and Exposures (CVE). + +#### CVEs + +Common Vulnerabilities and Exposures (CVE) is a global dictionary of (some) publicly disclosed cybersecurity vulnerabilities. The goal of CVE is to make it easier to share data about vulnerabilities. A CVE entry has an identification number (ID), description, and at least one public reference. CVE IDs have the form CVE-*year*-*number*, where *year* is the year it was reported and *number* is an arbitrary positive integer to ensure that CVE IDs are unique. For example, [CVE-2014-0160](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160) is a specific vulnerability in OpenSSL (called the Heartbleed vulnerability) that was first reported in 2014. There are databases, such as the [US National Vulnerability Database (](https://nvd.nist.gov/)[NVD](https://nvd.nist.gov/)[)](https://nvd.nist.gov/), that track the current public set of CVE entries. + +CVEs are assigned by a CVE Numbering Authority (CNA). A CNA is simply an organization authorized to assign CVE IDs to vulnerabilities affecting products within some scope defined in advance. The primary CNA (aka “CNA of last resort”) can assign a CVE even if no one else can (this role is currently filled by [MITRE](https://www.mitre.org/)). Many CNAs are software product developers (such as Microsoft and Red Hat) who assign CVE numbers for their own products. There are also third-party coordinators for vulnerabilities, such as the [CERT Coordination Center](https://sei.cmu.edu/about/divisions/cert/index.cfm), who are CNAs. Each CNA is given a block of integers that it can use in CVEs. This means that CVE-2025-50000 does not mean that it is vulnerability number 50,000 in the year 2025, but merely that the CNA who assigned that CVE ID was authorized to assign 50,000 in the year 2025. + +Many publicly-known vulnerabilities do not have CVE assignments. First of all, CVEs are only assigned if someone requests an assignment from a CNA; if no request is made, there will be no CVE. In addition, CVEs are intentionally limited in scope. CVEs are only granted for software that has been publicly released (including pre-releases if they are widely used). CVEs are generally not assigned to custom-built software that is not distributed. They are also not normally assigned to online services. That said, CVEs are the most widely used method for giving a unique identifier for each publicly-known vulnerability, so it is important to know about them. + +#### Top Kinds of Vulnerabilities + +The vast majority of vulnerabilities can be grouped into categories. That turns out to be very useful; once we identify categories, we can determine which ones are common and what steps we can take to prevent those kinds of vulnerabilities from happening again. + +The [Common Weaknesses Enumeration (CWE)](https://cwe.mitre.org/) is a very long list of common weaknesses. In their terminology, a “weakness” is a category (type) of vulnerability. Note the difference between CVE and CWE: a CWE identifies a *type* of vulnerability, while a CVE identifies a *specific* vulnerability in a particular (family of) products. Each CWE has an identifier with a number, e.g., CWE-20. We will mention CWE from time to time. However, the CWE is a large list, and we cannot cover all CWEs in this course. + +People have identified the most important or top kinds of vulnerabilities in terms of their likelihood and severity. Two of the most popular lists of top kinds of vulnerabilities are: + +1. [**OWASP Top 10**](https://owasp.org/www-project-top-ten/)
This list, developed by the Open Web Application Security Project (OWASP), represents a *“broad consensus about the most critical security risks to web applications.”* It is also called the OWASP Top 10 Web Application Security Risks. + +2. [**CWE Top 25 List**](https://cwe.mitre.org/top25/archive/2019/2019_cwe_top25.html)
This is a list of the most widespread and critical kinds of vulnerabilities. It was created by the Common Weaknesses Enumeration (CWE) Team by analyzing data about publicly-known vulnerabilities over many years. This list can be applied to any software, but it is especially common to apply it to software that is not a web application (since the OWASP list focuses on web applications). One interesting quirk: they identify important weaknesses beyond the first 25, so you can see numbers larger than 25 associated with this list. + +OWASP has other top 10 lists for different kinds of software. For example: + +* [OWASP Mobile Top 10](https://owasp.org/www-project-mobile-top-10/) - the mobile applications top 10 + +* [OWASP Internet of Things Project](https://wiki.owasp.org/index.php/OWASP_Internet_of_Things_Project) - the Internet of Things (IoT) top 10. + +That said, the web application top 10 list is the best known top 10 list from OWASP. + +These top vulnerabilities are not only common, but they tend to result in severe vulnerabilities. + + + +These top lists do change over time. Unfortunately, they do not change very much. Many of the top vulnerabilities in the CWE Top 25 have been the same common kinds of vulnerabilities for decades (e.g., see *Computer Security Technology Planning Study*, [volume I](https://csrc.nist.gov/csrc/media/publications/conference-paper/1998/10/08/proceedings-of-the-21st-nissc-1998/documents/early-cs-papers/ande72a.pdf) and [volume II](https://apps.dtic.mil/dtic/tr/fulltext/u2/772806.pdf), by James P. Anderson, 1972), and most of the top web application problems have been common kinds of web application vulnerabilities since the 1990s. So while things do change, learning about the *top* kinds of vulnerabilities will be helpful to you for years to come. + +In various places throughout the course you will see the alarm bell symbol 🔔. This symbol indicates that the vulnerabilities being discussed are so common that they are in the OWASP top 10 web application security risk list and/or the CWE top 25 list. + +#### Value of Knowing Top Kinds of Vulnerabilities + +We will spend a lot of time in this course reviewing common kinds of vulnerabilities. The risk of doing this is that you may think that is all there is to developing secure software. This is not true. + +Avoiding common mistakes is **_not_** enough, by itself, to make software secure. + +But depending on how you measure things, anywhere from 90% to 99% or more vulnerabilities are covered by these top lists. By preventing common mistakes, you will reduce the number of vulnerabilities by at least an order of magnitude! That makes knowing - and countering - common kinds of vulnerabilities very valuable, because it will make your software much more secure. Saying *never make a mistake* is impractical. In contrast, it is practical to focus on identifying and managing the most common kinds of mistakes that lead to vulnerabilities. Part of the reason that these vulnerabilities are common is that most developers do not know what they are; knowing what they are is the first step to managing them. + +Identifying common kinds of vulnerabilities has another advantage, too: It will help you identify *other* kinds of vulnerabilities. As we have already noted, there is no substitute for thinking. But many developers find it challenging to view their systems like an attacker would. By looking at common kinds of vulnerabilities of the past, you can become more sensitive to vulnerabilities in general. So while knowing common kinds of vulnerabilities does not *replace* thinking, knowing them can *help* you think. + +#### Quiz 1.8: Vulnerabilities + +\>\>Choose the true statement.<< + +(!) All publicly-known vulnerabilities are assigned CVE IDs. {{No, someone has to request a CVE ID. In addition, CVEs are only granted for software that has been publicly released (including pre-releases if they are widely used). CVEs are generally not assigned to custom-built software that is not distributed. They are also not normally assigned to online services.}} + +( ) All CVEs are assigned by the MITRE Corporation. {{No, CVEs are assigned by a “CVE Numbering Authority” (CNA.)}} + +(x) Avoiding common kinds of vulnerabilities is not enough by itself to make software secure, but it can be a significant help. + +# Design + +> 🎥 Non-trivial software needs to broken into smaller components that work together, and that breakdown is often called design or architectural design. This chapter describes how to design software to be secure, focusing on key secure design principles such as least privilege, complete mediation, and input validation. These principles will help you avoid common problems and make your software harder to attack. + +Learning objectives: + +1. Explain what secure design principles are and provide examples of some key widely-accepted principles. + +2. Discuss the concept of least privilege. + +3. Discuss complete mediation (“non-bypassability”), including common mistakes. + +4. Understand input validation on an environment you can trust. + +5. Discuss other widely-accepted secure design principles, particularly those identified by Saltzer and Schroeder. + +## Secure Design Basics + +### What Are Security Design Principles? + +When you write non-trivial software, you have to break the problem into smaller components that work together. This process of deciding how to break a problem into components and how they will work together is called *design* or *architectural design*. For example, you are designing when you are trying to decide how to break a problem into a particular set of classes and methods. The result of those decisions is also called a design or architectural design. The word “design” is also used to describe user interface design, but that is not the sense we mean here. + +Remember that the design process, like any other software development process, doesn’t happen just once. It is really common to try to implement some software, realize that the design doesn’t work, and then change the design. You often have to change a design when you change what the software does. So the design process happens whenever you think about changing how to break the problem down in your software. + +Some designs are better than others: some are easier to maintain, faster, and so on. In particular, some designs are more secure than other designs. There is no magic trick that guarantees that your design is secure. But people have been developing software for decades, and through experience, they have identified a set of *design principles* that can help you choose good designs over bad ones. + +Design principles are broadly accurate guides based on experience and practice. Put another way, design principles are rules of thumb for helping you quickly avoid a bad design and guiding you to a good design instead. Secure design principles do not guarantee security, though; they are an aid to thinking, not a replacement for thinking. For example, sometimes a principle will not apply at all. Sometimes principles clash; for example, one secure design principle is keeping things simple, but sometimes you need more complexity to get something else done. In rarer cases, there may be good reasons from a security point of view to even completely violate a principle. That said, your software will generally be more secure if you think about secure design principles and try to apply them. Secure design principles are distilled wisdom, and you would be wise to consider them. + +When thinking about your design, you need to think about what components you can trust (and how much), and what components you cannot necessarily trust. Some design principles talk about a *trust boundary*. The trust boundary is simply the boundary between the components you trust and the components you do not necessarily trust. Where the trust boundary is depends on what software you are developing: + +* If you are writing a server-side application, you presumably trust what you are running on (e.g., the computer, operating system, and container runtime if there), but not the external client systems (some of which might be controlled by an attacker). The trust boundary is between the server and the clients. + +* If you are writing a mobile (smartphone) application that talks to a server you control, you presumably trust that remote server. You should not trust the communication path between your mobile application and server (so you will want to use TLS to encrypt it). You certainly should not trust other applications on the smartphone, unless you have special reason to trust one. So clearly, there is a boundary between your mobile application and (1) the general Internet and (2) other mobile applications. Trust is often not absolute; you probably trust that the mobile smartphone operating system will run for that user, but that user might be an attacker, so you should probably ensure that some secrets never get into the mobile application at all. + +#### Quiz 2.1: What Are Security Design Principles? + +\>\>If you follow secure design principles, you will always create secure software. True or False?<< + +(!) True + +(x) False + +[Explanation] + +Sadly, following secure design principles does not guarantee secure software. Instead, they are a merely valuable guide to that path. You still need to *think*. + +[Explanation] + +### Widely-Recommended Secure Design Principles + +Software has been under attack for decades, and many key secure design principles were identified in 1975 by Jerome H. Saltzer and Michael D. Schroeder (S&S) in their paper, [*The Protection of Information in Computer Systems*](http://web.mit.edu/Saltzer/www/publications/protection/index.html). What is great about their list is that it has stood the test of time; these principles are just as important today. Other principles have been identified since then, but let’s start with their list. + +In their list they focus on the *protection system* - that is, the part of the system that the security depends on. Here is their list, along with some alternative names: + +1. **Least privilege**
Each (human) user and program should operate using the fewest privileges possible. This principle limits the damage from an accident, error, or attack. It also reduces the number of potential interactions among privileged programs, so unintentional, unwanted, or improper uses of privilege are less likely to occur. + +2. **Complete mediation (aka non-bypassability)**
Every access attempt must be checked; position the mechanism so it cannot be subverted. A synonym for this goal is non-bypassability. + +3. **Economy of mechanism (aka simplicity)**
The system, in particular the part that security depends on, should be as simple and small as possible. + +4. **Open design**
The protection mechanism must not depend on attacker ignorance. Instead, you should act as if the mechanism is publicly known, and instead depend on the secrecy of relatively few and easily changeable items like passwords or private keys. An attacker should not be able to break into a system just because the attacker knows how it works. “Security through obscurity” generally does not work. + +5. **Fail-safe defaults**
The default installation should be the secure installation. If it’s not certain that something should be allowed, don’t allow it. + +6. **Separation of privilege (e.g., use two-factor authentication)**
Access to objects should depend on more than one condition (such as having a password). That way, if an attacker manages to break one condition (e.g., by stealing a key) the system remains secure. Note: sometimes programs are broken into parts, each part with a different privilege. This approach is sometimes confusingly called “privilege separation” - but breaking a program into parts with different privileges is something else. In this terminology, that is an example of least privilege. + +7. **Least common mechanism (aka minimize sharing)**
Minimize the amount and use of shared mechanisms. Avoid sharing files, directories, operating system kernel execution, or computers with something you do not trust, because attackers might exploit them. + +8. **Psychological acceptability (aka easy to use)**
The human interface must be designed for ease of use so users will routinely and automatically use the protection mechanisms correctly. + +Since then, other secure design principles have also been identified by different people; we will cover a few of those throughout the course. + +Remember, design principles are simply rules of thumb. As you break your problem down to solve it, you should think about these principles, because they will help guide you to creating more secure software. There are some cases where you will have good reasons to *not* apply them. These principles do not replace thinking - they help *guide* you when you are thinking. + +Next, we will look in more detail at a few of these principles, because they have ramifications that might not be obvious. In the next unit we’ll start by looking at *least privilege*. + +#### Quiz 2.2: Widely-Recommended Secure Design Principles + +\>\>If we keep how the system works a secret, then the system will be secure. True or False?<< + +( ) True + +(x) False + +[Explanation] + +The “open design” principle says that we cannot depend on attackers not knowing how a system works. Instead, we need to design our systems so that they stay secure even when the attacker knows exactly how it works. + +[Explanation] + +### Least Privilege + +We already noted that least privilege is an important secure design principle. The basic idea is that each user (human or program) should operate using the fewest privileges possible. In general, don’t allow reading or writing of information unless you need to do that for that user. + +Least privilege limits the potential damage from an attack, and also reduces the complexity of security-related interactions. This even extends to the internals of a program: only the smallest portion of a program which needs privileges should (ideally) have them. Of course, at some point, this becomes too complicated to do (and we also want to keep the program as simple as reasonably possible). + +#### Ways to Implement Least Privilege + +Here are several ways to implement least privilege, depending on the circumstance: + +1. **Don’t give a program any special privileges (where practical)**
If this can be done, do it, as this is the best from a security point of view. For example, Linux supports making programs **setuid** or **setgid**, so that simply running the program gives the program the privileges of its owner. If you can completely avoid using this mechanism, consider doing it, because it gives special privileges to programs. There are often safer alternatives; for example, requiring people to log in specifically with privileges (this is the purpose of **sudo**). + +2. **Minimize the special privileges a program gets, including minimizing whatever data is accessible to it**
On Linux, you might have a program below (or run on the behalf of) a special group or user that only has specific rights, instead of something more privileged (like root). If you are calling a database system query interface, limit the rights of the database user that the application uses. If your database system uses SQL, you might be able to use the SQL GRANT command to limit the privileges the program gets. Redis users might use Redis’ ACL command to limit privileges. + +3. **Permanently give up privileges as soon as possible**
For example, if you are using Linux saved group IDs, user IDs, or capabilities, permanently drop those extra privileges as soon as possible. That way, if the attack happens afterwards, the attacker cannot exploit those privileges. + +4. **If you cannot permanently give up privileges, try to minimize the time the privilege is active**
This is less effective, because some attacks can force programs to run arbitrary code. But some attacks can only make programs do a limited number of things, and minimizing when the privilege is active will reduce what an attacker can do. + +5. **Break the program into different modules, and give special privileges to only one or a few modules (portions of the program)**
The privileged module will ideally not even fully trust the other parts of your program (aka a *mutually suspicious design*). If you do that, then if some part of your program is subverted, it will limit what an attacker can immediately do. For example, you might split the part of a program that implements a GUI from a different part with privileges. Separation mechanisms like containers, virtual machines, Linux seccomp, and various kinds of security wrappers can help you separate parts of your program so that subversion of one part does not necessarily break another. **_Beware:_** *make sure that you configure these mechanisms to securely separate the modules, and limit the privileges in each part.* These separation mechanisms are often not foolproof, so don’t assume that using them automatically makes your program secure. That said, they can make your program harder to attack and may reduce damage if an attack is successful. + +6. **Minimize (limit) the attack surface**
The *attack surface* is the set of operations (e.g., its API and its open network ports) that a potential attacker can access. For example, if you allow public access to some method, then you are giving all attackers access to that method - are you sure you need to? Where possible, limit the operations that a potential attacker can access. If the public does not need access, do not give the public access. In particular, avoid leaving debug operations in production systems that an attacker can access; debug operations are a common source of problems. + +7. **Validate (check) input before you accept it**
Don’t just accept data from a potential attacker; check it thoroughly before accepting it. We will discuss input validation in more detail later. Of course, you need to make sure that attackers cannot bypass this input validation; this is such a big issue that it has its own principle, *complete mediation*, aka *non-bypassability*. We will be talking about that next. + +8. **Sandbox your program**
Intentionally run your program (or part of it) in an environment with intentionally-restricted capabilities. + +9. **Minimize privileges for files & other resources**
For example, normally you should not have files writable by everyone (even readable by everyone is often dubious). On Android, a file writable by all could be changed by a different (possibly malicious) application. + +
+ +🔔 Incorrect permissions are such a common cause of security vulnerabilities that it is 2021 CWE Top 25 #22 and 2019 CWE Top 25 #15. It is [CWE-732](https://cwe.mitre.org/data/definitions/732.html) (*Incorrect Permission Assignment for Critical Resource*). Incorrect permissions are especially bad if the *default* permissions are insecure; that special case is [CWE-276](https://cwe.mitre.org/data/definitions/276.html) (*Incorrect Default Permissions*). + +#### Examples of Least Privilege + +Let’s take a look at a few specific examples. + +When developing web-based applications, do not allow users to access (read) files such as the server’s **include** and **configuration** files. This data may accidentally provide enough information (e.g., passwords) to break into the system. If you are using a traditional web server, keep everything you don’t need to serve directly to users outside the “documentation root” (**DOCROOT**); that way, attackers cannot even easily request the information. Deny serving files that you know should not be directly served (such as **include** files). + +Don’t allow users to write system configuration files by default (e.g., system files in **/etc** on Linux and Unix), and, where practical, consider preventing reads by normal users as well. The problem is that system administrators often put passwords and keys in configuration files. If there are reasons to give broader read permissions to some of the system configuration information (e.g., in **/etc**), consider creating a system configuration directory instead of a system configuration file where the directory name conventionally ends in **.d**. System configuration directories are often better anyway, because they make it trivial for package managers to add and remove specific configuration files. For security, system configuration directories not only reduce the risk of error, but specific files (such as those with secret keys and passwords) can have more restricted permissions. If you use a system configuration directory, it is less of a problem to allow user read, because it is much easier to protect the secret keys and passwords. + +If you implement an external API (e.g., with REST or GraphQL), don’t provide a “write” operation unless you expect it to be used. If you allow writes, try to maximally limit *who* can write. For example, have owners of specific data and only let owners modify that data, instead of allowing anyone to modify anything. If practical, design your software so it cannot write data *even* if it is subverted by an attacker (though this often is not practical). + +It is unfortunately common to mismanage privileges. For example, there are many cases where programs have failed to drop privileges in all cases (e.g., because raising an exception skipped the code that dropped privileges, or because the code that was supposed to drop privileges does not work in all cases). + +🔔 Improper privilege management is such a common cause of security vulnerabilities that it is 2021 CWE Top 25 #29 and 2019 CWE Top 25 #24. It is [CWE-269](https://cwe.mitre.org/data/definitions/269.html) (*Improper Privilege Management*). + +#### Quiz 2.3: Least Privilege + +\>\>One way you *might* be able to implement some of the “least privilege” privilege (depending on the program) is to use SQL GRANT statements so the program doesn’t have the rights to change certain data even if an attacker takes control of that program. True or False?<< + +(!) False. + +(x) True. + +### Complete Mediation (Non-Bypassability) + +Every time a program gets a request, at least from a source the program cannot completely trust (it is outside the trust boundary), the program must check the request. Examples of security checks are checking that the request is authorized and that the input is valid before you act on that data. This principle is also called *non-bypassability*, because the point is that it must not be possible for an attacker to bypass security checks. + +A common mistake is to try to run security checks on a system that the attacker can control. If an attacker can control a system, then the attacker can easily bypass all security checks run by that system. Let’s look at some examples of *insecure* designs. + +#### Insecure Design: Client-side HTML Input Validation + +A simple example of an insecure design is when a server-side web application sends some HTML to a client, and the HTML includes some validation requirement. For example, the HTML might include the following statement to require that the maximum length be no more than 100: + +~~~~html + +~~~~ + +This HTML is fine if its purpose is to be a quick check to counter accidental mistakes. But since attackers can control their own web browser, this maximum length check is trivial to bypass. An attacker can easily send a much longer input. You cannot *depend* on the web browser to do any security-relevant checking for you if the attacker could control or replace the web browser. + +#### Insecure Design: Client-Side JavaScript/WASM Input Validation + +A related and common insecure design is where code is sent to web browsers, for example, as JavaScript or WebAssembly (WASM), and that code does security checks before sending its data to a server. In most situations, an attacker can control the web browser, while the server is under your control, so again, you cannot trust anything the web browser does. Put another way, any security checks in the code sent to the browser can be trivially bypassed by an attacker, since attackers control their own web browsers. A related problem is providing direct database access to untrusted users. Often users do not need full access, so this is giving users far more privilege than they need (violating least privilege), and such access can make it harder to prevent bypassing security checks. The following figure shows this mistake: + + + +An Insecure JavaScript Application + +#### Secure Design: Input Validation on an Environment You Can Trust + +You can use JavaScript securely, you just need to do it correctly. You can send JavaScript to the client, and you can do some security-relevant checks in the browser (say, to give quick feedback). But if attackers could control some web browsers (but not the servers), the browser-side security checks are irrelevant for security. In this common case, you have to do all security-related input checks in the servers, even if some of the checks were supposed to be done on the client and are now being “redone”. The input checks (validations) are not really being redone, because the client-side ones could not be trusted. + +The following figure shows a similar but secure design; notice that all the security-related checks are being done in the server, since in this case that is the system we can trust. It also prevents direct database access, which is often a good idea if users do not need direct access: + + + +A More Secure Alternative of the JavaScript Application + + +#### Insecure Design: Mobile Application with Client-Side Checking + +A similar common insecure design is code in smartphone mobile applications that does all the security checks before sending its data to a server. Again, we cannot assume that any security checks in the mobile application will actually be made. An attacker could modify the mobile application, or write a different application, to bypass any checks made in the mobile application. If you are writing a smartphone mobile application, you also normally cannot trust the other applications - the other applications may themselves be malicious! + +#### Insecure Design: Client Application Depending on Untrusted Server + +Don’t be confused; the message is not *“server good, client bad”*. The issue is that in almost all cases, any code you need to trust must run in an environment you can trust. + +If you’re writing a web browser, for example, you will need to trust the local operating system services, but you certainly cannot trust arbitrary remote web servers - some of those remote web servers may send you malicious data! + +#### The Key: Run Code You Must Trust in an Environment You Can Trust + +In short: any code you need to trust must (in most cases) run in an environment you can trust, *not* on a system potentially controlled by an attacker. + +You can use client-side JavaScript, client-side WebAssembly, and mobile applications - that is not the problem. You can write web browsers, too! The problem is trusting a system that might be under the control of an attacker. If you have a web-based client-server system, for example, generally the code that runs on the server (that you control) must do all the security checking. After all, attackers can build or modify their own web clients, including any JavaScript sent to their client by a server. It is fine to run checks on a system you don’t fully trust if you want to provide rapid response for unintentional mistakes. But that is not enough - for security, all security checks have to be done (or redone) on a system that you can fully trust. You can run those server-side checks using JavaScript, WebAssembly, or anything else that you trust - but you have to run the checks on a system you can trust. + +Some developers try to run code on systems they cannot trust by using obfuscation. That is, they will use tools that try to make it harder to understand the code sent to a system they cannot trust. An example of this is using JavaScript minification and hoping that it will make the client code hard to figure out. Don’t do that! JavaScript minification’s purpose is to reduce the number of bytes sent over a network, not to hide what the code does or to prevent changing it. + +What can be obfuscated can be de-obfuscated, and it is remarkably easy for attackers to de-obfuscate information. Many tools exist that can quickly de-obfuscate information. Trying to run code you need to trust on systems you cannot trust is best avoided. + +It is much better to run software you need to trust on a system you can trust; then the software just works all the time. + +#### Warning Signs + +Building a system with security checks that can be bypassed is a dangerous mistake. Not only does it mean the system is insecure, but it is often very difficult to fix this mistake once you make it. You might have to rewrite a lot of software to fix this mistake. Here is a quick checklist of things to look for that might indicate these kinds of mistakes: + +* HTML or other data format sent to a client that performs security-relevant input validation on a system an attacker might control. This could be fine, but only if all of those checks are re-performed in a trusted environment. + +* JavaScript or other code sent to the client that does input validation or other security-relevant operations on a system an attacker might control. This could be fine, but only if all of those checks are re-performed in a trusted environment. + +* A mobile app that does security-relevant input validation. This is the same client-side issue. + +* A database that is directly accessible via the network for use by a client application (web browser, mobile app, etc.). This can be secure, but you must ensure that all operations the user is allowed to perform are authorized. In many systems, you can control this with the SQL GRANT command, if you need to do this. However, it is often better (or necessary) to mediate access using a program instead of providing direct access to a database. Direct database access can make it harder to do input validation. It often violates least privilege, since often the user does not need full access to the database. If you do provide direct access to a database, consider limiting the privileges. For example, you might grant access to only a read-only view instead of the entire database. + +* A network communication channel that an attacker can hijack. Properly-implemented network connections that use TLS (such as **https:**) and SSH resist hijacking; almost everything else does not. Software may communicate over the channel assuming that it is talking to the same user/software, but this is easily bypassed if the channel can be hijacked. + +#### Trying to Run Software You Must Trust in Untrustworthy Environments + +*Could* you try to run software that you need to trust on a system you don’t trust? You can try, but that generally works out badly, and trying to do it is a highly advanced topic. Here are some of the techniques that have been tried: + +* One technique is homomorphic encryption. This lets you run code while data stays encrypted. But currently homomorphic encryption is only practical for specialized circumstances. It is orders of magnitude slower and far more complex. + +* Intel’s Software Guard eXtensions (SGX) CPU mechanisms are supposed to enable execution and data storage, but in practice they have been repeatedly broken ([*Plundering of crypto keys from ultrasecure SGX sends Intel scrambling again*](https://arstechnica.com/information-technology/2020/06/new-exploits-plunder-crypto-keys-and-more-from-intels-ultrasecure-sgx/), by Dan Goodin, 2020). + +* If you are trying to secure games on a laptop/desktop, and you don’t trust the laptop/desktop, there are anti-cheat systems. But anti-cheat systems are routinely broken. You are better off having physical events where all the laptops/desktops are owned by you. + +In general, you are better off with simple solutions that do not involve trying to trust systems controlled by attackers. + +#### Quiz 2.4: Complete Mediation (Non-Bypassability) + +\>\>A server sends some React-based JavaScript to a web browser. A developer wants to include some security checks of the input in the client-side (browser-side) React code, and says that the server can trust those security checks because the server sent the client-side React code in the first place. Which of the following is true?<< + +( ) The server *can* trust the client-side security checks in this case. + +(x) The server *cannot* trust the client-side security checks in this case + +[Explanation] + +The server cannot check client-side security checks in general, including in this case. The server may send React-based JavaScript to a web browser, but the *attacker* controls the web browser. That means the attacker can change the code run after it is received, or simply modify the answers the code would send back to the server. Note that this is not specific to React, it would be true for *any* client-side code… we are just using React as a common example. A system generally cannot trust another system that is under the potential control of an attacker. + +[Explanation] + +### The Rest of the Saltzer & Schroeder Design Principles + +Let’s briefly look at the rest of the secure design principles identified by Saltzer and Schroeder (beyond least privilege and complete mediation): + +1. **Economy of mechanism (aka simplicity)**. The system, in particular the part that security depends on, should be as simple and small as possible. This makes that part of the system easier to review and harder to get wrong. Of course, modern software is often asked to provide lots of functionality, so you typically cannot make everything extremely simple, but you can at least work to make the part that security depends on as simple as possible. + +2. **Open design**. The protection mechanism must not depend on attacker ignorance. Instead, the mechanism should be public, depending on the secrecy of relatively few (and easily changeable) items like passwords or private keys. An open design makes extensive public scrutiny possible. An open design also makes it possible for users to convince themselves that the system about to be used is adequate. Frankly, it is not realistic to try to maintain secrecy for a system that is widely distributed; decompilers and subverted hardware can quickly expose any “secrets” in an implementation. One of the big advantages of open source software (OSS) is that it better implements the open design principle; OSS source code has an open design, enabling anyone else to review it and make changes to potentially improve it. Of course, the OSS has to *actually* be reviewed for this to help, but it is an important *potential* advantage. + +3. **Fail-safe defaults (aka fail-secure defaults)**. The default installation should be the secure installation. If it is not certain that something should be allowed, don’t allow it. For example, don’t distribute software with an empty or default password; instead, *require* that a new password be set when the software is installed. That way, if someone just quickly installs it, it will not have a vulnerability due to a known password. Make sure the default permissions are secure; weakness category [CWE-276](https://cwe.mitre.org/data/definitions/276.html) is “Incorrect Default Permissions”. + +4. **Separation of privilege (e.g., use two-factor authentication)**. Access to objects should depend on more than one condition, so that breaking one condition does not break everything. In short, make sure that if your software has a login mechanism, it has a way to support two-factor authentication (2FA). + +5. **Least common mechanism (aka minimize sharing)**. Minimize the amount and use of shared mechanisms if the sharers have different privileges. Avoid sharing files, directories, operating system kernel execution, or computers with something you don’t trust, because attackers might exploit them. Of course, in many cases this is traded off because of other factors. An obvious example is cloud services: in some cases, using a cloud service may cause your program to run in a shared environment with an adversary. In the case of cloud services, there are often mitigating factors that make it acceptable (e.g., the cloud service provider may provide a host of measures to provide better isolation, and/or may have a more experienced team protecting and monitoring the systems than you could). That said, it is still true that anything you share with an attacker might add another way for it to get attacked. If such sharing is too risky for your application, then you could choose alternatives with less sharing (such as a single-tenant cloud or a private cloud). In some cases sharing can reduce costs but increase security risks. The best decision depends on the circumstances, and all the design principles can do is help you identify the trade-off. + +6. **Psychological acceptability (aka easy to use)**. The human interface must be designed for ease of use so users will routinely and automatically use the protection mechanisms correctly. Mistakes will be reduced if the security mechanisms closely match the user’s mental image of his or her protection goals. Some people think that there is always a trade between security and ease-of-use, but that is often not true; if something is hard to use, it is often insecure in practice (because people will work around it). Bad ease-of-use for security reasons usually shows that the software was not designed to be secure in the first place; hopefully this course will help you avoid that! + +## Quiz 2.5 + +\>\>Which of the following is a generally-accepted security principle?||Check all of the options below that are generally-accepted security principles, and do NOT check them otherwise.<< + +[!] Make the source code difficult to understand (e.g., use obscure names) so that vulnerabilities will be more difficult to detect. {{ selected: No, if the source code is more difficult to understand, then it will be more difficult for developers to make it secure in the first place. You should strive to keep the system as reasonably simple as you can. }} + +[ ] Ensure that the design of the security mechanism is secret so that it will be more difficult to discover problems in it. {{ selected: No, a long-understood principle is “open design” - the system must be secure even if the design of the security mechanism is public. Sooner or later its design will be revealed, and you might not know when that has occurred. It is better to ensure that it will be secure even if how it works is well-known. }} + +[x] The software should be secure by default. + +[x] Support 2-factor authentication (2FA), so that even if an attacker has a single authentication value (such as a password) the attacker cannot exploit it. + +[x] Minimize sharing of components between those with different privileges. Examples of components are directories and running containers. + +[x] Make the software easy-to-use, in particular, try to ensure that users will routinely and automatically use the protection mechanisms correctly. + +### Other Design Principles + +Many other design principles have been proposed, based on problems that have happened to past systems. Next, we will take a look at a few other design principles that you should consider. + +#### Beware of Race Conditions + +A *race condition* happens when a system’s correct behavior depends on the sequence of events, but there is no control over that sequence. Race conditions generally involve one or more processes or threads accessing a shared resource, but this multiple access has not been properly controlled. + +
+*Racecars* generated by [OpenAI's Dall-E-2](https://openai.com/dall-e-2/) + +If there is no control at all, that is a defect, and it might even be a vulnerability. Many programs, to be secure, have to do two things: (1) determine if a request is authorized, and (2) if it is, act on that request. If it is possible for an attacker to change the situation between steps 1 and 2, then the program could correctly determine that it is authorized, but then allow a different action that was *not* authorized. This kind of security mistake is so common that it has a name, a *time of check - time of use* (TOCTOU) race condition. + +In many situations, the right way to counter TOCTOU race conditions is to implement and use APIs that both check the authorization and perform the action *simultaneously* (that is, they will not allow an attacker to change the situation between the check and the use). For example: + +1. When you create files or anything else that has privileges associated with it, do not create them and then try to reduce their privileges. Instead, create them with very minimal privileges and expand them as needed. That way, there is no window of time where an attacker might be able to exploit the excess permissions. + +2. If you are writing a program for a Unix-like system, do not call **access()** to see if a file can be opened, followed by a call to **open()** to actually open the file. Instead, set things up to just call **open()** directly, since **open()** includes a check to see if the access is permitted. + +3. If you want to ensure that you create a new file on a Unix-like system, make sure you request that it be created *exclusively* (**O_EXCL** in the C **open()** API, and the letter **x** in **fopen()** and the option flags used in many other programming languages). Again, that way there is no window of opportunity for an attacker to create the file before the program can (if the attacker could do so). + +A somewhat common error on Unix-like systems is insecurely creating temporary files. Temporarily files may be created in a directory where an attacker can influence the creation and names of other files. If an attacker creates a file first, and the application then requests to “create” a file without requesting that it be exclusive, then the existing file controlled by the attacker will be reused. Simply using the exclusive option isn’t enough, since that would still permit a denial of service. The solution is to use a simple loop that creates a “random” filename in the intended directory and then attempt to create exclusively with maximally limited privileges. + +Most languages have a routine or command to securely create temporary files; use them where available. In Python the tempfile module can securely create temporary files. Shell scripts can use the mktemp command to securely create temporary files. + + +🔔 Race conditions are such a common cause of security vulnerabilities that it is 2021 CWE Top 25 #33 and 2019 CWE Top 25 #29. *Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’)* is [CWE-362](https://cwe.mitre.org/data/definitions/362.html). *Insecure Temporary File* is [CWE-377](https://cwe.mitre.org/data/definitions/377.html). + +#### Harden the System + +Defects happen! But they don’t need to turn into vulnerabilities. Instead, try to design your system so a single defect is much less likely to result in complete compromise. This is basically a specific application of the least privilege principle, but if you think specifically about making the system hard to subvert *even* when there is a defect in it, you may identify other steps you can take. + +There are many mechanisms that can harden a system. Examples include Content Security Policy (CSP) and Address Space Layout Randomization (ASLR). We’ll discuss some hardening mechanisms later in the course. The point here is that you should either enable hardening mechanisms or ensure that your users can enable them. + +#### Keep Secrets Secret + +If your software manages secrets like private cryptographic keys and passwords, make sure they stay secret. In particular: + +* Do not put live secrets in your source code. Source code is managed by version control systems and often gets spread to more people and systems than you might think. + +* Store passwords used for inbound authentication with an algorithm specifically designed to do this. We will discuss these later in the course, but these kinds of algorithms are called *iterated per-user salted hash* algorithms (such as argon2id, bcrypt, or PBKDF2). If done correctly, it is infeasible for an attacker to determine many passwords even if the attacker gets the encrypted password data. + +* Use **https://** instead of **http://**; that provides an encrypted link to prevent data leakage. + +* Avoid accepting and sending secret data (like private keys) as command line parameters, where you can; command line parameters are often visible to other processes on a system. + + +#### Trust Only Trustworthy Channels + +In general, only trust information (input or results) from trustworthy channels. For example, use **https://** instead of **http://** when contacting a server, because enables checking if the server has a valid cryptographic certificate for that site. In general you should use **https**, because that will prevent attackers from snooping or modifying information exchanged with other users. + +#### Separate Data from Control + +A useful trick for developing more secure software is to separate data from control (aka programs). Put another way, you should separate the passive data from the programs that are executed. That way, if an attacker manages to slip in “extra” information into data, that will not cause a potentially-malicious program to be executed. This is basically another way to implement least privilege - don’t give data the right to run as a program. + +A good example of this is the Content Security Policy (CSP) supported by modern web browsers. CSP lets you state that the HTML being sent is only data, and is *not* allowed to provide inline scripts (programs) or styles (which can also be programs) - instead, the scripts and styles may only be downloaded from specified trusted places. That way, if an attacker manages to subvert the HTML, the attacker will not be able to cause attacker-provided programs to be run. + +🔔 Insecure design is such a common mistake in web applications that it is 2021 OWASP Top 10 #4. + +#### Quiz 2.6: Other Design Principles + +\>\>Which of the following is a useful additional security principle?||Check all of the options below that are generally-accepted security principles, and do NOT check them otherwise.<< + +[!x] Design and implement systems to ensure that after a request has been authorized, an attacker cannot change something relevant to that decision before the request is acted on. {{ unselected: This is important, it is called a time-of-check/time-of-use (TOCTOU) race condition. }} + +[x] Modify the system’s design and configuration so that compromise is less likely *even* if there is a defect. {{ unselected: This is true, it is called “hardening” a system. }} + +[ ] Put passwords and secret keys in the source code, so that the system can quickly get and use that information without depending on external components or data stores. {{ selected: No, please do *not* do that. Passwords and secret keys should not be in source code. If they re not in source code, people who can see the source code will not get the secret information, and keeping them out of source code also makes passwords and keys easier to change. }} + +[ ] Include control (including programs) with data, so that how to manipulate the data is easily provided with the code. {{ selected: That can be useful, but it is also dangerous from a security point of view. If an attacker manages to slip in “extra” information into data, this design can make it easy to cause a potentially-malicious program to be executed. Sometimes it is important to do this anyway, but it does create more complications when developing secure software. }} + +# Reusing External Software + + + +> 🎥 When developing software today we typically don't develop everything from scratch, we typically reuse a lot of existing software. In fact, on average, software products are mostly reused software. This chapter describes how to reuse software with security in mind, including selecting, downloading, installing, and updating such software. Reusing more secure software generally produces more secure results. + +Learning objectives: + +1. Discuss the vital impact external software has on security. + +2. Discuss how to consider security when selecting software. + +3. Discuss how to consider security when downloading and installing software. + +4. Discuss the importance of updating reused software. + +5. Discuss the importance of avoiding/replacing the use of obsolete interfaces. + +## Supply Chain + +### Basics of Reusing Software + +When developing software, you normally reuse lots of other software. This may include an operating system, a container runtime, frameworks, libraries, extensions, plug-ins, themes, and so on. You will typically also use development tools that others have developed. This reused software, and how you get it, can significantly impact the security of the result. + + + +*Dependency* (retrieved from [xkcd.com](https://xkcd.com/2347/), licensed under [CC-BY-NC-2.5](https://creativecommons.org/licenses/by-nc/2.5/)) + +Some consider the selection of reused software as part of design, since it clearly impacts how we divide up the problem. Others might describe this as its own category, e.g., supply chain. No matter what you call it, it is important. In general, software systems today are mostly reused software from somewhere else. + +If you are purchasing expensive software you selected on behalf of an organization, there are often many steps and processes to work through, primarily focused on controlling money. That is outside the scope of this course. Instead, we are going to focus on the specific aspects related to security. + +Many systems support installing extensions that are separately developed and maintained than the “core” program (often by different developers). ***Extensions need to be separately evaluated before installing them***. The core system may be relatively secure, but that does not mean all its extensions are secure, and often the biggest risks are from the extensions. These extensions may be called many names including extensions, plug-ins, add-ons, themes, components, or packages. No matter what they’re called, evaluate them too. For example, PatchStack reported that while WordPress powered 43.2% of websites on the web in 2021, “vulnerabilities from plugins and themes remain as one of the biggest threats to websites built on WordPress.” They noted that only 0.58% of security vulnerabilities originate from WordPress core in 2021; the rest of the vulnerabilities were in components (plugins and themes). What’s worse, 29% of the WordPress plugins with critical vulnerabilities received no patch. This wouldn’t matter as much if few sites used components, but on average a WordPress website has 18 different components (plugins and themes) installed. See [*State Of WordPress Security In 2021*](https://patchstack.com/whitepaper/the-state-of-wordpress-security-in-2021/) by PatchStack for more information. + +In most cases, the majority of a software application's code is reused software that is licensed as open source software (OSS). OSS is, briefly, software where users have the freedom to run, copy, distribute, study, change and improve the software (this is actually the [Free Software Definition](https://www.gnu.org/philosophy/free-sw.en.html)). A very widely-used and more detailed definition of OSS is the [Open Source Definition (OSD)](https://opensource.org/osd) from the [Open Source Initiative (OSI)](https://opensource.org), who also maintain a list of [OSI Approved Licenses](https://opensource.org/licenses). Software licensed as OSS can be collaboratively reviewed and developed worldwide. Studies show that the average percentage of OSS in software applications is somewhere between 77% ([Black Duck 2024](https://www.blackduck.com/resources/analyst-reports/open-source-security-risk-analysis.html)) and 90% ([Sonatype 2024](https://www.sonatype.com/state-of-the-software-supply-chain/introduction)). + +Since it's so common, let's focus on tips on how to evaluate OSS before reusing it. Many of these tips will also apply to evaluating closed source software. + +### Selecting (Evaluating) Open Source Software + +There are many important things to consider when selecting open source software (OSS). + +The Open Source Security Foundation (OpenSSF) has developed a [*Concise Guide for Evaluating Open Source Software*](https://github.com/ossf/wg-best-practices-os-developers/blob/main/docs/Concise-Guide-for-Evaluating-Open-Source-Software.md#readme) that can help. They suggest that, "As a software developer, before using open source software (OSS) dependencies or tools, identify candidates and evaluate the leading ones against your needs. To evaluate a potential OSS dependency for security and sustainability, consider these questions..." + +The 2022-09-01 version suggests the following questions, along with how to get information to help answer them: + +1. **Can you avoid adding it?** Can you use an existing (possibly indirect) dependency instead? Every new dependency increases the attack surface (a subversion of the new dependency, or its transitive dependencies, may subvert the system). +2. **Are you evaluating the intended version?** Ensure you are evaluating the intended version of the software, not a personal fork nor an attacker-controlled fork. These techniques help to counter the common “typosquatting” attack (where an attacker creates an “almost-correct” name). + 1. Check its name and the project website for the link. + 2. Verify the fork relation on GitHub/GitLab. + 3. Check if the project is affiliated with a foundation (in this case, you should be able to access the official source from the foundation’s website). + 4. Check its creation time, and check its popularity. +3. **Is it maintained?** Unmaintained software is a risk; most software needs continuous maintenance. If it’s unmaintained, it’s also likely to be insecure. + 1. Has significant recent activity (e.g., commits) occurred within the last year? + 2. When was its last release (was it less than a year ago)? + 3. Is there more than one maintainer, ideally from different organizations? + 4. Are there recent releases or announcements from its maintainer(s)? + 5. Does its version string indicate instability (e.g., begin with “0”, include “alpha” or “beta”, etc.) +4. **Is there evidence that its developers work to make it secure?** + 1. Determine whether the project has earned (or is well on the way to) an [Open Source Security Foundation (OpenSSF) Best Practices badge](https://www.bestpractices.dev/). + 2. Examine information on [https://deps.dev](https://deps.dev/), including its [OpenSSF Scorecards](https://github.com/ossf/scorecard) score and any known vulnerabilities. + 3. Determine whether the package dependencies are (relatively) up to date. + 4. Determine whether there is documentation explaining why it’s secure (aka an “assurance case”). + 5. Are there automated tests included in its CI pipeline? What is its test coverage? + 6. Does the project fix bugs (especially security bugs) in a timely manner? Do they release security fixes for older releases? Do they have an LTS (Long Time Support) version? + 7. Do the developers use code hosting security features where applicable (e.g., if they’re on GitHub or GitLab, do they use branch protection)? + 8. Identify security audits and whether any problems found were fixed. Security audits are relatively uncommon, but see OpenSSF’s “[Security Reviews](https://github.com/ossf/security-reviews)”. + 9. Use [SAFECode’s guide _Principles for Software Assurance Assessment_](https://safecode.org/resource-managing-software-security/principles-of-software-assurance-assessment/) (2019), a multi-tiered approach for examining the software’s security. + 10. How do they fare per the [OpenChain](https://www.openchainproject.org/) Security Assurance Reference Guide (the [August 2021 guide](https://www.openchainproject.org/security-guide) and [more recent draft](https://github.com/OpenChain-Project/SecurityAssuranceGuide/tree/main/Guide/2.0) are available)? + 11. Do they apply many practices in the [Concise Guide for Developing More Secure Software](https://github.com/ossf/wg-best-practices-os-developers/blob/main/docs/Concise-Guide-for-Evaluating-Open-Source-Software.md#readme)? +5. **Is it easy to use securely?** + + 1. Are the default configuration and “simple examples” secure (e.g., encryption turned on by default in network protocols)? If not, avoid it. + 2. Is its interface/API designed to be easy to use securely (e.g., if the interface implements a language, does it support parameterized queries)? + 3. Is there guidance on how to use it securely? + +6. **Are there instructions on how to report vulnerabilities?** See the [Guide to implementing a coordinated vulnerability disclosure process for open source projects](https://github.com/ossf/oss-vulnerability-guide/blob/main/guide.md) for guidance to OSS projects., +7. **Does it have significant use?** Software with many users or large users may be inappropriate for your use. However, widely used software is more likely to offer useful information on how to use it securely, and more people will care about its security. Check if a similar name is more popular - that could indicate a typosquatting attack. +8. **What is the software’s license?** Licenses are technically not security, but licenses can have a significant impact on security and sustainability. Ensure every component has a license, that it’s a widely-used [OSI license](https://opensource.org/licenses) if it’s OSS, and that it’s consistent with your intended use. Projects that won’t provide clear license information are less likely to follow other good practices that lead to secure software. +9. **What is your evaluation of its code?** Even a brief review of software source code, and its changes over time, can give you some insight. Here are things to consider: + 1. When you review its source code, is there evidence in the code that the developers were trying to develop secure software (such as rigorous input validation of untrusted input and the use of parameterized statements)? + 2. Is there evidence of insecure/ incomplete software (e.g., many TODO statements)? + 3. What are the “top” problems reported by static analysis tools? + 4. Is there evidence that the software is malicious? Per [_Backstabber’s Knife Collection_](https://arxiv.org/abs/2005.09535), check the installation scripts/routines for maliciousness, check for data exfiltration from **~/.ssh** and environment variables, and look for encoded/ obfuscated values that are executed. Examine the most recent commits for suspicious code (an attacker may have added them recently). + 5. Consider running the software in a sandbox to attempt to trigger and detect malicious code. + 6. Consider running all defined test cases to ensure the software passes them. + +Other resources you may wish to consider include: + +1. [The Tidelift guide to choosing packages well (February 2021)](https://tidelift.com/subscription/choosing-open-source-packages-well), Tidelift +2. [How to Evaluate Open Source Software / Free Software (OSS/FS) Programs](https://dwheeler.com/oss_fs_eval.html) + +There are many places where some of this information can be found (beyond simply using a search engine). They include the projects’ home page and/or source code repository, the main page for an ecosystem’s default package repository, [deps.dev](https://deps.dev/), [metrics.openssf.org](https://metrics.openssf.org/), [libraries.io](https://libraries.io/), Synopsys Black Duck [OpenHub](https://www.openhub.net/), and Linux Foundation [LFX](https://lfx.linuxfoundation.org/). + +Most of these questions also apply to closed source software that is reused. + +Most software depends on other software, which in turn often depends on other software with many tiers. A software bill of materials (SBOM) is a nested inventory that identifies the software components that make up a larger piece of software. Many ecosystems have ecosystem-specific SBOM formats. There are also some SBOM formats that support arbitrary ecosystems: [Software Package Data Exchange (SPDX)](https://spdx.dev/), [Software ID (SWID)](https://csrc.nist.gov/Projects/Software-Identification-SWID/), and [CycloneDX](https://github.com/CycloneDX/specification). When an SBOM is available for a component you are thinking about using, it’s often easier to use that data to help answer some of the questions listed above. It’s also good to provide an SBOM to potential users of your software, for the same reasons. + +> 😱 STORY TIME: Typosquatting by jeIlyfish and python3-dateutil + +> On 2019-12-01 German software developer Lukas Martini discovered that two Python libraries in the popular PyPI (Python Package Index) repository implemented typosquatting attacks. These malicious packages would steal SSH and GPG private keys from developers who used them. The malicious package `jeIlyfish` imitated the non-malicious `jellyfish` package and did the damage (note that in the malicious package's name the third character is an uppercase "`I`", not a lowercase "`l`"). The same attacker also uploaded a malicious package named `python3-dateutil` which imitated the popular `dateutil` library for Python3. The malicious package `python3-dateutil` didn't include any malicious code itself, but instead loaded the malicious package `jeIlyfish` as a dependency. The malicious package `python3-dateutil` had only been on PyPI for two days, but the malicious package `jeIlyfish` had been available for nearly a year. Both libraries were removed by PyPI on the day PyPI was notified (["Two malicious Python libraries caught stealing SSH and GPG keys" by Catalin Cimpanu, ZDNet, 2019](https://www.zdnet.com/article/two-malicious-python-libraries-removed-from-pypi/)). + +#### Quiz 3.1: Selecting (Evaluating) Open Source Software + +\>\>What is evidence that the software you are thinking of reusing will probably be a good choice for security? Select all answers that apply.<< + +[!x] Evidence that it is easy to use securely + +[x] An OSS project that has earned an OpenSSF Best Practices badge + +[x] An OSS project with multiple contributors active within the past year + +[ ] The software has no license statement + +### Downloading and Installing Reusable Software + +Of course, if you download and install a subverted version of the reused software, that could be a serious problem. So make sure that you get the *correct* version of the software: + +1. Make sure you have exactly the correct name. A common attack is called “typosquatting”. In typosquatting, an attacker will create a package name or domain name that is intentionally and maliciously similar to a widely-used software component, and use that misleading name to spread a malicious version of that software. [Ohm & all, 2020](https://arxiv.org/abs/2005.09535) found that *“most malicious [OSS] packages mimic existing packages’ names via typosquatting”*. For example: + + 1. Check for common misleading name changes. It is easy to switch between dash (**-**) and underscore (**_**). One (**1**) and lower-case L (**l**) look similar, as do zero (**0**) and capital O (**O**). In some package managers, uppercase and lowercase ASCII are considered different; in those situations, beware of case. Unicode provides characters that appear exactly the same as ASCII, but are another alphabet, like Cyrillic or Greek; in some cases, these can also be exploited. + + 2. Check how popular the package is. Generally the more-popular version is the correct version. For packages, compare the download counts of similarly-named packages. The ones with lower counts may be typosquatting attacks. Consider using a search engine to identify the most popular package or domain. However, be sure to *ignore* all advertised domains from a search engine; attackers may pay to advertise their malicious version! + + 3. Check the package release date. The older one is often the one you wanted. + +2. Make sure you download and install the software in a trustworthy way: + + 1. You should directly download the software from its main site or from a redistribution site that you have good reason to trust (such as your Linux distribution’s repository or your programming language package manager’s standard repository). + + 2. Typically this means that you should use **https:** (TLS) to download the software, not **http:**, since this generally ensures that you are contacting the site you requested and prevents attackers from modifying the software en route to you. + + 3. Consider downloading the software, but then only install and use it a few days later after verifying nothing has changed. That way, if the distribution site is temporarily subverted when you download the software, but is quickly fixed, you will not be using the subverted version. This is not always practical, since you may be in too much of a hurry to wait, but in some cases this is easy to do. + + 4. Try to avoid using pipe-to-shell (such as **curl … | sh**) to download and install software. You obviously cannot download and delay installation when you use pipe-to-shell. In addition, attackers who subvert a source site can detect a pipe-to-shell request and selectively subvert pipe-to-shell users, who by definition are not reviewing what they are downloading (see [Phil's "Detecting the use of "curl | bash" server side"](https://web.archive.org/web/20230325190353/https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/)). Using pipe-to-shell makes source site subversions much harder to detect and counter. It also makes understanding the actual version you downloaded and installed difficult to authoritatively determine - so you have effectively lost some version control, and you cannot depend on others to be able to determine what happened. Yes, the installed program could report a version, but programs can report any number and could report the same number for different actual versions. In short, your risks increase if you use pipe-to-shell. + + That said, if you only use pipe-to-shell in a contained environment (e.g., a container or virtual machine with limited privileges) and throw away any produced executables, as it often happens in the test environments of continuous integration (CI) pipelines, pipe-to-shell is much less risky. Pipe-to-shell is also hard to avoid in some situations, depending on how the reused software is distributed, and sometimes it is not worth trying to avoid pipe-to-shell. So this is a tip that’s worth considering, but not always worth doing. **Remember**: focus on risk management, not total risk avoidance. + + 5. Where important and practical, try to verify that the package is digitally signed by its expected creators (or at least its redistributors). Software to verify that a package is digitally signed, also called cryptographically signed, has been around for decades. In some situations, there is automated verification that the package does come from a particular redistributor. That said, it is often harder to ensure that you have the correct corresponding public keys (this is an example of a *key management* problem.) There is continuing work in this area, for example, the [sigstore](https://www.sigstore.dev/) project is working to make it significantly easier to digitally sign and verify software artifacts. When you can practically create and verify digital signatures, take advantage of them. + + 6. Beware of depending on being able to download and install components at run-time from other (external) locations. This is a widespread practice for many web applications, particularly for their client-side components such as JavaScript components and webfonts. However, the risk is that if that location becomes unavailable (due to attack or simply because the supplier decides to stop supporting it), your system will become unavailable. The supplier may be a large organization, but they may still choose to stop supporting what you are depending on. Before depending on something at run-time that you don’t have to, at least investigate to determine the future reliability of that service, and use a reliable service such as a well-known content distribution network (CDN). + +You also need to ensure that your system is not vulnerable to a “dependency confusion” aka “substitution” attack. This vulnerability affects systems that identify a list of dependencies and are configured to retrieve those dependencies from more than one repository. Such systems are often configured to depend on some package P where the developers assumed that package P would be retrieved from one particular repository (typically a private repository). The vulnerability occurs if nothing *requires* that the package P be retrieved from its expected repository. If nothing requires it, an attacker can create a malicious package P with the same name on a *different* repository (typically a public repository), and fool the system into using that malicious package instead. Attackers can take many steps to make its use likely, such as giving their malicious version a large version number. This is not a theoretical attack; attackers began widely exploiting this vulnerability in 2021. (For more information, see “[3 Ways to Mitigate Risk When Using Private Package Feeds](https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/)” by Microsoft and “[Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610)” by Alex Birsan.) There are various countermeasures to dependency confusion, for example: + +1. Use a single feed (e.g., a single repository or registry). If there’s a single source, there’s no opportunity for confusion. +2. Clearly declare, for each package, where the package must be retrieved from. These are sometimes called “controlled scopes”. +3. Prioritize feeds so that the most trusted feed(s) are always consulted first, and then less-trusted feeds are only consulted when the more trusted feeds expressly report that the package is not found. Make sure that the less-trusted feeds never override the more-trusted feeds. +4. Use client-side verification features. One approach is to enforce dependency pinning aka version pinning, that is, requiring that a specific known version be used. This can be enforced by requiring a specific cryptographic hash value (aka a “digital fingerprint”) of a package. Another approach is integrity verification to verify that a downloaded package is identical to the first time it was downloaded. + +🔔 Dependency confusion is a special case of 2021 CWE Top 25 #34, *Uncontrolled Search Path Element* ([CWE-427](https://cwe.mitre.org/data/definitions/427.html)). Relying on plugins, libraries, or modules from untrusted sources, and relying on untrustworthy content delivery networks, is considered part of 2021 OWASP Top 10 #8 (A08:2021), *Software and Data Integrity Failures*. + +#### Quiz 3.2: Downloading and Installing Reusable Software + +\>\>What are good ways to acquire software? Select all answers that apply.<< + +[!x] Double-check that the name you will request is really the one you wanted (e.g., **-** and **&95;** are not swapped, **O** and **0** are not swapped, and so on) + +[x] Use **https:**, not **http:** + +[x] Consider downloading the software, but then only installing it a few days later after verifying there are no problems reported on that site + +### Updating Reused Software + +#### Updating Reused Software Components + +In practice, you will have many reused software components, and they will need to be updated occasionally. Sometimes a vulnerability will be found in one, in which case you need to be notified quickly and be prepared to rapidly update. As a result, you need to manage reused components: + +1. Use package managers, version control systems (such as git), build tools, and automated tests so that you can easily determine exactly what versions you have of every reused component and can rapidly update any of them. + +2. Only depend on *documented* interfaces and behavior, and avoid obsolete interfaces, to maximize the likelihood of being able to update reused software when necessary. + +3. *Expect* that you will be updating the software you use, including your underlying platform. It is foolish to assume that software will never need to be rapidly updated. + +4. Do not modify OSS and create your own “local fork”. If a vulnerability is fixed in a later version of that OSS, it will become increasingly difficult to incorporate that fix. Instead, if you need to modify some OSS to fit your needs, work with the original upstream OSS project to get your improvements incorporated into the official version. Then newer versions of that OSS, including ones that fix vulnerabilities, will also include the capabilities you need. + +5. Keep your reused software relatively up-to-date. If your reused components go very far out-of-date, then it may be very difficult to replace a vulnerable version with a fixed version. + +6. Monitor to determine if any of the software versions you use has had a publicly-known vulnerability discovered. We will discuss this later in the section on software composition analysis (SCA). + +> 😱 STORY TIME: Equifax + +> The widely-used program Apache Struts had a critical vulnerability that was fixed on 2017-03-06 and widely reported by the computer press. The data broker Equifax was notified by Apache, US CERT, and the US Department of Homeland Security about the vulnerability, and was provided instructions on how to make the fix. However, Equifax failed to implement a timely update. *“Two months later, Equifax had still failed to patch its systems. It eventually got around to it on July 29. The attackers used the vulnerability to access the company’s databases and steal consumer information on May 13, over two months after Equifax should have patched the vulnerability.” Equifax reported that “145.5 million US customers, about 44% of the [US] population, were impacted by the breach... The attackers got access to … exactly the sort of information criminals can use to impersonate victims to banks, credit card companies, insurance companies, cell phone companies and other businesses vulnerable to fraud. As a result, all 143 million US victims are at greater risk of identity theft, and will remain at risk for years to come. And those who suffer identity theft will have problems for months, if not years, as they work to clean up their name and credit rating.”* (Bruce Schneier, [*Me on the Equifax Breach: Testimony and Statement for the Record of Bruce Schneier*](https://www.schneier.com/blog/archives/2017/11/me_on_the_equif.html), 2017) + +#### Updating How You Use Reused Software (Avoid/Replace Obsolete Interfaces) + +You not only need to update components you use, but also how you use them. + +When components are updated, they sometimes replace their interface with a new/improved interface over an obsolete/deprecated interface. Where practical, you should avoid or replace any uses of the obsolete/deprecated interfaces of other components. Sometimes the interface is obsolete because of a security vulnerability. In addition, these obsolete interfaces are typically dropped over time, so if you use the obsolete interface, it may be impossible to quickly update if a vulnerability is later found. + +If you are obsoleting an interface used by others, do your best to provide a long transition period where both the old and new interfaces are available. Some projects will not be able to easily switch, and it can sometimes take time. Trying to force a rapid update often backfires and causes users to *reject* your updates or delay using them, potentially leading to long-term security problems. + +#### Reusing Software: Wrap-up + +These are merely tips, and are by no means exhaustive. It is great that we have so much great software to reuse; modern software development would be impossible without them. However, there are a few potential security pitfalls with reused software. The practices we have discussed in this chapter will help you avoid many security problems due to reused software. + +#### Quiz 3.3: Updating Reused Software + +\>\>Reused software is so dangerous that you should always prefer to rewrite that software yourself when you can. True or False?<< + +( ) True + +(x) False + +[Explanation] + +This is false. Sure, there are risks when reusing software, but there are risks in writing software yourself. It is likely that you will make mistakes as well, and those who wrote the reusable software have often spent years developing expertise in that specific area. Instead of trying to rewrite everything - which would be economically impractical - you should approach reusing software as a risk management problem. You should examine your choices, including using the tips here, to make reasoned decisions. + +[Explanation] + +# Part I: Final Exam + +* Not included as part of the free version of the course. + +# Part II: Implementation + +# Basics of Implementation + +### Implementation Overview + +You may know what your software is supposed to do (requirements) and may have a way to divide up the problem (design). But if your implementation is bad, the software is bad! + +This section discusses how to implement secure software. We will do that by considering a very abstract view of a program, as illustrated by the following figure: + + + +**Abstract View of a Program** + +Almost all programs have inputs (that you should validate), process data, call out occasionally to other programs, and eventually produce output(s). Calling out to another program creates (essentially) inputs to those other programs, and outputs from those other programs. The next few subsections will discuss each of those areas in turn. We will then discuss a few specialized topics. + +Of course, just saying *“write secure code”* or *“don’t make mistakes”* is not helpful. The good news is that nearly all errors that cause vulnerabilities today can be grouped into a relatively small number of categories, and some of those categories are especially common. So as noted earlier, we can eliminate a vast majority of security vulnerabilities simply by learning about these categories, knowing how to look for them, and mitigating them. We will repeatedly mention the OWASP Top 10 List (for web applications) and CWE Top 25 List (for applications in general), as they provide a useful way to identify what is most important. + +A few of the common kinds of vulnerabilities are design problems. However, most of the rest are implementation issues. As we walk through our model of a program, we will discuss the relevant kinds of vulnerabilities, including how to detect them and counter them. Once you start applying this information, you will find that many vulnerabilities vanish from your program. + +Practically all programs have to accept input. So we will begin examining how to implement secure software by discussing how to securely handle inputs. + +# Input Validation + +> 🎥 A key part of implementing secure software is to only accept input that should be accepted. This chapter describes how to validate input, including how to validate numbers and text, the importance of minimizing attack surfaces, and how to improve availability by considering the inputs. Limiting input won't counter every attack, but it will tend to make the software harder to attack. + +Learning objectives: + +1. Discuss the basics of input validation. + +2. Understand how to validate numbers. + +3. Examine key issues with text, including Unicode and locales. + +4. Explain how to use regular expressions to validate text input. + +5. Understand the importance of minimizing attack surfaces. + +6. Discuss secure defaults and secure startup. + +7. Improve availability by considering the inputs. + +## Input Validation Basics + +### Input Validation Basics Introduction + +Some inputs are from untrusted users, and those inputs (at least) must be validated before being used. If you prevent invalid data from getting into your program, it will be much harder for attackers to exploit your software. Input validation can also prevent many bugs and make your program simpler. After all, if your program can immediately reject some malformed data, you don’t have to write the code to deal with those special cases later. That saves time, and such special-case code is more likely to have subtle errors. + +It can also be a good idea to check inputs from trusted users. Even trusted users make mistakes, and immediately catching those mistakes can make the system more reliable. There is debate on how much validation should be done on the inputs from trusted users. On one hand, trusted users can clearly make mistakes, and validation can prevent costly mistakes. On the other hand, if too much time is spent on validating inputs from trusted users, perhaps other more-important tasks will be skipped, and sometimes trusted users need to be able to do unusual things to respond to unexpected events. Where it is not too time-consuming, it is probably best to do at least some input validation on inputs from trusted users too. For the purpose of this course, we will focus on validating input from untrusted users. Just remember that the same techniques can also be applied to trusted inputs. + +First, make sure that you identify all inputs from potentially untrusted users, so that you validate them all. Where you can, eliminate the inputs or make it impossible for untrusted users to provide information to them. We discussed this earlier as the design principle *minimize the attack surface*. + +At each remaining input from potentially untrusted users you need to validate the data that comes in. These input validation checks are a kind of security check, so you need to make sure that these input validation checks are non-bypassable, as we discussed earlier in the design principle *non-bypassability*. **As a reminder:** only trust security checks (including input validation) when they run on an environment you trust. This is especially important for JavaScript programs - since JavaScript can run on web browsers, it is easy to send security checks to the web browser and forget that *attackers* can control their own web browsers. Any input validation checks you do in an untrusted environment cannot be trusted. If you trust your server environment and not the client environment, then all security-relevant checks must be done in the server environment. We discussed this already, but it is important to emphasize because it is such a common and serious problem. Now let’s move on to how to actually validate input. + +#### Lab: Input Validation Basics Introduction + + 🧪 **Lab: This course includes some labs. Please try lab [hello](https://best.openssf.org/labs/hello.html) to see how the labs work in this course.** + +*Labs are optional, but you're strongly encouraged to try them!* + +If a section has a quiz and one or more labs, we'll present the +quiz first. This order is intentional. +Quizzes help make sure you can *recognize* a correct answer, +while labs help you *create* a correct answer. Recognizing a correct answer +can be a first step towards creating your own. + +### How Do You Validate Input? + +You should determine what is legal, as narrowly as you reasonably can, and reject anything that does not match that definition. Using rules that define what is legal, and by implication rejecting everything else, is called *allowlisting* (the rules themselves are an *allowlist*). Synonyms are *goodlisting* (the rules are the *goodlist*) and the historically common *whitelisting* (the rules are the *whitelist*). In general, do not do the reverse. That is, it is normally a mistake to try to identify what is illegal and write code to reject just those cases. This generally insecure approach, where you try to list everything that should be rejected, is called *denylisting* (the rules are a *denylist*). Synonyms for denylisting are *badlisting* and the historically common *blacklisting* (the rules are then called a *badlist* or *blacklist*). Denylisting typically leads to security vulnerabilities, because if you forget to handle one or more important cases of illegal input, it could be an opportunity for an attacker. If you forget to allow a case, you get a bug report and your software fails securely. Besides, it is usually much easier to simply identify *what is allowed* and only allow those inputs. In a few rare cases you *can* absolutely be certain that you have enumerated all possible bad inputs, in which case denylisting is okay, but those are rare. Generally denylisting leads to trouble. + +🔔 Improper input validation is such a common cause of security vulnerabilities that it is 2019 CWE Top 25 #3 and 2021 CWE Top 25 #4. It is also identified as [CWE-20](https://cwe.mitre.org/data/definitions/20.html) (*Improper Input Validation*). + +The good news is that it usually does not take long to add input validation, and that can immediately make your program harder to attack. It may be hard to decide on a user-friendly response to invalid input, but it is easier than suffering a successful attack. + +There is a good reason for identifying *illegal* values; use them as a set of tests to be sure that your validation code is thorough. These tests may possibly just be executed in your head, but at least a few should become test cases in your automated test suite. When we set up an input filter, we mentally attack our allowlist with a few pre-identified illegal values to make sure that a few obvious illegal values will not get through. Depending on the input, here are a few examples of common illegal values that your input filters may need to prevent: the empty string, “**.**”, “**..**”, “**../**”, anything starting with “**/**” or “**.**”, anything with “**/**” or “**&**” inside it, common metacharacters (like semicolon, single quote, double quote, and the less-than symbol), and any control characters (especially the NUL character and newline). Where numbers are expected, checking for other kinds of text that should not be allowed. Also check for very, very long inputs. + +Later, we will discuss various kinds of security analysis tools. One kind, fuzzers, intentionally create a large number of malicious inputs that (among other things) test the quality of your input validation checks. But fuzzers do not guarantee to find all input validation problems. Instead, carefully implement your input validation, and then use tools to help you find problems you would have otherwise missed. + +Again, your code should use *allowlisting* (narrowly identifying what is legal and reject the rest), not *denylisting* (trying to identify bad inputs). Try to make that allowlist pattern as narrow as possible, including limiting the maximum input length (and minimum input length if appropriate). + +#### Quiz 1.1: How Do You Validate Input? + +\>\>In general, you should validate inputs from untrusted users by:<< + +(!) Rejecting patterns that are known to be malicious. + +(x) Identifying a strict pattern of what is permitted and rejecting any input that does not meet it. + +[Explanation] + +In general, you should use *allowlisting*, not *denylisting*. Attackers can always come up with another attack, so trying to come up with a list of “everything that should be denied” is a never-ending task. It is generally better to narrowly determine what should be allowed, and then reject everything else. + +[Explanation] + +## Input Validation: Numbers and Text + +### Input Validation: A Few Simple Data Types + +So, how do you do input validation that uses an allowlist (that is, a pattern that is as narrowly-defined as possible)? In short, you do it on each input, and what you check for depends on the type of data. Let’s discuss a few common cases next. + +#### Numbers + +One common input is a sequence of characters representing a number. Typically, you check numbers (especially integers) to make sure they are between a minimum and maximum value. It is good to do some checking before you convert the text to a number, but in this particular case, check the value *after* converting to a number, to be certain that the *rest* of the program will only see that number if it is in a valid range. Common minimums are 0 and 1. If the number is supposed to be an integer, make sure it is an integer and reject anything else. + +Where practical, store the numeric result in a type that is narrowly defined for the purpose. For example, store the number in an integer type if the number is an integer, use an unsigned type if negative numbers are not allowed, and so on. If you have to accept floating point data from an untrusted user (and try not to!), store it in an appropriate type and watch out for its many special cases (such as NaN, infinities, negative 0, underflows, and overflows). For example, normally the floating point value NaN is not equal to any value; it is not even equal to itself. Limiting the type is not always practical because this is very language-dependent; not all languages have such types. For example, JavaScript does not have an unsigned type. + +Note that *“only allow an integer between 0 and 200 including those endpoints”* is an allowlist; you have identified the pattern of what is allowed, and anything else will be rejected. + +#### Well-Known Special Text Formats + +Sometimes your inputs are text with a standard format and there is a library that can do the validation for you. For example, most languages have some routine that can check the format of email addresses. When you have one you can trust, use it! + +Sometimes the validation libraries you can use require some configuration. Again, configure them to be as narrow (limiting) as possible. For example, if you accept HTML, limit it to only the tags and attributes that you need. Often when you accept HTML, you need to only accept a few tags (e.g., **<i>** for italics, **<b>** for bold, **<a>** for hyperlinks) and attributes (e.g., the **href** attribute of the **<a>** tag so that you can say where to link to, and maybe an **id** attribute so others can refer to a particular point). Then, when an attacker tries to provide HTML with other tags (for example, a malicious **<script>**), the validator simply will not accept it at all. + +Some input formats are composite structures of a lot of other data. For example, JSON, XML, and CSV files can contain lots of other data. You would typically use a trustworthy library to examine and extract the portions of the data you need, and then you would validate each piece. So again, if you extract a sequence of characters representing a number, you would validate the number (e.g., to see if it is within the minimum and maximum range). In many cases, it is a text value. We will further discuss handling composite structures later, but at some point, they will decompose to specific values, often as numbers or text. + +Many programs need to validate text fields, but those fields’ rules are not defined in a pre-existing library. Some tools allow us to easily handle them, but to use them, we need to understand some background. We will first need to discuss more about text, unicode, and locales in general. Then we will discuss text validation in general and the common way of doing so - regular expressions. + +#### Quiz 1.2: Input Validation: A Few Simple Data Types + +\>\>Select all the good practices for validating an input number from an untrusted source:<< + +[!x] Check that it is at least as large as the minimum. + +[x] Check that it is at most as large as the maximum. + +[x] Use an unsigned type if your language supports it and the input is not allowed to be negative. + +[x] Require that the number be an integer if that is the only expected kind of number. + +#### Lab: Input Validation: A Few Simple Data Types + + 🧪 **Lab: Please try lab [input1](https://best.openssf.org/labs/input1.html), which lets you practice validating input of a simple data type.** + +*Labs are optional, but you're strongly encouraged to try them!* + +### Sidequest: Text, Unicode, and Locales + +[[OPTIONAL]] + +Often you receive text as input (either directly or as part of some larger structure). We will describe text as simply a sequence of characters. If the text input is untrusted, you then need to validate that text. To understand this, we must understand what text *is*. A remarkably large number of developers have never learned much about text - even though it is one of the most common data types - so let’s make sure you understand that first. If you are already confident you are familiar with text issues such as Unicode, encoding, and locales, feel free to skip on. + +#### Code Points and Encoding + +Digital computers do not directly handle characters; we instead need to assign a number to each character. Different character sets with different assignments were created for different languages, and this created interoperability nightmares. In the vast majority of cases today you will use the character assignments specified by Unicode and ISO/IEC 10646, which define a Universal Character Set (UCS) that assigns a unique number (*code point*) for every character. For example, they assign the Latin character capital “A” the decimal number 65. + +Historically, it was thought that 16 bits would be enough to identify all characters, but this was mistaken and was changed in 1996 (they now use 21 bits to encode any character). As a result of this mistake, some programming languages have a “character” type (e.g., Java’s **char**) that is only 16 bits long. A 16-bit data type cannot, by itself, store any arbitrary 21-bit character, so in programming languages and APIs with a 16-bit “character”, a “character” is sometimes only half of an actual character. + +Text that uses these assignments need to be exchanged using an *encoding*. There are five standard encodings for Unicode: UTF-32 (big-endian and little-endian), UTF-16 (big-endian and little-endian), and UTF-8. Generally, you should use UTF-8 unless you have a reason to do otherwise. UTF-16 and UTF-32 both have two forms: “little endian” and “big endian”. If you don’t know if the recipient expects big-endian or little-endian, you should add a *byte order marker* at the beginning of the text to make sure that the receiver interprets it correctly, and when receiving UTF-16 or UTF-32, your application needs to pay attention to that. A critical issue is that some sequences of bytes are *not* valid, so when we do input validation, we will need to ensure that the data we receive is valid for the encoding we expect. + +#### Locales + +Interpreting characters is more complicated than you might think. Much depends on the “locale”, which defines the user’s language, country/region, user interface preferences, and probably character encoding. For example, on Unix/Linux systems, Australian English with UTF-8 encoding is represented as the locale **en_AU.UTF-8**. Locale is important, because it affects how characters are interpreted. For example, it affects: + +* Collation (sorting) order + +* Character classification (what is a “letter"?). Ranges like “A-Za-z” do not list *all the alphabetic characters* in arbitrary locales. If you use the C or POSIX locale and are only processing ASCII characters, then that range is the complete list of alphabetic characters, but that is not true in general. + +* Case conversion (what is upper/lower case of a character, if it exists?). Note that even if there is a conversion, it might not convert to a single character in a given locale. + +If you want to interpret text in the same way regardless of locale, the usual solution is to use the “C” aka “POSIX” locale - however, be careful, because that is not always what the user wanted. + +Case conversion is especially fraught. Some languages don’t have upper and lower case letters. Even if they do, the mapping between them is different between different locales. So the uppercase version of a letter is *not* fixed - it is based on the locale! + +A great example of this are the Turkic languages that use the Turkish alphabet. In this alphabet dotted and dotless “I” are distinct letters with upper and lower case forms. For example, lowercase dotted “i” when capitalized becomes capital dotted “İ” (not uppercase dotless “I” as it does in an English locale), and uppercase dotless “I” when lowercased becomes lowercase dotless “ı”. Note that “i” and “I” are *not* equal in a case-insensitive match in a correctly-implemented system for such locales. This has resulted in several security vulnerabilities, and we will occasionally mention this in the course because it is a great example of the kinds of mistakes that can happen if you are not aware of it. + +If you want to know if “two sequences of characters are equivalent” ignoring case, then in the general case you need to call a routine to do this *and* provide it the locale to use. This raises the issues about equivalence in general, which we will discuss next. + +#### Unicode Equivalence + +Many programmers assume that if a sequence of text “code points” are different, they are different strings. While that is fine for some purposes, that is the wrong mental model for others, even if you assume that you want a “case sensitive” match. Unicode had to be developed in a way that was compatible with pre-existing standards, and that led to some complications. + +In some cases you should use library routines to test for Unicode canonical equivalence. That is because there are some code points, or sequences of code points, that in many circumstances should be considered *equivalent* in the sense that they should always appear identical, even if they have different underlying values. For example, the code point U+006E (the Latin lowercase “n”) followed by U+0303 (the combining tilde “◌̃”) is canonically equivalent to code point U+00F1 (“ñ”). Another example is the character “Å” that can be represented as U+00C5 (the letter “LATIN CAPITAL LETTER A WITH RING ABOVE”) or as U+212B (“ANGSTROM SIGN”): these two values should be considered equivalent. + +In some other cases, you should use routines to test for Unicode compatibility. That is because there are some sequences that might appear different but would have the same underlying meaning. For example, the code point U+FB00 (typographic “ff”) is compatible, but not equivalent, to U+0066 U+0066 (two Latin “f” letters). Equivalent strings are always compatible, but compatible strings are not always equivalent. + +This is a pain, so the Unicode standard defines text normalization procedures, called Unicode normalization. Unicode normalization turns equivalent or compatible sequences into the exact same sequence of characters. There are 4 normalization forms: + +* NFD (Normalization Form Canonical Decomposition)
Characters are decomposed by canonical equivalence, and multiple combining characters are arranged in a specific order. + +* NFC (Normalization Form Canonical Composition)
Characters are decomposed and then recomposed by canonical equivalence. + +* NFKD (Normalization Form Compatibility Decomposition)
Characters are decomposed by compatibility, and multiple combining characters are arranged in a specific order. + +* NFKC (Normalization Form Compatibility Composition)
Characters are decomposed by compatibility, then recomposed by canonical equivalence. + +From a security point-of-view it normally does not matter *which* Unicode normalization you use, but if you want to determine if two strings are equal, you need to be *consistent* about the normalization you use when comparing them. Also note that once you normalize a sequence of characters, you cannot in general regenerate exactly the original sequence. + +#### Visual Spoofing + +*Visual spoofing* happens when two different strings are mistaken as being the *same* by the user. Attackers will sometimes use visual spoofing as part of an attack. + +Visual spoofing can even happen in the ASCII subset of Unicode. The digit “0” looks like the uppercase letter “O”, and the digit “1” looks like the lowercase letter “l”. For example, an attacker might try to create a malicious **paypa1.com** domain instead of **paypal.com**. The sequence “rn” is sometimes misread as the letter “m”! That said, most users of Latin alphabets are aware of these problems, and many fonts take care to make them more distinguishable. + +But once we move beyond the ASCII subset, many other tricks exist: + +* Decomposition
“ƶ” may be expressed as U+007A U+0335 (z + combining short stroke overlay) or as U+01B6. This means that different sequences of bytes may still indicate the same letter (and thus look identical). Normalization solves this problem. + +* Mixed-script
Greek omicron & Latin “o” typically look the same, even though they are in different sections of Unicode. + +* Same-script
Some characters simply look similar. E.g., “-” Hyphen-minus U+002D vs. hyphen “‐” U+2010. + +* Bidirectional Text Spoofing
Some languages are mostly right-to-left, but switch in certain situations to left-to-right. Thus, Unicode includes mechanisms to indicate direction. But this means that the string “olleh”, surrounded by “use right-to-left”, will visually look the same as “hello”. + +Visual spoofing can be very challenging to counter in general. Normalization and using distinctive fonts is not always enough, but it can sometimes be very helpful. + +#### Quiz 1.3: Sidequest: Text, Unicode, and Locales + +\>\>In Unicode a character is represented by a 16-bit value. True or False?<< + +( ) True + +(x) False + +[Explanation] + +There are simply too many characters to encode them all in 16 bits, so Unicode now uses 21 bits to encode characters. Many languages and APIs use 16-bit “character” values, but if they are to represent all Unicode characters, sometimes these characters are only *part* of an actual character. + +[Explanation] + +### Validating Text + +Now that we have an understanding about text, let’s talk about validating it. In almost all cases there are at least two checks to do on text from an untrusted source: + +* Validate that the text is in the expected text encoding. As noted earlier, unless you have a reason to do otherwise, we recommend using the UTF-8 encoding. UTF-8 will let you work with scripts from arbitrary languages, is backwards-compatible with ASCII, and is widely supported. UTF-8 is a good encoding, but not every sequence of bytes is valid UTF-8. Many vulnerabilities have occurred because a system accepted bytes from an attacker that are not valid UTF-8. So it is really important to validate UTF-8 text before you accept it from an untrusted source. + +* Check if it is within the minimum and maximum lengths, if there are minimum and maximum lengths. Many systems will want to have a maximum simply to prevent attackers from sending absurdly-large amounts of data. + +In some cases it may be very difficult to check much more. Personal names, in particular, are challenging, especially if you must deal with names in all locales. Many locales have conventions that are different from other locales; for example, is the given name or the surname (e.g., family name) listed first? There may not even be a surname or a given name. Names may contain spaces (even within a given name or surname), and, of course, there is no guarantee that the name uses only Latin or Chinese characters. For a discussion of the challenges, see the [*Falsehoods Programmers Believe About Names – With Examples*](https://shinesolutions.com/2018/01/08/falsehoods-programmers-believe-about-names-with-examples/) article by Tony Rogers (2018). + +In many cases, though, there is more that you should do to validate text. In many cases, text values have additional rules they need to obey, and those rules vary depending on each text input. + +Sometimes the text value must be one of a short list of values. That’s easy, just store the allowed collection somewhere (e.g., in a set or dictionary). Then, every time you receive input, validate that the input is one of the allowed values. + +But that leaves us with the many text inputs that have rules, but they are not just a list of allowed values. They may be dates, times, part numbers, phone numbers, locations, and a host of other kinds of data. We still need to validate those inputs, and many programs have many different kinds of data. That means we need some way to *easily* describe those validation rules. The common tool for this purpose is regular expressions. In the next unit, we will optionally explain regular expressions (regexes) if you are not familiar with them; the unit after that will explain how to use regular expressions to validate inputs. + +### Introduction to Regular Expressions + +[[OPTIONAL]] + +If you already know about regular expressions, feel free to skip this unit. + +A regular expression (a *regex*) is a sequence of characters that defines a text pattern. Practically all programming languages have a built-in system or easily-acquired library that implements a regular expression language, so it is usually easy to start using regular expressions in a program regardless of how it is implemented. + +However, some software developers have never used regexes. This unit provides a brief introduction if you are not already familiar with them. If you already understand regexes, feel free to skip to the next unit! + +Historically regexes were developed to make it easy to search for text, though they are now often used to determine if some text matches a pattern. There are many implementations of regex systems, but since they all come from the same historical root they have much in common. + +The most trivial rule is that a letter or digit matches itself. That is, the regex “**d**” matches the letter “**d**”. Most implementations use case-sensitive matches by default, and that is usually what you want. + +Another rule is that square brackets surround a rule that specifies any of a number of characters. If the square brackets surround just alphanumerics, then the pattern matches any of them. So **[brt]** matches a single “**b**”, “**r**”, or “**t**”. + +The pattern “**.**” matches any one character, with the possible exception of the newline character. If you want to match a literal period, precede it with a backslash (“**\.**”). Practically every implementation of regexes has a mechanism to let you decide if “**.**” should match a newline. + +A regex pattern is usually a sequence of rules, stated one after the other. For example, the regex pattern “**ca[brt]**” will match the text “**cab**”, “**car**”, or “**cat**”, because the letters “**c**” and “**a**” match themselves, and “**[brt]**” matches a single “**b**”, “**r**”, or “**t**”. + +In fact, by default, regexes *search* for the given pattern in a string. That is, normally a regex implementation will see if a pattern matches some text if it starts at the first character, then second character, and so on, reporting if it can find *any* match. So the pattern “**ca[brt]**” will also match “**abdicate**” because there is a “**cat**” in the word “**abdicate**”. + +Regular expressions can do much more, though. If you follow a pattern with “*****”, that means “*0 or more times*”. So the regex pattern “**a*b*x**” describes a pattern of 0 or more **a**’s, followed by 0 or more **b**’s, followed by **x**. This pattern matches strings like “**aabx**”, “**bbbx**”, and “**abx**”, but not “**aabb**”. Most regex implementations also support “**+**” for “*1 or more times*” and “**?**” for “*0 or 1 times*”. Most regex implementations also let you use parentheses to group expressions, for example, “**f(abc)*d**” matches if there is an “**f**”, followed by 0 or more instances of the sequence “**abc**”, followed by the letter “**d**”. + +You can usually do a case-insensitive match through some option. Make sure you set the locale if you use case-insensitive matching, since different languages have different rules, and sometimes the rules can be complex. For example, in German the lowercase “sharp-s” character “**ß**” is equivalent to the uppercase “**SS**” when using a case-insensitive match. In some cases, you may only want to do “*ASCII case-insensitive matching*”; this compares a sequence of code points as if all ASCII code points in the range 0x41 to 0x5A (A to Z) were mapped to the corresponding code points in the range 0x61 to 0x7A (a to z). + +There is far more to regexes. In fact, there is a whole book on just regular expressions, [*Mastering Regular Expressions, 3rd Edition*](https://www.oreilly.com/library/view/mastering-regular-expressions/0596528124/), by Jeffrey Friedl (2006), and there are many tutorials on regexes such as the [Regular Expressions for Regular Folk](https://refrf.shreyasminocha.me/) tutorial by Shreyas Minocha. But that introduction will get us started, because we are now going to discuss how regexes can be used for input validation. + +#### Lab: Introduction to Regular Expressions + + 🧪 **Lab: Please try lab [regex0](https://best.openssf.org/labs/regex0.html), which lets you experiment with simple regex notation.** + +*Labs are optional, but you're strongly encouraged to try them!* + +### Using Regular Expressions for Text Input Validation + +Many programs need to quickly validate input text from untrusted sources. While there are many ways to do that, regexes are often an especially useful tool for input validation of text. Regexes are generally quick to write down (so they take very little development time), easy to use, and widely available. They’re also flexible enough for many input validation tasks, compact, and normally execute very quickly. They are also widely known and understood. These are important advantages; if writing input validation is too hard, it won’t be done. They don’t solve all possible input validation problems, but they are useful enough that they are important to know. + +Regular expressions were originally used in software for *searching* for text patterns, not for validating text inputs against a pattern. Regexes are also good at text input validation, but there are a few things you need to know so you can use regexes correctly for text input validation. + +#### Match, Don’t Search + +A key issue with regexes is that by default most regex implementations *search* to see if a given pattern can be found anywhere within some text. When we are doing input validation we don’t want to search; we want to know if all the text input *exactly matches* a pattern. That means we need to be able to ask the regex implementation *“does this input text exactly match this pattern”* - and reject the input if it doesn’t match. As with any other input validation, we need to make our pattern as limiting as possible, and if the input doesn’t match, then reject the input. + +The usual way to require a regex to match an entire input is to include *anchors* in the regex. Just start your regex pattern with a *start anchor* - usually represented by “**^**” or sometimes “**\A**” - and end the pattern with “**$**” or sometimes “**\z**”. With these, the entire input must match the pattern. For example, this regex will match *any* text that contains “**cab**”, “**car**”, or “**cat**” - it will even match “**abdicate**” - so you should *not* use a regex like this for input validation: + +**ca[brt]** + +In contrast, this regex will only match *exactly* the words “**cab**”, “**car**”, or “**cat**” in many regex implementations, because “**^**” often means *“match the beginning”* and “**$**” often means *“match the end”*: + +**^ca[brt]$** + +In some implementations (depending on the option), “**^**” may mean *“beginning of any line”* not *“beginning of the string”* - and you usually want *“beginning of the string”*. A “**$**” means *"end of the string*" in some implementations, and not in others. Since regular expression notations vary, it's important to know about your specific regex expression system. + +#### Know Your Regex Implementation + +Regex notations are *not* the same between different languages and libraries. Almost every programming language has at least one good regex implementation and they all share many features. However, they are often slightly different. + +So, when you use a regex implementation you have not used before, look at its documentation every time you use an operation that you have not used before. Also, be careful when reusing a pattern. Here are some variations to look for. + +There are three major families of regex language notations: + +1. Basic regular expression (BRE)
This is the default for **grep** and **sed**. This is defined by the POSIX standard. However, its syntax is sometimes a little awkward, so in most cases, it is easier to use extended regular expressions instead for input validation. + +2. Extended regular expression (ERE)
This is defined by the POSIX standard and adds capabilities like using parentheses for grouping and “**+**” for *“one or more”*. This is often used in C programs. So for example, “**[B-D]+**” means *“one or more of the letters B, C, or D”*. + +3. Perl Compatible Regular Expressions (PCRE)
This is mostly an extension of the ERE format; many other programming languages use this family of regex languages. It includes capabilities like “**\d**” to represent digits. + + Here are some important things that vary: + +1. Sometimes there is an option or alternative method to match the entire input; if available, you can use that instead of the anchoring symbols. Make sure it matches the whole thing, though; some methods only check the beginning. + +2. Sometimes “**^**” matches the beginning of all the data, while in others it represents the beginning of any line in the data. This is often controlled by a *multiline* option. + +3. Sometimes “**$**” matches the end of all the data, while in others it represents the end of any line in the data. In some systems, an optional newline character (or similar) is also always accepted. In some systems you must use "**\z**" to match the end of the data, but in Python you must use "**\Z**". + +4. The “**.**” for representing *“any character”* doesn’t always match the newline character (**\n**); often there is an option to turn this on or off. + +5. Some properly support Unicode and the encoding you are using; others do not. + +6. Some can handle data with the **NUL** character (byte value 0) within the data; others do not. If not, and your input data could have an embedded **NUL** character, you will need to validate the data first to make sure there are no **NUL** characters before passing the data to the regex implementation. + +7. Some do case-sensitive matching by default; others do not. Usually it is case-sensitive by default, and there is a trivial way to make it case-insensitive. If it is case-insensitive, remember that exactly what characters have case-insensitive matches depends on the locale. For example, “**I**” and “**i**” match in the English (“**en**”) and the C locale (“**C**”), but not in the Turkish (“**tr**”). In the Turkish locale, the Unicode LATIN CAPITAL LETTER I matches the LATIN SMALL LETTER DOTLESS I - not a lowercase “**i**”. + +The following table shows how to create a regex pattern that matches an entire input string for some common platforms, as provided by [Correctly Using Regular Expressions for Secure Input Validation](https://best.openssf.org/Correctly-Using-Regular-Expressions). There's no need to memorize this; the point to understand is to make sure you use the correct symbols for the platform you're using: + +
| +Platform + | +Prepend + | +Append + | +
| POSIX BRE, POSIX ERE, and ECMAScript (JavaScript) + | +“^” (not “\A”) + | +“$” (not “\z” nor “\Z”) + | +
| Perl, .NET/C# + | +“^” or “\A” + | +“\z” (not “$”) + | +
| Java + | +“^” or “\A” + | +“\z”; “$” works but some documents conflict + | +
| PHP + | +“^” or “\A” + | +“\z”; “$” with “D” modifier + | +
| PCRE + | +“^” or “\A” + | +“\z”; “$” with `PCRE2_DOLLAR_ENDONLY` + | +
| Golang, Rust crate regex, and RE2 + | +“^” or “\A” + | +“\z” or “$” + | +
| Python + | +“^” or “\A” + | +“\Z” (not “$” nor “\z”) + | +
| Ruby + | +“\A” (not “^”) + | +“\z” (not “$”) + | +
Well-formed XML follows certain syntax rules. For example, all opened tags must be closed, and XML elements must be properly nested. If you are accepting XML, at *least* verify that the XML is well-formed; there are easily-available libraries for this, and applications are only supposed to accept XML that is well-formed. + +* **Valid**
Valid XML meets some schema definition. The schema specifies information such as *what* tags are allowed, how they may be nested, and whether some are required. A schema definition, if rigorous, is a kind of allowlist. Thus, checking for validity before accepting XML input can be really useful for countering attacks. However, do *not* allow the attacker to determine what schema to use - decide what schema is okay and use *that*. Sometimes no schema is available, and if you are only extracting a small part of XML, it may not be worth it to create an XML schema. + +If you are using XML, there is an extremely common vulnerability you need to counter called XML External Entities (XXE). To understand them, you need to understand some XML functionality that is not widely known. + +XML supports external references which can be auto-loaded when the original document is loaded. The external reference can be any file location or URL. This means an attacker can provide files that quietly cause other files or URLs to be loaded and placed in certain places. This functionality exists for a reason, and some systems legitimately depend on it. However, many developers have no idea that this is possible, and this has led to many vulnerabilities. Here is an example of an XML document with embedded external entities: + +~~~~xml + + + + + ]> ... + +
The software receives some credentials as input and checks if it matches to authenticate something else. + +* **Outbound**
The software sends the credentials to something else to authenticate itself to something else. + +#### Avoid Default Credentials + +Software should never be delivered with default credentials. There are endless web pages that track default credentials like **admin/admin**. Once anyone finds the credentials, they are likely to eventually end up on these listings. This will enable attackers to break into your software (if it is an inbound credential) or others’ software (if it is an outbound credential). If the software has many installations, then they may all be vulnerable at the same time. **Remember:** Users generally accept whatever is the default, and if the default is insecure, then the software will be insecure. Obfuscating the code is not enough; many attackers are quite adept at extracting and analyzing executables. + +The usual solution for this is to have a “first login” mode that detects that there is no credential (password or key) yet, and then lets the user create a unique one. That is assuming it needs to be stored at all; in some cases, you can simply ask the user to provide it each time. + +#### Avoid Hardcoded Credentials, Store Them Safely Instead + +Hardcoded credentials are credentials stored within the source code, compiled code, or any other location that cannot be quickly changed by someone authorized to do so. + +Hardcoded credentials are mistakes. Credentials should be changed whenever the software is first installed for use and should be easy and quick to change. Storing credentials in source code is a particularly bad idea. Source code is typically managed by version control systems, so any credentials in the code will become available to anyone with access to that source code … and that is often far more people than need to know. Encoding this information in a way that can be undone (e.g., using Base64 or ROT13) doesn’t help. + +So: don’t hardcode credentials (e.g., within source code or compiled code). Instead, store credentials separately in a way that makes them easy to change. Public key certificates usually don’t need to be kept secret, but they may need to be updated. Other credentials often need to be kept secret, and should be protected at least as much as necessary. As we will briefly discuss later, there are tools that may help you identify hardcoded credentials in source code. + +For inbound authentication using passwords, store credentials separately and use a secure algorithm specifically designed for encoding them. We will discuss this in more detail later in the section on Cryptography, but for now, just know that you need to use an *iterated per-user salted cryptographic hash* algorithm such as Argon2id. + +For outbound authentication, credentials should be stored outside the code in a storage system that is protected from all outsiders (including local users on the same system/cloud host). Ideally, all credentials would be stored in an encrypted file or database, but in many environments, this is difficult to do (where do you store the key to access the key?). At the very least, store credentials in something like a file or database table with permissions that are as restrictive as you can practically make them. Environment variables are generally a weaker way to store credentials, since their values are available to the entire process that loads them, but in some circumstances this is acceptable… and it is generally much better than hardcoding credentials. + +🔔 Hardcoded credentials are such a common cause of security vulnerabilities that they are 2021 CWE Top 25 #16 and 2019 CWE Top 25 #19. This weakness is [CWE-798](https://cwe.mitre.org/data/definitions/798.html), *Use of Hard-coded Credentials*. The related *Insufficiently Protected Credentials* is 2021 CWE Top 25 #21 and 2019 CWE Top 25 #27 as [CWE-522](https://cwe.mitre.org/data/definitions/522.html). + +##### Lab: Hardcoded credentials + +🧪 **Lab: Please try lab [hardcoded](https://best.openssf.org/labs/hardcoded.html), which lets you experiment with how to eliminate hardcoded credentials as a vulnerability.** + +*Labs are optional, but you're strongly encouraged to try them!* + +#### Quiz 2.2: Avoid Default & Hardcoded Credentials + +\>\>Secret keys should be stored in source code so that they cannot be easily read, as they could be if they were stored in separate files. True or False?<< + +( ) True + +(x) False + +[Explanation] + +No, quite the opposite. Don’t store secret keys in source code! Source code is often shared with many others, and is stored in version control systems (making it more accessible to others). Another reason to store secret keys separately is so they can be easily changed. If an attacker reads the secret keys, then just change the keys. + +[Explanation] + +### Avoid Incorrect Conversion or Cast + +Almost all programming languages support multiple data types, such as integers, floating point, characters, and strings. Most programming languages have at least some type checking built into them; types can be checked statically (before run-time) and/or dynamically (at run-time). These checks can sometimes warn, or counter, serious problems. + +Sometimes it is necessary to convert or cast a data value from one type to another. The details depend on the programming language, but while it is necessary, incorrect conversions and casts end up causing a disproportionate number of vulnerabilities. The conversion can lose information, or lead to a new value that might have been completely unexpected. Any conversion or casting, especially one that might lose information, should be reviewed to consider if there is a risk to doing it. Some languages have a **const** qualifier for declaring constants; it is dangerous to cast away a **const** qualifier, because this allows changes to the value while other parts of the system may depend on it being constant. + +A special case, which can happen in some programming languages, is called “type confusion”. Type confusion occurs when the access to a resource occurs using a type that’s incompatible with its original type. This could be considered a silent incorrect conversion. This is easily done in languages like C and C++ using union types, where the same memory region can be expressly defined as allowing multiple types. When using union types, the developer must ensure that only the correct type is used for a given access (read or write). + +Type confusion isn’t limited to C and C++, however. Type confusion can happen in any language where the same variable or memory location can be interpreted in more than one way. As noted by MITRE for [CWE-843](https://cwe.mitre.org/data/definitions/843.html), “errors in PHP applications can be triggered by providing array parameters when scalars are expected, or vice versa. Languages such as Perl, which perform automatic conversion of a variable of one type when it is accessed as if it were another type, can also contain these issues.” + +For our purposes, conversions do not include determining if a value is truthy. In general, programming languages have conditional constructs (such as **if** and **while**) that will produce different results depending on whether or not a condition’s value is truthy. What is truthy is a key design decision when creating a programming language. For example, every value in JavaScript is considered truthy except for a specific list of falsy values (currently **false**, **0**, **-0**, **0n**, **“”**, **null**, **undefined**, and **NaN**). In such languages, **if p** and similar are a shorthand for checking if a value is truthy. This interpretation in conditionals might be considered a conversion from some other type into a boolean type, but such constructs are really just an abbreviated way to determine if a value is truthy, and that is not what we are concerned with here. + +🔔 *Incorrect Type Conversion or Cast* ([CWE-704](https://cwe.mitre.org/data/definitions/704.html)) is such a common cause of security vulnerabilities that it is 2019 CWE Top 25 #28. 2021 CWE Top 25 #36 refers to its special case, *Access of Resource Using Incompatible Type ('Type Confusion')* ([CWE-843](https://cwe.mitre.org/data/definitions/843.html)). + + +#### Quiz 2.3: Avoid Incorrect Conversion or Cast + +\>\>Which of the following might be concerning about a cast? Select all answers that apply.<< + +[!x] The cast might lose important information. + +[x] The cast might produce a new value that was unexpected in that context. + +[x] The cast might remove whether or not the value is considered constant, causing potential problems for other code that might depend on it being constant. + +[ ] The cast might change the type. + +[Explanation] + +A cast changes a value’s type (that is what it is *for*), so by itself that is not concerning. What is concerning are the potential impacts of such changes in context. + +[Explanation] + +#### Lab: Avoid Incorrect Conversion or Cast + + 🧪 **Lab: Please try lab [conversion](https://best.openssf.org/labs/conversion.html), which lets you experiment with how to counter improper conversion.** + +*Labs are optional, but you're strongly encouraged to try them!* + +## Processing Data Securely: Undefined Behavior / Memory Safety + +### Countering Out-of-Bounds Reads and Writes (Buffer Overflow) + +[Memory-unsafe code] + +#### Memory Safety + +Unfortunately, handling untrusted data can be *especially* hard in some programming languages or when certain programming language modes are enabled. Most programming languages automatically prevent any attempt to read or write memory areas that are not allocated. These are called *memory safe languages*. However, memory safety mechanisms generally have a performance overhead. + +As a result, some programming languages that emphasize performance are either *not* memory safe or have a way to disable memory safety. The widely-used programming languages C and C++ are *not* memory safe. There are also some languages emphasize performance that are *normally* memory safe, but have a way to disable safety checks to enable adequate performance; these include Rust (when using unsafe code), C# (when using unsafe code), and Ada (when using pragma suppress to suppress memory safety checks). + +Memory safety problems are a common cause of vulnerabilities. Catalin Cimpanu’s study, [*Microsoft: 70 percent of all security bugs are memory safe issues*](https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/) (2019), found that about ~70% of all Microsoft vulnerabilities in 2006-2018 were due to memory safety issues. What is more, while there are annual fluctuations, it has been relatively stable over that time: + + + +**Percentage of memory-safety vulnerabilities at Microsoft** (by Catalin Cimpanu, 2019, retrieved from [ZDNet](https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/)) + +Memory safety is a subset of a larger category called *undefined behavior*, where the system guarantees nothing - and undefined behavior often leads to security vulnerabilities. We will discuss this more later, but we will briefly note that C and C++ have a remarkably large number of undefined behaviors, making it especially difficult to write secure software in these languages. + +You can have these problems *even if* you write code in a language that is memory-safe and has no undefined behaviors. Your code might call some *other* code with undefined behavior that leads to vulnerabilities. Since almost every program ends up calling out to at least some code written with C or C++, that means at least some parts of your program might be indirectly vulnerable, even if your program is not written in C or C++. + +One of the best-known attacker tricks is out-of-bounds reads and writes (including *buffer overflows*) - so we will briefly talk about what that is and how to counter it. We will then discuss another kind of flaw that often leads to security vulnerabilities, double-frees. Finally, we will discuss the larger category of undefined behaviors. + +#### Out-of-Bounds Reads/Writes and Buffer Overflow + +One of the most common kinds of security vulnerabilities is where a read or write is *“out of bounds”* inside memory-unsafe code. Such vulnerabilities are common, and attackers find them easy to exploit. This problem has been well-known for a long time; Aleph One (Elias Levy) describes in detail in [*Smashing the Stack for Fun and Profit*](http://phrack.org/issues/49/14.html#article) (1996) how to exploit such vulnerabilities. + +🔔 Out-of-bounds reads and writes are so common and dangerous that in the 2021 CWE Top 25 list, the #1 weakness involves writes ([CWE-787](https://cwe.mitre.org/data/definitions/787.html) *Out-of-bounds Write*), the #3 weakness involves reads ([CWE-125](https://cwe.mitre.org/data/definitions/125.html) *Out-of-bounds Read*), and the general issue is #17 ([CWE-119](https://cwe.mitre.org/data/definitions/119.html) *Improper Restriction of Operations within the Bounds of a Memory Buffer*). In the 2019 CWE Top 25 list the general issue is #1 ([CWE-119](https://cwe.mitre.org/data/definitions/119.html) *Improper Restriction of Operations within the Bounds of a Memory Buffer*), and specific cases of it are #5 ([CWE-125](https://cwe.mitre.org/data/definitions/125.html) *Out-of-bounds Read*) and #12 ([CWE-787](https://cwe.mitre.org/data/definitions/787.html) *Out-of-bounds Write*). + +Here are the fundamentals. Almost all programs have to store intermediate results, and such storage areas are often called *buffers*. Reading and writing within that buffer is fine. But what happens when your program tries to read from or write to that buffer, but it tries to do that outside the range of that storage area? For example, here is a trivial fragment of a C program that allocates some array **x** of size 10 (index values 0 through 9), and later stores the value of **y** to the index value **i** of that array: + +~~~~C + char x[10]; + ... + x[i] = y; +~~~~ + +What happens if the value of **i** is out of bounds (that is, has a value other than 0 through 9)? There are two safe and common options that happen in different programming languages: + +1. **Resize**
In many programming languages, trying to write (or read) out of bounds will resize the array so that the value can be stored or read from. + +2. **Error**
In some languages, particularly those focused on excellent performance, an error (usually an exception) will be reported if the index is out of bounds. + +Unfortunately, there is a third option: an out-of-bounds read or write can be accepted and turned into a potential security vulnerability. If you use a memory-unsafe language such as C, C++, or assembly language, then any read or write that can go out-of-bounds is a potentially dangerous security vulnerability. This problem can also happen if the language is normally memory-safe, but you disable the language’s memory safety checks (such as Rust, C#, and Ada). + +In C, any attempt to read or write outside the bounds of a buffer (via an array index or a pointer) is an example of *undefined behavior*. If a C program will eventually execute a statement that will cause undefined behavior, the code is allowed to do anything at all at any time - even before that statement that caused the undefined behavior! You can find more information in the following references: + +* [*With Undefined Behavior, Anything is Possible*](https://raphlinus.github.io/programming/rust/2018/08/17/undefined-behavior.html) (2018), by Raph Levien + +* [*Undefined behavior can result in time travel (among other things, but time travel is the funkiest)*](https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=633) (2014), by Raymond Chen + +* [*A Guide to Undefined Behavior in C and C++ (Parts 1-3)*](http://blog.regehr.org/archives/213) (2010), by John Regehr. + +In *practice*, if there is no memory safety, a write outside a buffer in most programming language implementations often ends up corrupting internal data structures that the program depends on. For example, it may overwrite local variables and/or change what will be run after a function returns. Similarly, a read outside a buffer often reveals internal information that is not normally revealed, including secrets that security (such as keys or hardening systems) depend on. In addition, if it is C or C++, compilers will often use such statements as a license to generate some very surprising machine code (because compiler authors are allowed to presume that such things will not happen). Attackers have honed their craft over decades to exploit these vulnerabilities, because they are common and they can often quickly turn discovery of this kind of vulnerability into a devastating attack. + +There are many names for these attacks, with varying terminology and meanings. One of the most common variations of this vulnerability is when the attacker can write past the end of an array, and this vulnerability is sometimes called a *classic buffer overflow* vulnerability. An attack that exploits this vulnerability by writing data outside a buffer is often called a *stack smashing attack* (if the buffer is on the stack, such as by being a local parameter) or a *heap smashing attack* (if the buffer is on the heap, that is, was previously allocated by **new** or **malloc** depending on the language). CWE has various identifiers and names, including [CWE-119](https://cwe.mitre.org/data/definitions/119.html) (*Improper Restriction of Operations within the Bounds of a Memory Buffer*), which is a special case of [CWE-118](https://cwe.mitre.org/data/definitions/118.html) (*Incorrect Access of Indexable Resource (‘Range Error’)*). + +If an attacker can cause your program to write outside its buffer, this often results in a serious vulnerability where the attacker can cause the program to do anything at all. + +Unbounded writes are not the only problem. Historically, people worried about out-of-bounds writes more than reads, but the Heartbleed vulnerability in 2014 showed that out-of-bounds reads could also be extremely dangerous. Out-of-bounds reads can reveal information that allow attackers to completely break into a system. Even programs that only allow one byte of an out-of-bound read or write can have a dangerous vulnerability. + + + +**Heartbleed Explained**. Retrieved from [xkcd](https://xkcd.com/1354/), licensed under [CC-BY-NC-2.5](https://creativecommons.org/licenses/by-nc/2.5/) + +> 😱 STORY TIME: Heartbleed + +> In 2014 a vulnerability named Heartbleed ([CVE-2014-0160](https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2014-0160)) was found in the widely-used OpenSSL cryptographic library. The key weakness was a buffer over-read (past the end of the buffer) was allowed in the heap due to improper input validation. This vulnerability allowed attackers to acquire sensitive data, and OpenSSL managed some extremely sensitive data such as server private keys. This vulnerability affected a huge number of popular websites, leading to problems such as user account hijacking and information compromises of millions of patients. ([*How to Prevent the next Heartbleed*](https://dwheeler.com/essays/heartbleed.html), 2020, by David A. Wheeler) + +#### Solutions for Out-of-Bounds Reads and Writes + +If you are curious, there are many papers and college courses that go into depth on exactly why this problem is so dangerous. But if you are just developing software, those details do not matter - you simply need to make sure that reads and writes are always within the bounds of what they are supposed to refer to. So how can we do this? + +The simplest solution: **_always, where practical, use memory-safe languages and keep memory safety on_**. Almost all programming languages are memory-safe, at least by default. If you try to access a buffer outside of its bounds in a memory-safe language, it will resize the buffer or give you an error (typically an exception). In either case, the system doesn’t just cede control to an attacker. This solution is easier to apply when you are writing code from scratch, of course. + +But sometimes this is not practical. This means you could never use C, C++, or assembly language. It would also mean you could not ever disable memory-safety in other languages. There are many large programs in C or C++ that would be difficult to rewrite, and of course, there are reasons people choose those languages. Most operating system kernels are written in C, since they are performance-critical and C was specifically designed for this task. Similarly, in languages that let you disable memory safety, there are reasons those mechanisms exist. + +If you *must* have code without memory-safety, try to limit what is memory-unsafe where that is practical. For example, in languages that are memory-safe by default, but have mechanisms to disable it, you should minimize the amount of code that runs without memory safety. A large library in Rust, C#, or Ada should be almost entirely safe, with at most a very small unsafe portion. If you have a lot of existing C or C++ code, consider rewriting a portion in a memory-safe language. If you rewrite a portion, you should typically focus on the *most dangerous* portion (that is, code that is most exposed to attackers). For example, Mozilla’s Firefox browser was written mostly in C++ (and some JavaScript), but in 2017 some of that C++ code was replaced by implementations in Rust, and increasingly more and more of Firefox is written in Rust (Mozilla [*Oxidation*](https://wiki.mozilla.org/Oxidation) and [*Rust vs. C++ in macOS Firefox Nightly*](https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9emD9EAN01ljTAVft2S4Dq620/edit#gid=885787479)). + +If you have to program without memory safety checks, for whatever reason, then you have to carefully implement all the checks in the code itself. For security, you must make sure you never ever make a mistake: you must ensure that every reference is in bounds no matter what the attacker does. Each check is not hard to do; this is not rocket science. The problem is that never ever making a mistake is difficult to do. You can be very smart and still make a mistake. If you do write software without memory safety checks, where possible, you should use mechanisms like tools and peer review to reduce the risks of something slipping through to users. Later on we will discuss some of the tooling available to help. + +Of course, just doing a check is not enough - what do you do when the check fails? The safest thing to do is to reject the input and not perform any action if a check fails along the way. However, it is often hard to do the rejection, and so developers are tempted to simply trim off any extra (or write code that accidentally does this). Sometimes that is fine, but this often means that an attacker can control what stays in the buffer and what doesn’t. That can sometimes lead to vulnerabilities, and determining if there is a vulnerability can be really difficult. + +If you use C, there are many patterns that are especially likely to be vulnerable, including the use of functions like **strcpy()** to copy a string, **strcat()** to concatenate a string, and loops that incrementally add to a buffer. Early in C’s development, functions were created that limited where data would be written, specifically **strncpy()** and **strncat()**. However, using **strncpy()** and **strncat()** requires constant recalculation of the *space left over*, making them difficult to use correctly (it is extremely easy to have an “off by one” error in this code that only attackers notice). The **strncpy()** function also overwrites all remaining space, making it absurdly inefficient for most circumstances. + +If you use C, sometimes you can use safer functions instead. The C function **snprintf()** writes output to a string buffer given a format, and it will not overwrite past a given length. The function **memccpy()** lets you do a simple copy, again without going beyond a maximum length. However, in all these cases you cannot just call the function - in most cases, you also have to check its return value to see if there was an overrun, and if there was, do something sensible (which is usually to stop processing the input). The functions **asprintf()** and **vasprintf()** let you reallocate a new string, which you can use to resize a string. As always, you must ensure that you free any previously-allocated strings once they are no longer used, and ensure that you only free them once (a problem we will discuss more soon). If you are not prepared to do this very carefully and methodically, you probably should not be using C. + +Modern compilers for these languages, and the operating systems that support them, use a variety of hardening techniques to make exploiting these attacks harder. Widely-applied hardening measures include: + +* Address Space Layout Randomization (ASLR)
Randomize where objects are stored in memory, making it harder for attackers to target some objects (in the gcc and clang compilers you may need to enable PIE mode, e.g., using **-fPIE**) + +* Non-executable memory
Ensure that memory with executable instructions cannot also be written to at the same time, making it slightly harder for attackers to modify software or introduce their own malicious code. + +* Canaries
Insert an extra check in selected functions; before they return, they do a sanity check on a value called a “guard” or “canary” that detects certain kinds of buffer overflows that perform writes (the gcc and clang compilers can do this with options like **-fstack-protector**) + +* Automated bounds insertions
Modify code during compilation to do bounds checking even if was not originally requested (the gcc and clang compilers can do this with the option **-D_FORTIFY_SOURCE=2**). + +If you are writing code that is not memory-safe, or calling code that is not memory-safe, make sure hardening measures like these are enabled whenever you can, including in compilation, test, and production. The good news is that hardening measures like these will slow down some exploits. But in the end, hardening measures often do not *prevent* exploits. In the best case, these hardening measures turn “take over program” into “program stops working”... and that is the *best* case. The only way to not have vulnerable code… is to not have vulnerable code. + +#### Quiz 2.4: Countering Out-of-Bounds Reads and Writes (Buffer Overflow) + +\>\>Programs written in memory-unsafe languages, such as C and C++, must be careful to *never* allow an untrusted user to cause an out-of-bounds read or write. This can be challenging to do without fail; correct application of functions like **snprintf()** can help. True or False?<< + +(x) True + +( ) False + +[Explanation] + +Correct. Of course, it is safer to not use memory-unsafe languages in the first place, but that is not always an option today. + +[Explanation] + +#### Lab: Countering Out-of-Bounds Reads and Writes (Buffer Overflow) + + 🧪 **Lab: Please try lab [oob1](https://best.openssf.org/labs/oob1.html), which lets you experiment with how to counter an out-of-bounds vulnerability.** + +*Labs are optional, but you're strongly encouraged to try them!* + +### Double-free, Use-after-free, and Missing Release + +[Memory-unsafe code] + +Out-of-bounds reads and writes are not the only problem for programs written in languages like C or C++. + +When processing information you typically need to allocate memory (e.g., with **new**) and use it for a while. Most programming languages automatically track when you don’t need to use memory any more and reclaim it; this process is called *automatic garbage collection* or *automated memory management* (we will use the latter term). There are different ways to do automated memory management (the most typical are reference counting or tracing), and terminology varies, but the point is that in most programming languages this is automatically handled for you. + +But in some programming languages you must *manually* release memory when you are done with it. In particular, this is true for C (**free**) and C++ (**delete**). If you forget to release the memory when you are done using it, this leads to a “memory leak"; the program will increasingly use more and more memory. In some situations this increasing memory use can lead to increasingly poor performance or a crash, which is a loss of availability. + +Often the more important security issue is manually freeing the memory region *more* than once; this is called a *double free*. Another big security problem is *use-after-free*, that is, using the memory after it has been freed. In memory-safe languages a double-free or use-after-free won’t happen. However, a double-free or use-after-free in a C or C++ program often corrupts low-level infrastructure and can change the value of program values that *appear* to be unrelated. + +If an attacker can cause your program to double-free or use-after-free, this can result in a serious vulnerability where the attacker can cause the program to do anything. That is because these mistakes often allow an attacker to corrupt and control the infrastructure your program runs on. + +The obvious solution is to only use programming languages where you don’t have to manually release memory. Most programming languages handle memory management automatically. + +In cases where that is not practical, simplify your code as best you can so that it is clear where deallocation will occur, so that it will occur exactly once and you never use it again. Consider setting pointers to NULL (0) when you are done with what they point to. This will reduce the risk of freeing them or using them again later, and if unnecessary many of those assignments will be optimized away by the compiler. + +🔔 Use-after-free is such a common cause of security vulnerabilities that it is 2021 CWE Top 25 #7 and 2019 CWE Top 25 #7. It is [CWE-416](https://cwe.mitre.org/data/definitions/416.html) (*Use After Free*). Double-free is such a common cause of security vulnerabilities that it is 2019 CWE Top 25 #31. It is [CWE-415](https://cwe.mitre.org/data/definitions/415.html) (*Double Free*). Failing to release memory once it is no longer needed is 2021 CWE Top 25 #32; it is [CWE-401](https://cwe.mitre.org/data/definitions/401.html) (Missing Release of Memory after Effective Lifetime). + +#### Quiz 2.5: Double-free, Use-after-free, and Missing Release + +\>\>In C and C++ it doesn’t matter if you use a memory region after freeing it, as long as you use the memory region within the same function or method. True or False?<< + +( ) True + +(x) False + +[Explanation] + +No, it is not safe to use a memory region after freeing it, no matter what. It *might* work out a specific time, and not another. + +[Explanation] + +#### Lab: Double-free, Use-after-free, and Missing Release + + 🧪 **Lab: Please try lab [free](https://best.openssf.org/labs/free.html), which lets you experiment on how to fix a simple use-after-free bug.** + +*Labs are optional, but you're strongly encouraged to try them!* + +### Avoid Undefined Behavior + +[Memory-unsafe code] + +Many programming languages are defined in some sort of formal specification. When that is the case, where practical, you should try to write code that conforms to those specifications, because your code is more likely to work in all cases, and as the language implementations change, your code is more likely to keep working. + +Sometimes these specifications will permit one of several different options (this is sometimes called “unspecified behavior” or “compiler-specific behavior”). You should normally try to write your code so that it does not matter which permitted option is used, it will just keep working. Languages that support threading allow the threads to execute in parallel and in arbitrary order. In many languages, the order of operations in a call such as **f(aa, bb, cc)** is not defined (that is, it does not guarantee that **aa** or **cc** is computed first). Beware of depending on what your tools currently do, because when the tools are upgraded what they do may change. For many developers, dealing with this is already second nature. + +However, some languages (such as C and C++) have constructs with truly *undefined behavior*. That is, if you take certain actions, the specification guarantees *absolutely nothing*. For example, the [C FAQ](http://c-faq.com/ansi/undef.html) notes that with undefined behavior, *“Anything at all can happen; the Standard imposes no requirements. The program may fail to compile, or it may execute incorrectly (either crashing or silently generating incorrect results), or it may fortuitously do exactly what the programmer intended.”* + +Any undefined behavior can be - and often is - a security vulnerability. Even if it just happens to not be a security vulnerability today, a minor upgrade in your tools, operating system, or configuration might turn it into a vulnerability. + +Many languages have at least some undefined behaviors, and so, if you use those languages, you need to learn what they are and avoid them. C and C++ have an especially large number of undefined behaviors. For example, for C, there are hundreds of undefined behaviors; the list is 11 pages long in the publicly available final draft of [C18 annex J.2](https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf). It is also very easy in C and C++ to accidentally write code that has undefined behavior. We have already seen some examples of undefined behavior: reads and writes out of the bounds of a buffer, use-after-free, and double-frees. Here are a few more. + +In C and C++, a null pointer dereference is also undefined (e.g., evaluating “***p**” when **p** is **NULL**). This means that an attempt to dereference a null pointer does not necessarily lead to trying to read an invalid value, the program might do *anything* at all. + +🔔 *Null Pointer Dereference* ([CWE-476](https://cwe.mitre.org/data/definitions/476.html)) is such a common cause of security vulnerabilities that it is 2021 CWE Top 25 #15 and 2019 CWE Top 25 #14. + +In C and C++, signed integer overflow is undefined (e.g., an **int** with value **MAX_INT** with 1 added to it). There is no guarantee that signed integers wrap; instead, the program might do anything at all. + +🔔 Integer overflow or wraparound is such a common cause of security vulnerabilities that it is 2021 CWE Top 25 #12 and 2019 CWE Top 25 #8. It is [CWE-190](https://cwe.mitre.org/data/definitions/190.html), *Integer overflow or wraparound* (though this CWE also covers unsigned wraparound, which is defined in C and C++). + +Perhaps by now it is clear why many people recommend avoiding C and C++ if the code has to be secure. For a variety of reasons, it is more difficult to write secure software in these languages! But again, there are *reasons* that people choose these languages, and of course, if something is already written in these languages, it is hard to change. + +So, if you do use C and C++, there are ways you can reduce your risks. We have already discussed some options. Here are a few more: + +* Read its standards carefully so that you know all common undefined behaviors and actively avoid them when writing code. + +* Turn on warnings about undefined behaviors. Examples of such gcc and/or clang flags include **-fsanitize=signed-overflow** (warn about signed overflow), **-ftrapv** (traps signed integer overflows), **-fsanitize=address**, **-fsanitize=undefined**, and **-fcatch-undefined-behavior** (but it will not ALWAYS detect them!) + +* Force the compiler to assign a meaning to officially undefined behaviors. You should not rely on these, but they will reduce the impact of making a mistake. Examples of such gcc and/or clang flags include **-fwrapv** (wrap integers on overflow), **-fno-delete-null-pointer-checks**, and **-fno-strict-overflow**. + +We will later discuss using tools to try to detect these, but be warned: most tools at best detect *some* undefined behaviors, not all of them. Your best defense is to use a language with no or few undefined behaviors. Where that is not reasonable, know exactly what is not defined, and carefully write code so it does not depend on undefined behaviors. + +#### Quiz 2.6: Avoid Undefined Behavior + +\>\>In C and C++, a null pointer dereference is not a serious security problem, because you will just read a data value or, at worst, crash the program. True or False?<< + +( ) True + +(x) False + +[Explanation] + +No, in C and C++ a null pointer dereference is undefined behavior. Any undefined behavior could cause anything bad to happen, including erasing all files, displaying all secret keys, or anything else. It is more likely to cause a subtle problem, but that subtle problem could also be a serious security vulnerability. + +[Explanation] + +## Processing Data Securely: Calculate Correctly + +### Avoid Integer Overflow, Wraparound, and Underflow + +It’s common to calculate integers in programs, such as by continuously incrementing (adding 1 to) a variable. However, no computer can truly handle an infinite number of digits. In fact, many programming languages use a fixed number of bits in their most common integer types, so the minimum and maximum integers have a much smaller range than what could be represented by the computer. + +If an attacker can cause an integer calculation to exceed the range of the integer’s representation, the result can be a vulnerability. Since integer calculations are common, and developers often forget that computers can’t actually handle an infinite number of digits, this is a relatively common vulnerability. + +As we’ve already noted, in C and C++, you must write your program so that an attacker cannot cause the usual signed integer types (such as int) to overflow or underflow. A signed integer overflow or underflow is normally undefined behavior in C and C++, and the program is allowed to do anything at all when it occurs (including triggering a vulnerability). + +In C and C++, overflowing or underflowing an unsigned integer wraps around in its underlying representation (typically two’s complement). So in C and C++ it’s typical that adding 1 to the largest representable unsigned value will produce 0. In many other programming languages, both signed and unsigned integers are stored in a fixed length and wrap around on overflow & underflow (typically in two’s complement). This is not always a good thing; if an attacker can cause an underflow or overflow, and if the program was not designed to handle it, the result can often be a vulnerability. + +Some programming languages automatically switch to “big number” integer formats as needed to support an arbitrary number of digits, instead of using a fixed number of bits to represent an integer. These programming languages include Python, Ruby, and Scheme. Many other programming languages provide support for such formats, such as through a library, though you may need to specifically request using this format (e.g., as a type). These formats can’t really support an infinite number of digits, since no computer has infinite memory, but this does greatly reduce the risk of such problems. In many cases an exception is raised if the calculation runs out of space, so make sure the program can properly handle that exception. A common problem is that programs often need to call a routine written in a different programming language, and during that conversion the number may be converted to a fixed-width format that cannot store the value (thus recreating the problem). + +The JavaScript programming language is an unusual case. The JavaScript specification, called ECMAScript, does not provide direct support for integers. Instead, integers are typically represented using floating point numbers. As noted in the ECMAScript language specification (section "The Number Type"), this means that JavaScript’s Number type can accurately represent all positive and negative mathematical integers whose magnitude is no greater than 253. However, if an attacker can cause calculated integers to go beyond this range, odd things can happen. For example, incrementing a positive integer beyond this value is likely to produce an unchanged result, since the underlying type cannot store every digit. There are also some operators that only deal with integers in specific ranges (such as -231 through 231-1 inclusive, or 0 through 216-1 inclusive); make sure an attacker can’t cause those ranges to be exceeded before you call those operators. For more information see the [ECMAScript ® 2021 Language Specification](https://www.ecma-international.org/publications-and-standards/standards/ecma-262/) from ECMA. + +One of the simplest ways to ensure an attacker cannot trigger vulnerabilities from integer overflows and underflows is to do input validation on all untrusted numbers. In all those input validation checks, enforce minimum and maximum values on all untrusted integers so that the accepted inputs cannot lead to a calculation that would trigger an integer overflow or underflow. If this is done, then there can’t be any such vulnerabilities. If this can’t be done, then the program needs to detect integer overflows and underflows that can be triggered by an attacker, either before or after the calculation, and handle them appropriately. + +> 😱 STORY TIME: NetUSB CVE-2021-45608 + +> An example of an integer overflow leading to a vulnerability is [CVE-2021-45608](https://nvd.nist.gov/vuln/detail/CVE-2021-45608), as explained in “[CVE-2021-45608 | NetUSB RCE Flaw in Millions of End User Routers](https://www.sentinelone.com/labs/cve-2021-45608-netusb-rce-flaw-in-millions-of-end-user-routers/)” by Sentinel Labs. The KCodes NetUSB kernel module, used by a large number of network device vendors, had an integer overflow vulnerability. The module took an untrusted client-provided length, added 0x11, and allocated that amount of memory. If the requested length was large (e.g., all 1s in binary), the addition would wrap around, causing a too-small allocation. After that, data would be dumped into the too-small buffer, leading to a buffer overflow. +> +> This shows that it’s important to check for wraparound when using attacker-controlled data, especially if you use it to make size or out-of-range decisions. Other rules can be learned as well. First, always validate data from an untrusted source (e.g., data from the Internet) - there was no reason to allow any allocation request this big. Second, this module listened to requests from the wide-area network (WAN) instead of just the local area network (LAN); software should minimize privilege to only what's needed to reduce the likelihood or impact of damage if there is a vulnerability. + + +🔔 Integer overflow or wraparound is such a common cause of security vulnerabilities that it is 2021 CWE Top 25 #12 and 2019 CWE Top 25 #8. It is [CWE-190](https://cwe.mitre.org/data/definitions/190.html), *Integer overflow or wraparound*. + +#### Quiz 2.7: Avoid Integer Overflow, Wraparound, and Underflow + +>>Integer overflows can be ignored when handling untrusted data. True or False?<< + +( ) True +(x) False + +[Explanation] +No. The range of possible values varies by language and types used, but attackers can sometimes exploit integer overflows. +[Explanation] + + +# Calling Other Programs + +> 🎥 Real-world programs often call out to other programs. On a server-side application these programs might include the operating system or a database. On a client-side application this might include the supporting browser. This chapter describes how to call other programs securely. We'll discuss in particular on how to counter injection attacks, including SQL injection and OS command injection, as well as how to properly handle filenames and pathnames. + +Learning objectives: + +1. Discuss the basics of securely calling other programs. + +2. Understand how to counter injection attacks (including SQL injection and OS command injection). + +3. Discuss proper handling of filenames/pathnames. + +## Introduction to Securely Calling Programs + +### Introduction to Securely Calling Programs - The Basics + +Very few programs are entirely self-contained; nearly all programs call out to other programs. This includes local programs, such as programs provided by the operating system, built-in software libraries for that language, and software from package repositories (like npm, PyPI, and maven). Modern systems often call out through a network to other services, making requests through various APIs (such as REST and GraphQL APIs) and receiving data in formats such as JSON and XML. Almost all of these programs then call other programs. Often, these indirect calls are not obvious (e.g., calling a library written by someone else) or involve a great deal of “hidden” infrastructure. + +You need to be careful about what programs you choose to use (trust) and manage them (e.g., how you record and update them). Once you choose them, you must be careful about how you use these other programs. In this section, we are going to talk about securely *using* other programs. + +First, the obvious: if a program is known to be insecure, and security matters, then don’t use it! But usually, you are not using a known-insecure program, so let’s move beyond that. + +If there is a relatively easy way to limit privileges of the routine you are calling, do so. If you can *limit* the privileges given, then, if an attacker breaks through, the damage is more limited and it may make it harder for the attacker to cause more damage. This is another example of the security principle of least privilege. For example, if you are calling a database, try to limit database privileges of the program making the request. If you are using SQL, consider using the **GRANT** command so the requesting program has fewer privileges. + +A useful principle is to only call a routine with valid values. If a routine requires that a number be 0 through 9, then it should not be possible for an attacker to cause 50 to be sent. This is easier in theory than in practice, especially since those limits are not always well-documented. But where you know of a limitation, consider doing some checks to make sure they are honored, or write your program so that the limitations are necessarily honored. + +A very important principle is that if a routine is hard to use securely, and there is another way to do the task that is easier to do securely, *use the routine that is easier to use securely*. Here are some warning signs that you are using a routine that is hard to use securely: + +* It executes whatever program is sent to it, and some data you send might come from an attacker. Any routine with a name like **eval()**, **exec()**, **execute()**, or **system()** has a high chance of being in this category. For example, don’t use **eval()** in JavaScript to process JSON data (in general!); use something safer like JavaScript’s function **JSON.parse()**. + +* It requires you to concatenate constant strings with data that might come from an attacker. Generally, that other data from an attack has to be escaped, and it is easy to make a mistake when escaping data. + +* Its input format is described using a language specification (such as Backus-Naur Form). + +* It was intended for direct human interaction, not for a program to invoke it. + +You *can* use such routines securely, and sometimes you need to. But if you can avoid it, your program will probably be more secure - and it will probably be easier to maintain, too. If you cannot avoid them, you may want to wrap their use in special wrappers to make them easier to use safely. + +Why are certain kinds of routines hard to use securely? One common problem is that many routines accept languages with *metacharacters* - that is, characters that change how other characters are interpreted instead of being data themselves. For example, the double quote character (**“**) is often a metacharacter (including in SQL and shell). If there is a language specification, that almost certainly means there are metacharacters. Supporting metacharacters is very flexible, and if all of the input is trusted, it is not a problem. But when parts of the data might be from an attacker, you need to be very careful and take extra precautions. If an attacker can insert metacharacters into the input, and they are not escaped exactly correctly, then dangerous and easily-exploited vulnerabilities often follow if they are read by some kind of interpreter. These kinds of attacks are sometimes called injection attacks. + +🔔 Vulnerabilities to injection attacks are such common mistakes in web applications that “Injection” is 2017 OWASP Top 10 #1 and 2021 OWASP Top 10 #3. 2021 CWE Top 25 #28 and 2019 CWE Top 25 #18 are identified [CWE-94](https://cwe.mitre.org/data/definitions/94.html), *Improper Control of Generation of Code (‘Code Injection’)*. 2021 CWE Top 10 #25 is [CWE-77](https://cwe.mitre.org/data/definitions/77.html), *Improper Neutralization of Special Elements used in a Command ('Command Injection')*. Both CWE-94 and CWE-77 are special cases of [CWE-74](https://cwe.mitre.org/data/definitions/74.html). *Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')*. The general category CWE-74 has other common special cases such as SQL injection vulnerabilities ([CWE-89](https://cwe.mitre.org/data/definitions/89.html)) and operating system command injection ([CWE-78](https://cwe.mitre.org/data/definitions/78.html)) that we will soon discuss. + +So you need to ensure that when you send data to some program (or output), you send it in a secure way. That may involve: + +* **Sanitizing**
Removing any illegal or potentially-malicious character (usually metacharacters) from the data. + +* **Escaping**
Modifying characters (some metacharacters) so that they are not interpreted incorrectly. + +* **Normalizing**
Changing the form of data to be a common form (and, as a side-effect, preventing it from causing a security problem). + +Where possible, use libraries and APIs that do this for you; they are easier to use securely. + +Let’s now examine some common injection attack cases and how to handle them securely. Again, an injection vulnerability is when a program accepts data from an attacker and improperly hands that data to some command interpreter. Some of the most common problems occur when that data is sent to a database system (SQL injection attacks) or an operating system command interpreter (OS command injection attacks), so we will focus on those. Once you understand how to deal with these two common cases, it will be much clearer how to properly handle other interpreters we will not cover here (e.g., the Lightweight Directory Access Protocol (LDAP)). We will begin by discussing sending data to database systems, which are often vulnerable to SQL injection attacks. + +#### Quiz 3.1: Introduction to Securely Calling Programs - The Basics + +\>\>Just pick secure software to reuse, and your application will be secure. True or False?<< + +( ) True + +(x) False + +[Explanation] + +This is false. Clearly, if you pick known *insecure* software, you will have a problem. In addition, you should prefer software that’s easier to use securely. But in general, you need to *use* reused software in a secure way - not just pick secure components. + +[Explanation] + +## Calling Other Programs: Injection and Filenames + +### SQL Injection Vulnerability + + + +**Exploits of a Mom**, retrieved from [xkcd.com](https://xkcd.com/327/), licensed under [CC-BY-NC-2.5](https://creativecommons.org/licenses/by-nc/2.5/) + +Most database systems include a language that can let you create arbitrary queries, and typically many other functions too (e.g., creating and modifying things). The SQL language is especially common, and while some database systems use other languages, those other languages often have similarities with SQL. Such languages, including SQL, include metacharacters. When attackers can insert metacharacters into a SQL command to cause a security problem, the attack is called an *SQL injection attack*, and the vulnerability is called an *SQL injection vulnerability*. SQL injection is sometimes abbreviated as SQLi. + +Even if the database language is not SQL, if it is an attack on a language for a database system it is often called an SQL injection attack (even though this is technically not accurate). We will focus on SQL, because SQL is very common and once you understand how to counter SQL injection attacks, it is easy to generalize this to any database language. + +Here is a trivial example; here is a snippet of Java that tries to do an SQL query, but does it insecurely: + +~~~~java + String QueryString = "select * from authors where lastname = ' " + search_lastname + " '; "; // VULNERABLE CODE + rs = statement.executeQuery(QueryString); // VULNERABLE CODE +~~~~ + +The intent is clear; if **search_lastname** has the value **Fred**, then the database will receive the query “**select * from authors where lastname='Fred';**” - a reasonable SQL query. But remember our warning signs - this code concatenates strings, some of that data is probably provided by an attacker, and we’re doing something called “execute”. The warning signs are right. Imagine that the attacker provides the input “**Fred' OR 'a'='a**”. This will produce the query “**select * from authors where lastname='Fred' OR 'a'='a';**” and now the attacker can retrieve the entire database. The attacker could even modify or delete data this way, depending on various factors. This is a simple example of an SQL injection attack; an attacker can insert some characters and inject new or modified commands. + +There are many ways to trigger SQL injection attacks; attackers can insert single quotes (used to surround constant character data), semicolons (which act as command separators), “**--**” which is a comment token, and so on. This is not a complete list; different database systems interpret different characters differently. For example, double quotes are often metacharacters, but with different meanings. Even different versions of the *same* database system, or different configurations, can cause changes to how the characters are interpreted. We already know we should not create a list of “bad” characters, because that is a denylist. We could create an allowlist of characters we know are not metacharacters and then escape the rest, but this process is hard to do correctly for SQL. + +Don't concatenate strings to create a DBMS query, because that is insecure by default. That includes using format strings, string interpolations, string templates, and all other mechanisms that simply concatenate text. For example, the same vulnerabilities happen if you use Python formatted string literals (f-strings such as f'{year}-{month}'), Python's `.format` method, JavaScript's template strings (`${year}-${month}`), PHP's string interpolations ("${year}-${month}"), Ruby string interpolation ("#{year}-#{month}"), Go (string) templates, or any other string-based template or formatting language. Remember, we want to try to use a routine that is easy to use securely, and all of these are dangerous by default when used to create commands like SQL commands. + +Many developers try to fix this in an unwise way by calling an escape routine on every value, e.g., like this: + +~~~~java + String QueryString = "select * from authors where lastname = ' " + + sql_escape(search_lastname) + " '; "; // BAD IDEA +~~~~ + +This approach (calling an escape routine every time you use untrusted input) +has a fundamental flaw: the *default* is insecure. +If an escape routine must be called every time untrusted data is used, +and there are many uses of untrusted data, +eventually someone will forget to call the escape function. +Many programs create many queries, so there are many opportunities to +forget to do it. +The mistake can happen at the beginning, or later when the code is modified, +but experience shows that the mistake *will* happen. + +> 😱 STORY TIME: Heartland Payment Systems / SQL Injection + +> In late 2007 attackers used a SQL injection attack to compromise the database of Heartland Payment Systems (aka "Heartland"). At the time Heartland processed 100 million payment card transactions per month for 175,000 merchants. The attackers used the SQL injection to insert code into Web scripts used by the Web login page. The attackers eventually used this accept to install a spyware program called a 'sniffer' that captured the card data as payments were processed for several months in 2008. As a result, Heartland temporarily lost its compliance with the Payment Card Industry Data Security Standard (PCI DSS), which was required to implement their core business of processing card payments. Heartland reportedly had to pay $145 million in compensation for fraudulent payments (["Data Breach Directions: What to Do After an Attack" by Diane Ritchey](https://www.securitymagazine.com/articles/86071-data-breach-directions-what-to-do-after-an-attack)). They have since taken many steps to make their systems stronger and more robust to try to prevent a recurrence. + +🔔 SQL injection is a special case of injection attacks, and we have already noted that injection attacks are so common and dangerous that they are 2017 OWASP Top 10 #1. SQL injection specifically is such a common cause of security vulnerabilities that just SQL injection is 2021 CWE Top 25 #6 and 2019 CWE Top 25 #6. SQL injection is also identified as [CWE-89](https://cwe.mitre.org/data/definitions/89.html), *Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)*. + +Again, we want to try to use an approach that is easy to use correctly - it needs to be secure by default. + +For databases, there are well-known solutions that are far easier to use securely. + +#### Quiz - SQL Injection Vulnerability + +\>\>Select all the warning signs suggesting that a SQL injection is especially likely:<< + +[x] A SQL statement is being created via string concatenation. + +[x] At least one part of the SQL statement is data that may be from an attacker. + +[x] The SQL statement is executed. + +### SQL Injection: Parameterized Statements + +SQL injection vulnerabilities are one of the most common and devastating vulnerabilities, especially in web applications. They are also easy to counter, once you know how to do it. + +*Parameterized statements*, aka *parameterized queries*, are perhaps the best way to counter SQL injection attacks if you are directly creating SQL commands that need to be secure. Parameterized statements are statements that let you identify placeholders (often a “**?**”) for data that needs to be escaped. A pre-existing library that you call then takes those parameters and in effect escapes the data properly for that specific implementation. The exact syntax for placeholders depends on the library and/or database you're using. + +For our purposes, a *prepared statement* compiles the statement with the database system ahead-of-time so that a later request with specific data can be executed more efficiently. Preparing a statement with a database ahead-of-time can improve performance if the statement will be executed multiple times. Prepared statement APIs generally include support for parameterized statements, and many people (and APIs) use the terms "prepared statement" and "parameterized statement" as synonyms. + +For security, the key is to use an API with parameterized statements (including a prepared statement API) and ensure that every untrusted input is sent as a separate parameter. Make sure that you do *not* normally include untrusted input by concatenating untrusted data as a string (including a formatted string) into a request. + +#### Advantages of parameterized/prepared statements + +Most programming languages have at least one library that implements parameterized statements and/or prepared statements. Using parameterized statements, including by using prepared statements, has many advantages: + +1. Since the library does the escaping for you, it is simpler to use and more likely to be right. + +2. It tends to produce easier-to-maintain code, since the code tends to be easier to read. + +3. Many can handle variation in different SQL engines (which is important because different systems often have different syntax rules). + +#### Example: Prepared statements in Java + +Here is an example of using prepared statements in Java +using its JDBC interface: + +~~~~java + String QueryString = "select * from authors where lastname = ?"; + PreparedStatement pstmt = connection.prepareStatement(QueryString); + pstmt.setString(1, search_lastname); + ResultSet results = pstmt.execute( ); +~~~~ + +There are more statements than our earlier example, but the statements are simpler. In particular, the complicated concatenation is now a simple string constant. We still call something called “**execute**” - but remember, avoiding methods named “execute” is just a rule of thumb to help us detect potential problems. + +Note: Some parameterized statement and/or prepared statement +libraries are not thread-safe. In other words, +some libraries assume that at any given time only a single thread can +access an instance. +This is true for the Java prepared statement API used here; +this Java API is not thread-safe. So when using this Java interface, +only define `PreparedStatement` objects as method-level variables +(instead of class-level variables) to reduce the risk of thread safety +problems, as suggested by +[*Bobby Tables* (Java)](https://bobby-tables.com/java). + +Of course, like any technique, if you use it wrongly then it won’t be secure. Here is an example of how to use prepared statements in Java to produce a probably-insecure program: + +~~~~java + String QueryString = "select * from authors where lastname = '" + search_lastname + "';"; + PreparedStatement pstmt = connection.prepareStatement(QueryString); + ResultSet results = pstmt.execute( ); // Probably insecure, don’t do this! +~~~~ + +This insecure program uses a prepared statement, but instead of correctly using “**?**” as a value placeholder (which will then be properly escaped), this code directly concatenates data into the query. Unless the data is properly escaped (and it almost certainly is not), this code can quickly lead to a serious vulnerability if this data can be controlled by an attacker. + +##### Lab: SQL injection + + 🧪 **Lab: Please try lab [sql-injection](https://best.openssf.org/labs/sql-injection.html), which lets you experiment with how to counter a SQL injection vulnerability.** + +*Labs are optional, but you're strongly encouraged to try them!* + +#### Examples: Parameterized and Prepared Statements in some Other Languages + +Parameterized and prepared statements are widely available, though the +APIs and placeholder syntax vary by programming language, library, and database. +Here we'll see some examples. + +In Python there are several libraries that interface to databases. +Many of them implement the Python Database API Specification v2.0 +([PEP 249](https://peps.python.org/pep-0249/)), +whose `execute` and `executemany` methods implement parameterized statements. +The library's placeholder syntax is reported by its `paramstyle` attribute. +Here's a simple Python example from the +Python sqlite3 library documentation +[Python (sqlite3)](https://docs.python.org/3/library/sqlite3.html): + +~~~~python + con = sqlite3.connect(...) + cur = con.cursor() + cur.execute("insert into test(d, ts) values (?, ?)", (today, now)) +~~~~ + +Here's an example of a query in go from the [go.dev documentation on querying](https://go.dev/doc/database/querying): + +~~~~go + rows, err := db.Query("SELECT * FROM album WHERE artist = ?", artist) +~~~~ + +When using Node and JavaScript there are many ways to use +parameterized and prepared statements. +Here's an example using the node-postgres callback interface, +as described in the +[node-postgres documentation](https://node-postgres.com/features/queries): + +~~~~javascript + const text = 'INSERT INTO users(name, email) VALUES($1, $2) RETURNING *' + const values = ['brianc', 'brian.m.carlson@gmail.com'] + client.query(text, values, (err, res) => { .... }) +~~~~ + +The PostgreSQL `libpq` C interface provides several functions, as +explained in the [PostgreSQL (Command Execution Functions) documentation](https://www.postgresql.org/docs/current/libpq-exec.html): + +* `PQexec` directly runs a single string command and returns a result. +* `PQexecParams` implements a parameterized statement. + Placeholders are represented in the command as `$1`, `$2`, etc., + and the parameter values are supplied as separate parameters in the same call. +* `PQprepare` implements a prepared statement. + It takes a statement with placeholders and + submits it to the database to be prepared. + Users can later use the separate `PQexecPrepared` call + to provide the placeholder parameter values and execute the resulting + command. + +The [OWASP Query Parameterization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) and [Bobby Tables website](https://bobby-tables.com/) provide examples for a variety of ecosystems. + +#### Quiz 3.2: SQL Injection: Parameterized Statements + +\>\>Parameterized statements (including prepared statements) are a valuable countermeasure against SQL injection, but you have to use placeholders for every data value that might possibly be controllable by an attacker. True or False?<< + +(x) True + +( ) False + +### SQL Injection: DBMS (Server) side vs. Application (client) side + +An important yet subtle security issue when using +SQL parameterized statements is *where* the +parameters of a parameterized statement are processed. +There are two options, DBMS-side and application-side. + +From a security point-of-view it's best if the parameters of +parameterized statements are processed directly +within the database management system (DBMS), +aka "DBMS-side" parameter processing. +This approach is often called "server-side" since many DBMSs use a +client/server architecture where the client connects over a network +to a server-side DBMS. + +There are many advantages to DBMS-side parameter processing. +The DBMS has the current information on escaping rules +(and can often use more efficient mechanisms than adding escape characters), +and it also has other information such the relevant character encodings +and expected data types. +Perhaps most importantly, the DBMS developers will typically have +security experts review this part of the DBMS system. +However, DBMS-side parameter processing can require more effort to +implement, so some libraries use +"application-side" parameter processing instead. + +"Application-side" parameter processing occurs when the parameter escaping +occurs within a library *not* in the DBMS, but instead in the application's +processing space. +This is also called "client-side" parameter processing. +Application-side parameter processing systems generally are implemented +by directly inserting escape characters where they are needed. +Application-side parameter processing is often easier to implement, so +several DBMS libraries use this approach. +Application-side libraries are better than directly calling an escape +mechanism "by hand" on every use since the escapes are automatically added. + +Unfortunately, application-side parameter processing has a weakness: +the application side may interpret information differently than the DBMS. +This weakness can lead to vulnerabilities. For example: + +1. The application-side library may be intended for a different + version of the DBMS. The DBMS may have a different list of characters + or situations that need to be escaped. +2. The application-side library may interpret multi-byte characters + differently or not escape multi-byte characters correctly for the + circumstance that actually exists on the DBMS side. (See + [Multibyte character exploits PHP/MySQL](https://security.stackexchange.com/questions/9908/multibyte-character-exploits-php-mysql).) +3. If the application-side library implements parameterization of + data types more complex than numbers and strings (such as arrays, + objects, associative arrays, and/or dictionaries), then there + is a significant risk of a vulnerability. + The fundamental problem is that the application-side library isn't + necessarily parsing the query language the same way that the DBMS would - + it is usually doing simple text substitutions. + So if the library implements this + functionality, it must typically make *guesses* of what types are expected. + For example, it may guess that associative arrays are only sent + to the library when that is sensible in the parameterized SQL query. + That guess, sadly, may be exploitable. + This is especially a risk in languages that don't require static types + (compile-time knowledge of types), as it's much easier to get unexpected + complex types into a library that cannot always handle them securely. + For example, the widely-used Node.js MySQL library + [mysqljs/mysql](https://github.com/mysqljs/mysql) + as of early 2022 is often exploitable through its parameterized library + *if* a JavaScript object can be sent as a parameter to it + (see + [Finding an Authorization Bypass on my Own Website](https://maxwelldulin.com/BlogPost?post=9185867776) by Maxwell Dulin (ꓘ)). + +That last issue for application-side processing +(that complex data types may not always be escaped properly) +can be confusing, so an example may help. +In the Node.js mysqljs/mysql library, +imagine that an attacker manages to provide +the JavaScript *object* `{password = 1}` as the password parameter +(this is not just a string, but an actual JavaScript object). +Now imagine that this object is used in the SQL query +SELECT * FROM accounts WHERE username = ? AND password = ? +(note that this is parameterized). +The library will internally expand the expression after `AND` +into password = `password` = 1 because the library does simple +text replacement of the second `?`, without noticing that a JavaScript object +doesn't make sense in the context of this query (a string or number would +be expected here). +The MYSQL DBMS will interpret password = `password` +as 1 (true), and then determine that `1 = 1` is true. +The result: this expression will *always* be true. +This incorrect escaping of a complex data type +is enough to completely bypass authentication in some situations. + +Unfortunately, this last issue can be a challenge to solve: + +1. The safe solution is to make sure that complex data types + (types other than numbers and strings) are not expanded by + application-side libraries + unless the developer specifically marks them as allowed. + This may be impractical if the application already depends on this, + and the library might not provide a way to fully disable the functionality. + For example, mysqljs/mysql allows setting `stringifyObjects` to true + when calling `mysql.createConnection`, but while this can help, + this only disables escaping generic Objects - it does not + disable other complex data types such as arrays. +2. The general solution is to verify every type before calling the library. + For example, require that all data expected to be strings must be strings. + This is typically easy to do in a statically typed language + if the language enforces the types - just declare the required type. + This can take a lot of time to implement in languages that don't + enforce static types, and there is also the + risk of missing a check when creating or modifying the code. + However, this approach is more flexible. + (See ["Finding an unseen SQL Injection by bypassing escape functions in mysqljs/mysql"](https://flattsecurity.medium.com/finding-an-unseen-sql-injection-by-bypassing-escape-functions-in-mysqljs-mysql-90b27f6542b4) by Flatt Security Inc., 2022-02-21.) + +It's often hard to determine if a library uses DBMS-side or +application-side parameterization, and in some circumstances +only an application-side approach is available. +In some cases requesting a prepared statement forces the library to +use DBMS-side processing, but don't assume it - check the documentation. +If you have a practical choice, prefer a DBMS-side implementation. +Otherwise, carefully validate input and data going to the library +to ensure they are the appropriate types. + +This is a good example of a general kind of security issue, +namely, that different components may interpret the same input differently. +In some cases, an attacker can exploit this, by making their input +appear benign to one part while performing something malicious in another. + +#### Quiz: SQL Injection: DBMS (Server) side vs. Application (client) side + +\>\>Which of these is an advantage of libraries that implement application-side parameterization?<< + +( ) The library necessarily has the current information on the +DBMS' current escaping rules for its particular version and configuration. + +( ) The library has the information on this DBMS session's character encodings +and expected data types. + +(x) An application-side library is often easier to implement. + +### SQL Injection: Alternatives to Parameterized Statements + +Database systems are widely used, so there are many ways to +interact with them. +Here we discuss some alternatives. + +#### Stored Procedures + +Many database systems support "stored procedures", that is, +procedures embedded in the database itself. +If you use stored procedures, and commands (such as queries) +are dynamically constructed in them, then you can again have +SQL injection vulnerabilities. + +Again, the best solution is usually to use a parameterized query mechanism +when creating the dynamic command (e.g., the SQL) inside the +stored procedure. Be careful; in some systems using them correctly +can be a little tricky. + +For more information on using parameterized queries +in stored procedures, see your library's documentation, the +[OWASP Query Parameterization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html#stored-procedure-examples), and the +[OWASP SQL Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) + +#### When Parameterized Statements Won't Work + +In some situations parameterized statements (including +prepared statements) will *not* work. +Many parameterized statement APIs only allow replacing SQL values, so +they do not allow varying information such as the names of tables, the names +of columns, or the sort order direction. + +In those cases you may need to create a query by concatenating data. +In those cases, make *sure* you carefully validate the data (using an allowlist) +so only specific and safe values are allowed. +Often the allowlist is a short list of permitted values, or at most +a simple expression that only allows ASCII letters and digits. +A risk with this approach is that if the validation +is ever skipped (e.g., after some code change), +the system may become extremely vulnerable. + +The [OWASP SQL Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) +has a nice suggestion: if you *must* do this concatenation, +make the user input *different* from what you will actually use, and +in the program map the user input to the values you will use. +If user input doesn't have a valid mapping, reject the input. +This increases the probability that a change to the program +will not result in unvalidated input being concatenated into a query, +or that the problem will be detected before shipping. +For example, in Python, if you need to write to a user-provided table name, you can do the following: + +~~~~python + table_name_untrusted = request.get("table_name") # This is untrusted, don't put this directly in the query! + table_name_map = {"table1": "db.table1", "table2": "db.table2"} + table_name = table_name_map[table_name_untrusted] + con = sqlite3.connect(...) + cur = con.cursor() + cur.execute(f"insert into {table_name}(d, ts) values (?, ?)", (today, now)) # This is safe because we know that table_name can only take trusted values from table_name_map +~~~~ + +#### Other Approaches for Countering SQL Injection + +Many programs use object-relational mapping (ORM). This is just a technique to automatically convert data in a relational database into an object in an object-oriented programming language and back; lots of libraries and frameworks will do this for you. This is fine, as long as the ORM is implemented using parameterized statements or something equivalent to them. In practice, any good ORM implementation will do so. So if you are using a respected ORM, you are already doing this. That said, it is common in systems that use ORMs to occasionally need to use SQL queries directly… and when you do, use parameterized statements or prepared statements. + +Some applications use a "query builder" library to build commands (queries) programmatically through a sequence of calls instead of embedding a command string. Some ORMs include a query builder system. Again, a well-implemented query builder will use parameterized statements or similar internally. So if you use a query builder, use one that is implemented using parameterized statements, and provide untrusted data as separate parameters so the query builder can use the parameterized statements correctly. + +There are other approaches, of course. You can write your own escape code, but this is difficult to get correct, and typically a waste of time since there are usually existing libraries to do the job. + +In summary, properly using parameterized statement libraries makes it much easier to write secure code. In addition, they typically make code easier to read, automatically handle the variations between how databases escape things, and sometimes they are faster than doing metacharacter escapes yourself. + +#### Quiz: SQL Injection: Alternatives to Parameterized Statements + +\>\>True or false: A good object-relational mapping (ORM) system should be implemented using parameterized statements or something equivalent to them.<< + +(x) True + +( ) False + +### OS Command (Shell) injection + +Another kind of injection attack is the operating system (OS) injection attack, also known as a shell injection attack. This is similar to an SQL injection attack; the problem is that information (usually text), some of it trusted and some from an attacker, is sent to an interpreter that executes what it is sent. The difference is that instead of being sent to a database, this mixture is sent to the OS command interpreter, aka the command shell. + +Most systems have at least one command shell. Even small embedded systems, like televisions and routers, often have a command shell inside. Shells are useful for many things, including quickly combining programs, doing some queries, debugging, and so on. Many Unix-like systems, including typical Linux distributions, have multiple shells available including bash, dash, ksh, zsh, and csh; at least one of those is installed as **/bin/sh** or **/usr/bin/sh**. MacOS similarly comes with a shell and others can be easily installed. Windows systems typically use different shells with very different syntax (**cmd.exe**, **command.exe**, or PowerShell), but they have shells too. + +A shell is a program that directly takes commands and runs programs as commanded. Since this is useful, many programming languages make it easy to call out to a shell. In particular, many languages have a way to dynamically construct a call to a shell and then execute it. However, it is easy to make mistakes when combining attacker data into a command to be run by a shell. In particular, try to avoid dynamically creating a mixture of commands and attacker-provided data to then be executed by the shell. Instead, try to find an alternative that is easier to use securely. + +If all you want to do is call another program and pass it some parameters, try to do that without dynamically creating and then interpreting a shell command at all! Instead, try to call the program directly. This is more efficient anyway, and this is far easier (and more likely) to be secure if any of those parameters might include data from an attacker. For example: + +* In C, prefer **execve(3)** (it does not use the shell) instead of using **system(3)** (which does use the shell). + +* In Python, prefer using **shell=False** (the default) with **subprocess.run()** or **subprocess.call()**, instead of using **shell=True** or **os.system()** + +* In JavaScript Node.js, prefer using **shell=False** (the default) with **child_process.spawn()** or **child_process.execFile()** instead of using **shell=True** or **child_process.exec()** + +In short: if you see code that concatenates strings (including formatted strings) for execution by a shell, and that concatenation includes untrusted input, be extremely concerned. While it is possible to do this securely, it is better avoided when you reasonably can. + +If you must call a program through a shell, and also include some data that might be provided by an attacker, you need to use it securely. That is actually rather tricky. As always, *do not use a denylist*. There are many “lists of shell metacharacters” that are wrong because they miss some. So if you are sending data through a shell, you need to escape every character except for ones on an allowlist (characters you know are *not* metacharacters). Generally, A-Z, a-z, and 0-9 are not metacharacters, and after that, check very carefully. Make sure you quote everything as needed. + +Of course, if you are calling a program with any data that might be from an attacker, you need to make sure that the data will not be misinterpreted. For example, make sure your command-line options will be correctly interpreted; if an attacker can cause the initial character to be “**-**” or “**/**” in a parameter, then they might be misinterpreted as an option or root directory. Anything passed in (e.g., by parameter or anything else) must be carefully escaped to prevent attack. This brings us to the topic of filenames, which we will cover next. + +🔔 OS command injection is such a common cause of security vulnerabilities that it is 2019 CWE Top 25 #11 and 2021 CWE Top 25 #5. It is [CWE-78](https://cwe.mitre.org/data/definitions/78.html), *Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)*. + +#### Quiz 3.3: OS Command (Shell) injection + +\>\>Avoid unnecessarily calling an operating system shell when you simply want to run another program. True or False?<< + +(x) True + +( ) False + +[Explanation] + +This is true. Not only is it more efficient, but the operating system shell usually responds to a large number of special characters that you would need to deal with to use it securely. If you don’t need its additional functions, there is no point in calling through it. Of course, there may be cases where its additional capabilities are valuable to you; in those cases, you will need to be very careful and escape metacharacters to ensure that data is not misinterpreted. + +[Explanation] + +#### Lab: OS Command (Shell) injection + + 🧪 **Lab: Please try lab [shell-injection](https://best.openssf.org/labs/shell-injection.html), which lets you experiment with how to counter an OS shell (injection) vulnerability.** + +*Labs are optional, but you're strongly encouraged to try them!* + +### Other Injection Attacks + +There are many other kinds of injection attacks beyond SQL injection and operating system command injection. There may be a risk of an injection attack any time you are sending data partly controlled by an untrusted user in a format that has metacharacters, is defined as a language, and/or is processed by an interpreter. + +Examples where there may be a risk of an injection vulnerability include generating and sending JSON, yaml, XML, Lightweight Directory Access Protocol (LDAP) commands, and many other formats to libraries, frameworks, and other components that you depend on, as well as outputting them to eventual users. In all cases, one solution is to use an API that automatically escapes the text as necessary, just like using parameterized statements when generating SQL. + +One interesting variation of an injection attack occurs when some expression is unintentionally executed twice. This can occur, for example, in some uses of the expression language in the widely-used Spring Java framework, where the attack is called expression language injection. This vulnerability is remarkably common, so we’ll explain it further here. + +An “Expression Language” (EL) was developed as part of the Java Server Pages Standard Tag Library (JSTL) to make it easy to get data from the underlying object model. For example, this: + +> `
The malicious data is stored in a database for later retrieval. For example, an attacker submits a comment with an embedded malicious script; when someone else uses their web browser to view the comments, the web browser runs the malicious script. + +* **Reflection**
The malicious data is sent by the victim’s web browser to the server (typically inside a URL) and immediately reflected back to the browser. + +* **DOM-based**
The web client sends the attack data to itself, typically using data provided from an attack and then sent via the DOM using JavaScript. + +🔔 XSS is such a common mistake in web applications that it is 2017 OWASP Top 10 #7. XSS is considered part of 2021 OWASP Top 10 #3 (Injection) in its 2021 edition. It is also 2019 CWE Top 25 #2 and 2021 CWE Top 25 #2. In CWE it is [CWE-79](https://cwe.mitre.org/data/definitions/79.html), *Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)*. + +#### The XSS Solution: Escape Output + +The standard way to counter XSS is to escape all output that might be from an attacker and is not specifically approved. In many ways, this is the best countermeasure. Done right, it completely counters the attack and is very flexible. For example, if you have untrusted HTML data from an attacker, apply the standard HTML escapes unless you have a good reason to do otherwise: + +**Standard HTML Escapes** + +
| Original | +Escaped HTML | +
| & | +& | +
| < | +< | +
| > | +> | +
| " | +" | +
| ‘ | +' or ' | +
This should be set to **nosniff**, which means that the MIME types provided are correct and that the receiver should not try to guess what the type is. This means that attackers won’t be able to fool the web browser into using a different type. + +* **X-Frame-Options**
This should be set to **DENY** or **SAMEORIGIN**. Like the CSP **frame-ancestors**, this prevents the use of frames or only allows them from the origin, countering many clickjacking attacks. Technically, X-Frame-Options has been obsoleted by CSP **frame-ancestors**, but if you might have Internet Explorer (IE) users, you also need this as IE does not support CSP **frame-ancestors**. + +* **HTTP Strict-Transport-Security (HSTS)**
This means that *only* the secured HTTPS protocol, and not the insecure HTTP protocol, is permitted for future visits to this site for a given number of seconds. A common setting is “**Strict-Transport-Security: max-age=31536000;**” which means that *only* HTTPS will be allowed for a year (the number is the number of seconds). A larger number is fine. + +If your site is publicly accessible, you can easily test your headers using the [Security Headers website](https://securityheaders.com/). + +Also, an important word about HTTP headers in general. You may decide, for various reasons, to provide other HTTP headers. If some of that header information might be from an attacker, be *especially careful*. As always, do very careful input validation. There is a nasty attack, in particular, where the attacker manages to insert a newline in the input; this will cause *HTTP header splitting* in HTTP versions 1.1 and 2, where the rest of the text after the newline may be interpreted as an HTTP header provided by the attacker. This could disable many protections or even implement an attack. + +#### Quiz 4.4: Other HTTP Hardening Headers + +\>\>When sending information using HTTP, you can set various HTTP headers (such as HTTP Strict-Transport-Security (HSTS)) to help harden your system against attack. True or False?<< + +(x) True + +( ) False + +### Cookies & Login Sessions + +[Web application] + +An important mechanism in the HTTP protocol is support for *cookies*. Cookies are small chunks of data sent from a web server to a web browser. From then on, when the web browser contacts that web server, the web browser will send that cookie value back to the server it came from, subject to certain restrictions. + +#### Cookie Attributes + +Web servers can also set some attributes on the cookies they send. For example: + +* Expiration time: If no expiration time is set, the cookie expires when the browser exits (such cookies are called *session cookies*). Otherwise, the browser may store the cookie permanently until the time expires (such cookies are called *permanent cookies* - a user *can* delete these cookies, but few do). + +* **Secure** flag: If set, the cookie will only be sent to HTTPS servers, and not to HTTP. You should set this whenever practical. + +* **HttpOnly** flag: The cookie is not visible to JavaScript programs. You should set this whenever practical. + +* **SameSite**: This has three main values - **None**, **Lax**, and **Strict**. “**None**” means that cookies are always sent to the matching web server. “**Lax**” means that cookies are sent if they are a **GET** (click) on a third-party website, and otherwise cookies are only sent if the request comes from the same site. “**Strict**” means that cookies are only sent in a first-party context; any request from another website will *not* cause the cookie to be sent. Historically, the web browser default was effectively **None**, but modern web browsers now act with **Lax** as the default because this counters certain attacks. We will discuss this later, but you should set this to at least **Lax** wherever practical. + +#### Cookies in Context + +Cookies are not, by themselves, necessarily malicious. However, cookies can reveal who the requester is in some cases, making them a potential privacy issue. This is especially true for cookies that have **SameSite=None**. If someone sets up requests for this kind of cookie on many websites (e.g., by embedding third-party images), the cookie can be used to track that user’s actions across many sites. A cookie intended to track users across websites is called a *tracking cookie*. Tracking cookies can be even worse if they have a long expiration time, because such cookies persist after the browser exits. Tracking cookies have attracted the concerns of many nations because of their detrimental effect on user privacy. As a result, various laws have passed involving cookies and consent. However, implementing tracking cookies is not the only way to use cookies; cookies can also improve security. + +Cookies are important in part because they are often used to implement login sessions on the world wide web (WWW). A login session is simply a period of activity between when a user logs in and logs out. The original WWW protocol did not have a way to implement login sessions, and cookies provide a simple mechanism to support login sessions. + +#### Cookies and Login Sessions + +On the web, a common way to implement a login session is to have a login form. If the login is successful, the web server sends a “**session id**” within a cookie value. The session id is simply a large random number that cannot be guessed by anyone else. From then on, the web browser then sends this cookie (with the session id) whenever it contacts that web server. The web server can check this session id to see who is making the request… and if that session id is valid, the web server looks up the user id for that session and allows the user to whatever the user is authorized to do. Including a session id in a cookie is **not** the only way to use cookies to support login, but it is a common approach. + +Normally, when developing web applications, you will use a framework or library that (mostly) handles login sessions for you. This is fine, just check to ensure that it is secure. Here we will cover some key features to look for. In some cases, your framework won’t do it by itself, but you can take some additional steps to make them happen. + +First, if your framework uses session ids in cookies (a common approach), it is critical that the implementation does not allow attackers to guess or discover the session ids. If an attacker can get the session id, the attacker can act with the same privileges as the logged-in user! In this common case, check for these key factors at least: + +1. The session identifier must have at least 128 bits of random data. + +2. The session id must be created using a *cryptographically secure* pseudo-random number generator (CSPRNG). Anything guessable (like *“add one to the last session id”* or *“ordinary call to random()”)* is not acceptable. We will discuss this in more detail later. + +3. Encrypt session ids between the web server and web browser. The usual solution is to set the cookie’s **Secure** flag and always communicate using HTTPS (TLS). + +Second, set the attributes of cookies that contain session ids to be secure: + +1. As noted earlier, where practical set cookies for login session handling with the **HttpOnly** flag. That way, JavaScript programs won’t have direct access to it. This is another example of least privilege; if a privilege is not needed, don’t provide the access. + +2. Similarly, consider using session cookies (cookies with no expiration time) for cookies that store information on login sessions. You don’t have to do this; you can use permanent cookies to store session information. But if you use permanent cookies, consider limiting the time to at most a few days. Permanent cookies are stored in permanent storage, and an attacker might be able to gain access to that stored information. + +Third, make sure that you have login and logout functions, and that they actually work correctly! + +Whenever a user successfully logs in, make sure that the user *always* gets a *new* session id (this is typically returned in a cookie). In particular, the receiving side of a login must *never* reuse session values. A new login means a new session is being requested (even if there is already a current session), so make sure a new session is created and used for that request! If your program fails to create a new session for a new login, it may be vulnerable to a *session fixation attack*. + +🔔 Session fixation is such a common cause of security vulnerabilities that it is 2019 CWE Top 25 #37. It is [CWE-384](https://cwe.mitre.org/data/definitions/384.html). + +Similarly, make *sure* that you provide users a “log off” (“sign off”) action that *actually works*. If you use session ids - a common approach - then a log off should invalidate that session. This generally means that you need to remove the record of that session id from the server database that records active session ids (and the user id each session id applies to). You also need to tell the browser to delete the cookie or at least the session id value in that cookie. That way, the user is actually logged out. Users log out to reduce their risks, but this does not work if the application does not actually log them out. A surprisingly large number of major sites have, at one time or another, not logged out users when they requested it. + +You should also eventually log out an inactive session automatically. Some easy ways to do that are to not set an expiration date (so the user will log out when they shut down their browser) or set an expiration date for when the user will be logged out. Frameworks will typically let you configure this easily. + +#### Quiz 4.5: Cookies & Login Sessions + +\>\>When a user logs in again, reuse the session id if session ids are used and already present, to reduce confusion to the user. True or False?<< + +( ) True + +(x) False + +[Explanation] + +This is false. If a user is logging in again, they are asking for a new session. Honor that request by creating a new session! + +Reusing an existing session can, in some implementations, open a system to an attack called session fixation. We have not gone into the details of session fixation in this course, but that is because the countermeasure (“don’t reuse session ids”) is much easier to explain than the attack. + +[Explanation] + +### CSRF / XSRF + +[Web application] + +Another kind of attack that websites have often been vulnerable to is called cross-site request forgery (CSRF or XSRF). It is less of a problem today, but it can still happen, so let’s learn what it is and how it can be countered. CSRF is also a great example of how specific security vulnerabilities can become less common over time; if you can, try to find general ways to eliminate other kinds of vulnerabilities! + +In a CSRF attack, an attacker tricks the user into sending data to a *server*, where the server interprets the request as a request from the user and directly acts on it. For example, the attacker could create a form with a submit button on the attacker’s website, but tell the user’s web browser to submit the completed form to a server that will act on that form. Note that if the user is logged in to that server (say for a bank), the server will see that the user really is logged in to the bank, and might be convinced to do something the user did not intend (such as transfer a lot of money to the attacker). + +In some ways, a CSRF attack is the opposite of an XSS attack. XSS exploits the user’s trust in a server; CSRF exploits the server’s trust in a client (that the user is actually intentionally making a given request). Put another way: XSS fools clients; CSRF fools servers. + +A common countermeasure used today in most widely-used web application frameworks is to send a secret user-specific CSRF token in all forms and any other URLs with side-effects, and then check to ensure that the correct secret is included with any request with a side-effect. Since attackers will not know the secret value, the attacker cannot insert a matching CSRF token. Since this is built into almost all widely-used web frameworks today, many applications are automatically protected from CSRF (unless they disable the protection or don't use the framework correctly). You should prefer a web application framework that has a CSRF token mechanism. + +Another common countermeasure used today is what are called **SameSite** cookies. Historically, all cookies were sent to a server whenever the user had matching cookies for that server, even when the primary page being displayed was from a different server. For example, a web page on site BB might include a reference to an image on site CC; when the web browser downloaded the image from CC it would send all related cookies. However, this does not really make much sense; in many cases cookies should not be sent if the interaction was caused by an unrelated server. So modern browsers have an optional **SameSite** setting on cookies. If the setting is **Lax** or **Strict**, a request caused by an attacker on a different server will not cause the cookie (like a session) to be sent. So as long as your session cookies have a **SameSite** setting of **Lax** or **Strict**, CSRF attacks generally don’t work. Even better, modern browsers are working to make **SameSite=Lax** the default. It is best to set **SameSite** to **Lax** or **Strict** yourself, but a secure default is still a good thing. + +In short, CSRF vulnerabilities are becoming less common because the industry is moving towards safe defaults. This shows it is *possible* to reduce the likelihood of entire classes of vulnerabilities by designing or modifying systems so that the default is secure. Where possible, build countermeasures into your tools/standards/system so the problem won’t occur. If you are building a new web application, it is much less likely to be a problem, but make sure that your web framework counters it and that you use its mechanisms correctly. + +🔔 Although it’s becoming less common, Cross-Site Request Forgery (CSRF) is still a common enough cause of security vulnerabilities that it is 2019 CWE Top 25 #9. It is also identified as [CWE-352](https://cwe.mitre.org/data/definitions/352.html). It used to be in the OWASP Top 10. It is not in the 2017 edition, because so many modern frameworks now prevent it, but it is still important if your software is vulnerable to it. + +Of course, there are other ways an attacker might be able to gain temporary control over a user’s system. So you might still want to implement some other traditional CSRF countermeasures, such as: + +1. Automatically log off users after some period of time, or some time of inactivity. + +2. If an action is especially dangerous (e.g., account deletion or moving a large sum of money), require a separate additional authenticated confirmation that the user really is requesting it. This is good anyway, because there are many ways an attacker might be able to temporarily gain control over an account; limiting the impact is all part of managing risk. + +#### Quiz 4.6: CSRF / XSRF + +\>\>CSRF vulnerabilities are less common today because web application frameworks and web browsers generally have countermeasures to make these vulnerabilities less likely. True or False?<< + +(x) True + +( ) False + +[Explanation] + +This is true! This shows that sometimes it *is* possible to modify systems to reduce the likelihood of whole classes of attacks. You should also continuously look for ways to eliminate entire classes of attacks, either in your specific application or the world in general. + +[Explanation] + +### Open Redirects and Forwards + +[Web application] + +A web application should not accept user-controlled input that specifies a link to some site on a different server and then, without strict controls, use that link to do a redirect. A web application that does this has an *open redirect*. + +This can be hard to understand, so let’s look at an example. Let’s imagine that a server-side web application has a “**/redirect**” link that accepts a parameter **url=**, and then simply redirects requests to the **url= value**. That means that an attacker could create an HTML file anywhere that looks like this (the example is based on text in MITRE’s text on [CWE-601](https://cwe.mitre.org/data/definitions/601.html)): + +<a href="https://bank.example.com/redirect?url=https://attacker.example.net">Click here to log in</a> + +What is the problem? The problem is that a user who checked the link would think that this link went to a trusted domain (e.g., **bank.example.com**). While technically that is true, when clicked, the supposedly trusted domain will quietly redirect the user to some other domain that might be dangerous and not what the user expected (e.g., **attacker.example.net**). More generally, the problem is that an open redirect can be used to fool humans and create stronger phishing attacks. Humans can be lulled into thinking they are going to a trusted domain, without realizing that they will in fact be immediately transferred to an untrusted domain. In theory, the users should also check *where they are now* on each page, but busy humans often don’t do that. We want to make it harder, not easier, to fool busy humans. + +A related problem is a “forward”, where the web application forwards the request to some other part of the web application. The web application might incorrectly view the request as an *internal* request from the web application itself, instead of more accurately coming from an external user, and give it unwarranted privileges. + +The [OWASP cheat sheet on unvalidated redirects and forwards](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html) discusses various possible countermeasures: + +* *“Simply avoid using redirects and forwards.* + +* *If used, do not allow the URL as user input for the destination.* + +* *Where possible, have the user provide [a] short name, ID or token which is mapped server-side to a full target URL.* + + * *This provides the highest degree of protection against the attack tampering with the URL.* + + * *Be careful that this doesn’t introduce an enumeration vulnerability where a user could cycle through IDs to find all possible redirect targets* + +* *If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user.* + +* *Sanitize input by creating a list of trusted URLs (lists of hosts or a regex).* + + * *This should be based on an allowlist approach, rather than a denylist.”* + +🔔 Open redirects are such a common cause of security vulnerabilities that this weakness is 2021 CWE Top 25 #37 and 2019 CWE Top 25 #32. It is [CWE-601](https://cwe.mitre.org/data/definitions/601.html). + +#### Quiz 4.7: Open Redirects and Forwards + +\>\>It is fine to support a redirector URL, e.g., **
| Analysis/tool report | +Report correct | +Report incorrect | +
| Reported (a defect) | +True positive (TP): Correctly reported (a defect) | +False positive (FP): Incorrect report (of a “defect” that’s not a defect) (“Type I error”) | +
| Did not report (a defect (there)) | +True negative (TN): Correctly did not report (a given defect) | +False negative (FN): Incorrect because it failed to report (a defect) (“Type II error”) | +
Creating these is highly specialized. To do a good job you need a PhD in cryptography, which in turn requires advanced college mathematics. Instead, find out what has been publicly vetted by reputable cryptographers and use that. + +2. **_Never_ implement your cryptographic algorithms or protocols (if you have an alternative)**.
There are a large number of specialized rules for implementing cryptographic algorithms that don’t apply to normal software and are thus not known to most software developers. Tiny implementation errors of cryptographic algorithms often become massive vulnerabilities. Instead, reuse good implementations where practical. + +3. **Cryptographic systems (such as algorithms and protocols) are occasionally broken.**
Make sure the ones you choose are still strong enough, and make sure you are prepared to replace them. + +When choosing a cryptographic library, prefer ones that have had significant public review and have a simple-to-use-correctly API. Otherwise, you risk having a vulnerability either in the reused component or having one caused due to incorrect use of an API. + +Cryptanalysts are always looking for ways to break cryptographic algorithms, and cryptographers are always working to counter those attacks. Historically, cryptographic algorithms are developed, last for a while, and then finally are broken due to some attack. So before choosing anything in cryptography, do some searches to make sure that what you are choosing is not weak or broken. Perhaps nothing has been broken recently… but it would be unwise to assume that. + +The following sections will identify some key algorithms and protocols, and some pointers about them. + +### Symmetric/Shared Key Encryption Algorithms + +A *symmetric key* or *shared key* encryption algorithm takes data (called “cleartext”) and a key as input, and produces encrypted data (called “ciphertext”). It can also go the other way: using the ciphertext and the same key, it can produce the corresponding cleartext. + +What is important about symmetric key encryption algorithms is that the *same* key is used to both encrypt and decrypt the data. So if you want people to be able to decrypt some ciphertext encrypted this way, you have to arrange for them to get the key. Most modern symmetric key algorithms are extremely fast (they are often hardware-accelerated), and they form the basis of many cryptographic systems. + +#### Choosing a Symmetric Key Algorithm + +At the time of this writing (2020), the most common symmetric key algorithm is the Advanced Encryption Standard (AES). AES supports 3 key sizes: 128, 192, or 256 bits; the longer key sizes are stronger against attack, but take longer to execute. At the time of this writing, even 128 bits is considered adequately secure for most purposes, but check to see if something has changed. AES is extremely fast; it was designed to be fast on modern processors, and many processors have mechanisms that speed it up even further. + +There are other historical symmetric key algorithms that are considered *insecure* for typical use cases today: + +* DES: Its 56-bit key length is far too short to be secure today. + +* RC4: Many vulnerabilities have been found in RC4, and it is generally considered insecure. + +* 3DES: Internally, this has a block size of only 64 bits. Algorithms with such small block sizes are vulnerable to an attack called a *birthday attack* if they are used to encrypt significant amounts of data with the same key. + +* Blowfish: This also has a block size of only 64 bits, and thus has the same problems as 3DES. + +There are alternative symmetric key algorithms that are also generally considered secure. For example, TwoFish was a finalist in the contest that led to AES, and at the time of this writing has no known practical vulnerabilities. + +#### Choosing a Mode + +Many symmetric key algorithms, including AES, are what is called *block algorithms*. With block algorithms you must also choose a *mode* to use. Here is the most important rule about modes: + +**Never use Electronic Code Book (ECB) mode!** + +The ECB mode is basically a debug or test mode for testing cryptographic algorithms. In ECB mode, the same block of data will produce the same encryption result. This is disastrous for an encryption algorithm, because it reveals far too much about the data that is supposed to be encrypted. A great illustration of this is the so-called “ECB Penguin” image; this image is encrypted using an ECB mode. Note that in the ECB Penguin below, the image of Tux the Penguin is clearly (and disastrously) visible. An encrypted image should appear as random noise, as illustrated by the GCM Penguin below, an encrypted image that uses the Galois/Counter mode (GCM). + +
| Original | +ECB encrypted | +GCM encrypted | +
 |
+  |
+  |
+
Anyone could encrypt a message using a public key, but only someone with the corresponding private key could decrypt it. Public key encryption algorithms are generally relatively slow, so in many situations, a *key* for a shared-key algorithm is encrypted, and the rest of the message is encrypted with a shared key. + +* **Digital signatures (authentication)**
A sender can use a public key algorithm and their private key to provide additional data called a *digital signature*; anyone with the public key can verify that the sender holds the corresponding private key. + +* **Key exchange**
There are public key algorithms that enable two parties to end up with a shared key without outside passive observers being able to determine the key. + +A widely-used public key algorithm is the RSA algorithm, which *can* be used for all these purposes. However, *do not implement RSA yourself*. RSA is fundamentally based on exponentiation of large numbers, which lures some developers into implementing it themselves or thinking it is simple. In practice it is extremely easy to implement RSA *insecurely*. For example, it is very difficult to check for weak parameters that *look* acceptable but make it trivial to defeat. To be secure, RSA *must* be implemented with something called “padding”. There is a standard RSA padding scheme with a rigorous proof called OAEP, but it is difficult to implement correctly (incorrect implementations may be vulnerable to *Manger’s attack*). In practice, RSA can be tricky to apply correctly, and unless you understand cryptography, you won’t be able to tell when it is not working ([*Seriously, stop using RSA*](https://blog.trailofbits.com/2019/07/08/fuck-rsa/), 2019). + +RSA key lengths need to be longer than you might expect. An RSA key length of 1024 bits is approximately equivalent to a symmetric key length of 80 bits, which is so small that it is generally considered insecure. An RSA key length of 2048 bits is equivalent to a symmetric key length of 112 bits; a 2048 bit is considered barely acceptable by some (e.g., NIST says that this may be used through 2030, after which it may not be used by the US government). If you are using RSA, you should probably use at least 3,072 bit key in current deployments (this is equivalent to a 128 bit symmetric key). You would need an RSA key of 15,360 bits to get the equivalent of a 256-bit symmetric key. See [NIST’s *Recommendation for Key Management: Part 1 - General*](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf) for more about key equivalent lengths. Unfortunately, RSA is relatively slow, especially as you increase to key lengths necessary for minimum security. For all these reasons, some organizations, such as Trail of Bits, recommend avoiding using RSA in most cases ([*Seriously, stop using RSA*](https://blog.trailofbits.com/2019/07/08/fuck-rsa/), 2019). + +A whole family of algorithms are called *elliptic curve cryptography*; these are algorithms that are based on complex math involving elliptic curves. These algorithms require far shorter key lengths for equivalent cryptographic strength, and that is a significant advantage. Historically, elliptic curve cryptography involved a minefield of patents, but over the years many of those patents have expired and so elliptic curve cryptography has become more common. A widely-used and respected elliptic curve algorithm for key exchange is X25519, while for digital signatures it's EdDSA. A related protocol called ECIES combines elliptic curve key exchange with a symmetric key algorithm (for more details, see [*Seriously, stop using RSA*](https://blog.trailofbits.com/2019/07/08/fuck-rsa/), 2019). + +The Digital Signature Standard (DSS) is a NIST standard (FIPS 186-5) for creating cryptographic digital signatures. It supports several underlying algorithms: the RSA digital signature algorithm, the elliptic curve digital signature algorithm (ECDSA) and the Edwards-curve digital signature algorithm (EdDSA). + +There are also a variety of key exchange algorithms. The oldest is the Diffie-Hellman key exchange algorithm. There is a newer key exchange algorithm based on elliptic curves, called Elliptic Curve Diffie-Hellman (ECDH). + +As hinted at earlier, it is critical that you use existing well-respected implementations (don’t implement it yourself), and check any parameters you choose carefully. Perhaps the most important is the key length for that algorithm (as noted earlier, elliptic curve algorithms have equivalent strength with shorter keys). A useful source for recommended key lengths is [NIST’s *Recommendation for Key Management: Part 1 - General*](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf). + +#### Quiz 3.3: Public-Key (Asymmetric) Cryptography + +\>\>Select the true statement(s):<< + +[!] RSA with a 1024-bit key is generally considered adequately secure for most use cases. + +[ ] RSA is basically exponentiation, so to limit dependencies it is often better to reimplement it within a larger system. + +[x] X25519 is a widely-used algorithm that is generally considered secure. + +### Cryptographically Secure Pseudo-Random Number Generator (CSPRNG) + +Many algorithms depend on secret values that cannot be practically guessed by an attacker, aka "cryptographically secure". This includes values used by cryptography algorithms (such as private keys and nonces), session ids, and many other values. If an attacker can guess a value, including past or future values, many systems become insecure. + +One challenge is historical: today, the name *random* in programming language libraries usually implies that the function is *not* cryptographically secure. One of the first uses for digital computers was to implement simulations (especially *Monte Carlo simulations*) where random numbers were repeatedly acquired for a simulation. It was often important to be able to *reconstruct* these random numbers so experiments could be repeated. Internally, such random functions would be implemented using algorithms such as a linear congruential generator (LCG), and would often be “seeded” (initialized) by values such as a date/time that can be trivially guessed by an attacker. Because this was one of the first uses of computers, there is a convention across almost all programming languages that the word “random” refers to a way to create a sequence of numbers that could be easily reconstructed later if needed. In other words, the word “random” in programming languages typically implies “*predictably random*”, and that is not what you want in cryptography or security. Such random numbers *must not* be used for security mechanisms where it is important that an attacker *not* be able to determine the number. + + + +**Random Number**, retrieved from [xkcd.com](https://xkcd.com/221), licensed under [CC-BY-NC-2.5](https://creativecommons.org/licenses/by-nc/2.5/) + +Instead, for cryptography and security-related tasks you need to use a [cryptographically secure pseudo-random number generator (CSPRNG)](https://en.wikipedia.org/wiki/Cryptographically-secure_pseudorandom_number_generator) for crypto and security-related tasks. Put another way, there are many pseudo-random number generator (PRNG) algorithms and implementations, but for security, you should *only* use PRNGs that are cryptographically secure PRNGs (CSPRNGs). A good CSPRNG prevents practically predicting the next output given past outputs (at greater than random chance) and it also prevents revealing past outputs if its internal state is compromised. CSPRNGs are also called cryptographic PRNGs (CPRNGs). Typically a CSPRNG implementation's name will have “secure” and/or “crypto” in it. In their documentation, you may see references to well-accepted CSPRNG algorithms such as Yarrow, Fortuna, ANSI X9.17 (which can use any block cipher), NIST SP 800-90A’s Hash_DRBG, HMAC_DRBG, and CTR_DRBG. + +**🚩 Never use the algorithm Dual_EC_DRBG, as it is widely accepted that this is a subverted and insecure algorithm.** + +Here are some examples of how to call the predictable PRNG versus a cryptographically secure PRNG in different programming languages (in practice there are often multiple ways; the point is to show that they are different): + +
| Language | +Predictable random value (do not use for security) |
+ Cryptographically secure random value | +
| Java | +Random() | +SecureRandom() | +
| C# | +System.Random | +System.Security.Cryptography. RandomNumberGenerator | +
| JavaScript | +Math.random | +window.crypto.getRandomValues or crypto.randomBytes |
+
| Python | +random | +os.random | +
| Ruby | +rand (or Random.rand) | +SecureRandom.rand | +
Unless you have a strong reason to use something else, this is the algorithm to use today. It is relatively strong against both software and hardware-based attacks. + +* **Bcrypt**
This is a decent algorithm against software-based attacks. It is not as easy to attack with hardware compared to PBKDF2 (because bcrypt requires more RAM), but it is weaker against hardware-based attacks compared to Argon2id. + +* **PBKDF2**
This is a decent algorithm against software-based attacks, but it is the most vulnerable of these widely-used algorithms to hardware-based attacks from specialized circuits or GPUs. That is because it can be implemented with a small circuit and little RAM. You may not need to replace it (depending on the kinds of attackers that concern you), but it is probably best to avoid this for new systems today. + +Another algorithm that is in use is scrypt. This should also be strong against hardware attacks, but it has not gotten as much review compared to Argon2id, so Argon2id is more commonly recommended. That said, at the time of this writing, it has no known serious problems. + +All of these algorithms have various configuration options, and it is vital to use an adequately secure set of options. The OWASP [Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) provides a set of recommended configuration option values. + +You should allow users to require the use of two-factor authentication (2FA), either directly or by delegating to a service that does. + +Also, beware of implementing these algorithms only on the client side. It is fine to implement them on the client side (because that prevents the server from ever discovering the password the user enters), as long as they are *also* implemented on the server. The danger is doing them *only* on the client; if that happens, then what is stored in the server is no different from storing passwords in the clear. Once attackers get the password database, they can simply create or modify their own client to log into anyone’s account. + +> 😱 STORY TIME: Ashley Madison data breach +> Ashley Madison is a Canadian commercial online dating service founded in 2002 and marketed as enabling cheating on romantic partners. In 2015 attackers stole its customer data. Many issues were revealed at that point; we will focus on one here. Ashley Madison had correctly used the **bcrypt** routine to store user passwords. Unfortunately, in many cases they had *also* stored passwords encoded using the **MD5** hashing algorithm, which is not an appropriate algorithm for storing passwords (as noted above). Attackers used these unprotected MD5 password hashes to decipher more than 11 million of these accounts' passwords in just 10 days, enabling them to log into those accounts (["Once seen as bulletproof, 11 million+ Ashley Madison passwords already cracked" by Dan Goodin, 2015](https://arstechnica.com/information-technology/2015/09/once-seen-as-bulletproof-11-million-ashley-madison-passwords-already-cracked/)). + +> 😱 STORY TIME: Meta fined for plaintext passwords +> Meta was fined 91 million Euros (USD $102 million) in 2024 for storing passwords in plain text. +(["Meta Fined $102M for Storing Facebook Passwords in Plain Text" by Katie Collins, 2024-09-27](https://www.cnet.com/tech/services-and-software/meta-fined-102m-for-storing-facebook-passwords-in-plain-text/)] + +#### Quiz 3.5: Storing Passwords + +\>\>Select the true statement(s):<< + +[!] You can eliminate all authentication security and privacy concerns by delegating authentication to another service. {{ selected: Not so. For one thing, can you trust that other service? That other service will know who authenticated when; is that acceptable? In many cases it is a good decision to delegate, but you need to consider the ramifications. }} + +[ ] A secure way for a server to store passwords for inbound authentication is to hash the password using SHA-1. {{ selected: Absolutely not, that is an *insecure* approach. You should use an algorithm specifically designed for this purpose, such as Argon2id. }} + +[ ] PBKDF2 is more secure than Argon2id. {{ selected: No, that is the wrong way around. Argon2id has a much stronger resistance to hardware-based attacks than PBKDF2. }} + +[x] Argon2id, bcrypt, and PBKDF2 are all common iterated per-user salted cryptographic hash algorithms; among those three, prefer Argon2id unless you have a reason to do otherwise. + +### Transport Layer Security (TLS) + +Transport Layer Security (TLS) is a widely-used cryptographic protocol to provide security over a network between two parties. It provides privacy and integrity between those parties. TLS version 1.3 was released in 2018. An older and insecure version of this protocol was named Secure Sockets Layer (SSL), and sometimes the terms are used interchangeably. When you use **https://** in a web browser or server today, you are normally using TLS (in rare cases, you might be using its insecure predecessor, SSL). TLS is also used in other applications, for example, to protect exchanges of email between different Mail Transport Agents (MTAs). + +#### Certificate Validation + +To use TLS properly, the server side at least needs a certificate (so it can prove to potential clients that it is the system it claims to be). You can create a certificate yourself and install its public key on each client (e.g., web browser) who will connect to that server. That is fine for testing, but in most other situations, that is too complicated. In most cases (other than testing) you should get a certificate assigned by a certificate authority. You can get free certificates from [Let’s Encrypt](https://letsencrypt.org/). If the requirements of Let’s Encrypt don’t suit your needs, other certificate authorities may be useful to you. + +When clients connect to a server using TLS, the client normally needs to check that the certificate is valid. Web browsers have long worked this out; web browsers come with a configurable set of certificate authority public keys (directly or via the operating system) and automatically verify each new TLS connection. + +*Beware*: If you are using your own client, instead of using a web browser, double-check that you are using the TLS library API *correctly*. Many TLS library APIs do *not* fully verify the server’s TLS certificate automatically. For example, they may allow connections to a server when there is no server certificate, they may allow any certificate (instead of a certificate for the site you are trying to connect to), or allow expired certificates. This is an extremely common mistake ([*The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software*](https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf), by Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh, and Vitaly Shmatikov, 2012). If this is the case, you may be using a low-level TLS API instead of the API you should be using. + +🔔 Improper certificate validation is such a common cause of security vulnerabilities that it is 2021 CWE Top 25 #26 and2021 CWE Top 25 #26 and 2019 CWE Top 25 #25. It is identified as [CWE-295](https://cwe.mitre.org/data/definitions/295.html), *Improper Certificate Validation*. + +#### Ciphersuites + +TLS, as a protocol, combines many of the pieces we have discussed. At the beginning of communication, the two sides must negotiate to determine the set of algorithms (including key lengths) that will be used for its connection. This set of algorithms is called the *ciphersuite*. That means that, for security, it is important to have good default configurations and to have the software configured correctly when deploying it. + +If you are configuring an HTTPS site, a great place to get currently-recommended settings is [Mozilla’s](https://wiki.mozilla.org/Security/Server_Side_TLS) [*Security/Server Side TLS*](https://wiki.mozilla.org/Security/Server_Side_TLS)[site](https://wiki.mozilla.org/Security/Server_Side_TLS). A key decision for you to make is if you want the modern, intermediate, or old configuration: + +* Modern: Most secure, but a non-trivial number of clients might not be able to connect to it. + +* Intermediate: A compromise setting that allows slightly older clients to connect while providing reasonably good security. + +* Old: A setting that provides the best possible security that supports much older clients and libraries. Its security is much weaker than intermediate. + +At the time of this writing, the *intermediate setting* is recommended in most cases, but check that website for updates. + +You will notice that any configuration has a list of TLS ciphersuites in order of preference. For example, the `TLS_AES_128_GCM_SHA256` means that TLS is to use the Advanced Encryption Standard (AES) with 128-bit key in Galois/Counter mode (GCM) combined with the secure hash algorithm with 256 bits (SHA-256). + +Once you have deployed your system, you should test it. If the site is publicly visible, it is a great idea to use the free Qualys test called the [SSL Server Test](https://www.ssllabs.com/ssltest/). It is called the SSL Server Test because that is the old name for TLS, but don’t be fooled, it works well with TLS (and will complain if you allow the vulnerable SSL protocols). + +#### Quiz 3.6: Transport Layer Security (TLS) + +\>\>Select the true statement(s):<< + +[!] If you are invoking a TLS library, it is reasonable to assume that it fully verifies the server’s TLS certificate automatically. {{ selected: Not so. Many libraries do *not* fully verify it, e.g., they might not verify that the certificate is appropriate for a given system. Some do, but when using a TLS library you have not used before, it is important to check what it verifies. }} + +[x] Web browsers use TLS or SSL when connecting to an external site with an “**https:**” URL. + +[x] When web browsers contact a server with TLS, they use a configurable set of certificate authority public keys (either included with the browser or provided via the operating system). + +[x] Recommended HTTPS server settings can be found at Mozilla’s “Security/Server Side TLS” site. + +### Other Topics in Cryptography + +#### Getting Cryptographic Advice + +In this course, we have tried to give some basics and enough information to apply them in various circumstances. Perhaps most important, however, are the key pieces of advice: do not create your own cryptographic algorithms or protocols, and do not create your own implementations. Instead, reuse well-respected algorithms, protocols, and implementations. When configuring cryptography, look for current well-respected advice. Examples of such sources include Mozilla’s [Security/Server Side TLS site](https://wiki.mozilla.org/Security/Server_Side_TLS), NIST (especially NIST’s [*Recommendation for Key Management: Part 1 - General*](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf)), and CISCO’s [*Next Generation Cryptography*](https://tools.cisco.com/security/center/resources/next_generation_cryptography). Cryptographers won’t always agree on what is “best” (as with any other field), but experts will be able to point out what is clearly broken and what is widely agreed to be much safer. + +#### Constant Time Algorithms + +There is an important topic that we have not mentioned yet: constant-time algorithms, especially constant-time comparisons. Many algorithms take a variable amount of time depending on their data. For example, if you want to determine if two arrays are equal, usually that comparison would stop on the first unequal value. + +Those who develop cryptographic libraries must implement their algorithms so that the time they take does not vary based on their input data (this is non-trivial, though possible, with AES). Most developers are never taught how to do this, so this is one of many reasons you should not write your own cryptographic library. However, there is a variation that can often happen outside of these libraries: sometimes you have to handle array comparisons specially. + +The normal comparison operations (such as **is-equal**) try to minimize execution time, and this can sometimes leak timing information about the values to attackers. If an attacker could repeatedly send in data and notice that a comparison of a value beginning with “0” takes longer than one that does not, then the first value it is compared to must be “0”. The attacker can then repeatedly guess the second digit, then the third, and so on. Many developers incorrectly believe that it is not possible for attackers to exploit timing variations over a network; this is a false belief attackers love to exploit. Modern statistics turns out to be remarkably powerful for removing latency variances; attackers really *can* exploit these latencies. + +*Constant-time comparisons*, also called *fixed-time comparisons*, are comparisons (usually equality) that avoid leaking this timing information. These comparisons always take the same time based purely on the length of the data, and do *not* take shorter times for different data values of the same length. These are not the same as O(1) operations in computer science. Examples of these constant-time comparison functions are: + +* Node.js: [`crypto.timingSafeEqual`](https://nodejs.org/api/crypto.html#cryptotimingsafeequala-b) + +* Ruby on Rails: [`ActiveSupport::SecurityUtils`](https://api.rubyonrails.org/classes/ActiveSupport/SecurityUtils.html) methods `secure_compare` and `fixed_length_secure_compare` + +* Java: [`MessageDigest.isEqual`](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/MessageDigest.html#isEqual(byte%5B%5D,byte%5B%5D)), assuming you are not using an ancient version of Java. Users of Google Guava can also use [`HashCode::equals`](https://github.com/google/guava/blob/master/guava/src/com/google/common/hash/HashCode.java#L371) + +* C#/.NET: [`CryptographicOperations.FixedTimeEquals`](https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.cryptographicoperations.fixedtimeequals?view=netcore-2.1) + +* C/OpenSSL: [`CRYPTO_memcmp`](https://docs.openssl.org/master/man3/CRYPTO_memcmp/) + +Whenever you compare secret values or cryptographic values (such as session keys), use a *constant-time comparison* instead of a normal comparison unless an attacker cannot exploit the normal comparison timing. You don’t need to do this with an iterated salted hash computed in a trusted environment (such as your server), because it will take an attacker too much time to create the matching values. You *do* need to do this if you are directly comparing session keys to a stored value, since attackers *can* sometimes iterate this to figure out each digit in the session key. + +#### Minimizing the Time Keys/Decrypted Data Exists + +Remember that per least privilege, we want to minimize the time a privilege is active. In cryptography, you often want to minimize the time a private key or password is available, or at least minimize the time that the decrypted data is available. This can be harder that you might think. At the operating system level you can probably lock it into memory with **mlock()** or **VirtualLock()**; this will at least prevent the data from being copied into storage. Ideally, you would erase it from memory after use using interfaces that are safe for that purpose. Compiler optimizers may quietly eliminate the code to overwrite data, because they detect that nothing else in the program reads the overwritten values. In addition, languages with built-in garbage collection often quietly make extra copies and/or do not provide a mechanism for erasure. That said, some languages or infrastructure do make this easy. For example, those using the .NET framework (e.g., C#) can use SecureString. The following interfaces in C and C++ are safer for overwriting sensitive data in memory. + +* Linux: **explicit_bzero** + +* Windows: **SecureZeroMemory** + +#### Quantum Computing + +One of the large future unknowns in cryptography is the potential impact of general-purpose quantum computers. At the time of this writing, so-called *general-purpose* quantum computers exist, but they are not powerful enough to threaten current cryptographic algorithms. It is not known if such more powerful general-purpose quantum computers can be built, and if so, when that will happen. + +If powerful general-purpose quantum computers are built, they have the potential to break all the historically popular public-key algorithms using an algorithm called *Shor’s algorithm*. As a result, researchers are developing new public-key algorithms that resist attacks from such quantum computers, an area called *post-quantum cryptography*. At the time of this writing, many such algorithms have been developed and are being evaluated. + +In contrast, current symmetric cryptographic algorithms and hash functions are less affected by quantum computers. A quantum computer algorithm called *Grover’s algorithm* speeds up attacks against symmetric ciphers, halving their effective key bit length. That means that 128-bit AES could be broken by a quantum computer (because it would then be equivalent to a 64-bit key today), but 256-bit AES would still be secure (because it would be equivalent to a 128-bit key today). So simply using longer keys and hashes is generally expected to be adequate in a post-quantum world for symmetric cryptographic algorithms and hash functions. + +So be prepared to change any public key algorithms to resist quantum computing, and ensure that key lengths are long enough when using symmetric and hash cryptographic algorithms. Some large organizations record vast amounts of Internet traffic for later decryption [[European Parliament 2001](https://irp.fas.org/program/process/rapport_echelon_en.pdf)], so if your users are at risk from data capture and decryption years later, you should consider implementing countermeasures now against quantum computing. + +Unfortunately, creating radically new cryptographic algorithms is difficult and risky. About half of all post-quantum cryptography algorithms in NIST's competition have been found to not meet their claimed security levels. One of the leading contenders for post-quantum cryptography was SIKE (Supersingular Isogeny Key Encapsulation), but in 2022 it was discovered that SIKE could be broken by ordinary non-quantum computers [[Goodin 2022](https://arstechnica.com/information-technology/2022/08/sike-once-a-post-quantum-encryption-contender-is-koed-in-nist-smackdown/)]. Thus, if you're adding a post-quantum cryptographic algorithm, be sure to also keep a pre-quantum layer so that if a break is found in the post-quantum algorithm you are still secure from attacks by traditional computers. This approach of combining algorithms is called a "hybrid" system. Hybrid systems add a little more complexity (because you're using two algorithms), but they help counter the significant risk of failure in these newer post-quantum algorithms. [[Bernstein 2024](https://blog.cr.yp.to/20240102-hybrid.html)] + +#### Humility Is Important in Cryptography + +Perhaps the most important lesson here is to be humble when using cryptography. Many cryptographic algorithms have been developed in the past, only to be broken later. It is hubris to think that our current algorithms and protocols cannot be broken. + +You should instead have a plan for handling when (not if) your cryptographic algorithms and protocols are broken. Make sure all your co-developers learn of this plan so that they will not ruin it (e.g., if you run an OSS project, put this in the **CONTRIBUTING.md** or equivalent file). In short, plan for change. + +Similarly, seek advice from experts, and weigh that advice carefully. Errors in cryptographic systems can be devastating, and can last for many years because they are not obvious. Getting others’ review and constructive feedback is generally a good idea, but it is especially important when using cryptography. + +#### Quiz 3.7: Other Topics in Cryptography + +\>\>Select the true statement(s):<< + +[!] Attackers cannot detect latency within an equality check over a network. + +[x] Where practical, you should minimize the time that normally-encrypted data is decrypted. + +[ ] If powerful “general-purpose” quantum computers are developed, they will render all encryption algorithms useless. {{ selected: No. Such computers will render useless common *public-key* algorithms that are popular in 2020. However, while they will halve the effective bit length of symmetric encryption algorithms, they will not render them useless; a 256-bit key for a symmetric encryption algorithm will effectively become a 128-bit key, which is still adequately secure for most purposes. In addition, new public-key algorithms are being developed that resist attacks from such quantum computers. }} + +# Other Topics + +> 🎥 This chapter describes topics on the fundamentals of developing secure software that have not been covered elsewhere, including handling vulnerability disclosures, assurance cases, the basics after development, formal methods, and top vulnerability lists. + +Learning objectives: + +1. Understand how to properly handle vulnerability disclosures. + +2. Discuss the basics of assurance cases. + +3. Discuss the basics beyond development: distributing, fielding/deploying, operations, and disposal. + +4. Get a brief introduction about formal methods. + +5. Take a look at top vulnerability lists (e.g., OWASP Top 10 and CWE Top 25). + +## Vulnerability Disclosures + +### Receiving Vulnerability Reports + +Unfortunately, even after your best efforts, someone may find a vulnerability in the software you have developed. In this unit, we will discuss receiving vulnerability reports, including how to prepare to receive vulnerability reports *before* vulnerabilities are found. + +#### Product Security Incident Response Teams (PSIRTs) + +If you are part of a team developing a large software application within a single organization, then you probably have or should consider forming a group to address security incidents related to that software. Such teams are sometimes called a Product Security Incident Response Team (PSIRT). The nonprofit Forum of Incident Response and Security Teams (FIRST) defines a PSIRT as *“an entity within an organization which... focuses on the identification, assessment and disposition of the risks associated with security vulnerabilities within the products, including offerings, solutions, components and/or services which an organization produces and/or sells”* ([FIRST](https://www.first.org/standards/frameworks/): *Product Security Incident Response Team (PSIRT) Services Framework* and *Computer Security Incident Response Team (CSIRT) Services Framework*). FIRST recommends that PSIRTs be formed while requirements are still being developed, but they should at least be formed before the initial release of the software. A properly-running PSIRT can identify and rapidly respond to an extremely serious vulnerability report. + +PSIRTs often work with computer incident response teams (CSIRTs); a CSIRT is focused on the security of computer systems and/or networks that make up the infrastructure of an entire organization, while PSIRTs focus on specific products/services. Should you have one (or want to establish one), FIRST provides useful frameworks describing what PSIRTs and CSIRTs should do within an organization ([FIRST Services Framework](https://www.first.org/standards/frameworks/)). + +Many governments and large companies also have their own requirements and guidelines for how to handle vulnerability reports. If your project is one of their efforts, you will need to follow those requirements and consider its guidelines. + +A simple short guide is the [OWASP Vulnerability Disclosure Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html). This short document provides useful guidance for both security researchers (who find security vulnerabilities) and organizations (who receive vulnerability reports). + +There are many other useful documents that discuss vulnerability disclosure. In particular: + +* [*The CERT Guide to Coordinated Vulnerability Disclosure*](https://vuls.cert.org/confluence/display/CVD/The+CERT+Guide+to+Coordinated+Vulnerability+Disclosure), by Allen Householder, 2019. In that document the “vendor” is the organization that releases the software and needs to learn about the security vulnerability. + +* FIRST’s [*Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure*](https://www.first.org/global/sigs/vulnerability-coordination/multiparty/guidelines-v1.1) [https://www.first.org/global/sigs/vulnerability-coordination/multiparty/guidelines-v1.1](https://www.first.org/global/sigs/vulnerability-coordination/multiparty/guidelines-v1.1) + +The Open Source Security Foundation (OpenSSF) [Vulnerability Disclosures Working Group](https://github.com/ossf/wg-vulnerability-disclosures) +has developed a [Guide to coordinated vulnerability disclosure for open source software projects](https://github.com/ossf/oss-vulnerability-guide). If you maintain an OSS project, apply that guide so you’ll be prepared for vulnerability reports before they happen. + + +In the rest of this unit we will discuss some of the key issues for accepting vulnerability reports. + +#### Publicly State How to Send Vulnerability Reports + +You must tell others, publicly, how to send vulnerability reports… and this information must be extremely easy to find. Otherwise, potential reporters will not report vulnerabilities to you, or there may be a significant delay while the project tries to figure out how to receive a report. This is time wasted where time is often of the essence. In 2019, failure to publicly state how to send vulnerability reports was the #1 most common reason OSS projects did not earn the OpenSSF Best Practices *passing* badge ([*Core Infrastructure Initiative (CII) Best Practices Badge in 2019*](https://events19.linuxfoundation.org/wp-content/uploads/2018/07/cii-bp-badge-2019-03.pdf), by David A. Wheeler). + +In one sense this requirement is easy. Decide what your reporting convention is, and make that information easy to find. Here are some common conventions: + +1. Many companies and projects support an email address of the form **security@example.com** or **abuse@example.com**. + +2. A common convention in OSS projects is to provide this information in a file named **SECURITY.md** in the repository’s root or **docs/** directory. Sites such as GitHub will highlight this file if present and encourage their creation. Add a link from your **README.md** file to this **SECURITY.md** file. + +3. If the project has or implements a website, a common recommendation is to add a **security.txt** file on the website at **/security.txt** or **/.well-known/security.txt**. To learn more, visit [securitytxt.org](https://securitytxt.org/). + +4. GitHub provides a new type of issue tracking that projects can enable for [privately reporting a security vulnerability](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability). Other source code management platforms have similar capabilities. When used, typically the **SECURITY.md** file will tell reporters to use it. + +One challenge is that attackers are also very interested in getting vulnerability reports, because they want to exploit those vulnerabilities until everyone installs its fixes or mitigations. So, it is usually important to have some mechanism for reporting vulnerabilities that prevents attackers from also getting this information before a patch is distributed. This can sometimes be hard to do: + +1. Email systems are generally not end-to-end encrypted. Email systems that support end-to-end encryption (e.g., OpenPGP and S/MIME) are not widely used, may be hard to use, and/or are primarily used only within specific communities. + +2. Many other communication systems for 1-on-1 secure communication expect that the parties already know each other, which is often not the case in vulnerability reporting. + +3. OSS projects generally work in the open, so normal reporting and discussion forums (such as issue trackers, chat systems, etc.) may allow many people (or everyone) to see the discussion about a vulnerability, even if it is not supposed to be publicly known. + +If you don’t want attackers to immediately exploit vulnerabilities reported to you, you should use some sort of encryption for the initial report. One imperfect but useful solution is to use email systems that support STARTTLS. Most large email providers (like GMail) and many companies support STARTTLS. STARTTLS provides *transport layer encryption*, that is, the emails are encrypted *between* email relays. Transport layer encryption is not as secure as end-to-end encryption, because the emails are decrypted at various points. In addition, STARTTLS is often deployed as *opportunistic TLS* - meaning an active attacker who controls certain network routers or email relays may be able to disable this encryption for a period of time. That said, using email providers who support STARTTLS transparently provides protection from many of the most common kinds of attacks on communication, while being very easy to use. + +You should also use encryption to communicate among the key developers if you don’t want attackers to know about what is going on. However, the developers often know each other, so this is usually much easier to accomplish. + +#### Monitor for Vulnerabilities, Including Vulnerable Dependencies + +As we have already mentioned, monitor for vulnerabilities about your software and all libraries embedded in it. You can use Google alerts to alert you about your software from various news sources. Use a software composition analysis (SCA) / origin analysis tool to alert you about newly-found publicly-known vulnerabilities in your dependencies. + +As noted earlier, a software bill of materials (SBOM) is a nested inventory that identifies the software components that make up a larger piece of software. When an SBOM is available for a component you are using, it’s often easier to use that data to help detect known vulnerabilities. Many ecosystems have ecosystem-specific SBOM formats. There are also some SBOM formats that support arbitrary ecosystems: [Software Package Data Exchange (SPDX)](https://spdx.dev/), [Software ID (SWID)](https://csrc.nist.gov/Projects/Software-Identification-SWID/), and [CycloneDX](https://github.com/CycloneDX/specification). + +#### Consider Creating a Bug Bounty Program + +A widely-used technique to encourage vulnerability reporting is a *bug bounty program*, where you pay reporters to report about especially important defects. This can be a cost-effective way to encourage people to report vulnerabilities to you once all relatively “easy-to-find” vulnerabilities have been found and fixed. If you don’t want to manage such a program yourself, there are various companies that can do that for you for a fee. + +Be sure to clearly establish the scope and terms of any bug bounty programs ([OWASP Vulnerability Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)). Specify what you will pay for, including a minimum and maximum range. For example, *“$X-$Y for a vulnerability that directly leads to a remote code execution without requiring login credentials.”* If there is a maximum that you can spend in a year, say so, and indicate the total amount, the calendar used, and what will happen to reports after the annual funding is used up. Also make it clear who is ineligible, e.g., developers of the software and/or employees of companies that develop the software. + +However, beware: a bug bounty program can be an incredible waste of money unless the easy to find vulnerabilities are found and fixed first. As Katie Moussouris has noted, *“Not all bugs are created equal"*; many defects (such as most XSS defects) are easy to detect and fix, and *“you should be finding those bugs easily yourselves too.”* Using a bug bounty program to find easy-to-find vulnerabilities is extremely costly and *“is not appropriate risk management.”* She even noted a case where a company ended up paying a security researcher $29,000/hour to find simple well-known defects. Find and fix the simple bugs first, and *then* a bug bounty program may make sense ([*Relying on bug bounties ‘not appropriate risk management’: Katie Moussouris*](https://www.zdnet.com/article/relying-on-bug-bounties-not-appropriate-risk-management-katie-moussouris/), by Stilgherrian, 2019). + +### Respond To and Fix the Vulnerability in a Timely Way + +Of course, once a vulnerability report is received, it must be responded to and fixed in a timely way. OWASP recommends the following ([OWASP Vulnerability Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)): + +* Respond to reports in a reasonable timeline. + +* Communicate openly with researchers. + +* [Do] not threaten legal action against researchers. + +You need to be able to quickly triage vulnerability reports; some reports won’t apply to your software or are not really vulnerabilities. It is quite common to need to ask further questions to really understand the vulnerability. + +#### Fixing the Vulnerability + +Once you have determined that it really is a vulnerability, you will need to fix it. + +If you want to be able to discuss reports in a constrained group - and most groups do - you should set that up ahead of time. + +Ensure that you can quickly stand up a working test environment for any supported version and environment of the software. So make sure you have good version control of the source code, and also ensure that you can quickly stand up the development and test environments. + +When fixing a security vulnerability, check to see if the same kind of vulnerability exists in similar situations in the software. If they do, fix those as well. Also, where practical, consider making changes to prevent recurrence of this kind of vulnerability. + +If your update causes problems, people will reject it and learn to not accept any future updates from you. Any proposed fix must avoid backwards incompatibilities if at all possible. It must also be of high quality. This implies that you need to have a strong *automated* test suite before you release the software, and have any needed hardware to execute it (if the tests need special hardware). Add automated tests related to what you are changing, both to ensure that it really fixes the problem and also to verify that the change does not negatively affect anything else. + + + +**Worst Thing That Could Happen**, retrieved from [xkcd.com](https://xkcd.com/2261/), licensed under [CC-BY-NC-2.5](https://creativecommons.org/licenses/by-nc/2.5/) + +#### Limiting Disclosure and the FIRST Traffic Light Protocol (TLP) + +When discussing a vulnerability, it is often important to discuss detailed information, yet simultaneously tell people to limit disclosure of some information for a period of time. In addition, it has become common for there to be multiple different parties involved in a vulnerability: there may be multiple suppliers (including vendors) who implement software with the vulnerability, distributors, and organizations involved in distributing information about the vulnerability. + +FIRST developed a simple marking system for this called the [Traffic Light Protocol](https://www.first.org/tlp/) (TLP) that is often used to indicate to whom the information can be shared. Here is a brief summary. The TLP has four color values to indicate sharing boundaries, which are placed as follows: + +1. In email: the TLP color is in the subject line and also in the body before the designated information. + +2. In documents: the TLP color is in the header and footer of each page, typically right-justified. + +The TLP color is shown in all-caps after “**TLP:**”, so you will see **TLP:RED**, **TLP:AMBER**, **TLP:GREEN**, or **TLP:WHITE**. These colors have the following meaning: + +* **TLP:RED** = Not for disclosure, restricted to participants only. + +* **TLP:AMBER** = Limited disclosure, restricted to participants’ organizations. + +* **TLP:GREEN** = Limited disclosure, restricted to the community. + +* **TLP:WHITE** = Disclosure is not limited. + + + +#### Get a CVE and Compute CVSS + +You should request a CVE where appropriate and it has not already been requested ([OWASP Vulnerability Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)). Typically, you would start this process once you have verified that the report really is a vulnerability, and thus you would do it simultaneously with fixing it. If you request a CVE, you should also calculate the vulnerability’s Common Vulnerability Scoring System (CVSS) score. CVSS is a rough estimate of a vulnerability’s severity. + +The reason for CVEs and CVSS is simple: organizations are overwhelmed with software updates, and they need information to help them prioritize updates. CVE and CVSS are not perfect, but they are widely used and depended on. The Ponemon Institute’s [*Costs and Consequences of Gaps in Vulnerability Responses*](https://www.servicenow.com/lpayr/ponemon-vulnerability-survey.html) (2019) survey found that: + +* *“Almost half of respondents (48%) report that their organizations had one or more data breaches in the past two years.”* + +* *“60% of breach victims said they were breached due to [a] known vulnerability where the patch was not applied”* + +* *“CVSS scoring… is often the only metric of patch prioritization [even though it] leaves out asset criticality and systems as part of vulnerability response.”* + +* *“44% of respondents say their organizations use automation to assist with vulnerability management and patching [(primarily prioritization and patching)]”* + +* *“Automation reduces the time to respond to vulnerabilities… 80% of organizations… that use automation say they have the ability to respond to vulnerabilities in a shorter timeframe.”* However, this automation depends on a variety of factors, including (in most cases) having a CVE assigned when there is a vulnerability. + +CVSS is widely used, because there is a need for clear prioritization, but CVSS is also widely criticized (for example, [*Broken vulnerabilities severities*](https://opensourcesecurity.io/2020/05/27/broken-vulnerability-severities/), by Josh Bressers, 2020). A new version of CVSS (beyond version 3), or a replacement for it, may be developed and/or become widely used in the future. + +#### Release the Update and Tell the World + +Once the fix is ready, release it. You will need to tell the world the software is fixed, and do all you can to encourage rapid uptake of the fixed version. OWASP recommends that suppliers publish clear security advisories and changelogs, and also that suppliers offer credit to the vulnerability finder ([OWASP Vulnerability Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)). + +If there are workarounds that can be applied without updating the software, be sure to note those. This is particularly important if: + +* there are likely to be many users who cannot update their software, or + +* the vulnerability is publicly known, but the patch will not be released for some time. + +Ensure that it is easy to automatically update to the fixed version of the software. If your software platform does not provide automated patch releases or installation, consider implementing one yourself. Users need to be able to quickly and automatically receive fixes, unless they have expressly opted out of updates. + +Be sure to always credit and thank vulnerability reporters, unless they request otherwise. It is rude to not provide credit, and many vulnerability reporters provide reports *primarily* to get credit. What is worse, reporters may be less cooperative in the future if they do not receive appropriate credit. + +#### Quiz 4.1: Respond To and Fix the Vulnerability in a Timely Way + +\>\>What is the meaning of **TLP:RED**?<< + +(!x) Not for disclosure, restricted to participants only. + +( ) Limited disclosure, restricted to participants’ organizations. + +( ) Limited disclosure, restricted to the community. + +( ) Disclosure is not limited. + +### Sending Vulnerability Reports to Others + +Once you have completed this course, you are far more likely to be able to detect vulnerabilities in software. In this unit, we will discuss how to send vulnerability reports to others. + +The [OWASP Vulnerability Disclosure Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html) recommends that security researchers (who find security vulnerabilities) should: + +* Ensure that any testing is legal and authorized. + +* Respect the privacy of others. + +* Make reasonable efforts to contact the security team of the organization. + +* Provide sufficient details to allow the vulnerabilities to be verified and reproduced. + +* Not demand payment or rewards for reporting vulnerabilities outside of an established bug bounty program. + +Reporting a vulnerability that you have found can be surprisingly complicated. If there is a single supplier, you could report to just that supplier. But sometimes there are multiple suppliers and other stakeholders involved. There are also various ways you can choose to report a vulnerability. + +#### Reporting Models + +There are several different kinds of disclosure models: + +1. **Private Disclosure**
*“In the private disclosure model, the vulnerability is reported privately to the organisation. The organisation may choose to publish the details of the vulnerabilities, but this is done at the discretion of the organisation, not the researcher, meaning that many vulnerabilities may never be made public. The majority of bug bounty programs require that the researcher follows this model. The main problem with this model is that if the vendor is unresponsive, or decides not to fix the vulnerability, then the details may never be made public. Historically this has led to researchers getting fed up with companies ignoring and trying to hide vulnerabilities, leading them to the full disclosure approach.”* ([OWASP Vulnerability Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)) + +2. **Full Disclosure**
*“With the full disclosure approach, the full details of the vulnerability are made public as soon as they are identified. This means that the full details (sometimes including exploit code) are available to attackers, often before a patch is available. The full disclosure approach is primarily used in response to organizations ignoring reported vulnerabilities, in order to put pressure on them to develop and publish a fix. This makes the full disclosure approach very controversial, and it is seen as irresponsible by many people. Generally it should only be considered as a last resort, when all other methods have failed, or when exploit code is already publicly available”* ([OWASP Vulnerability Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)). Another reason to consider full disclosure is if there is reason to believe that the supplier is intentionally malicious; reporting a vulnerability to only a malicious supplier gives the malicious supplier more time to exploit the vulnerability. + +3. **Coordinated Disclosure (historically called Responsible Disclosure)**
Coordinated disclosure *“attempts to find a reasonable middle ground between these two approaches. … the initial report is made privately, but with the full details being published once a patch has been made available (sometimes with a delay to allow more time for the patches to be installed).”* ([OWASP Vulnerability Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)). Historically, this has been called *responsible disclosure*, but this is a biased term, and its original coiner now recommends calling it coordinated disclosure instead. It is **important** that there is a **time limit** before the vulnerability will be unilaterally disclosed. Without a time limit this is essentially identical to private disclosure, since the supplier may have little incentive to fix the vulnerability. + +4. **Disclosure to Attackers**
Some researchers work for organizations who attack others’ systems. Other researchers sell vulnerabilities to such organizations, or to brokers who then sell the vulnerabilities on. Doing this is controversial, especially when they are sold to brokers who do not clearly disclose exactly who is buying the vulnerabilities. The impact of doing this varies, because there is great variety in organizations who pay for vulnerabilities. These organizations include law enforcement in various countries, militaries in various countries, organized crime, and/or terrorist groups. Anyone who provides vulnerabilities to attackers should consider the ethical implications. In particular, you should consider what the attackers are likely to do with these vulnerabilities. Do you have confidence that the attackers will not use the vulnerabilities in contravention of human rights? Will they harm certain people or groups such as ethnic minorities, political dissidents, or journalists? If you disclose vulnerabilities to attackers, then you are supporting how these organizations will use those vulnerabilities to attack others; you should be confident that they will use them for good. + +From here on we will presume that you follow a *coordinated disclosure model* with some limited timeframe. + +Coordinated disclosure time limits (aka *embargo periods*) vary greatly. This time limit is the amount of time between when a reporter reports the vulnerability to the supplier and the reporter will unilaterally disclose it to the public. In general, suppliers push for longer time limits or no time limits, often because that will lower their costs (possibly to nothing if the supplier can get the time limit extended so the supplier never needs to fix the vulnerability). Organizations charged with protecting the public and multi-party organizations tend to press for shorter time limits. Some vulnerabilities are easier to fix than others, which makes simple numbers difficult to choose. Here are some examples of public disclosure time limits: + +* [linux-distros](https://oss-security.openwall.org/wiki/mailing-lists/distros): less than 7 days preferred, up to 14 days allowed, up to 19 days if Thu/Fri report & disclosure on Mon/Tue + +* [oCERT](http://ocert.org/): 14 days standard; 7 days if trivial, 30 days if critical/complex, up to 2 months “extremely exceptional” + +* [CERT/CC](https://www.cert.org/vulnerability-analysis/vul-disclosure.cfm): 45 days “regardless of the existence… of patches or workarounds… Extenuating circumstances … may result in earlier or later disclosure... We will not distribute exploits” + +* [Google Project Zero](https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html): 90 days. + +#### Further Information + +A good source for more information is FIRST’s “[Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure](https://www.first.org/global/sigs/vulnerability-coordination/multiparty/guidelines-v1.1)”. Historically many documents have focused on simple bi-lateral coordination between a security researcher and a software supplier, but today there are often complexities due to the need for multi-party coordination. This FIRST document discusses these more complex situations, and provides guidelines for addressing them. + +## Miscellaneous + +### Assurance Cases + +Sadly, you cannot just do one thing and make a system secure. Instead, you need to do a variety of things. Tracking the various techniques you need to do, to ensure that you are really addressing everything you think you should, can become overwhelming… especially if your software gets large or there are expectations of strong security. In addition, sometimes potential stakeholders (such as users) want to understand what you are doing in order to determine if you are doing enough for their purposes. An unstructured list of “*things that were done*” does not really help when a system gets larger; you might do many things, but fail to address something important. + +A practical alternative is creating an *assurance case*. An assurance case *“includes a top-level claim for a property of a system or product (or set of claims), systematic argumentation regarding this claim, and the evidence and explicit assumptions that underlie this argumentation”* ([ISO/IEC 15026-2:2011](https://www.iso.org/standard/52926.html)). Let’s look at that definition; put another way, an assurance case includes: + +* Claim(s): Top-level claim(s) for a property of a system or product. That is, something that you want to be true. + +* Arguments: A systematic argumentation justifying this claim. + +* Evidence/assumptions: Evidence and explicit assumptions underlying the argument. + +The point of an assurance case is that it is *systematic*. In other words, you should start with whatever claim(s) you want to make that are important, and repeatedly break that down to show that the claim is true. Imagine that you are a lawyer trying to make a case to a skeptical jury; your job is to justify that the claim(s) are true. Creating an assurance case helps you determine and justify to people that the software is secure, both to others and yourself. + +An assurance case does not have to be in any particular form. However, they are often documents with figures showing the high-level structure, and text providing the details. That is simply because it is easy to glance at the figures to see how things work together, but the text provides the details to really understand things. + +Let’s talk about one way to create an assurance case, based on material from [*A Sample Security Assurance Case Pattern*](https://www.ida.org/-/media/feature/publications/a/as/a-sample-security-assurance-case-pattern/p-9278.ashx) by David A. Wheeler (2018). Let’s say that we have an overall claim: we want to claim that our “system is adequately secure against moderate threats”. Let’s argue that we can provide adequate proof of this if our security requirements are identified and met by its functionality, and that security is implemented by system life cycle processes. We can break down the security requirements further into our security requirement triad (confidentiality, integrity, and availability), properly handling access control, and identifying and addressing the assets and threat actors. Here is a figure that shows the top level of an assurance case: + + + +**Sample top level of an assurance case**, by David A. Wheeler (2018) + +We could then repeatedly break each item down further. For example, we might divide the lifecycle processes into areas like design, implementation, and verification. We could then explain how we address security in each: + +* For design, we might show that we followed all the Saltzer & Schroeder (S&S) design principles we have already discussed. + +* For implementation, we might show that we countered all the “top” vulnerabilities identified by some widely-accepted and relevant list of top vulnerabilities. + +* For verification, we might show that we use a variety of tools to detect vulnerabilities before the software is released. + +For a detailed discussion and template for creating an assurance case, see [*A Sample Security Assurance Case Pattern*](https://www.ida.org/-/media/feature/publications/a/as/a-sample-security-assurance-case-pattern/p-9278.ashx) by David A. Wheeler (2018). If you would like to see an actual example, you can see the [OpenSSF Best Practices BadgeApp assurance case](https://github.com/coreinfrastructure/best-practices-badge/blob/main/docs/assurance-case.md). + +When do you end? The usual answer is when the stakeholders agree that it is enough. If they don’t think it is enough, then ask them what would be enough and if they are willing to pay for those changes. If they are not paying you enough, then you don’t need to do it. + +What is great about an assurance case is that if someone later wants to know “is this software adequately secure”, they can simply review the assurance case. Simply *having* an assurance case provides a lot of confidence, because it shows that someone thought through what the system is supposed to do and has a reasonable argument (with evidence) that the claims are correct. + +#### Quiz 4.2: Assurance Cases + +\>\>Select the true statement(s):<< + +[!x] A claim describes an important property that you want to be true for a system or product + +[x] An assurance case should repeatedly break down a claim until you can show that it is true by showing that each part is true. + +[x] In principle, an assurance case is repeatedly drilled down until the stakeholders agree that enough has been done (e.g., because they are unwilling to pay for more). + +### Harden the Development Environment (Including Build and CI/CD Pipeline) & Distribution Environment + +Most attacks occur when a system is deployed, but increasingly attackers are attacking systems during their development and distribution. For our purposes, the “development environment” includes the set of all machines and other infrastructure used to develop the software, including each developer’s systems, version control system(s), build systems, CI/CD pipelines, and so on. The “distribution environment” is the environment used to distribute the resulting built software, e.g., package registries/repositories, container registries/repositories, and so on. It’s important to secure the development environment and distribution environment against unauthorized access or compromise. This includes protecting them against the insertion of malicious code. Assume that attackers are attempting to subvert any system used for software development or distribution, especially any shared systems. + +First, minimize privileges. Limit who can control these environments, and by how much. If someone leaves a project and/or organization, remove their privileges; even if they wouldn’t attack, an attacker might acquire their credentials. Limit the privileges given the environments, for example, if a CI/CD pipeline is given an authentication token, provide a token with the minimum privileges necessary so that if the token is exposed the damage is reduced. If a token is only needed in some cases (such as only when processing certain branches like “main”), only provide the token in those cases. + +One simple approach is to have developers use multi-factor authentication (MFA) tokens (aka keys) when accessing development environments. These are hardware devices that prove that the developer possesses the device, and since they are single-purpose they are hard for attackers to subvert. If you must use passwords, ensure they are long and not shared between people. + +Consider using “branch protection” or similar, if your version control system supports it, to restrict operations that can occur on certain branches (such as “main”). For example, you can ensure that a merge request/pull request has received human review and that it has passed automated checks before the proposed change can be accepted. Protected branches can also prevent dangerous operations such as force pushes, overwrites of commit histories, and similar changes. + +Where practical, harden the development environment and distribution environment so they are harder to attack. In many projects, many or all parts of these environments are hosted elsewhere (often in a cloud); make sure the hosting system you choose has adequate security. Once chosen, consult the documentation for the systems you use and configure them to maximize security, e.g., to minimize privileges granted to others. For example, if you use GitHub, look at the [GitHub documentation on securing your repository](https://docs.github.com/en/code-security/getting-started/securing-your-repository). If you have a GitLab installation, [look at the GitLab documentation on securing your installation (“security”)](https://docs.gitlab.com/ee/security/). + +The build process should be fully scripted/automated. That way builds will be performed predictably each time. Where possible, the build system should provide provenance information, that is, record what components were included in the build and ideally what components were used to perform the build. Be careful when logging a build process; often you want to avoid recording in log files any secrets like active authentication tokens. + +Build, verification, and distribution processes (including CI/CD pipelines) often bring in many other reusable software components. Make sure you apply the good practices discussed in the course sections on (1) [Selecting (Evaluating) Open Source Software](#selecting-evaluating-open-source-software) and (2) [Downloading and Installing Reusable Software](#downloading-and-installing-reusable-software). + +Supply chain Levels for Software Artifacts, or SLSA (“salsa”), is a security framework being developed as a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. At the time of this writing it is still in development, but you should consider its recommendations. SLSA is being developed under the Open Source Security Foundation (OpenSSF). To learn more, see the SLSA home page at
A formal specification is created (that is, mathematically-based techniques are used to rigorously describe what the program is supposed to do). The program is then informally developed from it. This is sometimes called *formal methods lite*. This approach can help remove some ambiguities. + +* **Level 1**
Apply level 0 and then prove some select properties from that or do a formal refinement from specification towards something that will become the program. + +* **Level 2**
Fully prove the claims of a program, including mechanically checking it. This provides the strongest results, but also requires the most effort. + +#### How Can Math Be Applied? + +There are many different ways to apply mathematics, and so there are many different ways to use formal methods. Let’s briefly look at a few common math concepts that are used in formal methods. + +##### Boolean Expressions + +A widely-used tool is the idea of boolean expressions. These expressions are true or false, and can include various *propositional connectives* (a proposition is simply something that is either true or false). Here are common propositional connectives. The first three should be very familiar to you, since programming languages copied them from mathematics, but their traditional mathematical notation might be new to you: + +1. “x and y” (mathematical “x ∧ y”) is true if both x and y are true, otherwise it is false. + +2. “x or y” (mathematical “x ∨ y”) is true if either or both x and y are true; if both are false it is false. + +3. “not x” (mathematical “￢x”) is true if x is false, and it is false if x is true. + +4. “x→y” is true if x is false *or* if y is true, that is, x → y is the same as ((not x) or y). The arrow is often read as “implies”. This operator may be new to you, but this arrow simply represents “if x is true then y is true”. It is formally called *material implication*. + +5. “x↔y” is true if x and y have the same value. This is basically “are these values equal” for boolean values. It is sometimes read as “if and only if” (iff). + +You may find it easier to understand the connectives by looking at the following table. This table shows the results of these connectives given the possible input values of x and y (in this table T is true while F is false): + +Propositional Connectives + +
| x | +y | +x ∧ y | +x ∨ y | +￢x | +x→y | +x↔y | +
|---|---|---|---|---|---|---|
| F | +F | +F | +F | +T | +T | +T | +
| F | +T | +F | +T | +T | +T | +F | +
| T | +F | +F | +T | +F | +F | +F | +
| T | +T | +T | +T | +F | +T | +T | +
These try to prove goals given assumptions using only a sequence of allowed rules. Some are fully automated while others are interactive. The interactive tools can handle harder problems but are generally harder to use. + + * Widely-used OSS automated theorem provers include E and SPASS. + + * Widely-used OSS interactive theorem provers include Coq and Isabelle. + +* *Satisfiability (SAT) solvers / SAT modulo theories (SMT)*
These take a bunch of equations with variables, and try to find a set of values for those variables that makes all equations true. SAT solvers only handle boolean variables and boolean equations, while SMT solvers can handle other values. Some package managers internally use a SAT solver. Widely-used OSS SMT solvers include Z3, CVC4, and Alt-Ergo-Free. + +* *Model-checkers*
These take a model and “exhaustively” show it is true in all cases, using many optimization tricks to make that practical. A widely-used OSS generic model checker is Spin (which supports a language called ProMeLa). There are also many model-checking tools specifically designed to analyze programs. For example, CBMC is an OSS bounded model checker for C and C++ programs that can verify memory safety, check for exceptions, check for various variants of undefined behavior, and supports user-specified assertions. + +* *Abstract interpretation / symbolic execution (for programs)*
These “execute” programs using relevant simplifications (abstract interpretation) or symbols (symbolic execution). + +There are some systems that can combine these tools. For example: + +* The Why3/Frama-C ecosystem combines a suite of tools for proving programs correct. + +* Temporal Logic of Actions+ (TLA+) is a general-purpose formal specification language that is particularly useful for describing concurrent and distributed systems, and has a variety of supporting tools. + +#### Formal Methods and the Future + +Today formal methods are only used in special circumstances, but they might become more prominent in the future. Our goal has been to simply make you aware of it, in case you decide that it might be worth pursuing further in the future. You cannot consider using an approach if you have never heard of it. + +#### Quiz 4.4: Formal Methods + +\>\>Select the true statement(s):<< + +[!x] The expression “∀ X foo” is true if *foo* is true no matter what the value of X is. + +[ ] Formal methods eliminate assumptions. {{ selected: Not at all. Any formal method has to start with some assumptions. }} + +[x] A Satisfiability (SAT) solver takes a bunch of boolean variables and boolean expressions, and tries to find a set of boolean variable values where all the boolean expressions are true. + +[x] A model-checker takes a model and tries to exhaustively show it’s true in all cases. + + + +## Top Vulnerability Lists + +### OWASP Top 10 + +We noted earlier that there are two widely-used lists of “top” vulnerabilities, the OWASP Top 10 (focusing on web application security risks) and the CWE Top 25. They identify what they perceive as the “top” items in terms of being especially common and especially dangerous. + +Their different scopes result in many differences. For example, the CWE Top 25 lists buffer overflows, while the OWASP Top 10 does not, because buffer overflows are a common serious problem in some domains (such as embedded systems) but they are not common in web applications. + +Here is the [*OWASP Top 10*](https://owasp.org/Top10/) (2021 edition) list of categories: + +1. Broken Access Control +2. Cryptographic Failures +3. Injection +4. Insecure Design +5. Security Misconfiguration +6. Vulnerable and Outdated Components +7. Identification and Authentication Failures +8. Software and Data Integrity Failures +9. Security Logging and Monitoring Failures +10. Server Side Request Forgery (SSRF) + + +In this course we have covered all of the OWASP Top 10, in both the [2017](https://owasp.org/www-project-top-ten/2017/Top_10) and [2021](https://owasp.org/Top10/) editions, and included cross-references when we did. + +#### Quiz 4.5: OWASP Top 10 + +\>\>Select the true statement(s):<< + +[!x] Injection is a risk listed in the 2021 OWASP Top 10. + +[x] Security Misconfiguration is a risk listed in the 2021 OWASP Top 10. + +[ ] Buffer overflows are in the 2021 OWASP Top 10. {{ selected: No, and it is understandable if you missed this. Buffer overflows are very common in embedded systems, because they are widely implemented in C and C++ which provide little protection against buffer overflows. Most web applications are written in other programming languages that protect against buffer overflows, and thus they have relatively rare in web applications. }} + +### CWE Top 25 + +Here is the 2021 edition of the [CWE Top 25 Most Dangerous Software Errors](https://cwe.mitre.org/top25/archive/2019/2019_cwe_top25.html). This list was created using real-world data, specifically, the publicly known vulnerabilities with Common Vulnerabilities and Exposures (CVE) as published in the National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD), including the severity scores as calculated using the Common Vulnerability Scoring System (CVSS) scores. This list combines many different kinds of software; whether or not that is good depends on your perspective. + +No system is perfect. A complication is that the CWEs identified here are at various hierarchical levels. For example, #17 [CWE-119](https://cwe.mitre.org/data/definitions/119.html) (*Improper Restriction of Operations within the Bounds of a Memory Buffer*) is a superset of both #3 [CWE-125](https://cwe.mitre.org/data/definitions/125.html) (*Out-of-bounds read*) and #1 [CWE-787](https://cwe.mitre.org/data/definitions/787.html) (*Out-of-bounds Write*), yet they are all listed here. Still, this does provide a defensible and repeatable approach for identifying what’s important. + +#### Top 25 + +
| Rank | +ID | +Name | +
| [1] | +CWE-787 | +Out-of-bounds Write | +
| [2] | +CWE-79 | +Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') | +
| [3] | +CWE-125 | +Out-of-bounds Read | +
| [4] | +CWE-20 | +Improper Input Validation | +
| [5] | +CWE-78 | +Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') | +
| [6] | +CWE-89 | +Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') | +
| [7] | +CWE-416 | +Use After Free | +
| [8] | +CWE-22 | +Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') | +
| [9] | +CWE-352 | +Cross-Site Request Forgery (CSRF) | +
| [10] | +CWE-434 | +Unrestricted Upload of File with Dangerous Type | +
| [11] | +CWE-306 | +Missing Authentication for Critical Function | +
| [12] | +CWE-190 | +Integer Overflow or Wraparound | +
| [13] | +CWE-502 | +Deserialization of Untrusted Data | +
| [14] | +CWE-287 | +Improper Authentication | +
| [15] | +CWE-476 | +NULL Pointer Dereference | +
| [16] | +CWE-798 | +Use of Hard-coded Credentials | +
| [17] | +CWE-119 | +Improper Restriction of Operations within the Bounds of a Memory Buffer | +
| [18] | +CWE-862 | +Missing Authorization | +
| [19] | +CWE-276 | +Incorrect Default Permissions | +
| [20] + | +CWE-200 | +Exposure of Sensitive Information to an Unauthorized Actor | +
| [21] | +CWE-522 | +Insufficiently Protected Credentials | +
| [22] | +CWE-732 | +Incorrect Permission Assignment for Critical Resource | +
| [23] | +CWE-611 | +Improper Restriction of XML External Entity Reference | +
| [24] | +CWE-918 | +Server-Side Request Forgery (SSRF) | +
| [25] | +CWE-77 | +Improper Neutralization of Special Elements used in a Command ('Command Injection') | +
| Rank | +ID | +Name | +
| [26] | +CWE-295 | +Improper Certificate Validation | +
| [27] | +CWE-400 | +Uncontrolled Resource Consumption | +
| [28] | +CWE-94 | +Improper Control of Generation of Code ('Code Injection') | +
| [29] | +CWE-269 | +Improper Privilege Management | +
| [30] | +CWE-917 | +Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') | +
| [31] | +CWE-59 | +Improper Link Resolution Before File Access ('Link Following') | +
| [32] | +CWE-401 | +Missing Release of Memory after Effective Lifetime | +
| [33] | +CWE-362 | +Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') | +
| [34] | +CWE-427 | +Uncontrolled Search Path Element | +
| [35] | +CWE-319 | +Cleartext Transmission of Sensitive Information | +
| [36] | +CWE-843 | +Access of Resource Using Incompatible Type ('Type Confusion') | +
| [37] | +CWE-601 | +URL Redirection to Untrusted Site ('Open Redirect') | +
| [38] | +CWE-863 | +Incorrect Authorization | +
| [39] | +CWE-532 | +Inclusion of Sensitive Information in Log Files | +
| [40] | +CWE-770 | +Allocation of Resources Without Limits or Throttling | +
| Rank | +ID | +Name | +
| [1] | +CWE-119 | +Improper Restriction of Operations within the Bounds of a Memory Buffer | +
| [2] | +CWE-79 | +Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) | +
| [3] | +CWE-20 | +Improper Input Validation | +
| [4] | +CWE-200 | +Information Exposure | +
| [5] | +CWE-125 | +Out-of-bounds Read | +
| [6] | +CWE-89 | +Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) | +
| [7] | +CWE-416 | +Use After Free | +
| [8] | +CWE-190 | +Integer Overflow or Wraparound | +
| [9] | +CWE-352 | +Cross-Site Request Forgery (CSRF) | +
| [10] | +CWE-22 | +Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’) | +
| [11] | +CWE-78 | +Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) | +
| [12] | +CWE-787 | +Out-of-bounds Write | +
| [13] | +CWE-287 | +Improper Authentication | +
| [14] | +CWE-476 | +NULL Pointer Dereference | +
| [15] | +CWE-732 | +Incorrect Permission Assignment for Critical Resource | +
| [16] | +CWE-434 | +Unrestricted Upload of File with Dangerous Type | +
| [17] | +CWE-611 | +Improper Restriction of XML External Entity Reference | +
| [18] | +CWE-94 | +Improper Control of Generation of Code (‘Code Injection’) | +
| [19] | +CWE-798 | +Use of Hard-coded Credentials | +
| [20] | +CWE-400 | +Uncontrolled Resource Consumption | +
| [21] | +CWE-772 | +Missing Release of Resource after Effective Lifetime (!) | +
| [22] | +CWE-426 | +Untrusted Search Path (!) | +
| [23] | +CWE-502 | +Deserialization of Untrusted Data | +
| [24] | +CWE-269 | +Improper Privilege Management | +
| [25] | +CWE-295 | +Improper Certificate Validation | +
| Rank | +ID | +Name | +
| [26] | +CWE-835 | +Loop with Unreachable Exit Condition (‘Infinite Loop’) (!) | +
| [27] | +CWE-522 | +Insufficiently Protected Credentials | +
| [28] | +CWE-704 | +Incorrect Type Conversion or Cast (!) | +
| [29] | +CWE-362 | +Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’) | +
| [30] | +CWE-918 | +Server-Side Request Forgery (SSRF) | +
| [31] | +CWE-415 | +Double Free (!) | +
| [32] | +CWE-601 | +URL Redirection to Untrusted Site (‘Open Redirect’) | +
| [33] | +CWE-863 | +Incorrect Authorization | +
| [34] | +CWE-862 | +Missing Authorization | +
| [35] | +CWE-532 | +Inclusion of Sensitive Information in Log Files | +
| [36] | +CWE-306 | +Missing Authentication for Critical Function | +
| [37] | +CWE-384 | +Session Fixation (!) | +
| [38] | +CWE-326 | +Inadequate Encryption Strength (!) | +
| [39] | +CWE-770 | +Allocation of Resources Without Limits or Throttling | +
| [40] | +CWE-617 | +Reachable Assertion (!) | +