From ef0e0f5940398f225a1ddb5dd0f957ab43137979 Mon Sep 17 00:00:00 2001 From: Elar Lang <47597707+elarlang@users.noreply.github.com> Date: Sun, 3 Nov 2024 09:44:50 +0200 Subject: [PATCH] Resolve #2214 by correcting HTTP header vs HTTP header field (#2217) Co-authored-by: Elar Lang --- 5.0/en/0x12-V3-Session-management.md | 2 +- ...0x13-V5-Validation-Sanitization-Encoding.md | 6 +++--- 5.0/en/0x16-V8-Data-Protection.md | 6 +++--- 5.0/en/0x20-V12-Files-Resources.md | 4 ++-- 5.0/en/0x21-V13-API.md | 10 +++++----- 5.0/en/0x50-V50-Web-Frontend-Security.md | 18 +++++++++--------- 6 files changed, 23 insertions(+), 23 deletions(-) diff --git a/5.0/en/0x12-V3-Session-management.md b/5.0/en/0x12-V3-Session-management.md index 411f38532f..63df7ca404 100644 --- a/5.0/en/0x12-V3-Session-management.md +++ b/5.0/en/0x12-V3-Session-management.md @@ -46,7 +46,7 @@ TLS or another secure transport channel is mandatory for session management. Thi | # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---: | :---: | :---: | :---: | | **3.4.1** | Verify that cookie-based session tokens have the 'Secure' attribute set. | ✓ | ✓ | ✓ | 614 | 7.1.1 | -| **3.4.2** | [MODIFIED] Verify that cookie-based session tokens are not readable by client-side scripts. The session token cookie should have the 'HttpOnly' attribute set and the session token value should only be transferred to the client via the Set-Cookie header. | ✓ | ✓ | ✓ | 1004 | 7.1.1 | +| **3.4.2** | [MODIFIED] Verify that cookie-based session tokens are not readable by client-side scripts. The session token cookie should have the 'HttpOnly' attribute set and the session token value should only be transferred to the client via the Set-Cookie header field. | ✓ | ✓ | ✓ | 1004 | 7.1.1 | | **3.4.3** | Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks. | ✓ | ✓ | ✓ | 1275 | 7.1.1 | | **3.4.4** | Verify that cookie-based session tokens use the "__Host-" prefix so cookies are only sent to the host that initially set the cookie. | ✓ | ✓ | ✓ | 16 | 7.1.1 | | **3.4.5** | [DELETED, DEPRECATED BY 50.1.1] | | | | | | diff --git a/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md b/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md index 3c0f59558f..cbd0f05436 100644 --- a/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md +++ b/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md @@ -10,7 +10,7 @@ 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. +Everything the application uses or processes must be handled as user input, including HTML form fields, REST requests, URL parameters, HTTP header fields, 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. @@ -18,7 +18,7 @@ Input validation provides valuable hygiene for the application in making sure th | # | 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 | +| **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 header fields). | ✓ | ✓ | ✓ | 235 | | **5.1.2** | [MOVED TO 10.4.4] | | | | | | **5.1.3** | [MODIFIED] Verify that all input is validated using positive validation, against an allowed list of values, patterns or ranges to enforce business or functional expectations for that input. | ✓ | ✓ | ✓ | 20 | | **5.1.4** | [MODIFIED, SPLIT TO 5.1.7] Verify that data items with an expected structure are validated according to the pre-defined rules. | ✓ | ✓ | ✓ | 20 | @@ -59,7 +59,7 @@ In many cases, software libraries will include safe or safer functions which wil | # | 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, CSS, or HTTP headers, to avoid changing the message or document structure. | ✓ | ✓ | ✓ | 116 | +| **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, CSS, or HTTP header fields, to avoid changing the message or document structure. | ✓ | ✓ | ✓ | 116 | | **5.3.2** | [DELETED, DUPLICATE OF 14.4.1] | | | | | | **5.3.3** | [MODIFIED, SPLIT TO 50.5.2] Verify that output encoding or escaping is used when dynamically building JavaScript content (including JSON), to avoid changing the message or document structure (to avoid JavaScript and JSON injection). | ✓ | ✓ | ✓ | | | **5.3.4** | [MODIFIED] Verify that data selection or database queries (e.g. SQL, HQL, NoSQL, Cypher) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from SQL Injection and other database injection attacks. This should also be considered when writing stored procedures. | ✓ | ✓ | ✓ | 89 | diff --git a/5.0/en/0x16-V8-Data-Protection.md b/5.0/en/0x16-V8-Data-Protection.md index eaa90fcd2b..2e9b4b9fd5 100644 --- a/5.0/en/0x16-V8-Data-Protection.md +++ b/5.0/en/0x16-V8-Data-Protection.md @@ -31,7 +31,7 @@ Ensure that a verified application satisfies the following high-level data prote | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | -| **8.2.1** | [MODIFIED] Verify that the application sets sufficient anti-caching headers (i.e. Cache-Control: no-store) so that sensitive data is not cached in browsers. | ✓ | ✓ | ✓ | 525 | +| **8.2.1** | [MODIFIED] Verify that the application sets sufficient anti-caching HTTP response header fields (i.e. Cache-Control: no-store) so that sensitive data is not cached in browsers. | ✓ | ✓ | ✓ | 525 | | **8.2.2** | [MODIFIED, MERGED FROM 3.2.3] Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data, with the exception of session identifiers. | ✓ | ✓ | ✓ | 922 | | **8.2.3** | [MODIFIED] Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated. The "Clear-Site-Data header" may be able to help with this but the client-side should also be able to clear up if the server connection is lost. | ✓ | ✓ | ✓ | 922 | @@ -45,7 +45,7 @@ Note: Privacy regulations and laws, such as the Australian Privacy Principles AP | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | -| **8.3.1** | [MODIFIED, MERGED FROM 3.1.1, 13.1.3] Verify that sensitive data is only sent to the server in the HTTP message body or headers and that the URL and query string do not contain sensitive information, such as an API key or session token. | ✓ | ✓ | ✓ | 598 | +| **8.3.1** | [MODIFIED, MERGED FROM 3.1.1, 13.1.3] Verify that sensitive data is only sent to the server in the HTTP message body or header fields and that the URL and query string do not contain sensitive information, such as an API key or session token. | ✓ | ✓ | ✓ | 598 | | **8.3.2** | [MODIFIED, SPLIT TO 8.3.9, LEVEL L1 > L3] Verify that users have a method to remove their data on demand. | | | ✓ | | | **8.3.3** | [MODIFIED, LEVEL L1 > L3] Verify that the application provides guidance regarding how it collects and uses of personal data and that users have to provide opt-in consent for this use. | | | ✓ | | | **8.3.4** | [DELETED, MERGED TO 1.8.1] | | | | | @@ -63,7 +63,7 @@ When considering data protection, a primary consideration should be around bulk For more information, see also: -* [Consider using the 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 header fields](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/) diff --git a/5.0/en/0x20-V12-Files-Resources.md b/5.0/en/0x20-V12-Files-Resources.md index 12914a0cf8..6508de57ba 100644 --- a/5.0/en/0x20-V12-Files-Resources.md +++ b/5.0/en/0x20-V12-Files-Resources.md @@ -50,8 +50,8 @@ Although zip bombs can be effectively tested using penetration testing technique | :---: | :--- | :---: | :---: | :---: | :---: | | **12.5.1** | [MOVED TO 14.3.6] | | | | | | **12.5.2** | [MOVED TO 50.5.1] | | | | | -| **12.5.3** | [MODIFIED, MOVED FROM 12.3.4] Verify that the application validates or ignores user-submitted filenames, including in a JSON, JSONP, or URL parameter and specifies a filename in the Content-Disposition header in the response. | ✓ | ✓ | ✓ | 641 | -| **12.5.4** | [ADDED] Verify that file names served (e.g., in HTTP response headers or email attachments) are encoded or sanitized (e.g., following RFC 6266) to preserve document structure and prevent injection attacks. | ✓ | ✓ | ✓ | | +| **12.5.3** | [MODIFIED, MOVED FROM 12.3.4] Verify that the application validates or ignores user-submitted filenames, including in a JSON, JSONP, or URL parameter and specifies a filename in the Content-Disposition header field in the response. | ✓ | ✓ | ✓ | 641 | +| **12.5.4** | [ADDED] Verify that file names served (e.g., in HTTP response header fields or email attachments) are encoded or sanitized (e.g., following RFC 6266) to preserve document structure and prevent injection attacks. | ✓ | ✓ | ✓ | | ## V12.6 SSRF Protection diff --git a/5.0/en/0x21-V13-API.md b/5.0/en/0x21-V13-API.md index 5197e030e5..d53c2a577b 100644 --- a/5.0/en/0x21-V13-API.md +++ b/5.0/en/0x21-V13-API.md @@ -57,7 +57,7 @@ GraphQL is becoming more common as a way of creating data rich clients which are | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | | **13.5.1** | [ADDED] Verify that WebSocket over TLS (wss) is used for all WebSocket connections. | ✓ | ✓ | ✓ | 319 | -| **13.5.2** | [ADDED] Verify that, during the initial HTTP WebSocket handshake, the Origin header is checked against a list of origins allowed for the application. | ✓ | ✓ | ✓ | 346 | +| **13.5.2** | [ADDED] Verify that, during the initial HTTP WebSocket handshake, the Origin header field is checked against a list of origins allowed for the application. | ✓ | ✓ | ✓ | 346 | | **13.5.3** | [ADDED] Verify that, if the application's standard session management cannot be used, dedicated tokens are being used for this which comply with the relevant Session Management security requirements. | ✓ | ✓ | ✓ | 331 | | **13.5.4** | [ADDED] Verify that dedicated WebSocket session management tokens are initially obtained or validated through the previously authenticated HTTPS session when transitioning an existing HTTPS session to a WebSocket channel. | ✓ | ✓ | ✓ | 319 | @@ -67,15 +67,15 @@ GraphQL is becoming more common as a way of creating data rich clients which are | :---: | :--- | :---: | :---: | :---: | :---: | | **13.6.1** | [MODIFIED, MOVED FROM 14.5.1] Verify that the application only responds to HTTP methods in use by the application or by the API (including OPTIONS during preflight requests) and unused methods (e.g. TRACE) are blocked. | ✓ | ✓ | ✓ | 749 | | **13.6.2** | [MODIFIED, MOVED FROM 13.2.1] Verify that HTTP requests using the HEAD, OPTIONS, TRACE or GET verb do not modify any backend data structure or perform any state-changing actions. These requests are safe methods and should therefore not have any side effects. | ✓ | ✓ | ✓ | 650 | -| **13.6.3** | [ADDED] Verify that all application components, including load balancers, firewalls, and application servers, comply with RFC 2616 by ignoring the Content-Length header when a Transfer-Encoding header is present, to prevent HTTP Request Smuggling. | | ✓ | ✓ | 444 | -| **13.6.4** | [ADDED] Verify that any HTTP headers used by the application and defined by intermediary devices like load balancers or proxies, such as X-Real-IP and X-Forwarded-*, cannot be overridden by the end-user. | | ✓ | ✓ | 346 | +| **13.6.3** | [ADDED] Verify that all application components, including load balancers, firewalls, and application servers, comply with RFC 2616 by ignoring the Content-Length header field when a Transfer-Encoding header field is present, to prevent HTTP Request Smuggling. | | ✓ | ✓ | 444 | +| **13.6.4** | [ADDED] Verify that any HTTP header field used by the application and defined by intermediary devices like load balancers or proxies, such as X-Real-IP and X-Forwarded-*, cannot be overridden by the end-user. | | ✓ | ✓ | 346 | ## V13.7 HTTP/2 | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | -| **13.7.1** | [ADDED] Verify that the value in the Content-Length request header matches the calculated length using the built-in mechanism. | ✓ | ✓ | ✓ | 400 | -| **13.7.2** | [ADDED] Verify that all Transfer-Encoding headers are stripped from the message or that the request is blocked entirely. | ✓ | ✓ | ✓ | | +| **13.7.1** | [ADDED] Verify that the value in the Content-Length request header field matches the calculated length using the built-in mechanism. | ✓ | ✓ | ✓ | 400 | +| **13.7.2** | [ADDED] Verify that all Transfer-Encoding header fields are stripped from the message or that the request is blocked entirely. | ✓ | ✓ | ✓ | | | **13.7.3** | [ADDED] Verify that a full CRLF (\r\n) sequence is neutralized inside a HTTP/2 header. | ✓ | ✓ | ✓ | 113 | ## References diff --git a/5.0/en/0x50-V50-Web-Frontend-Security.md b/5.0/en/0x50-V50-Web-Frontend-Security.md index 4f0387cecb..77617e3b35 100644 --- a/5.0/en/0x50-V50-Web-Frontend-Security.md +++ b/5.0/en/0x50-V50-Web-Frontend-Security.md @@ -12,14 +12,14 @@ The category focuses on requirements that protect against attacks that are execu | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | -| **50.2.1** | [MODIFIED, MOVED FROM 14.4.3] Verify that a Content-Security-Policy response header is in place that helps mitigate impact for XSS attacks like HTML, DOM, CSS, JSON, and JavaScript injection vulnerabilities. | ✓ | ✓ | ✓ | | -| **50.2.2** | [MOVED FROM 14.4.4] Verify that all responses contain a X-Content-Type-Options: nosniff header. | ✓ | ✓ | ✓ | 116 | -| **50.2.3** | [MODIFIED, MOVED FROM 14.4.5] Verify that a Strict-Transport-Security header is included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=31536000; includeSubdomains. | ✓ | ✓ | ✓ | 523 | -| **50.2.4** | [MOVED FROM 14.4.6] Verify that a suitable Referrer-Policy header is included to avoid exposing sensitive information in the URL through the Referer header to untrusted parties. | ✓ | ✓ | ✓ | 116 | +| **50.2.1** | [MODIFIED, MOVED FROM 14.4.3] Verify that a Content-Security-Policy response header field is in place that helps mitigate impact for XSS attacks like HTML, DOM, CSS, JSON, and JavaScript injection vulnerabilities. | ✓ | ✓ | ✓ | | +| **50.2.2** | [GRAMMAR, MOVED FROM 14.4.4] Verify that all responses contain a X-Content-Type-Options: nosniff header field. | ✓ | ✓ | ✓ | 116 | +| **50.2.3** | [MODIFIED, MOVED FROM 14.4.5] Verify that a Strict-Transport-Security header field is included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=31536000; includeSubdomains. | ✓ | ✓ | ✓ | 523 | +| **50.2.4** | [GRAMMAR, MOVED FROM 14.4.6] Verify that a suitable Referrer-Policy header field is included to avoid exposing sensitive information in the URL through the Referer header field to untrusted parties. | ✓ | ✓ | ✓ | 116 | | **50.2.5** | [MODIFIED, MOVED FROM 14.4.7] Verify that the content of a web application cannot be embedded in a third-party site by default and that embedding of the exact resources is only allowed where necessary by using suitable Content-Security-Policy: frame-ancestors. Note that the X-Frame-Options solution is obsoleted. | ✓ | ✓ | ✓ | 1021 | -| **50.2.6** | [ADDED, SPLIT FROM 14.5.3] Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header uses a strict allowlist of trusted origins. When "Access-Control-Allow-Origin: *" needs to be used, verify that the responses do not include any sensitive information. | ✓ | ✓ | ✓ | 183 | -| **50.2.7** | [ADDED] Verify that the Content-Security-Policy header specifies a location to report violations. | | | ✓ | | -| **50.2.8** | [ADDED] Verify that the application's top-level domain (e.g. site.tld) is added to the public HSTS preload list so that the use of TLS for the application will be built directly into the main browsers rather than only relying on the relevant HTTP response header. | | | ✓ | | +| **50.2.6** | [ADDED, SPLIT FROM 14.5.3] Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header field uses a strict allowlist of trusted origins. When "Access-Control-Allow-Origin: *" needs to be used, verify that the responses do not include any sensitive information. | ✓ | ✓ | ✓ | 183 | +| **50.2.7** | [ADDED] Verify that the Content-Security-Policy header field specifies a location to report violations. | | | ✓ | | +| **50.2.8** | [ADDED] Verify that the application's top-level domain (e.g. site.tld) is added to the public HSTS preload list so that the use of TLS for the application will be built directly into the main browsers rather than only relying on the relevant HTTP response header field. | | | ✓ | | ## V50.3 Browser Origin Separation @@ -36,7 +36,7 @@ The category should contain requirements with ideas: | :---: | :--- | :---: | :---: | :---: | :---: | | **50.3.1** | [MODIFIED, MOVED FROM 4.2.2, MERGED FROM 13.2.3] Verify that the application defends against Cross-Site Request Forgery (CSRF) attacks to protect authenticated or sensitive public functionality using the development framework's built-in anti-CSRF functionality or CSRF tokens plus additional defense in depth measures. | ✓ | ✓ | ✓ | 352 | | **50.3.2** | [ADDED] Verify that messages received by the postMessage interface are discarded if the origin of the message is not trusted, or if the syntax of the message is invalid. | | ✓ | ✓ | 346 | -| **50.3.3** | [ADDED, SPLIT FROM 14.5.3] Verify that the Origin header is validated against a defined list of allowed origins to match the desired Cross-Origin Resource Sharing (CORS) policy. | ✓ | ✓ | ✓ | 346 | +| **50.3.3** | [ADDED, SPLIT FROM 14.5.3] Verify that the Origin header field is validated against a defined list of allowed origins to match the desired Cross-Origin Resource Sharing (CORS) policy. | ✓ | ✓ | ✓ | 346 | ## V50.4 Cross-Site Script Inclusion @@ -49,7 +49,7 @@ The category should contain requirements with ideas: | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | -| **50.5.1** | [MODIFIED, MOVED FROM 12.5.2, MERGED FROM 1.12.2, 14.4.2] Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when an API, a user-uploaded file or other resource is requested directly). Possible controls could include: not serving the content unless HTTP request headers, such as Sec-Fetch-\*, indicate it is the correct context, Content-Security-Policy: sandbox, Content-Disposition: attachment, etc. | ✓ | ✓ | ✓ | | +| **50.5.1** | [MODIFIED, MOVED FROM 12.5.2, MERGED FROM 1.12.2, 14.4.2] Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when an API, a user-uploaded file or other resource is requested directly). Possible controls could include: not serving the content unless HTTP request header fields, such as Sec-Fetch-\*, indicate it is the correct context, Content-Security-Policy: sandbox, Content-Disposition: attachment, etc. | ✓ | ✓ | ✓ | | | **50.5.2** | [ADDED, SPLIT FROM 5.3.3] Verify that context-aware methods are used when handling untrusted data to avoid unintended content execution, such as executing content as HTML instead of displaying it as text. | ✓ | ✓ | ✓ | | ## V50.6 External Resource Integrity