嘗試修復源代碼漏洞（CWE：113）； 類別：輸入驗證和表示 - 標頭操作：Cookie

Question

我正在嘗試修復我的 React 前端應用程序代碼中的漏洞（CWE：113，此處有詳細信息）。

也很難從工具的漏洞掃描消息中找到它（在 *.js 文件的第 1 行說）：

VULNERABILITY INFO
Category: Input Validation and Representation - Header Manipulation: Cookies
CWE: 113
Severity: High
Title:
Location: vendor/vendor.8c61c0dc12bc45759cf4.js : 1
Summary: The method yM() in vendor.8c61c0dc12bc45759cf4.js includes unvalidated data in an HTTP cookie on line 1. This enables Cookie manipulation attacks and can lead to other HTTP Response header manipulation attacks like: cache-poisoning, cross-site scripting, cross-user defacement, page hijacking or open redirect.Including unvalidated data in Cookies can lead to HTTP Response header manipulation and enable cache-poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation or open redirect.
Explanation: Cookie Manipulation vulnerabilities occur when:

1. Data enters a web application through an untrusted source, most frequently an HTTP request.

In this case, the data enters at in vendor.8c61c0dc12bc45759cf4.js on line 1.


2. The data is included in an HTTP cookie sent to a web user without being validated.

In this case, the data is sent at in vendor.8c61c0dc12bc45759cf4.js on line 1.

As with many software security vulnerabilities, cookie manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP cookie.

Cookie Manipulation: When combined with attacks like cross-site request forgery, attackers may change, add to, or even overwrite a legitimate user's cookies.

Being an HTTP Response header, Cookie manipulation attacks can also lead to other types of attacks like:

HTTP Response Splitting:
One of the most common Header Manipulation attacks is HTTP Response Splitting. To mount a successful HTTP Response Splitting exploit, the application must allow input that contains CR (carriage return, also given by %0d or \r) and LF (line feed, also given by %0a or \n)characters into the header. These characters not only give attackers control of the remaining headers and body of the response the application intends to send, but also allows them to create additional responses entirely under their control.

Many of today's modern application servers will prevent the injection of malicious characters into HTTP headers. For example, recent versions of Apache Tomcat will throw an IllegalArgumentException if you attempt to set a header with prohibited characters. If your application server prevents setting headers with new line characters, then your application is not vulnerable to HTTP Response Splitting. However, solely filtering for new line characters can leave an application vulnerable to Cookie Manipulation or Open Redirects, so care must still be taken when setting HTTP headers with user input.

Example: The following code segment reads the name of the author of a weblog entry, author, from an HTTP request and sets it in a cookie header of an HTTP response.


author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...


Assuming a string consisting of standard alphanumeric characters, such as "Jane Smith", is submitted in the request the HTTP response including this cookie might take the following form:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


However, because the value of the cookie is formed of unvalidated user input the response will only maintain this form if the value submitted for AUTHOR_PARAM does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", then the HTTP response would be split into two responses of the following form:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Clearly, the second response is completely controlled by the attacker and can be constructed with any header and body content desired. The ability of attacker to construct arbitrary HTTP responses permits a variety of resulting attacks, including: cross-user defacement, web and browser cache poisoning, cross-site scripting, and page hijacking.

Cross-User Defacement: An attacker can make a single request to a vulnerable server that will cause the server to create two responses, the second of which may be misinterpreted as a response to a different request, possibly one made by another user s
Recommendations: The solution to prevent Cookie Manipulation is to ensure that input validation occurs in the required places and checks for the correct properties.

Since Header Manipulation vulnerabilities like cookie manipulation occur when an application includes malicious data in its output, one logical approach is to validate data immediately before it leaves the application. However, because web applications often have complex and intricate code for generating responses dynamically, this method is prone to errors of omission (missing validation). An effective way to mitigate this risk is to also perform input validation for Header Manipulation.

Web applications must validate all input to prevent other vulnerabilities, such as SQL injection, so augmenting an application's existing input validation mechanism to include checks for Header Manipulation is generally relatively easy. Despite its value, input validation for Header Manipulation does not take the place of rigorous output validation. An application might accept input through a shared data store or other trusted source, and that data store might accept input from a source that does not perform adequate input validation. Therefore, the application cannot implicitly rely on the safety of this or any other data. This means that the best way to prevent Header Manipulation vulnerabilities is to validate everything that enters the application or leaves the application destined for the user.

The most secure approach to validation for Header Manipulation is to create an allow list of safe characters that can appear in HTTP response headers and accept input composed exclusively of characters in the approved set. For example, a valid name might only include alphanumeric characters or an account number might only include digits 0-9.

A more flexible, but less secure approach is to implement a deny list, which selectively rejects or escapes potentially dangerous characters before using the input. To form such a list, you first need to understand the set of characters that hold special meaning in HTTP response headers. Although the CR and LF characters are at the heart of an HTTP response splitting attack, other characters, such as ':' (colon) and '=' (equal), have special meaning in response headers as well.

After you identify the correct points in an application to perform validation for Header Manipulation attacks and what special characters the validation should consider, the next challenge is to identify how your validation handles special characters. The application should reject any input destined to be included in HTTP response headers that contains special characters, particularly CR and LF, as invalid.

Many application servers attempt to limit an application's exposure to HTTP response splitting vulnerabilities by providing implementations for the functions responsible for setting HTTP headers and cookies that perform validation for the characters essential to an HTTP response splitting attack. Do not rely on the server running your application to make it secure. For any developed application, there are no guarantees about which application servers it will run on during its lifetime. As standards and known exploits evolve, there are no guarantees that application servers will continue to stay in sync.

我從漏洞詳細信息中了解到必須處理 cookie 的設置，但我在我的代碼中將 cookie 設置為（使用 encodeURIComponent）

document.cookie = encodeURIComponent(name)+"="+encodeURIComponent(value)

我還瀏覽了另一個有一定解決方案的stackoverflow 帖子，但對我來說運氣不好。

這個漏洞還有更多嗎？

TIA

Answer 1

在摘要消息中，它在發生漏洞的 vendor.8c61c0dc12bc45759cf4.js 中發現了方法 yM()。 我猜您必須查找傳遞給該方法的任何參數或數據點並對其進行驗證。 在 CWE113 之后，您應該檢查該數據並驗證它不包含任何此字符集：

當 HTTP 請求包含意外的 CR 和 LF 字符時，服務器可能會以輸出流進行響應，該輸出流被解釋為將流“拆分”為兩個不同的 HTTP 消息，而不是一個。 CR 是回車，也由 %0d 或 \r 給出，LF 是換行，也由 %0a 或 \n 給出。 除了 CR 和 LF 字符外，還可以使用其他有效/RFC 兼容的特殊字符和唯一字符編碼，例如 HT（水平制表符，也由 %09 或 \t 給出）和 SP（空格，也由 + 號或%20).