diff --git a/5.0/en/0x02-Preface.md b/5.0/en/0x02-Preface.md index 1bb8656f0a..a36e062d53 100644 --- a/5.0/en/0x02-Preface.md +++ b/5.0/en/0x02-Preface.md @@ -12,11 +12,11 @@ We expect that there will most likely never be 100% agreement on the contents of ## What's new in 4.0 -The most significant change in this version is the adoption of the NIST SP 800-63-3 Digital Identity Guidelines, introducing modern, evidence based, and advanced authentication controls. Although we expect some pushback on aligning with an advanced authentication standard, we feel that it is essential for standards to be aligned, mainly when another well-regarded application security standard is evidence-based. +The most significant change in this version is the adoption of the NIST SP 800-63-3 Digital Identity Guidelines, introducing modern, evidence-based, and advanced authentication controls. Although we expect some pushback on aligning with an advanced authentication standard, we feel that it is essential for standards to be aligned, mainly when another well-regarded application security standard is evidence-based. -Information security standards should try to minimize the number of unique requirements, so that complying organizations do not have to decide on competing or incompatible controls. The OWASP Top 10 2017 and now the OWASP Application Security Verification Standard have now aligned with NIST SP 800-63 for authentication and session management. We encourage other standards-setting bodies to work with us, NIST, and others to come to a generally accepted set of application security controls to maximize security and minimize compliance costs. +Information security standards should try to minimize the number of unique requirements so that complying organizations do not have to decide on competing or incompatible controls. The OWASP Top 10 2017 and now the OWASP Application Security Verification Standard have aligned with NIST SP 800-63 for authentication and session management. We encourage other standards-setting bodies to collaborate with us, NIST, and others in establishing a generally accepted set of application security controls. This approach will maximize security while minimizing compliance costs. -ASVS 4.0 has been wholly renumbered from start to finish. The new numbering scheme allowed us to close up gaps from long-vanished chapters, and to allow us to segment longer chapters to minimize the number of controls that a developer or team has to comply. For example, if an application does not use JWT, the entire section on JWT in session management is not applicable. +ASVS 4.0 has been wholly renumbered from start to finish. The new numbering scheme allowed us to close up gaps from long-vanished chapters, and to allow us to segment longer chapters to minimize the number of controls that a developer or team has to comply with. For example, if an application does not use JWT, the entire section on JWT in session management is not applicable. New in 4.0 is a comprehensive mapping to the Common Weakness Enumeration (CWE), one of the most commonly desired feature requests we've had over the last decade. CWE mapping allows tool manufacturers and those using vulnerability management software to match up results from other tools and previous ASVS versions to 4.0 and later. To make room for the CWE entry, we've had to retire the "Since" column, which as we completely renumbered, makes less sense than in previous versions of the ASVS. Not every item in the ASVS has an associated CWE, and as CWE has a great deal of duplication, we've attempted to use the most commonly used rather than necessarily the closest match. Verification controls are not always mappable to equivalent weaknesses. We welcome ongoing discussions with the CWE community and information security field more generally on closing this gap. @@ -24,10 +24,10 @@ We have worked to comprehensively meet and exceed the requirements for addressin We set out to ensure that the ASVS 4.0 Level 1 is a comprehensive superset of PCI DSS 3.2.1 Sections 6.5, for application design, coding, testing, secure code reviews, and penetration tests. This necessitated covering buffer overflow and unsafe memory operations in V5, and unsafe memory-related compilation flags in V14, in addition to existing industry-leading application and web service verification requirements. -We have completed the shift of the ASVS from monolithic server-side only controls, to providing security controls for all modern applications and APIs. In the days of functional programming, server-less API, mobile, cloud, containers, CI/CD and DevSecOps, federation and more, we cannot continue to ignore modern application architecture. Modern applications are designed very differently from those built when the original ASVS was released in 2009. The ASVS must always look far into the future so that we provide sound advice for our primary audience - developers. We have clarified or dropped any requirement that assumes that applications are executed on systems owned by a single organization. +We have completed the shift of the ASVS from monolithic server-side-only controls, to providing security controls for all modern applications and APIs. In the days of functional programming, server-less API, mobile, cloud, containers, CI/CD and DevSecOps, federation and more, we cannot continue to ignore modern application architecture. Modern applications are designed very differently from those built when the original ASVS was released in 2009. The ASVS must always look far into the future so that we provide sound advice for our primary audience - developers. We have clarified or dropped any requirement that assumes that applications are executed on systems owned by a single organization. Due to the size of the ASVS 4.0, as well as our desire to become the baseline ASVS for all other ASVS efforts, we have retired the mobile chapter, in favor of the Mobile Application Security Verification Standard (MASVS). We have also retired the Internet of Things appendix, in favor of the IoT Security Verification Standard (ISVS). We thank both the OWASP Mobile Team and OWASP IoT Project Team for their support of the ASVS, and look forward to working with them in the future to provide complementary standards. -Lastly, we have de-duped and retired less impactful controls. Over time, the ASVS started being a comprehensive set of controls, but not all controls are equal at producing secure software. This effort to eliminate low impact items could go further. In a future edition of the ASVS, the Common Weakness Scoring System (CWSS) will help prioritize further those controls which are truly important and those that should be retired. +Lastly, we have de-duped and retired less impactful controls. Over time, the ASVS started being a comprehensive set of controls, but not all controls equally contribute to producing secure software. This effort to eliminate low-impact items could go further. In a future edition of the ASVS, the Common Weakness Scoring System (CWSS) will help prioritize further those controls that are truly important and those that should be retired. As of version 4.0, the ASVS will focus solely on being the leading web apps and service standard, covering traditional and modern application architecture, agile security practices and DevSecOps culture. diff --git a/5.0/en/0x03-Using-ASVS.md b/5.0/en/0x03-Using-ASVS.md index 21ec1077e8..3da7ccc41c 100644 --- a/5.0/en/0x03-Using-ASVS.md +++ b/5.0/en/0x03-Using-ASVS.md @@ -15,19 +15,19 @@ This chapter will talk about some of the key aspects of using the ASVS including The Application Security Verification Standard defines three security verification levels, with each level increasing in depth. -* ASVS Level 1 is for low assurance levels, and is completely penetration testable. +* ASVS Level 1 is for low assurance levels and is completely verifiable through penetration testing. * ASVS Level 2 is for applications that contain sensitive data, which requires protection and is the recommended level for most apps. -* ASVS Level 3 is for the most critical applications - applications that perform high value transactions, contain sensitive medical data, or any application that requires the highest level of trust. +* ASVS Level 3 is intended for the most critical applications, such as those handling high-value transactions, containing sensitive medical data, or any application demanding the highest level of trust. Each ASVS level contains a list of security requirements. Each of these requirements can also be mapped to security-specific features and capabilities that must be built into software by developers. -Level 1 is the only level that is completely penetration testable using humans. All others require access to documentation, source code, configuration, and the people involved in the development process. However, even if L1 allows "black box" (no documentation and no source) testing to occur, it is not an effective assurance activity and should be actively discouraged. Malicious attackers have a great deal of time, most penetration tests are over within a couple of weeks. Defenders need to build in security controls, protect, find and resolve all weaknesses, and detect and respond to malicious actors in a reasonable time. Malicious actors have essentially infinite time and only require a single porous defense, a single weakness, or missing detection to succeed. Black box testing, often performed at the end of development, quickly, or not at all, is completely unable to cope with that asymmetry. +Level 1 is the only level that is completely penetration testable using humans. All others require access to documentation, source code, configuration, and the people involved in the development process. However, even if L1 allows "black box" (no documentation and no source) testing to occur, it is not an effective assurance activity and should be actively discouraged. Malicious attackers have a great deal of time, most penetration tests are over within a couple of weeks. Defenders need to incorporate security controls, protect, find and resolve all weaknesses, and detect and respond to malicious actors in a reasonable time. Malicious actors have essentially infinite time and only require a single porous defense, a single weakness, or missing detection to succeed. Black box testing, often performed at the end of development, quickly, or not at all, is completely unable to cope with that asymmetry. -Over the last 30+ years, black box testing has proven over and over again to miss critical security issues that led directly to ever more massive breaches. We strongly encourage the use of a wide range of security assurance and verification, including replacing penetration tests with source code led (hybrid) penetration tests at Level 1, with full access to developers and documentation throughout the development process. Financial regulators do not tolerate external financial audits with no access to the books, sample transactions, or the people performing the controls. Industry and governments must demand the same standard of transparency in the software engineering field. +Over the last 30+ years, black box testing has proven over and over again to miss critical security issues that led directly to ever more massive breaches. We strongly encourage the use of a wide range of security assurance and verification, including replacing penetration tests with source code-led (hybrid) penetration tests at Level 1, with full access to developers and documentation throughout the development process. Financial regulators do not tolerate external financial audits with no access to the books, sample transactions, or the people performing the controls. Industry and governments must demand the same standard of transparency in the software engineering field. -We strongly encourage the use of security tools within the development process itself. DAST and SAST tools can be used continuously by the build pipeline to find easy to find security issues that should never be present. +We strongly encourage the use of security tools within the development process itself. DAST and SAST tools, when continuously implemented in the build pipeline, can effectively identify and address straightforward security issues that should never exist. -Automated tools and online scans are unable to complete more than half of the ASVS without human assistance. If comprehensive test automation for each build is required, then a combination of custom unit and integration tests, along with build initiated online scans are used. Business logic flaws and access control testing is only possible using human assistance. These should be turned into unit and integration tests. +Automated tools and online scans are unable to complete more than half of the ASVS without human assistance. If comprehensive test automation for each build is required, then a combination of custom unit and integration tests, along with build-initiated online scans are used. Business logic flaws and access control testing are only possible using human assistance. These should be turned into unit and integration tests. ## How to use this standard @@ -35,11 +35,11 @@ One of the best ways to use the Application Security Verification Standard is to ### Level 1 - First steps, automated, or whole of portfolio view -An application achieves ASVS Level 1 if it adequately defends against application security vulnerabilities that are easy to discover, and included in the OWASP Top 10 and other similar checklists. +An application achieves ASVS Level 1 if it adequately defends against application security vulnerabilities that are easy to discover and included in the OWASP Top 10 and other similar checklists. -Level 1 is the bare minimum that all applications should strive for. It is also useful as a first step in a multi-phase effort or when applications do not store or handle sensitive data and therefore do not need the more rigorous controls of Level 2 or 3. Level 1 controls can be checked either automatically by tools or simply manually without access to source code. We consider Level 1 the minimum required for all applications. +Level 1 is the bare minimum that all applications should strive for. It is also useful as a first step in a multi-phase effort or when applications do not store or handle sensitive data and therefore do not need the more rigorous controls of Level 2 or 3. Level 1 controls can be checked either automatically by tools or simply manually without access to the source code. We consider Level 1 the minimum required for all applications. -Threats to the application will most likely be from attackers who are using simple and low effort techniques to identify easy-to-find and easy-to-exploit vulnerabilities. This is in contrast to a determined attacker who will spend focused energy to specifically target the application. If data processed by your application has high value, you would rarely want to stop at a Level 1 review. +Threats to the application will most likely be from attackers who are using simple and low-effort techniques to identify easy-to-find and easy-to-exploit vulnerabilities. This is in contrast to a determined attacker who will spend focused energy to specifically target the application. If your application processes high-value data, you would rarely want to stop at a Level 1 review. ### Level 2 - Most applications @@ -53,25 +53,25 @@ Threats to Level 2 applications will typically be skilled and motivated attacker ASVS Level 3 is the highest level of verification within the ASVS. This level is typically reserved for applications that require significant levels of security verification, such as those that may be found within areas of military, health and safety, critical infrastructure, etc. -Organizations may require ASVS Level 3 for applications that perform critical functions, where failure could significantly impact the organization's operations, and even its survivability. Example guidance on the application of ASVS Level 3 is provided below. An application achieves ASVS Level 3 (or Advanced) if it adequately defends against advanced application security vulnerabilities and also demonstrates principles of good security design. +Organizations may require ASVS Level 3 for applications that perform critical functions, where failure could significantly impact the organization's operations and even its survivability. Example guidance on the application of ASVS Level 3 is provided below. An application achieves ASVS Level 3 (or Advanced) if it adequately defends against advanced application security vulnerabilities and also demonstrates principles of good security design. -An application at ASVS Level 3 requires more in depth analysis of architecture, coding, and testing than all the other levels. A secure application is modularized in a meaningful way (to facilitate resiliency, scalability, and most of all, layers of security), and each module (separated by network connection and/or physical instance) takes care of its own security responsibilities (defense in depth), that need to be properly documented. Responsibilities include controls for ensuring confidentiality (e.g. encryption), integrity (e.g. transactions, input validation), availability (e.g. handling load gracefully), authentication (including between systems), authorization, and auditing (logging). +An application at ASVS Level 3 requires more in-depth analysis of architecture, coding, and testing than all the other levels. A secure application is modularized in a meaningful way (to facilitate resiliency, scalability, and most of all, layers of security), and each module (separated by network connection and/or physical instance) takes care of its own security responsibilities (defense in depth), that need to be properly documented. Responsibilities include controls for ensuring confidentiality (e.g. encryption), integrity (e.g. transactions, input validation), availability (e.g. handling load gracefully), authentication (including between systems), authorization, and auditing (logging). ## How to Reference ASVS Requirements -Each requirement has an identifier in the format `.
.` where each element is a number, for example: `1.11.3`. +Each requirement has an identifier in the format `.
.` where each element is a number, for example, `1.11.3`. -* The `` value corresponds to the chapter from which the requirement comes, for example: all `1.#.#` requirements are from the `Architecture` chapter. +* The `` value corresponds to the chapter from which the requirement comes, for example, all `1.#.#` requirements are from the `Architecture` chapter. * The `
` value corresponds to the section within that chapter where the requirement appears, for example: all `1.11.#` requirements are in the `Business Logic Architectural Requirements` section of the `Architecture` chapter. -* The `` value identifies the specific requirement within the chapter and section, for example: `1.11.3` which as of version 4.0.2 of this standard is: +* The `` value identifies the specific requirement within the chapter and section, for example, `1.11.3` which as of version 4.0.2 of this standard is: > Verify that all high-value business logic flows, including authentication, session management and access control are thread safe and resistant to time-of-check and time-of-use race conditions. -The identifiers may change between versions of the standard therefore it is preferable that other documents, reports, or tools use the format: `v-.
.`, where: 'version' is the ASVS version tag. For example: `v4.0.2-1.11.3` would be understood to mean specifically the 3rd requirement in the 'Business Logic Architectural Requirements' section of the 'Architecture' chapter from version 4.0.2. (This could be summarized as `v-`.) +Since the identifiers may change between versions of the standard, it is preferable for other documents, reports, or tools to use the following format: `v-.
.`, where: 'version' is the ASVS version tag. For example: `v4.0.2-1.11.3` would be understood to mean specifically the 3rd requirement in the 'Business Logic Architectural Requirements' section of the 'Architecture' chapter from version 4.0.2. (This could be summarized as `v-`.) -Note: The `v` preceding the version portion is to be lower case. +Note: The `v` preceding the version number in the format should always be lowercase. -If identifiers are used without including the `v` element then they should be assumed to refer to the latest Application Security Verification Standard content. Obviously as the standard grows and changes this becomes problematic, which is why writers or developers should include the version element. +If identifiers are used without including the `v` element then they should be assumed to refer to the latest Application Security Verification Standard content. As the standard grows and changes this becomes problematic, which is why writers or developers should include the version element. ASVS requirement lists are made available in CSV, JSON, and other formats which may be useful for reference or programmatic use. @@ -83,7 +83,7 @@ Ideally, every organization should have its own forked ASVS and select tailor-fi ## Uses for the ASVS -The ASVS can be used to assess the security of an application and this is explored in more depth in the next chapter. However, we have identified a number of other potential uses for the ASVS (or a forked version). +The ASVS can be used to assess the security of an application and this is explored in more depth in the next chapter. However, we have identified several other potential uses for the ASVS (or a forked version). ### As Detailed Security Architecture Guidance @@ -99,11 +99,11 @@ The ASVS is designed to be highly testable, with the sole exception of architect ### For Secure Development Training -ASVS can also be used to define characteristics of secure software. Many “secure coding” courses are simply ethical hacking courses with a light smear of coding tips. This may not necessarily help developers to write more secure code. Instead, secure development courses can use the ASVS with a strong focus on the proactive controls found in the ASVS, rather than the Top 10 negative things not to do. +ASVS can also be used to define the characteristics of secure software. Many “secure coding” courses are simply ethical hacking courses with a light smear of coding tips. This may not necessarily help developers to write more secure code. Instead, secure development courses can use the ASVS with a strong focus on the proactive controls found in the ASVS, rather than the Top 10 negative things not to do. ### As a Driver for Agile Application Security -ASVS can be used in an agile development process as a framework to define specific tasks that need to be implemented by the team to have a secure product. One approach might be: Starting with Level 1, verify the specific application or system according to ASVS requirements for the specified level, find what controls are missing and raise specific tickets/tasks in the backlog. This helps with prioritization of specific tasks (or grooming), and makes security visible in the agile process. This can also be used to prioritize auditing and reviewing tasks in the organization, where a specific ASVS requirement can be a driver for review, refactor or auditing for a specific team member and visible as "debt" in the backlog that needs to be eventually done. +ASVS can be used in an agile development process as a framework to define specific tasks that need to be implemented by the team to have a secure product. One approach might be: Starting with Level 1, verify the specific application or system according to ASVS requirements for the specified level, find what controls are missing and raise specific tickets/tasks in the backlog. This helps with the prioritization of specific tasks (or grooming) and makes security visible in the agile process. This approach can also be employed to prioritize auditing and review tasks within the organization. A specific ASVS requirement can drive a review, refactor, or audit for a particular team member, and be visible as 'debt' in the backlog that must eventually be addressed. ### As a Framework for Guiding the Procurement of Secure Software @@ -111,11 +111,11 @@ ASVS is a great framework to help with secure software procurement or procuremen ## Applying ASVS in Practice -Different threats have different motivations. Some industries have unique information and technology assets and domain specific regulatory compliance requirements. +Different threats have different motivations. Some industries have unique information and technology assets and domain-specific regulatory compliance requirements. Organizations are strongly encouraged to look deeply at their unique risk characteristics based on the nature of their business, and based upon that risk and business requirements determine the appropriate ASVS level. -We have heard from various people in community on how they use the standard in practice: +We have received feedback from various members of the community on how they implement the standard in practice: ### Personal Case Studies @@ -148,5 +148,5 @@ We have heard from various people in community on how they use the standard in p ### Use within other projects and tools -* OWASP Defectdojo has built in ASVS support https://www.defectdojo.org/ +* OWASP Defectdojo has built-in ASVS support https://www.defectdojo.org/ * A few weeks after the ASVS 4 release, RIPS added support for it: https://blog.ripstech.com/2019/rips-3.1-adds-teamcity-ldap-jsp-support/ diff --git a/5.0/en/0x04-Assessment_and_Certification.md b/5.0/en/0x04-Assessment_and_Certification.md index dda656dc7c..8c9271b98c 100644 --- a/5.0/en/0x04-Assessment_and_Certification.md +++ b/5.0/en/0x04-Assessment_and_Certification.md @@ -14,15 +14,15 @@ The Application Security Verification Standard can be used as an open book verif Historically, penetration testing and secure code reviews have included issues “by exception” - that is only failed tests appear in the final report. A certifying organization must include in any report the scope of the verification (particularly if a key component is out of scope, such as SSO authentication), a summary of verification findings, including passed and failed tests, with clear indications of how to resolve the failed tests. -Certain verification requirements may not be applicable to the application under test. For example, if you provide a stateless service layer API without a client implementation to your customers, many of the requirements in V3 Session Management are not directly applicable. In such cases, a certifying organization may still claim full ASVS compliance, but must clearly indicate in any report a reason for non-applicability of such excluded verification requirements. +Some verification requirements might not apply to the specific application under test. For example, if you provide a stateless service layer API without a client implementation to your customers, many of the requirements in V3 Session Management are not directly applicable. In such cases, a certifying organization may still claim full ASVS compliance, but must clearly indicate in any report a reason for non-applicability of such excluded verification requirements. -Keeping detailed work papers, screenshots or movies, scripts to reliably and repeatedly exploit an issue, and electronic records of testing, such as intercepting proxy logs and associated notes such as a cleanup list, is considered standard industry practice and can be really useful as proof of the findings for the most doubtful developers. It is not sufficient to simply run a tool and report on the failures; this does not (at all) provide sufficient evidence that all issues at a certifying level have been tested and tested thoroughly. In case of dispute, there should be sufficient assurance evidence to demonstrate each and every verified requirement has indeed been tested. +Keeping detailed work papers, screenshots or movies, scripts to reliably and repeatedly exploit an issue, and electronic records of testing, such as intercepting proxy logs and associated notes such as a cleanup list, is considered standard industry practice and can be really useful as proof of the findings for the most doubtful developers. It is not sufficient to simply run a tool and report on the failures; this does not (at all) provide sufficient evidence that all issues at a certifying level have been tested and tested thoroughly. In case of dispute, there should be sufficient assurance evidence to demonstrate each verified requirement has indeed been tested. ### Testing Method Certifying organizations are free to choose the appropriate testing method(s), but should indicate them in a report. -Depending on the application under test and the verification requirement, different testing methods may be used to gain similar confidence in the results. For example, validating the effectiveness of an application's input verification mechanisms may either be analyzed with a manual penetration test or by means of source code analyses. +Depending on the application under test and the verification requirement, different testing methods may be used to gain similar confidence in the results. For example, validating the effectiveness of an application's input verification mechanisms can be assessed either through a manual penetration test or by conducting source code analysis. #### The Role of Automated Security Testing Tools diff --git a/5.0/en/0x10-V1-Architecture.md b/5.0/en/0x10-V1-Architecture.md index e11c67f399..6d21672c7d 100644 --- a/5.0/en/0x10-V1-Architecture.md +++ b/5.0/en/0x10-V1-Architecture.md @@ -6,9 +6,9 @@ Security architecture has almost become a lost art in many organizations. The da A specific implementation of a web application is likely to be revised continuously throughout its lifetime, but the overall architecture will likely rarely change but evolve slowly. Security architecture is identical - we need authentication today, we will require authentication tomorrow, and we will need it five years from now. If we make sound decisions today, we can save a lot of effort, time, and money if we select and re-use architecturally compliant solutions. For example, a decade ago, multi-factor authentication was rarely implemented. -If developers had invested in a single, secure identity provider model, such as SAML federated identity, the identity provider could be updated to incorporate new requirements such as NIST SP 800-63 compliance, while not changing the interfaces of the original application. If many applications share the same security architecture and thus that same component, they all benefit from this upgrade at once. However, SAML will not always remain as the best or most suitable authentication solution - it might need to be swapped out for other solutions as requirements change. Changes like this are either complicated, so costly as to necessitate a complete re-write, or outright impossible without security architecture. +If developers had invested in a single, secure identity provider model, such as SAML federated identity, the identity provider could be updated to incorporate new requirements such as NIST SP 800-63 compliance, while not changing the interfaces of the original application. If many applications share the same security architecture and thus that same component, they all benefit from this upgrade at once. However, SAML may not always remain the most suitable authentication solution - it might need to be swapped out for other solutions as requirements change. Changes like this are either complicated, so costly as to necessitate a complete rewrite, or outright impossible without security architecture. -In this chapter, the ASVS covers the primary aspects of any sound security architecture: availability, confidentiality, processing integrity, non-repudiation, and privacy. Each of these security principles must be built in and be innate to all applications. It is critical to "shift left", starting with developer enablement with secure coding checklists, mentoring and training, coding and testing, building, deployment, configuration, and operations, and finishing with follow up independent testing to assure that all of the security controls are present and functional. The last step used to be everything we did as an industry, but that is no longer sufficient when developers push code into production tens or hundreds of times a day. Application security professionals must keep up with agile techniques, which means adopting developer tools, learning to code, and working with developers rather than criticizing the project months after everyone else has moved on. +In this chapter, the ASVS covers the primary aspects of any sound security architecture: availability, confidentiality, processing integrity, non-repudiation, and privacy. Each of these security principles must be built in and be innate to all applications. It is critical to "shift left", starting with developer enablement with secure coding checklists, mentoring and training, coding and testing, building, deployment, configuration, and operations, and finishing with follow-up independent testing to ensure that all of the security controls are present and functional. The last step used to be everything we did as an industry, but that is no longer sufficient when developers push code into production tens or hundreds of times a day. Application security professionals must keep up with agile techniques, which means adopting developer tools, learning to code, and working with developers rather than criticizing the project months after everyone else has moved on. ## V1.1 Secure Software Development Lifecycle @@ -24,7 +24,7 @@ In this chapter, the ASVS covers the primary aspects of any sound security archi ## V1.2 Authentication Architecture -When designing authentication, it doesn't matter if you have strong hardware enabled multi-factor authentication if an attacker can reset an account by calling a call center and answering commonly known questions. When proving identity, all authentication pathways must have the same strength. +When designing authentication systems, the strength of hardware-enabled multi-factor authentication becomes irrelevant if an attacker can easily reset an account by calling a call center and answering commonly known questions. To ensure secure identity verification, all authentication pathways must possess equivalent strength. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | @@ -53,7 +53,7 @@ This is a placeholder for future architectural requirements. In 4.0, we moved away from the term "server-side" as a loaded trust boundary term. The trust boundary is still concerning - making decisions on untrusted browsers or client devices is bypassable. However, in mainstream architectural deployments today, the trust enforcement point has dramatically changed. Therefore, where the term "trusted service layer" is used in the ASVS, we mean any trusted enforcement point, regardless of location, such as a microservice, serverless API, server-side, a trusted API on a client device that has secure boot, partner or external APIs, and so on. -The "untrusted client" term here refers to client-side technologies that render the presentation layer, commonly referred to as 'front-end' technologies. The term "serialization" here not only refers to sending data over the wire like an array of values or taking and reading a JSON structure, but also passing complex objects which can contain logic. +The "untrusted client" term here refers to client-side technologies that render the presentation layer, commonly referred to as 'front-end' technologies. The term 'serialization' in this context refers not only to transmitting data over the wire, such as an array of values or processing a JSON structure but also to the handling of complex objects that may contain logic. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | @@ -64,7 +64,7 @@ The "untrusted client" term here refers to client-side technologies that render ## V1.6 Cryptographic Architecture -Applications need to be designed with strong cryptographic architecture to protect data assets as per their classification. Encrypting everything is wasteful, not encrypting anything is legally negligent. A balance must be struck, usually during architectural or high level design, design sprints or architectural spikes. Designing cryptography as you go or retrofitting it will inevitably cost much more to implement securely than simply building it in from the start. +Applications need to be designed with strong cryptographic architecture to protect data assets as per their classification. Encrypting everything is wasteful, not encrypting anything is legally negligent. A balance must be struck, usually during architectural or high-level design, design sprints or architectural spikes. Designing cryptography as you go or retrofitting it will inevitably cost much more to implement securely than simply building it in from the start. Architectural requirements are intrinsic to the entire code base, and thus difficult to unit or integration test. Architectural requirements require consideration in coding standards, throughout the coding phase, and should be reviewed during security architecture, peer or code reviews, or retrospectives. diff --git a/5.0/en/0x11-V2-Authentication.md b/5.0/en/0x11-V2-Authentication.md index 6858ba1ce6..aeb76db489 100644 --- a/5.0/en/0x11-V2-Authentication.md +++ b/5.0/en/0x11-V2-Authentication.md @@ -2,9 +2,9 @@ ## Control Objective -Authentication is the act of establishing, or confirming, someone (or something) as authentic and that claims made by a person or about a device are correct, resistant to impersonation, and prevent recovery or interception of passwords. +Authentication is the process of establishing or confirming the authenticity of an individual or device. It involves verifying claims made by a person or about a device, ensuring resistance to impersonation, and preventing the recovery or interception of passwords. -When the ASVS was first released, username + password was the most common form of authentication outside of high security systems. Multi-factor Authentication (MFA) was commonly accepted in security circles but rarely required elsewhere. As the number of password breaches increased, the idea that usernames are somehow confidential and passwords unknown, rendered many security controls untenable. For example, NIST SP 800-63 considers usernames and Knowledge Based Authentication (KBA) as public information, email as [not allowed](https://pages.nist.gov/800-63-FAQ/#q-b11), SMS as a ["restricted" authenticator type](https://pages.nist.gov/800-63-FAQ/#q-b01), and passwords as pre-breached. This reality renders knowledge based authenticators, SMS and email recovery, password history, complexity, and rotation controls useless. These controls have always been less than helpful, often forcing users to come up with weak passwords every few months, but with the release of over 5 billion username and password breaches, it's time to move on. +When the ASVS was initially released, the combination of username and password was the most common form of authentication, except in high-security systems. Multi-factor Authentication (MFA) was commonly accepted in security circles but rarely required elsewhere. As the number of password breaches increased, the idea that usernames are somehow confidential and passwords unknown, rendered many security controls untenable. For example, NIST SP 800-63 considers usernames and Knowledge Based Authentication (KBA) as public information, email as [not allowed](https://pages.nist.gov/800-63-FAQ/#q-b11), SMS as a ["restricted" authenticator type](https://pages.nist.gov/800-63-FAQ/#q-b01), and passwords as pre-breached. This reality renders knowledge-based authenticators, SMS and email recovery, and password-related controls such as history, complexity, and rotation, ineffective. These controls have always been less than helpful, often forcing users to come up with weak passwords every few months, but with the release of over 5 billion username and password breaches, it's time to move on. Of all the chapters in the ASVS, the authentication and session management chapters have changed the most. Adoption of effective, evidence-based leading practice will be challenging for many, and that's perfectly okay. We have to start the transition to a post-password future now. @@ -12,19 +12,19 @@ Of all the chapters in the ASVS, the authentication and session management chapt [NIST SP 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html) is a modern, evidence-based standard, and represents the best advice available, regardless of applicability. The standard is helpful for all organizations all over the world but is particularly relevant to US agencies and those dealing with US agencies. -NIST SP 800-63 terminology can be a little confusing at first, especially if you're only used to username + password authentication. Advancements in modern authentication are necessary, so we have to introduce terminology that will become commonplace in the future, but we do understand the difficulty in understanding until the industry settles on these new terms. We have provided a glossary at the end of this chapter to assist. We have rephrased many requirements to satisfy the intent of the requirement, rather than the letter of the requirement. For example, the ASVS uses the term "password" when NIST uses "memorized secret" throughout this standard. +NIST SP 800-63 terminology can be a little confusing at first, especially if you're only used to username + password authentication. Advancements in modern authentication are necessary, so we have to introduce terminology that will become commonplace in the future, but we do understand the difficulty in understanding until the industry settles on these new terms. We have provided a glossary at the end of this chapter to assist. We have rephrased many requirements to satisfy the intent of the requirement, rather than the letter of the requirement. For example, the ASVS uses the term "password" while NIST uses "memorized secret" throughout this standard. -ASVS V2 Authentication, V3 Session Management, and to a lesser extent, V4 Access Controls have been adapted to be a compliant subset of selected NIST SP 800-63B controls, focused around common threats and commonly exploited authentication weaknesses. Where full NIST SP 800-63 compliance is required, please consult NIST SP 800-63. +The V2 Authentication and V3 Session Management chapters in the ASVS, and to a lesser extent the V4 Access Control chapter, have been adapted to align as a compliant subset of selected NIST SP 800-63B controls. This adaptation focuses on common threats and frequently exploited authentication weaknesses. For cases where full NIST SP 800-63 compliance is necessary, please refer to NIST SP 800-63. ### Selecting an appropriate NIST AAL Level -The Application Security Verification Standard has tried to map ASVS L1 to NIST AAL1 requirements, L2 to AAL2, and L3 to AAL3. However, the approach of ASVS Level 1 as "essential" controls may not necessarily be the correct AAL level to verify an application or API. For example, if the application is a Level 3 application or has regulatory requirements to be AAL3, Level 3 should be chosen in chapters V2 and V3 Session Management. The choice of NIST compliant Authentication Assertion Level (AAL) should be performed as per NIST SP 800-63B guidelines as set out in *Selecting AAL* in [NIST SP 800-63B Section 6.2](https://pages.nist.gov/800-63-3/sp800-63-3.html#AAL_CYOA). +The Application Security Verification Standard has tried to map ASVS L1 to NIST AAL1 requirements, L2 to AAL2, and L3 to AAL3. However, the approach of ASVS Level 1 as "essential" controls may not necessarily be the correct AAL level to verify an application or API. For example, if the application is a Level 3 application or has regulatory requirements to be AAL3, Level 3 should be chosen in chapters V2 and V3 Session Management. The choice of NIST-compliant Authentication Assertion Level (AAL) should be performed as per NIST SP 800-63B guidelines as set out in *Selecting AAL* in [NIST SP 800-63B Section 6.2](https://pages.nist.gov/800-63-3/sp800-63-3.html#AAL_CYOA). ## V2.1 Password Security Passwords, called "Memorized Secrets" by NIST SP 800-63, include passwords, PINs, unlock patterns, pick the correct kitten or another image element, and passphrases. They are generally considered "something you know", and often used as single-factor authenticators. There are significant challenges to the continued use of single-factor authentication, including billions of valid usernames and passwords disclosed on the Internet, default or weak passwords, rainbow tables and ordered dictionaries of the most common passwords. -Applications should strongly encourage users to enroll in multi-factor authentication, and should allow users to re-use tokens they already possess, such as FIDO or U2F tokens, or link to a credential service provider that provides multi-factor authentication. +Applications should strongly encourage users to enroll in multi-factor authentication and should allow users to re-use tokens they already possess, such as FIDO or U2F tokens, or link to a credential service provider that provides multi-factor authentication. Credential Service Providers (CSPs) provide federated identity for users. Users will often have more than one identity with multiple CSPs, such as an enterprise identity using Azure AD, Okta, Ping Identity or Google, or consumer identity using Facebook, Twitter, Google, or WeChat, to name just a few common alternatives. This list is not an endorsement of these companies or services, but simply an encouragement for developers to consider the reality that many users have many established identities. Organizations should consider integrating with existing user identities, as per the risk profile of the CSP's strength of identity proofing. For example, it is unlikely a government organization would accept a social media identity as a login for sensitive systems, as it is easy to create fake or throw away identities, whereas a mobile game company may well need to integrate with major social media platforms to grow their active player base. @@ -53,9 +53,9 @@ Possible sources of frequently used passwords for requirement 2.1.7 include: ## V2.2 General Authenticator Security -Authenticator agility is essential to future-proof applications. Refactor application verifiers to allow additional authenticators as per user preferences, as well as allowing retiring deprecated or unsafe authenticators in an orderly fashion. +Authenticator agility is essential to future-proof applications. Refactor application verifiers to allow additional authenticators as per user preferences, as well as retiring deprecated or unsafe authenticators in an orderly fashion. -NIST considers SMS as ["restricted" authenticator types](https://pages.nist.gov/800-63-FAQ/#q-b01), and they are likely to be removed from NIST SP 800-63 and thus the ASVS at some point in the future. Applications should plan a roadmap that does not require the use of SMS. +NIST considers SMS as ["restricted" authenticator types](https://pages.nist.gov/800-63-FAQ/#q-b01), and they are likely to be removed from NIST SP 800-63, and consequently from the ASVS, in the future. Applications should plan a roadmap that does not require the use of SMS. As noted above, NIST SP 800-63 considers email as [not acceptable](https://pages.nist.gov/800-63-FAQ/#q-b11) as an authenticator. @@ -121,7 +121,7 @@ Where US standards are mentioned, a regional or local standard can be used in pl ## V2.6 Lookup Secret Verifier -Lookup secrets are pre-generated lists of secret codes, similar to Transaction Authorization Numbers (TAN), social media recovery codes, or a grid containing a set of random values. These are distributed securely to users. These lookup codes are used once, and once all used, the lookup secret list is discarded. This type of authenticator is considered "something you have". +Lookup secrets are pre-generated lists of secret codes, similar to Transaction Authorization Numbers (TAN), social media recovery codes, or a grid containing a set of random values. These are distributed securely to users. These lookup codes are single-use. Once all are utilized, the lookup secret list is discarded. This type of authenticator is considered "something you have". | # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---: | :---: | :---: | :---: | @@ -130,27 +130,27 @@ Lookup secrets are pre-generated lists of secret codes, similar to Transaction A | **2.6.3** | [MODIFIED] Verify that lookup secrets are generated using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) to avoid predictable values. | | ✓ | ✓ | 310 | 5.1.2.2 | | **2.6.4** | [ADDED, SPLIT FROM 2.6.2] Verify that lookup secrets have a minimum of 20 bits of entropy (typically 4 random alphanumeric characters or 6 random digits is sufficient). | | ✓ | ✓ | 330 | 5.1.2.1 | -## V2.7 Out of Band Verifier +## V2.7 Out-of-Band Verifier -In the past, a common out of band verifier would have been an email or SMS containing a password reset link. Attackers use this weak mechanism to reset accounts they don't yet control, such as taking over a person's email account and re-using any discovered reset links. There are better ways to handle out of band verification. +In the past, a common out-of-band verifier would have been an email or SMS containing a password reset link. Attackers use this weak mechanism to reset accounts they don't yet control, such as taking over a person's email account and re-using any discovered reset links. There are better ways to handle out-of-band verification. -Secure out of band authenticators are physical devices that can communicate with the verifier over a secure secondary channel. Examples include push notifications to mobile devices. This type of authenticator is considered "something you have". When a user wishes to authenticate, the verifying application sends a message to the out of band authenticator via a connection to the authenticator directly or indirectly through a third party service. The message contains an authentication code (typically a random six digit number or a modal approval dialog). The verifying application waits to receive the authentication code through the primary channel and compares the hash of the received value to the hash of the original authentication code. If they match, the out of band verifier can assume that the user has authenticated. +Secure out-of-band authenticators are physical devices that can communicate with the verifier over a secure secondary channel. Examples include push notifications to mobile devices. This type of authenticator is considered "something you have". When a user wishes to authenticate, the verifying application sends a message to the out-of-band authenticator via a connection to the authenticator directly or indirectly through a third-party service. The message includes an authentication code, typically a random six-digit number, or features a modal approval dialog. The verifying application waits to receive the authentication code through the primary channel and compares the hash of the received value to the hash of the original authentication code. If they match, the out-of-band verifier can assume that the user has authenticated. -The ASVS assumes that only a few developers will be developing new out of band authenticators, such as push notifications, and thus the following ASVS controls apply to verifiers, such as authentication API, applications, and single sign-on implementations. If developing a new out of band authenticator, please refer to NIST SP 800-63B § 5.1.3.1. +The ASVS assumes that only a few developers will be developing new out-of-band authenticators, such as push notifications, and thus the following ASVS controls apply to verifiers, such as authentication API, applications, and single sign-on implementations. If developing a new out-of-band authenticator, please refer to NIST SP 800-63B § 5.1.3.1. -Unsafe out of band authenticators such as e-mail and VOIP are not permitted. PSTN and SMS authentication are currently "restricted" by NIST and should be deprecated in favor of push notifications or similar. If you need to use telephone or SMS out of band authentication, please see NIST SP 800-63B § 5.1.3.3. +Unsafe out-of-band authenticators such as e-mail and VOIP are not permitted. PSTN and SMS authentication are currently "restricted" by NIST and should be deprecated in favor of push notifications or similar. If you need to use telephone or SMS out-of-band authentication, please see NIST SP 800-63B § 5.1.3.3. | # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---: | :---: | :---: | :---: | -| **2.7.1** | Verify that clear text out of band (NIST "restricted") authenticators, such as SMS or PSTN, are not offered by default, and stronger alternatives such as push notifications are offered first. | ✓ | ✓ | ✓ | 287 | 5.1.3.2 | -| **2.7.2** | [MODIFIED] Verify that the out of band verifier expires out of band authentication requests, codes, or tokens within 10 minutes. | ✓ | ✓ | ✓ | 287 | 5.1.3.2 | -| **2.7.3** | Verify that the out of band verifier authentication requests, codes, or tokens are only usable once, and only for the original authentication request. | ✓ | ✓ | ✓ | 287 | 5.1.3.2 | -| **2.7.4** | Verify that the out of band authenticator and verifier communicates over a secure independent channel. | ✓ | ✓ | ✓ | 523 | 5.1.3.2 | -| **2.7.5** | Verify that the out of band verifier retains only a hashed version of the authentication code. | | ✓ | ✓ | 256 | 5.1.3.2 | +| **2.7.1** | [GRAMMAR] Verify that cleartext out-of-band (NIST "restricted") authenticators, such as SMS or PSTN, are not offered by default, and stronger alternatives such as push notifications are offered first. | ✓ | ✓ | ✓ | 287 | 5.1.3.2 | +| **2.7.2** | [MODIFIED] Verify that the out-of-band verifier expires out-of-band authentication requests, codes, or tokens within 10 minutes. | ✓ | ✓ | ✓ | 287 | 5.1.3.2 | +| **2.7.3** | [GRAMMAR] Verify that the out-of-band verifier authentication requests, codes, or tokens are only usable once, and only for the original authentication request. | ✓ | ✓ | ✓ | 287 | 5.1.3.2 | +| **2.7.4** | [GRAMMAR] Verify that the out-of-band authenticator and verifier communicates over a secure independent channel. | ✓ | ✓ | ✓ | 523 | 5.1.3.2 | +| **2.7.5** | [GRAMMAR] Verify that the out-of-band verifier retains only a hashed version of the authentication code. | | ✓ | ✓ | 256 | 5.1.3.2 | | **2.7.6** | [MODIFIED] Verify that the initial authentication code is generated by a secure random number generator, containing at least 20 bits of entropy (typically 4 random alphanumeric characters or 6 random digits is sufficient). | | ✓ | ✓ | 310 | 5.1.3.2 | | **2.7.7** | [ADDED] Verify that the initial authentication code is protected against brute force attacks by using either rate limiting or a code with at least 64 bits of entropy. | | ✓ | ✓ | 307 | 5.1.3.2 | -## V2.8 One Time Verifier +## V2.8 One-Time Verifier Single-factor One-time Passwords (OTPs) are physical or soft tokens that display a continually changing pseudo-random one-time challenge. These devices make phishing (impersonation) difficult, but not impossible. This type of authenticator is considered "something you have". Multi-factor tokens are similar to single-factor OTPs, but require a valid PIN code, biometric unlocking, USB insertion or NFC pairing or some additional value (such as transaction signing calculators) to be entered to create the final OTP. diff --git a/5.0/en/0x12-V3-Session-management.md b/5.0/en/0x12-V3-Session-management.md index e0eb243aad..9c4733ddcc 100644 --- a/5.0/en/0x12-V3-Session-management.md +++ b/5.0/en/0x12-V3-Session-management.md @@ -9,7 +9,7 @@ Ensure that a verified application satisfies the following high-level session ma * Sessions are unique to each individual and cannot be guessed or shared. * Sessions are invalidated when no longer required and timed out during periods of inactivity. -As previously noted, these requirements have been adapted to be a compliant subset of selected NIST SP 800-63B controls, focused around common threats and commonly exploited authentication weaknesses. Previous verification requirements have been retired, de-duped, or in most cases adapted to be strongly aligned with the intent of mandatory [NIST SP 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html) requirements. +As previously noted, these requirements have been adapted to be a compliant subset of selected NIST SP 800-63B controls, focused on common threats and commonly exploited authentication weaknesses. Previous verification requirements have been retired, de-duped, or in most cases adapted to be strongly aligned with the intent of mandatory [NIST SP 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html) requirements. ## V3.1 Fundamental Session Management Security @@ -32,9 +32,9 @@ TLS or another secure transport channel is mandatory for session management. Thi ## V3.3 Session Timeout -Session timeouts have been aligned with NIST SP 800-63, which permits much longer session timeouts than traditionally permitted by security standards. Organizations should review the table below, and if a longer time out is desirable based on the application's risk, the NIST value should be the upper bounds of session idle timeouts. +Session timeouts have been aligned with NIST SP 800-63, which permits much longer session timeouts than traditionally permitted by security standards. Organizations are advised to review the table below. If a longer timeout is desired based on the application's risk profile, the NIST value should serve as the maximum limit for session idle timeouts. -L1 in this context is IAL1/AAL1, L2 is IAL2/AAL3, L3 is IAL3/AAL3. For IAL2/AAL2 and IAL3/AAL3, the shorter idle timeout is, the lower bound of idle times for being logged out or re-authenticated to resume the session. +L1 in this context is IAL1/AAL1, L2 is IAL2/AAL3, L3 is IAL3/AAL3. For both IAL2/AAL2 and IAL3/AAL3, the shorter the idle timeout, the lower the bound of idle times for being logged out or re-authenticated to resume the session. | # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---: | :---: | :---: | :---: | @@ -83,7 +83,7 @@ There are a small number of session management attacks, some related to the user ### Description of the half-open Attack -In early 2018, several financial institutions were compromised using what the attackers called "half-open attacks". This term has stuck in the industry. The attackers struck multiple institutions with different proprietary code bases, and indeed it seems different code bases within the same institutions. The half-open attack is exploiting a design pattern flaw commonly found in many existing authentication, session management and access control systems. +In early 2018, several financial institutions were compromised using what the attackers called "half-open attacks". This term has stuck in the industry. The attackers struck multiple institutions with different proprietary code bases, and indeed it seems different code bases within the same institutions. The half-open attack exploits a design pattern flaw commonly present in many authentication, session management and access control systems. Attackers start a half-open attack by attempting to lock, reset, or recover a credential. A popular session management design pattern re-uses user profile session objects/models between unauthenticated, half-authenticated (password resets, forgot username), and fully authenticated code. This design pattern populates a valid session object or token containing the victim's profile, including password hashes and roles. If access control checks in controllers or routers do not correctly verify that the user is fully logged in, the attacker will be able to act as the user. Attacks could include changing the user's password to a known value, updating the email address to perform a valid password reset, disabling multi-factor authentication or enrolling a new MFA device, revealing or changing API keys, and so on. diff --git a/5.0/en/0x12-V4-Access-Control.md b/5.0/en/0x12-V4-Access-Control.md index 0d873cf67d..a7781cd819 100644 --- a/5.0/en/0x12-V4-Access-Control.md +++ b/5.0/en/0x12-V4-Access-Control.md @@ -2,7 +2,7 @@ ## Control Objective -Authorization is the concept of allowing access to resources only to those permitted to use them. Ensure that a verified application satisfies the following high level requirements: +Authorization is the concept of allowing access to resources only to those permitted to use them. Ensure that a verified application satisfies the following high-level requirements: * Persons accessing resources hold valid credentials to do so. * Users are associated with a well-defined set of entitlements. diff --git a/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md b/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md index 0b45949fc0..830479b518 100644 --- a/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md +++ b/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md @@ -14,11 +14,11 @@ With modern web application architecture, output encoding is more important than ## V5.1 Input Validation -Properly implemented input validation controls, using positive allow lists and strong data typing, can sometimes eliminate injection attacks. However, sometimes input validation is not going to be effective in security, for example a valid e-mail address/URL can still be used to conduct successful attacks. +Properly implemented input validation controls, using positive allow lists and strong data typing, can sometimes eliminate injection attacks. However, there are instances where input validation may not be effective for security purposes. For example, a valid email address or URL can still be used to conduct successful attacks. -Input validation is still important security hygiene and should be applied to all inputs where possible. +Input validation is still important for security hygiene and should be applied to all inputs where possible. -Sometimes input validation is not going to be helpful for security, other times it will help it to a moderate degree, whilst other times it will be fundamental for security defense. It depends on the type of data and the use of that data to determine how effective input validation will be. Because input validation is not a complete security strategy, one should also make use of sandboxing, santisation, encoding and parameterisation. +Sometimes input validation is not going to be helpful for security, other times it will help it to a moderate degree, whilst other times it will be fundamental for security defense. It depends on the type of data and the use of that data to determine how effective input validation will be. Because input validation is not a complete security strategy, one should also make use of sandboxing, sanitization, encoding and parameterization. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | @@ -37,11 +37,11 @@ Sometimes input validation is not going to be helpful for security, other times For example: -* Santization: When a user is authoring HTML, the standard defense is to standardise HTML to remove Performing JSON sanitizing before JSON parsers are used, and of course HTML sanitization for XSS defense +* Sanitization: When a user is authoring HTML, the standard defense is to standardize HTML to remove Performing JSON sanitizing before JSON parsers are used, and of course HTML sanitization for XSS defense * Escaping: Done in the UI when you want to preserve displaying content as the user typed it in, also for some injection protection like LDAP injection protection * Parameterization: For SQL Injection, primarily * Sandboxing: When you can't sanitize HTML for some reason and need to dump potentially active content on your web page, iFrame sandboxing is critical. CSP has some sandboxing capabilities, too. -* Really important for URL's in Web UI's to stop JavaScript and data URL's (XSS defense) - but often valid data is still dangerous +* URLs in Web UIs should block JavaScript and data URLs as a defense against XSS attacks. However, it's important to note that often, even valid data can still pose a threat. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | @@ -59,7 +59,7 @@ For example: ## V5.3 Output Encoding and Injection Prevention -Output encoding close or adjacent to the interpreter in use is critical to the security of any application. Typically, output encoding is not persisted, but used to render the output safe in the appropriate output context for immediate use. Failing to output encode will result in an insecure, injectable, and unsafe application. +Output encoding close or adjacent to the interpreter in use is critical to the security of any application. Typically, output encoding is not persisted, but rather used to render output safely in the appropriate context for immediate use. Failing to output encode will result in an insecure, injectable, and unsafe application. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | @@ -79,7 +79,7 @@ Output encoding close or adjacent to the interpreter in use is critical to the s Note: Using parameterized queries or escaping SQL is not always sufficient; table and column names, ORDER BY and so on, cannot be escaped. The inclusion of escaped user-supplied data in these fields results in failed queries or SQL injection. -Note: The SVG format explicitly allows ECMA script in almost all contexts, so it may not be possible to block all SVG XSS vectors completely. If SVG upload is required, we strongly recommend either serving these uploaded files as text/plain or using a separate user supplied content domain to prevent successful XSS from taking over the application. +Note: The SVG format explicitly allows ECMA script in almost all contexts, so it may not be possible to block all SVG XSS vectors completely. If SVG upload is required, we strongly recommend either serving these uploaded files as text/plain or using a separate user-supplied content domain to prevent successful XSS from taking over the application. ## V5.4 Memory, String, and Unmanaged Code @@ -109,7 +109,7 @@ For more information, see also: * [OWASP Cheat Sheet: Input Validation](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html) * [OWASP Testing Guide 4.0: Testing for HTTP Parameter Pollution](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution.html) * [OWASP LDAP Injection Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html) -* [OWASP Testing Guide 4.0: Client Side Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/11-Client-side_Testing/README) +* [OWASP Testing Guide 4.0: Client-Side Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/11-Client-side_Testing/README) * [OWASP Cross Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html) * [OWASP DOM Based Cross Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html) * [OWASP Java Encoding Project](https://owasp.org/owasp-java-encoder/) @@ -132,4 +132,4 @@ For more information on deserialization or parsing issues, please see: * [OWASP Deserialization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) * [OWASP Deserialization of Untrusted Data Guide](https://owasp.org/www-community/vulnerabilities/Deserialization_of_untrusted_data) * [An Exploration of JSON Interoperability Vulnerabilities](https://bishopfox.com/blog/json-interoperability-vulnerabilities) -* [Orange Tsai - A new era of SSRF Exploiting URL Parser In Trending Programming Languages](https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf) +* [Orange Tsai - A New Era of SSRF Exploiting URL Parser In Trending Programming Languages](https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf) diff --git a/5.0/en/0x14-V6-Cryptography.md b/5.0/en/0x14-V6-Cryptography.md index ccef0103e8..3c1410343d 100644 --- a/5.0/en/0x14-V6-Cryptography.md +++ b/5.0/en/0x14-V6-Cryptography.md @@ -2,11 +2,11 @@ ## Control Objective -Ensure that a verified application satisfies the following high level requirements: +Ensure that a verified application satisfies the following high-level requirements: -* All cryptographic modules fail in a secure manner and that errors are handled correctly. +* All cryptographic modules fail securely and errors are handled correctly. * A suitable random number generator is used. -* Access to keys is securely managed. +* Access to keys is managed securely. ## V6.1 Data Classification @@ -37,7 +37,7 @@ Although this section is not easily penetration tested, developers should consid ## V6.3 Random Values -Cryptographically-secure Pseudo-random Number Generation (CSPRNG) is incredibly difficult to get right. Generally, good sources of entropy within a system will be quickly depleted if over-used, but sources with less randomness can lead to predictable keys and secrets. +Cryptographically secure Pseudo-random Number Generation (CSPRNG) is incredibly difficult to get right. Generally, good sources of entropy within a system will be quickly depleted if over-used, but sources with less randomness can lead to predictable keys and secrets. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | @@ -58,6 +58,6 @@ Although this section is not easily penetration tested, developers should consid For more information, see also: -* [OWASP Testing Guide 4.0: Testing for weak Cryptography](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/README.html) +* [OWASP Testing Guide 4.0: Testing for Weak Cryptography](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/README.html) * [OWASP Cheat Sheet: Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html) * [FIPS 140-3](https://csrc.nist.gov/publications/detail/fips/140/3/final) diff --git a/5.0/en/0x15-V7-Error-Logging.md b/5.0/en/0x15-V7-Error-Logging.md index f16554f8f7..b577a933bb 100644 --- a/5.0/en/0x15-V7-Error-Logging.md +++ b/5.0/en/0x15-V7-Error-Logging.md @@ -2,9 +2,9 @@ ## Control Objective -The primary objective of error handling and logging is to provide useful information for the user, administrators, and incident response teams. The objective is not to create massive amounts of logs, but high quality logs, with more signal than discarded noise. +The primary objective of error handling and logging is to provide useful information for the user, administrators, and incident response teams. The objective is not to create massive amounts of logs, but high-quality logs, with more signal than discarded noise. -High quality logs will often contain sensitive data, and must be protected as per local data privacy laws or directives. This should include: +High-quality logs, which often contain sensitive data, must be safeguarded in accordance with local data privacy laws or directives. This should include: * Not collecting or logging sensitive information unless specifically required. * Ensuring all logged information is handled securely and protected as per its data classification. @@ -67,7 +67,7 @@ Note: Log encoding (7.3.1) is difficult to test and review using automated dynam ## V7.4 Error Handling -The purpose of error handling is to allow the application to provide security relevant events for monitoring, triage and escalation. The purpose is not to create logs. When logging security related events, ensure that there is a purpose to the log, and that it can be distinguished by SIEM or analysis software. +The purpose of error handling is to allow the application to provide security-relevant events for monitoring, triage and escalation. The purpose is not to create logs. When logging security-related events, ensure that there is a purpose to the log and that it can be distinguished by SIEM or analysis software. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | @@ -76,7 +76,7 @@ The purpose of error handling is to allow the application to provide security re | **7.4.3** | Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 431 | | **7.4.4** | [ADDED] Verify that the application is designed in a way that a failure to access external resources does not result in the entire application failing, for example using the circuit breaker pattern. | | ✓ | ✓ | | -Note: Certain languages, such as Swift and Go - and through common design practice - many functional languages, do not support exceptions or last resort event handlers. In this case, architects and developers should use a pattern, language, or framework friendly way to ensure that applications can securely handle exceptional, unexpected, or security-related events. +Note: Certain languages, such as Swift and Go - and through common design practice - many functional languages, do not support exceptions or last-resort event handlers. In this case, architects and developers should use a pattern, language, or framework-friendly way to ensure that applications can securely handle exceptional, unexpected, or security-related events. ## References diff --git a/5.0/en/0x16-V8-Data-Protection.md b/5.0/en/0x16-V8-Data-Protection.md index d5e99d1d52..ca66efb04a 100644 --- a/5.0/en/0x16-V8-Data-Protection.md +++ b/5.0/en/0x16-V8-Data-Protection.md @@ -6,7 +6,7 @@ There are three key elements to sound data protection: Confidentiality, Integrit Applications have to assume that all user devices are compromised in some way. Where an application transmits or stores sensitive information on insecure devices, such as shared computers, phones and tablets, the application is responsible for ensuring data stored on these devices is encrypted and cannot be easily illicitly obtained, altered or disclosed. -Ensure that a verified application satisfies the following high level data protection requirements: +Ensure that a verified application satisfies the following high-level data protection requirements: * Confidentiality: Data should be protected from unauthorized observation or disclosure both in transit and when stored. * Integrity: Data should be protected from being maliciously created, altered or deleted by unauthorized attackers. @@ -61,7 +61,7 @@ When considering data protection, a primary consideration should be around bulk For more information, see also: -* [Consider using Security Headers website to check security and anti-caching headers](https://securityheaders.com/) +* [Consider using the Security Headers website to check security and anti-caching headers](https://securityheaders.com/) * [Documentation about anti-caching headers by Mozilla](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching) * [OWASP Secure Headers project](https://owasp.org/www-project-secure-headers/) * [OWASP Privacy Risks Project](https://owasp.org/www-project-top-10-privacy-risks/) @@ -70,4 +70,4 @@ For more information, see also: * [European Union General Data Protection Regulation (GDPR) overview](https://edps.europa.eu/data-protection_en) * [European Union Data Protection Supervisor - Internet Privacy Engineering Network](https://edps.europa.eu/data-protection/ipen-internet-privacy-engineering-network_en) * [Information on the "Clear-Site-Data" header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data) -* [White-paper on Web Cache Deception](https://www.blackhat.com/docs/us-17/wednesday/us-17-Gil-Web-Cache-Deception-Attack-wp.pdf) +* [White paper on Web Cache Deception](https://www.blackhat.com/docs/us-17/wednesday/us-17-Gil-Web-Cache-Deception-Attack-wp.pdf) diff --git a/5.0/en/0x17-V9-Communications.md b/5.0/en/0x17-V9-Communications.md index 444b13e0e1..cbbf7a1b94 100644 --- a/5.0/en/0x17-V9-Communications.md +++ b/5.0/en/0x17-V9-Communications.md @@ -2,13 +2,13 @@ ## Control Objective -Ensure that a verified application meets the following high level requirements: +Ensure that a verified application meets the following high-level requirements: -* Require TLS or strong encryption, independent of sensitivity of the content. +* Require TLS or strong encryption, independent of the sensitivity of the content. * Follow the latest guidance, including: * Configuration advice * Preferred algorithms and ciphers -* Avoid weak or soon to be deprecated algorithms and ciphers, except as a last resort. +* Avoid weak or soon-to-be deprecated algorithms and ciphers, except as a last resort. * Disable deprecated or known insecure algorithms and ciphers. Within these requirements: @@ -19,7 +19,7 @@ Within these requirements: ## V9.1 HTTPS Communication with External Facing Services -Ensure all HTTP traffic to external facing services to the appliation is sent encrypted, using TLS 1.2 or later, with publically trusted certificates. +Ensure all HTTP traffic to external-facing services to the application is sent encrypted, using TLS 1.2 or later, with publically trusted certificates. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | @@ -30,7 +30,7 @@ Ensure all HTTP traffic to external facing services to the appliation is sent en ## V9.2 General Service to Service Communication Security -Server communications are more than just HTTP. Secure connections to and from other systems, such as monitoring systems, management tools, remote access and SSH, middleware, database, mainframes, partner or external source systems — must be in place. All of these must be encrypted to prevent "hard on the outside, trivially easy to intercept on the inside". +Server communications involve more than just HTTP. Secure connections to and from other systems, such as monitoring systems, management tools, remote access and SSH, middleware, database, mainframes, partner systems, or external source systems — must be in place. All of these must be encrypted to prevent "hard on the outside, trivially easy to intercept on the inside". | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | @@ -42,7 +42,7 @@ Server communications are more than just HTTP. Secure connections to and from ot ## V9.3 HTTPS Communication between Internal Services -HTTP traffic between internal facing services should also be encrypted, idealy using TLS. +HTTP traffic between internal-facing services should also be encrypted, ideally using TLS. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | @@ -52,7 +52,7 @@ HTTP traffic between internal facing services should also be encrypted, idealy u ## V9.4 General TLS Security Guidance -Use secure TLS configuration and use up to date tools to review the configuration on a regular basis. While usage of wildcard TLS certificates is not inherently insecure, but a compromise of a certificate that is deployed across all owned environments (e.g. production, staging, development, test, etc.) may lead to compromise of the security posture of the applications using it. Proper protection, management, and usage of separate TLS certificates in different environments should be employed if possible. +Use secure TLS configuration and up-to-date tools to review the configuration on a regular basis. While usage of wildcard TLS certificates is not inherently insecure, a compromise of a certificate that is deployed across all owned environments (e.g. production, staging, development, test, etc.) may lead to a compromise of the security posture of the applications using it. Proper protection, management, and usage of separate TLS certificates in different environments should be employed if possible. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | @@ -68,4 +68,4 @@ For more information, see also: * [OWASP – TLS Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html) * Notes on “Approved modes of TLS”: * In the past, the ASVS referred to the US FIPS 140 standard, but as a global standard, applying US standards can be difficult, contradictory, or confusing to apply. - * A better method of achieving compliance with section 9.1 would be to review guides such as [Mozilla's Server Side TLS](https://wiki.mozilla.org/Security/Server_Side_TLS) or [generate known good configurations](https://mozilla.github.io/server-side-tls/ssl-config-generator/), and use known and up to date TLS evaluation tools to obtain a desired level of security. + * A better method of achieving compliance with section 9.1 would be to review guides such as [Mozilla's Server Side TLS](https://wiki.mozilla.org/Security/Server_Side_TLS) or [generate known good configurations](https://mozilla.github.io/server-side-tls/ssl-config-generator/), and use known and up-to-date TLS evaluation tools to obtain a desired level of security. diff --git a/5.0/en/0x18-V10-Malicious.md b/5.0/en/0x18-V10-Malicious.md index 568d7591ae..896d437e8f 100644 --- a/5.0/en/0x18-V10-Malicious.md +++ b/5.0/en/0x18-V10-Malicious.md @@ -2,7 +2,7 @@ ## Control Objective -Ensure that code satisfies the following high level requirements: +Ensure that the code satisfies the following high-level requirements: * Malicious activity is handled securely and properly to not affect the rest of the application. * Does not have time bombs or other time-based attacks. @@ -13,7 +13,7 @@ Finding malicious code is proof of the negative, which is impossible to complete ## V10.1 Code Integrity -The best defense against malicious code is "trust, but verify". Introducing unauthorized or malicious code into code is often a criminal offence in many jurisdictions. Policies and procedures should make sanctions regarding malicious code clear. +The best defense against malicious code is "trust, but verify". Introducing unauthorized or malicious code into code is often a criminal offense in many jurisdictions. Policies and procedures should make sanctions regarding malicious code clear. Lead developers should regularly review code check-ins, particularly those that might access time, I/O, or network functions. @@ -23,7 +23,7 @@ Lead developers should regularly review code check-ins, particularly those that ## V10.2 Malicious Code Search -Malicious code is extremely rare and is difficult to detect. Manual line by line code review can assist looking for logic bombs, but even the most experienced code reviewer will struggle to find malicious code even if they know it exists. +Malicious code is extremely rare and is difficult to detect. Manual line-by-line code review can assist with detecting logic bombs, but even the most experienced code reviewers will struggle to find malicious code even if they know it exists. Complying with this section is not possible without complete access to source code, including third-party libraries. diff --git a/5.0/en/0x19-V11-BusLogic.md b/5.0/en/0x19-V11-BusLogic.md index de23a16a44..252be35239 100644 --- a/5.0/en/0x19-V11-BusLogic.md +++ b/5.0/en/0x19-V11-BusLogic.md @@ -2,15 +2,15 @@ ## Control Objective -Ensure that a verified application satisfies the following high level requirements: +Ensure that a verified application satisfies the following high-level requirements: * The business logic flow is sequential, processed in order, and cannot be bypassed. -* Business logic includes limits to detect and prevent automated attacks, such as continuous small funds transfers, or adding a million friends one at a time, and so on. -* High value business logic flows have considered abuse cases and malicious actors, and have protections against spoofing, tampering, information disclosure, and elevation of privilege attacks. +* Business logic includes limits and controls to detect and prevent automated attacks, such as continuous small funds transfers and adding a million friends one at a time. +* High-value business logic flows have considered abuse cases and malicious actors, and have protections against spoofing, tampering, information disclosure, and elevation of privilege attacks. ## V11.1 Business Logic Security -Business logic security is so individual to every application that no one checklist will ever apply. Business logic security must be designed in to protect against likely external threats - it cannot be added using web application firewalls or secure communications. We recommend the use of threat modeling during design sprints, for example using the OWASP Cornucopia or similar tools. +Business logic security is so individual to every application that no one checklist will ever apply. Business logic security must be designed into the system to protect against likely external threats - it cannot be added using web application firewalls or secure communications. We recommend the use of threat modeling during design sprints, for example using the OWASP Cornucopia or similar tools. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | diff --git a/5.0/en/0x20-V12-Files-Resources.md b/5.0/en/0x20-V12-Files-Resources.md index 81139942b9..648c95bab3 100644 --- a/5.0/en/0x20-V12-Files-Resources.md +++ b/5.0/en/0x20-V12-Files-Resources.md @@ -2,14 +2,14 @@ ## Control Objective -Ensure that a verified application satisfies the following high level requirements: +Ensure that a verified application satisfies the following high-level requirements: * Untrusted file data should be handled accordingly and in a secure manner. * Untrusted file data obtained from untrusted sources are stored outside the web root and with limited permissions. ## V12.1 File Upload -Although zip bombs are eminently testable using penetration testing techniques, they are considered L2 and above to encourage design and development consideration with careful manual testing, and to avoid automated or unskilled manual penetration testing of a denial of service condition. +Although zip bombs can be effectively tested using penetration testing techniques, they are classified as L2 and above to encourage consideration during design and development, as well as careful manual testing. This classification also aims to prevent automated or unskilled manual penetration testing from triggering a denial of service condition. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | diff --git a/5.0/en/0x21-V13-API.md b/5.0/en/0x21-V13-API.md index aebea3c0a7..58644feb76 100644 --- a/5.0/en/0x21-V13-API.md +++ b/5.0/en/0x21-V13-API.md @@ -2,7 +2,7 @@ ## Control Objective -Ensure that a verified application that uses trusted service layer APIs (commonly using JSON or XML or GraphQL) has: +Ensure that a verified application that uses trusted service layer APIs (commonly using JSON, XML or GraphQL) has: * Adequate authentication, session management and authorization of all web services. * Input validation of all parameters that transit from a lower to higher trust level. diff --git a/5.0/en/0x22-V14-Config.md b/5.0/en/0x22-V14-Config.md index 5a7e6270a8..c5b5448195 100644 --- a/5.0/en/0x22-V14-Config.md +++ b/5.0/en/0x22-V14-Config.md @@ -5,17 +5,17 @@ Ensure that a verified application has: * A secure, repeatable, automatable build environment. -* Hardened third party library, dependency and configuration management such that out of date or insecure components are not included by the application. +* Hardened third-party library, dependency, and configuration management to ensure that out-of-date or insecure components are not included in the application. -Configuration of the application out of the box should be safe to be on the Internet, which means a safe out of the box configuration. +Configuration of the application out of the box should be safe to be on the Internet, which means a safe out-of-the-box configuration. ## V14.1 Build and Deploy -Build pipelines are the basis for repeatable security - every time something insecure is discovered, it can be resolved in the source code, build or deployment scripts, and tested automatically. We are strongly encouraging the use of build pipelines with automatic security and dependency checks that warn or break the build to prevent known security issues being deployed into production. Manual steps performed irregularly directly leads to avoidable security mistakes. +Build pipelines are the basis for repeatable security - every time something insecure is discovered, it can be resolved in the source code, build or deployment scripts, and tested automatically. We strongly encourage the use of build pipelines with automatic security and dependency checks that warn about or break the build to prevent known security issues from being deployed into production. Manual steps performed irregularly can directly lead to avoidable security mistakes. -As the industry moves to a DevSecOps model, it is important to ensure the continued availability and integrity of deployment and configuration to achieve a "known good" state. In the past, if a system was hacked, it would take days to months to prove that no further intrusions had taken place. Today, with the advent of software defined infrastructure, rapid A/B deployments with zero downtime, and automated containerized builds, it is possible to automatically and continuously build, harden, and deploy a "known good" replacement for any compromised system. +As the industry moves to a DevSecOps model, it is important to ensure the continued availability and integrity of deployment and configuration to achieve a "known good" state. In the past, if a system was hacked, it would take days to months to prove that no further intrusions had taken place. Today, with the advent of software-defined infrastructure, rapid A/B deployments with zero downtime, and automated containerized builds, it is possible to automatically and continuously build, harden, and deploy a "known good" replacement for any compromised system. -If traditional models are still in place, then manual steps must be taken to harden and back up that configuration to allow the compromised systems to be quickly replaced with high integrity, uncompromised systems in a timely fashion. +If traditional models are still in place, then manual steps must be taken to harden and back up that configuration to allow the compromised systems to be quickly replaced with high-integrity, uncompromised systems in a timely fashion. Compliance with this section requires an automated build system, and access to build and deployment scripts. @@ -48,11 +48,11 @@ Note: At Level 1, 14.2.1 compliance relates to observations or detections of cli | **14.2.7** | [ADDED] Verify that third party components are sourced separately from internally owned and developed applications to prevent dependency confusion attacks. | ✓ | ✓ | ✓ | 427 | | **14.2.8** | [ADDED, SPLIT FROM 14.2.6] Verify that risky third party libraries or those with a history of vulnerabilities are sandboxed away from the most sensitive system modules/services so that even if a vulnerability in the library was successfully exploited, the sensitive system modules/services would not be compromised. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | | ✓ | 1061 | -Note: Certain languages and package managers, have ecosystems that require the identification of packages using multiple factors (e.g groupId and artifactId). This would allow the build process to more specifically identify a resource. In other cases, package managers operate by the order of repositories or mirrors included. Consult your package managers to specifically indicate search order. +Note: Certain languages and package managers, have ecosystems that require the identification of packages using multiple factors (e.g. groupId and artifactId). This would allow the build process to more specifically identify a resource. In other cases, package managers operate by the order of repositories or mirrors included. Consult your package managers to specifically indicate the search order. ## V14.3 Unintended Information Leakage -Configurations for production should be hardened to protect against common attacks, such as debug consoles, raise the bar for Cross-site Scripting (XSS) and Remote File Inclusion (RFI) attacks, and to eliminate trivial information discovery "vulnerabilities" that are the unwelcome hallmark of many penetration testing reports. Many of these issues are rarely rated as a significant risk, but they are chained together with other vulnerabilities. If these issues are not present by default, it raises the bar before most attacks can succeed. +Configurations for production should be hardened to protect against common attacks. Measures should include disabling debug consoles, raising the bar against Cross-site Scripting (XSS) and Remote File Inclusion (RFI) attacks, and eliminating trivial information discovery "vulnerabilities" that often litter penetration testing reports. Many of these issues are rarely rated as a significant risk, but they are chained together with other vulnerabilities. If these issues are not present by default, it raises the bar before most attacks can succeed. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | @@ -109,6 +109,6 @@ For more information, see also: * [OWASP Web Security Testing Guide 4.1: Testing for HTTP Verb Tampering]( https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03-Testing_for_HTTP_Verb_Tampering.html) * [OWASP Web Security Testing Guide 4.1: Configuration and Deployment Management Testing](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README.html) -* [Defining multiple repositories in maven](https://maven.apache.org/guides/mini/guide-multiple-repositories.html) +* [Defining multiple repositories in Maven](https://maven.apache.org/guides/mini/guide-multiple-repositories.html) * [Software Component Verification Standard V2 L1-3 requirements](https://github.com/OWASP/Software-Component-Verification-Standard/blob/master/en/0x11-V2-Software_Bill_of_Materials.md) * [Tips to Reduce the Attack Surface When Using Third-Party Libraries](https://www.slideshare.net/KatyAnton1/tips-to-reduce-the-attack-surface-when-using-thirdparty-libraries) diff --git a/5.0/en/0x50-V50-Web-Frontend-Security.md b/5.0/en/0x50-V50-Web-Frontend-Security.md index 85a618944e..4035ca4957 100644 --- a/5.0/en/0x50-V50-Web-Frontend-Security.md +++ b/5.0/en/0x50-V50-Web-Frontend-Security.md @@ -1,6 +1,6 @@ # V50 Web Frontend Security -The category focuses on requirements which protect against attacks that are executed via a web frontend for an application. These requirements will not be relevant for machine-to-machine solutions. +The category focuses on requirements that protect against attacks that are executed via a web frontend for an application. These requirements will not be relevant for machine-to-machine solutions. ## V50.1 Site Isolation Architecture @@ -67,6 +67,6 @@ For more information, see also: * [OWASP Content Security Policy Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) * [Exploiting CORS misconfiguration for BitCoins and Bounties](https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) -* [Sandboxing third party components](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html#sandboxing-content) +* [Sandboxing third-party components](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html#sandboxing-content) * [OWASP Secure Headers Project](https://owasp.org/www-project-secure-headers/) * [OWASP Cross-Site Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) diff --git a/5.0/en/0x90-Appendix-A_Glossary.md b/5.0/en/0x90-Appendix-A_Glossary.md index f48177c0af..94f10cddc2 100644 --- a/5.0/en/0x90-Appendix-A_Glossary.md +++ b/5.0/en/0x90-Appendix-A_Glossary.md @@ -1,7 +1,7 @@ # Appendix A: Glossary * **Address Space Layout Randomization** (ASLR) – A technique to make exploiting memory corruption bugs more difficult. -* **Allow list** – A list of permitted data or operations, for example a list of characters that are allowed to perform input validation. +* **Allow list** – A list of permitted data or operations, for example, a list of characters that are allowed to perform input validation. * **Application Security** – Application-level security focuses on the analysis of components that comprise the application layer of the Open Systems Interconnection Reference Model (OSI Model), rather than focusing on for example the underlying operating system or connected networks. * **Application Security Verification** – The technical assessment of an application against the OWASP ASVS. * **Application Security Verification Report** – A report that documents the overall results and supporting analysis produced by the verifier for a particular application. @@ -11,45 +11,45 @@ * **Component** – a self-contained unit of code, with associated disk and network interfaces that communicates with other components. * **Cross-Site Scripting** (XSS) – A security vulnerability typically found in web applications allowing the injection of client-side scripts into content. * **Cryptographic module** – Hardware, software, and/or firmware that implements cryptographic algorithms and/or generates cryptographic keys. -* **Common Weakness Enumeration** (CWE) - A community-developed list of common software security weaknesses. It serves as a common language, a measuring stick for software security tools, and as a baseline for weakness identification, mitigation, and prevention efforts. +* **Common Weakness Enumeration** (CWE) - A community-developed list of common software security weaknesses. It serves as a common language, a measuring stick for software security tools, and a baseline for weakness identification, mitigation, and prevention efforts. * **Design Verification** – The technical assessment of the security architecture of an application. * **Dynamic Application Security Testing** (DAST) - Technologies are designed to detect conditions indicative of a security vulnerability in an application in its running state. * **Dynamic Verification** – The use of automated tools that use vulnerability signatures to find problems during the execution of an application. -* **Fast IDentity Online** (FIDO) - A set of authentication standards which allow a variety of different authentication methods to be used including biometrics, Trusted Platform Modules (TPMs), USB security tokens, etc. +* **Fast IDentity Online** (FIDO) - A set of authentication standards that allow a variety of different authentication methods to be used including biometrics, Trusted Platform Modules (TPMs), USB security tokens, etc. * **Globally Unique Identifier** (GUID) – a unique reference number used as an identifier in software. -* **Hyper Text Transfer Protocol** (HTTPS) – An application protocol for distributed, collaborative, hypermedia information systems. It is the foundation of data communication for the World Wide Web. -* **Hardcoded keys** – Cryptographic keys which are stored on the filesystem, be it in code, comments or files. -* **Hardware Security Module** (HSM) - Hardware component which is able to store cryptographic keys and other secrets in a protected manner. +* **HyperText Transfer Protocol** (HTTPS) – An application protocol for distributed, collaborative, hypermedia information systems. It is the foundation of data communication for the World Wide Web. +* **Hardcoded keys** – Cryptographic keys that are stored on the filesystem, be it in code, comments or files. +* **Hardware Security Module** (HSM) - Hardware component that stores cryptographic keys and other secrets in a protected manner. * **Hibernate Query Language** (HQL) - A query language that is similar in appearance to SQL used by the Hibernate ORM library. * **Input Validation** – The canonicalization and validation of untrusted user input. * **Malicious Code** – Code introduced into an application during its development unbeknownst to the application owner, which circumvents the application's intended security policy. Not the same as malware such as a virus or worm! * **Malware** – Executable code that is introduced into an application during runtime without the knowledge of the application user or administrator. * **Open Worldwide Application Security Project** (OWASP) – The Open Worldwide Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. See: [https://www.owasp.org/](https://www.owasp.org/). -* **One-time Password** (OTP) - A password which is uniquely generated to be used on a single occasion. +* **One-time Password** (OTP) - A password that is uniquely generated to be used on a single occasion. * **Object-relational Mapping** (ORM) - A system used to allow a relational/table-based database to be referenced and queried within an application program using an application-compatible object model. -* **Password-Based Key Derivation Function 2** (PBKDF2) - A special one-way algorithm used to create a strong cryptographic key from an input text (such as a password) and an additional random salt value and can therefore be used make it harder to crack a password offline if the resulting value is stored instead of the original password. +* **Password-Based Key Derivation Function 2** (PBKDF2) - A special one-way algorithm used to create a strong cryptographic key from an input text (such as a password) and an additional random salt value and can therefore be used to make it harder to crack a password offline if the resulting value is stored instead of the original password. * **Personally Identifiable Information** (PII) - is information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context. * **Position-independent executable** (PIE) - A body of machine code that, being placed somewhere in the primary memory, executes properly regardless of its absolute address. * **Public Key Infrastructure** (PKI) - An arrangement that binds public keys with respective identities of entities. The binding is established through a process of registration and issuance of certificates at and by a certificate authority (CA). -* **Public Switched Telephone Network** (PSTN) - The traditional telephone network including both fixed-line telephones and mobile telephones. -* **Relying Party** (RP) - Generally an application which is relying on a user having authenticated against a separate authentication provider. The application is relying on some sort of token or set of signed assertions provided by that authentication provider to trust that the user is who they say they are. +* **Public Switched Telephone Network** (PSTN) - The traditional telephone network that includes both fixed-line telephones and mobile telephones. +* **Relying Party** (RP) - Generally an application which is relying on a user having authenticated against a separate authentication provider. The application relies on some sort of token or set of signed assertions provided by that authentication provider to trust that the user is who they say they are. * **Static application security testing** (SAST) - A set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the “inside out” in a nonrunning state. -* **Software development lifecycle** (SDLC) - The step by step process by which software is developed going from the initial requirements to deployment and maintainance. +* **Software development lifecycle** (SDLC) - The step-by-step process by which software is developed going from the initial requirements to deployment and maintenance. * **Security Architecture** – An abstraction of an application's design that identifies and describes where and how security controls are used, and also identifies and describes the location and sensitivity of both user and application data. * **Security Configuration** – The runtime configuration of an application that affects how security controls are used. * **Security Control** – A function or component that performs a security check (e.g. an access control check) or when called results in a security effect (e.g. generating an audit record). -* **Server-side Request Forgery** (SSRF) - An attack which abuses functionality on the server to read or update internal resources by supplying or modifying a URL which the code running on the server will read or submit data to. -* **Single Sign-on Authentication** (SSO) - This occurs when a user logs into one application and is then automatically logged in to other applications without having to re-authenticate. For example, when you login to Google, when accessing other Google services such as YouTube, Google Docs, and Gmail you will be automatically logged in. -* **SQL Injection** (SQLi) – A code injection technique used to attack data driven applications, in which malicious SQL statements are inserted into an entry point. +* **Server-side Request Forgery** (SSRF) - An attack that abuses functionality on the server to read or update internal resources. The attacker supplies or modifies a URL, which the code running on the server will read or submit data to. +* **Single Sign-on Authentication** (SSO) - This occurs when a user logs into one application and is then automatically logged into other applications without having to re-authenticate. For example, when you log into Google, you will be automatically logged into other Google services such as YouTube, Google Docs, and Gmail. +* **SQL Injection** (SQLi) – A code injection technique used to attack data-driven applications, in which malicious SQL statements are inserted into an entry point. * **SVG** - Scalable Vector Graphics. * **Time-based OTP** - A method of generating an OTP where the current time acts as part of the algorithm to generate the password. * **Threat Modeling** - A technique consisting of developing increasingly refined security architectures to identify threat agents, security zones, security controls, and important technical and business assets. * **Transport Layer Security** (TLS) – Cryptographic protocols that provide communication security over a network connection. -* **Trusted Platform Module** (TPM) - A type of HSM which is usually attached to a larger hardware component such as a motherboard and acts as the "root of trust" for that system. +* **Trusted Platform Module** (TPM) - A type of HSM that is usually attached to a larger hardware component such as a motherboard and acts as the "root of trust" for that system. * **Two-factor authentication** (2FA) - This adds a second level of authentication to an account log-in. * **Universal 2nd Factor** (U2F) - One of the standards created by FIDO specifically for allowing a USB or NFC security key to be used as a 2nd authentication factor. * **URI/URL/URL fragments** – A Uniform Resource Identifier is a string of characters used to identify a name or a web resource. A Uniform Resource Locator is often used as a reference to a resource. * **Verifier** – The person or team that is reviewing an application against the OWASP ASVS requirements. -* **What You See Is What You Get** (WYSIWYG) - A type of rich content editor which shows how the content will actually look when rendered rather than showing the coding used to govern the rendering. +* **What You See Is What You Get** (WYSIWYG) - A type of rich content editor that shows how the content will actually look when rendered rather than showing the coding used to govern the rendering. * **X.509 Certificate** – An X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer or service identity contained within the certificate. -* **XML eXternal Entity** (XXE) - A type of XML entity that can access local or remote content via a declared system identifier. This may load to various injection attacks. +* **XML eXternal Entity** (XXE) - A type of XML entity that can access local or remote content via a declared system identifier. This may lead to various injection attacks. diff --git a/5.0/en/0x91-Appendix-B_References.md b/5.0/en/0x91-Appendix-B_References.md index 7437dc3648..a0fdd1babb 100644 --- a/5.0/en/0x91-Appendix-B_References.md +++ b/5.0/en/0x91-Appendix-B_References.md @@ -12,7 +12,7 @@ The following OWASP projects are most likely to be useful to users/adopters of t ## OWASP Cheat Sheet Series project -[This project](https://owasp.org/www-project-cheat-sheets/) has a number of cheat sheets which will be relevant for different topics in the ASVS. +[This project](https://owasp.org/www-project-cheat-sheets/) has several cheat sheets that will be relevant to different topics in the ASVS. There is a mapping to the ASVS which can be found here: [https://cheatsheetseries.owasp.org/IndexASVS.html](https://cheatsheetseries.owasp.org/IndexASVS.html) @@ -32,7 +32,7 @@ There is a mapping to the ASVS which can be found here: [https://cheatsheetserie ## Others -Similarly, the following web sites are most likely to be useful to users/adopters of this standard +Similarly, the following websites are most likely to be useful to users/adopters of this standard 1. SecLists Github: [https://github.com/danielmiessler/SecLists](https://github.com/danielmiessler/SecLists) 2. MITRE Common Weakness Enumeration: [https://cwe.mitre.org/](https://cwe.mitre.org/)