From ecdcfece347b1db99b33ff7b6228aa4e6016a03f Mon Sep 17 00:00:00 2001 From: Josh Grossman Date: Wed, 25 Sep 2024 08:45:55 +0300 Subject: [PATCH 1/3] Final wording tweaks on V5 --- .../0x13-V5-Validation-Sanitization-Encoding.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md b/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md index e412bcdc8..f1ae4e702 100644 --- a/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md +++ b/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md @@ -2,17 +2,21 @@ ## Control Objective -The most common web application security weakness is using untrusted content in an unsafe context without any output encoding, query parameterization, or other output handling defense. This weakness leads to many of the significant vulnerabilities in web applications, such as Cross-Site Scripting (XSS), SQL injection, OS command injection, template injection, log injection, LDAP injection, and more. +The most common web application security weakness is using untrusted content in an unsafe context without first making it safe. This weakness leads to many of the significant vulnerabilities in web applications, such as Cross-Site Scripting (XSS), SQL injection, OS command injection, template injection, log injection, LDAP injection, and more. -With modern web application architecture, output encoding is more important than ever. It is difficult to provide robust input validation in certain scenarios, so the use of safer API such as parameterized queries, auto-escaping templating frameworks, or carefully chosen output encoding is critical to the security of the application. +With modern web applications, it will always be best to use safer APIs such as parameterized queries, auto-escaping templating frameworks, etc. Otherwise, or carefully performed output encoding/escaping or sanitization will be critical to the security of the application. + +This chapter also talks about Input Validation which is a powerful defense in depth mechanism for protected against unexpected, dangerous content but should not be considered as a specific security control. ## V5.1 Input Validation +< + Input can come from a variety of sources including HTML form fields, REST requests, URL parameters, HTTP headers, cookies, files on disk, databases, external APIs, etc. Properly implemented input validation controls, using positive allowlists and strong data typing, provide an important enforcement of business logic controls or functional expectations around the type of data that the app expects to receive. Business logic controls could be that a particular input should be a number which is less than 100. Functional expectations might be that a certain number should be below a certain threshold as the number governs how many times a particular loop should take place and a high number could lead to excessive processing and a potential denial of servie condition. -Input validation still provides valuable security hygiene and should be applied to all inputs where possible. However, since input validation is generally not intended to prevent specific attacks is therefore not a complete security strategy, one should also make use of sandboxing, sanitization, encoding and parameterization whenever the input is being used in a potentially dangerous context. +Input validation provides valuable security hygiene and should be applied to all inputs where possible. However, since input validation is not able to prevent specific vulnerabilities, it should be used as a primary security defense. Other techniques detailed in later sections should be used as the primary defense against specific vulnerabilities. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | @@ -27,6 +31,8 @@ Input validation still provides valuable security hygiene and should be applied ## V5.2 Sanitization and Sandboxing +< + The ideal protection against using untrusted content in an unsafe context is using context specific encoding or escaping which maintains the same semantic meaning of the unsafe content but renders it safe for use in this particular context. This is discussed in more detail in the next section. Where it is not possible to do this, other options include sanitization and sandboxing. Sanitization will involve removing potentially dangerous characters or content which in some cases could change the semantic meaning of the input but for security reasons there may be no choice. Sandboxing mauy involve ensuring that a potentially dangerous operation is contained such that even if it suffers a security vulnerability, that will not endanger the wider application. @@ -51,8 +57,12 @@ Note: The SVG format explicitly allows ECMA script in almost all contexts, so it ## V5.3 Output Encoding and Injection Prevention +< + Output encoding or escaping close or adjacent to a potentially dangerous context is critical to the security of any application. Typically, output encoding and escaping is not persisted, but rather used to render output safe to use in the appropriate interpreter for immediate use. Trying to do this too early may lead to malformed content or even render the encoding or escaping ineffective. +Ideally, safe APIs should be used which will do this automatically but otherwise the developer will need to take the required action. + | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | | **5.3.1** | [MODIFIED, SPLIT TO 5.3.13] Verify that output encoding for an HTTP response, HTML document, or XML document is relevant for the context required, such as encoding the relevant characters for HTML elements, HTML attributes, HTML comments, JavaScript, CSS, or HTTP headers, to avoid changing the message or document structure. | ✓ | ✓ | ✓ | 116 | From 7fb1a2d6c6c0660f52c9f731695714bf88e3784a Mon Sep 17 00:00:00 2001 From: Josh Grossman Date: Thu, 26 Sep 2024 13:39:38 +0300 Subject: [PATCH 2/3] Some changes based on feedback from @elarlang --- 5.0/en/0x13-V5-Validation-Sanitization-Encoding.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md b/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md index f1ae4e702..8aaab251b 100644 --- a/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md +++ b/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md @@ -2,7 +2,7 @@ ## Control Objective -The most common web application security weakness is using untrusted content in an unsafe context without first making it safe. This weakness leads to many of the significant vulnerabilities in web applications, such as Cross-Site Scripting (XSS), SQL injection, OS command injection, template injection, log injection, LDAP injection, and more. +This chapter focuses on the most common web application security weaknesses that are related to unsafe processing of untrusted data. This leads to a variety of technical vulnerabilities where the untrusted data gets interpreted using the syntax rules of the relevant interpreter. With modern web applications, it will always be best to use safer APIs such as parameterized queries, auto-escaping templating frameworks, etc. Otherwise, or carefully performed output encoding/escaping or sanitization will be critical to the security of the application. @@ -12,12 +12,11 @@ This chapter also talks about Input Validation which is a powerful defense in de < -Input can come from a variety of sources including HTML form fields, REST requests, URL parameters, HTTP headers, cookies, files on disk, databases, external APIs, etc. + Everything the application uses or processes must be handled as user input, including HTML form fields, REST requests, URL parameters, HTTP headers, cookies, files on disk, databases, external APIs, etc. Properly implemented input validation controls, using positive allowlists and strong data typing, provide an important enforcement of business logic controls or functional expectations around the type of data that the app expects to receive. Business logic controls could be that a particular input should be a number which is less than 100. Functional expectations might be that a certain number should be below a certain threshold as the number governs how many times a particular loop should take place and a high number could lead to excessive processing and a potential denial of servie condition. -Input validation provides valuable security hygiene and should be applied to all inputs where possible. However, since input validation is not able to prevent specific vulnerabilities, it should be used as a primary security defense. Other techniques detailed in later sections should be used as the primary defense against specific vulnerabilities. - +Input validation provides valuable hygiene for the application in making sure that data is received in the correct format and should be applied to all inputs where possible. However, it does not remove or replace the need to use correct encoding, escaping, or sanitization when using the data for next component or for presenting it for output. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | | **5.1.1** | [MODIFIED] Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (query string, body parameters, cookies, or headers). | ✓ | ✓ | ✓ | 235 | @@ -61,7 +60,7 @@ Note: The SVG format explicitly allows ECMA script in almost all contexts, so it Output encoding or escaping close or adjacent to a potentially dangerous context is critical to the security of any application. Typically, output encoding and escaping is not persisted, but rather used to render output safe to use in the appropriate interpreter for immediate use. Trying to do this too early may lead to malformed content or even render the encoding or escaping ineffective. -Ideally, safe APIs should be used which will do this automatically but otherwise the developer will need to take the required action. +In many cases, software libraries will include safe or safer functions which will do this automatically although it will be necessary to be sure that they are correct for the current context. | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | From 62bb8a01ecd12ace6b4f7a59c2bce7a7120c5cc7 Mon Sep 17 00:00:00 2001 From: Elar Lang <47597707+elarlang@users.noreply.github.com> Date: Thu, 26 Sep 2024 15:28:52 +0300 Subject: [PATCH 3/3] syntax corrections --- 5.0/en/0x13-V5-Validation-Sanitization-Encoding.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md b/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md index 8aaab251b..5cbc6e55a 100644 --- a/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md +++ b/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md @@ -10,13 +10,14 @@ This chapter also talks about Input Validation which is a powerful defense in de ## V5.1 Input Validation -< + Everything the application uses or processes must be handled as user input, including HTML form fields, REST requests, URL parameters, HTTP headers, cookies, files on disk, databases, external APIs, etc. Properly implemented input validation controls, using positive allowlists and strong data typing, provide an important enforcement of business logic controls or functional expectations around the type of data that the app expects to receive. Business logic controls could be that a particular input should be a number which is less than 100. Functional expectations might be that a certain number should be below a certain threshold as the number governs how many times a particular loop should take place and a high number could lead to excessive processing and a potential denial of servie condition. Input validation provides valuable hygiene for the application in making sure that data is received in the correct format and should be applied to all inputs where possible. However, it does not remove or replace the need to use correct encoding, escaping, or sanitization when using the data for next component or for presenting it for output. + | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | | **5.1.1** | [MODIFIED] Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (query string, body parameters, cookies, or headers). | ✓ | ✓ | ✓ | 235 | @@ -30,7 +31,7 @@ Input validation provides valuable hygiene for the application in making sure th ## V5.2 Sanitization and Sandboxing -< + The ideal protection against using untrusted content in an unsafe context is using context specific encoding or escaping which maintains the same semantic meaning of the unsafe content but renders it safe for use in this particular context. This is discussed in more detail in the next section. @@ -56,7 +57,7 @@ Note: The SVG format explicitly allows ECMA script in almost all contexts, so it ## V5.3 Output Encoding and Injection Prevention -< + Output encoding or escaping close or adjacent to a potentially dangerous context is critical to the security of any application. Typically, output encoding and escaping is not persisted, but rather used to render output safe to use in the appropriate interpreter for immediate use. Trying to do this too early may lead to malformed content or even render the encoding or escaping ineffective.