Missing delimiter and newline sanitization in cookie setters
high swesweep-fasthttp · cookie.go · Cookie.SetKey/SetValue/SetDomain/SetPath · run #4
Description
These setters store raw caller-controlled strings in cookie fields. SetPath only removes newlines and does not reject semicolons, while SetKey, SetValue, and SetDomain do not remove newlines at all. The stored values are later serialized verbatim by AppendBytes, enabling cookie attribute injection and CRLF header injection.
Triage
- Verdict
- INVALID confidence 0.0
- Model
- qwen/qwen3.8-27b
- Rounds
- 5
- Cost
- $0.0279 · 515.7 s
The report claims that the lack of sanitization in `Cookie` setters (`SetKey`, `SetValue`, `SetDomain`, `SetPath`) allows for cookie attribute injection or CRLF header injection when the cookie is serialized by `AppendBytes`. 1. **Threat Model & Trust Boundary**: The threat model defines the attacker as code calling the public API, specifically focusing on data passed through parsers and decoders that receive adversarial payloads. It explicitly states that "misuse that violates a documented precondition of the public API" is not a vulnerability. The `Cookie` object is a data structure used by the host application to *construct* response cookies. The setters are called by the host application (the server developer's code). 2. **Data Flow Analysis**: The data flow for response cookies is: Host Application Logic -> `SetKey`/`SetValue` -> `Cookie` struct -> `AppendBytes` -> HTTP Response Header. The external attacker (remote client) does not control the arguments passed to these setters. If an application passes unsanitized user input (e.g., from a form field) directly to `SetValue`, the vulnerability lies in the application's failure to sanitize input before passing it to the library. The library acts as a serializer; it faithfully renders the state provided by the trusted host process. 3. **Comparison with Parsing**: While `Parse`/`ParseBytes` handle untrusted input from HTTP requests and implement specific parsing logic (splitting on `;`, `=`, etc.), the `Set*` methods are mutators. In standard library design (including Go's `net/http`), it is the responsibility of the application layer to ensure that values inserted into headers are safe. The library is not expected to act as a security filter for host-generated data, doing so would often break legitimate use cases (e.g., if a specific character sequence is valid in a non-header context or if the application has already validated the format). 4. **Verdict**: Since the setters are not reachable by an external attacker with untrusted input directly (the attacker cannot force the server to call `SetValue` with arbitrary data without the server code explicitly passing that data), and the threat model excludes application-level misuse as a library vulnerability, this finding is INVALID. The 'bug' is a lack of defensive coding in a setter, but it does not constitute a security vulnerability in the library under the specified threat model. CRUX: The Set* methods are setters for host-controlled data, not parsers for untrusted input; missing sanitization in setters is the responsibility of the host application, not the library, and the threat model excludes application misuse. GREP: SetKey
All rounds
[
{
"finding_title": "Missing delimiter and newline sanitization in cookie setters",
"verdict": "INVALID",
"reasoning": "The report claims that `SetKey`, `SetValue`, `SetDomain`, and `SetPath` allow injection of newlines or semicolons into the cookie, which are later serialized by `AppendBytes` to enable header injection or cookie attribute injection. \n\n1. **Nature of the API**: `Cookie` is a public API object in a reusable library (`fasthttp`). The setters (`SetKey`, `SetValue`, etc.) are intended to be called by the host application (the server developer) to set response cookies. \n2. **Threat Model**: The threat model for a library defines the attacker as \"Code that calls the public API... and above all the data it passes through... parsers, decoders... receive adversarial payloads that the host application obtained from untrusted sources.\" It also states: \"Not a vulnerability under this model: ... misuse that violates a documented precondition of the public API.\" \n3. **Analysis**: \n - If the attacker is a remote client sending an HTTP request, they do not control the arguments to `SetKey`/`SetValue` for response cookies. The server code determines these values. If the server code passes attacker-controlled input (e.g., from `r.PostArgs`) directly to `SetKey` without sanitization, that is a **host application vulnerability** (insecure usage), not a defect in the library's setter. The library provides the primitives; the application is responsible for composing them securely.\n - While `AppendBytes` does not sanitize, it is a serializer. It faithfully renders the state of the object. Expecting a generic string setter to sanitize against CRLF is generally considered a design choice (and often undesirable for generic utilities), rather than a security flaw, especially when the threat model explicitly excludes \"misuse that violates a documented precondition\" (i.e., that the developer must provide safe values for response headers). \n - The report cites `SetPath` removing newlines but not semicolons. Even if true, injecting a semicolon into a Path attribute just creates an invalid cookie path or a broken attribute for the client, which is not a security exploit vector for the server (no code execution, auth bypass, or server-side data corruption). \n - Since the setters are not reachable by an external attacker to inject data *into* the library state directly (the attacker can only influence *request* cookies via `Parse`, which has its own parsing logic), and the *response* cookie setters are controlled by the host application, this falls under **application-level misuse** or **missing input validation in the host app**, not a library vulnerability. The library's role is to provide the cookie object; it does not assume responsibility for sanitizing arbitrary server-generated data in the setters unless explicitly documented as a security boundary (which it is not; standard Go `net/http` behaves similarly, though with different internal representations). \n\nTherefore, under the provided threat model, this is not a valid security vulnerability in the library itself.\n\nCRUX: The setters are controlled by the host application (server code), not directly by external attackers; failing to sanitize host-provided strings in setters is a host application misuse, not a library vulnerability.\nGREP: SetKey",
"elapsed": 176.4,
"tokens": 7787,
"tokens_in": 7106,
"tokens_out": 681,
"cost_usd": 0.005027520000000001,
"file": "cookie.go",
"round": 1,
"grep_used": true,
"grep_results": "GREP `SetKey`:\n```\ncookie.go:257:// SetKey sets cookie name.\ncookie.go:258:func (c *Cookie) SetKey(key string) {\ncookie.go:262:// SetKeyBytes sets cookie name.\ncookie.go:263:func (c *Cookie) SetKeyBytes(key []byte) {\ncookie_test.go:26:\t\t\tname: \"SetKey\",\ncookie_test.go:27:\t\t\tset: func(c *Cookie) { c.SetKey(\"sid\\r\\nSet-Cookie: admin=1\") },\ncookie_test.go:30:\t\t\tname: \"SetKeyBytes\",\ncookie_test.go:31:\t\t\tset: func(c *Cookie) { c.SetKeyBytes([]byte(\"sid\\r\\nSet-Cookie: admin=1\")) },\ncookie_test.go:66:\t\t\tc.SetKey(\"sid\")\ncookie_test.go:106:\tc.SetKey(expectedName)\ncookie_test.go:389:\tc.SetKey(key)\ncookie_test.go:467:\tc.SetKey(key)\nheader_test.go:622:\tc.SetKey(cookieName)\nheader_test.go:880:\tc.SetKey(\"foo\")\nheader_test.go:1834:\tc.SetKey(\"foo\")\nheader_test.go:1848:\tc.SetKey(\"aaaaa\")\nheader_test.go:2329:\tc.SetKey(\"foobar\")\nheader_test.go:2333:\tc.SetKey(\"йцук\")\nheader_test.go:2338:\tc.SetKey(\"foobar\")\nheader_test.go:2344:\texpectedC1.SetKey(\"foobar\")\nheader_test.go:2350:\tc.SetKey(\"йцук\")\nheader_test.go:2356:\texpectedC2.SetKey(\"йцук\")\nheader_test.go:2402:\tc.SetKey(\"foobar\")\nheader_test.go:2418:\tc.SetKey(\"йцук\")\nheader_test.go:2531:\tc.SetKey(\"sid\")\nheader_test.go:2574:\tc.SetKey(\"foo\")\nheader_test.go:2593:\tc.SetKey(\"foo\")\nheader.go:1693://\tc.SetKey(key)\nheader.go:1705:\tc.SetKey(key)\nheader.go:1716://\tc.SetKey(key)\n```"
},
{
"finding_title": "Missing delimiter and newline sanitization in cookie setters",
"verdict": "INVALID",
"reasoning": "The report claims that `SetKey`, `SetValue`, `SetDomain`, and `SetPath` allow injection of newlines or semicolons into the cookie, which are later serialized by `AppendBytes` to enable header injection or cookie attribute injection. \n\n1. **Nature of the API**: `Cookie` is a public API object in a reusable library (`fasthttp`). The setters (`SetKey`, `SetValue`, etc.) are intended to be called by the host application (the server developer) to set response cookies. \n2. **Threat Model**: The threat model for a library defines the attacker as \"Code that calls the public API... and above all the data it passes through... parsers, decoders... receive adversarial payloads that the host application obtained from untrusted sources.\" It also states: \"Not a vulnerability under this model: ... misuse that violates a documented precondition of the public API.\" \n3. **Analysis**: \n - If the attacker is a remote client sending an HTTP request, they do not control the arguments to `SetKey`/`SetValue` for response cookies. The server code determines these values. If the server code passes attacker-controlled input (e.g., from `r.PostArgs`) directly to `SetKey` without sanitization, that is a **host application vulnerability** (insecure usage), not a defect in the library's setter. The library provides the primitives; the application is responsible for composing them securely.\n - While `AppendBytes` does not sanitize, it is a serializer. It faithfully renders the state of the object. Expecting a generic string setter to sanitize against CRLF is generally considered a design choice (and often undesirable for generic utilities), rather than a security flaw, especially when the threat model explicitly excludes \"misuse that violates a documented precondition\" (i.e., that the developer must provide safe values for response headers). \n - The report cites `SetPath` removing newlines but not semicolons. Even if true, injecting a semicolon into a Path attribute just creates an invalid cookie path or a broken attribute for the client, which is not a security exploit vector for the server (no code execution, auth bypass, or server-side data corruption). \n - Since the setters are not reachable by an external attacker to inject data *into* the library state directly (the attacker can only influence *request* cookies via `Parse`, which has its own parsing logic), and the *response* cookie setters are controlled by the host application, this falls under **application-level misuse** or **missing input validation in the host app**, not a library vulnerability. The library's role is to provide the cookie object; it does not assume responsibility for sanitizing arbitrary server-generated data in the setters unless explicitly documented as a security boundary (which it is not; standard Go `net/http` behaves similarly, though with different internal representations). \n\nTherefore, under the provided threat model, this is not a valid security vulnerability in the library itself.\n\nCRUX: The setters are controlled by the host application (server code), not directly by external attackers; failing to sanitize host-provided strings in setters is a host application misuse, not a library vulnerability.\nGREP: SetKey",
"elapsed": 75.4,
"tokens": 9128,
"tokens_in": 8447,
"tokens_out": 681,
"cost_usd": 0.00559074,
"file": "cookie.go",
"round": 2,
"grep_used": true,
"grep_results": "GREP `SetKey`:\n```\ncookie.go:257:// SetKey sets cookie name.\ncookie.go:258:func (c *Cookie) SetKey(key string) {\ncookie.go:262:// SetKeyBytes sets cookie name.\ncookie.go:263:func (c *Cookie) SetKeyBytes(key []byte) {\ncookie_test.go:26:\t\t\tname: \"SetKey\",\ncookie_test.go:27:\t\t\tset: func(c *Cookie) { c.SetKey(\"sid\\r\\nSet-Cookie: admin=1\") },\ncookie_test.go:30:\t\t\tname: \"SetKeyBytes\",\ncookie_test.go:31:\t\t\tset: func(c *Cookie) { c.SetKeyBytes([]byte(\"sid\\r\\nSet-Cookie: admin=1\")) },\ncookie_test.go:66:\t\t\tc.SetKey(\"sid\")\ncookie_test.go:106:\tc.SetKey(expectedName)\ncookie_test.go:389:\tc.SetKey(key)\ncookie_test.go:467:\tc.SetKey(key)\nheader_test.go:622:\tc.SetKey(cookieName)\nheader_test.go:880:\tc.SetKey(\"foo\")\nheader_test.go:1834:\tc.SetKey(\"foo\")\nheader_test.go:1848:\tc.SetKey(\"aaaaa\")\nheader_test.go:2329:\tc.SetKey(\"foobar\")\nheader_test.go:2333:\tc.SetKey(\"йцук\")\nheader_test.go:2338:\tc.SetKey(\"foobar\")\nheader_test.go:2344:\texpectedC1.SetKey(\"foobar\")\nheader_test.go:2350:\tc.SetKey(\"йцук\")\nheader_test.go:2356:\texpectedC2.SetKey(\"йцук\")\nheader_test.go:2402:\tc.SetKey(\"foobar\")\nheader_test.go:2418:\tc.SetKey(\"йцук\")\nheader_test.go:2531:\tc.SetKey(\"sid\")\nheader_test.go:2574:\tc.SetKey(\"foo\")\nheader_test.go:2593:\tc.SetKey(\"foo\")\nheader.go:1693://\tc.SetKey(key)\nheader.go:1705:\tc.SetKey(key)\nheader.go:1716://\tc.SetKey(key)\n```"
},
{
"finding_title": "Missing delimiter and newline sanitization in cookie setters",
"verdict": "INVALID",
"reasoning": "The report claims that the `SetKey`, `SetValue`, `SetDomain`, and `SetPath` methods in `cookie.go` are vulnerable to cookie injection because they do not sanitize input strings (e.g., removing newlines or semicolons) before storing them. \n\n1. **Threat Model Analysis**: The threat model for this library defines the attacker as external parties providing untrusted data to public APIs, specifically parsers and decoders. It explicitly excludes \"misuse that violates a documented precondition of the public API\" and implies that host applications are responsible for sanitizing data they generate or control. \n\n2. **Attack Surface Reachability**: The `Set*` methods on the `Cookie` struct are intended to be called by the server application code to set response cookies. The values passed to these methods are determined by the application developer or the application logic. An external attacker (e.g., a malicious client) does not have direct control over the arguments passed to `SetKey` or `SetValue` unless the application itself passes attacker-controlled data (e.g., from user input) directly into these setters without sanitization. In that case, the vulnerability is in the *application* code for failing to sanitize user input before passing it to the library, not in the library's failure to sanitize its own arguments. The library's role is to faithfully render the state provided by the host. \n\n3. **Comparison with Parsing**: While `Parse`/`ParseBytes` handle untrusted input from HTTP requests, the `Set*` methods are setters for trusted, host-generated data. If the library were to sanitize these inputs, it would interfere with legitimate use cases where specific characters might be required (though less likely for cookies, it's a general principle for setters). More importantly, the security burden for response header safety lies with the application ensuring that it does not pass malicious data to the library. \n\n4. **Precedent**: Standard Go `net/http` and other major HTTP libraries similarly expect the developer to provide safe values for response headers/cookies. If a developer passes `\"foo\\r\\nSet-Cookie: ...\"` to a cookie value setter, the resulting header injection is a result of the developer's failure to validate that input, which is outside the library's scope of responsibility under the defined threat model. \n\nTherefore, the lack of sanitization in the `Set*` methods is not a security vulnerability in the library itself, as it is not reachable by an external attacker directly; the attacker must first compromise the host application's logic to manipulate these setters.\n\nCRUX: The Set* methods are setters for host-controlled data, not parsers for untrusted input; missing sanitization in setters is the responsibility of the host application, not the library.\nGREP: SetKey",
"elapsed": 83.7,
"tokens": 9774,
"tokens_in": 9180,
"tokens_out": 594,
"cost_usd": 0.0056375999999999996,
"file": "cookie.go",
"round": 3,
"grep_used": true,
"grep_results": "GREP `SetKey`:\n```\ncookie.go:257:// SetKey sets cookie name.\ncookie.go:258:func (c *Cookie) SetKey(key string) {\ncookie.go:262:// SetKeyBytes sets cookie name.\ncookie.go:263:func (c *Cookie) SetKeyBytes(key []byte) {\ncookie_test.go:26:\t\t\tname: \"SetKey\",\ncookie_test.go:27:\t\t\tset: func(c *Cookie) { c.SetKey(\"sid\\r\\nSet-Cookie: admin=1\") },\ncookie_test.go:30:\t\t\tname: \"SetKeyBytes\",\ncookie_test.go:31:\t\t\tset: func(c *Cookie) { c.SetKeyBytes([]byte(\"sid\\r\\nSet-Cookie: admin=1\")) },\ncookie_test.go:66:\t\t\tc.SetKey(\"sid\")\ncookie_test.go:106:\tc.SetKey(expectedName)\ncookie_test.go:389:\tc.SetKey(key)\ncookie_test.go:467:\tc.SetKey(key)\nexamples/helloworldserver/helloworldserver.go:52:\tc.SetKey(\"cookie-name\")\nheader_test.go:622:\tc.SetKey(cookieName)\nheader_test.go:880:\tc.SetKey(\"foo\")\nheader_test.go:1834:\tc.SetKey(\"foo\")\nheader_test.go:1848:\tc.SetKey(\"aaaaa\")\nheader_test.go:2329:\tc.SetKey(\"foobar\")\nheader_test.go:2333:\tc.SetKey(\"йцук\")\nheader_test.go:2338:\tc.SetKey(\"foobar\")\nheader_test.go:2344:\texpectedC1.SetKey(\"foobar\")\nheader_test.go:2350:\tc.SetKey(\"йцук\")\nheader_test.go:2356:\texpectedC2.SetKey(\"йцук\")\nheader_test.go:2402:\tc.SetKey(\"foobar\")\nheader_test.go:2418:\tc.SetKey(\"йцук\")\nheader_test.go:2531:\tc.SetKey(\"sid\")\nheader_test.go:2574:\tc.SetKey(\"foo\")\nheader_test.go:2593:\tc.SetKey(\"foo\")\nheader.go:1693://\tc.SetKey(key)\nheader.go:1705:\tc.SetKey(key)\n```"
},
{
"finding_title": "Missing delimiter and newline sanitization in cookie setters",
"verdict": "INVALID",
"reasoning": "The report identifies a lack of sanitization in the `Cookie` setters (`SetKey`, `SetValue`, `SetDomain`, `SetPath`), claiming this allows cookie attribute injection or CRLF header injection when serialized by `AppendBytes`. \n\n1. **Reachability & Threat Model**: The threat model for this library defines the attacker as an entity providing untrusted data to public APIs, specifically parsers and decoders receiving adversarial payloads. It explicitly states that \"misuse that violates a documented precondition of the public API\" is not a vulnerability. The `Set*` methods are mutators intended to be called by the host application (server code) with data that the application trusts or has generated. The external attacker (remote client) does not control the arguments passed to these setters directly. If a server application passes untrusted user input (e.g., from a POST body) directly to `SetKey` without sanitization, that is an application-level vulnerability (insecure usage), not a defect in the library's primitive. The library's responsibility is to faithfully render the state provided by the host. \n\n2. **Defense/Behavior**: While `SetPath` does strip newlines, `SetKey`, `SetValue`, and `SetDomain` do not. However, since the input to these functions is under the control of the trusted host process (the server developer's logic), the library is not expected to act as a second line of defense against the host's own lack of input validation. Standard Go `net/http` and other major HTTP libraries similarly expect the developer to provide safe values for response headers/cookies; the library does not sanitize arbitrary server-generated data in setters unless explicitly documented as a security boundary. \n\n3. **Conclusion**: The bug pattern (missing sanitization) exists, but it is not attacker-reachable through the public trust boundary in the context of the library's threat model. The attacker cannot reach these setters with untrusted input without the host application violating its security responsibilities. Therefore, this is a code quality issue or application misuse, not a library security vulnerability.\n\nCRUX: The Set* methods are setters for host-controlled data, not parsers for untrusted input; missing sanitization in setters is the responsibility of the host application, not the library.\nGREP: SetKey",
"elapsed": 73.0,
"tokens": 10314,
"tokens_in": 9827,
"tokens_out": 487,
"cost_usd": 0.005588340000000001,
"file": "cookie.go",
"round": 4,
"grep_used": true,
"grep_results": "GREP `SetKey`:\n```\ncookie.go:257:// SetKey sets cookie name.\ncookie.go:258:func (c *Cookie) SetKey(key string) {\ncookie.go:262:// SetKeyBytes sets cookie name.\ncookie.go:263:func (c *Cookie) SetKeyBytes(key []byte) {\ncookie_test.go:26:\t\t\tname: \"SetKey\",\ncookie_test.go:27:\t\t\tset: func(c *Cookie) { c.SetKey(\"sid\\r\\nSet-Cookie: admin=1\") },\ncookie_test.go:30:\t\t\tname: \"SetKeyBytes\",\ncookie_test.go:31:\t\t\tset: func(c *Cookie) { c.SetKeyBytes([]byte(\"sid\\r\\nSet-Cookie: admin=1\")) },\ncookie_test.go:66:\t\t\tc.SetKey(\"sid\")\ncookie_test.go:106:\tc.SetKey(expectedName)\ncookie_test.go:389:\tc.SetKey(key)\ncookie_test.go:467:\tc.SetKey(key)\nheader_test.go:622:\tc.SetKey(cookieName)\nheader_test.go:880:\tc.SetKey(\"foo\")\nheader_test.go:1834:\tc.SetKey(\"foo\")\nheader_test.go:1848:\tc.SetKey(\"aaaaa\")\nheader_test.go:2329:\tc.SetKey(\"foobar\")\nheader_test.go:2333:\tc.SetKey(\"йцук\")\nheader_test.go:2338:\tc.SetKey(\"foobar\")\nheader_test.go:2344:\texpectedC1.SetKey(\"foobar\")\nheader_test.go:2350:\tc.SetKey(\"йцук\")\nheader_test.go:2356:\texpectedC2.SetKey(\"йцук\")\nheader_test.go:2402:\tc.SetKey(\"foobar\")\nheader_test.go:2418:\tc.SetKey(\"йцук\")\nheader_test.go:2531:\tc.SetKey(\"sid\")\nheader_test.go:2574:\tc.SetKey(\"foo\")\nheader_test.go:2593:\tc.SetKey(\"foo\")\nheader.go:1693://\tc.SetKey(key)\nheader.go:1705:\tc.SetKey(key)\nheader.go:1716://\tc.SetKey(key)\n```"
},
{
"finding_title": "Missing delimiter and newline sanitization in cookie setters",
"verdict": "INVALID",
"reasoning": "The report claims that the lack of sanitization in `Cookie` setters (`SetKey`, `SetValue`, `SetDomain`, `SetPath`) allows for cookie attribute injection or CRLF header injection when the cookie is serialized by `AppendBytes`. \n\n1. **Threat Model & Trust Boundary**: The threat model defines the attacker as code calling the public API, specifically focusing on data passed through parsers and decoders that receive adversarial payloads. It explicitly states that \"misuse that violates a documented precondition of the public API\" is not a vulnerability. The `Cookie` object is a data structure used by the host application to *construct* response cookies. The setters are called by the host application (the server developer's code). \n\n2. **Data Flow Analysis**: The data flow for response cookies is: Host Application Logic -> `SetKey`/`SetValue` -> `Cookie` struct -> `AppendBytes` -> HTTP Response Header. The external attacker (remote client) does not control the arguments passed to these setters. If an application passes unsanitized user input (e.g., from a form field) directly to `SetValue`, the vulnerability lies in the application's failure to sanitize input before passing it to the library. The library acts as a serializer; it faithfully renders the state provided by the trusted host process. \n\n3. **Comparison with Parsing**: While `Parse`/`ParseBytes` handle untrusted input from HTTP requests and implement specific parsing logic (splitting on `;`, `=`, etc.), the `Set*` methods are mutators. In standard library design (including Go's `net/http`), it is the responsibility of the application layer to ensure that values inserted into headers are safe. The library is not expected to act as a security filter for host-generated data, doing so would often break legitimate use cases (e.g., if a specific character sequence is valid in a non-header context or if the application has already validated the format). \n\n4. **Verdict**: Since the setters are not reachable by an external attacker with untrusted input directly (the attacker cannot force the server to call `SetValue` with arbitrary data without the server code explicitly passing that data), and the threat model excludes application-level misuse as a library vulnerability, this finding is INVALID. The 'bug' is a lack of defensive coding in a setter, but it does not constitute a security vulnerability in the library under the specified threat model.\n\nCRUX: The Set* methods are setters for host-controlled data, not parsers for untrusted input; missing sanitization in setters is the responsibility of the host application, not the library, and the threat model excludes application misuse.\nGREP: SetKey",
"elapsed": 107.2,
"tokens": 10933,
"tokens_in": 10363,
"tokens_out": 570,
"cost_usd": 0.0060624599999999996,
"file": "cookie.go",
"round": 5,
"grep_used": true,
"grep_results": "GREP `SetKey`:\n```\ncookie.go:257:// SetKey sets cookie name.\ncookie.go:258:func (c *Cookie) SetKey(key string) {\ncookie.go:262:// SetKeyBytes sets cookie name.\ncookie.go:263:func (c *Cookie) SetKeyBytes(key []byte) {\ncookie_test.go:26:\t\t\tname: \"SetKey\",\ncookie_test.go:27:\t\t\tset: func(c *Cookie) { c.SetKey(\"sid\\r\\nSet-Cookie: admin=1\") },\ncookie_test.go:30:\t\t\tname: \"SetKeyBytes\",\ncookie_test.go:31:\t\t\tset: func(c *Cookie) { c.SetKeyBytes([]byte(\"sid\\r\\nSet-Cookie: admin=1\")) },\ncookie_test.go:66:\t\t\tc.SetKey(\"sid\")\ncookie_test.go:106:\tc.SetKey(expectedName)\ncookie_test.go:389:\tc.SetKey(key)\ncookie_test.go:467:\tc.SetKey(key)\nheader_test.go:622:\tc.SetKey(cookieName)\nheader_test.go:880:\tc.SetKey(\"foo\")\nheader_test.go:1834:\tc.SetKey(\"foo\")\nheader_test.go:1848:\tc.SetKey(\"aaaaa\")\nheader_test.go:2329:\tc.SetKey(\"foobar\")\nheader_test.go:2333:\tc.SetKey(\"йцук\")\nheader_test.go:2338:\tc.SetKey(\"foobar\")\nheader_test.go:2344:\texpectedC1.SetKey(\"foobar\")\nheader_test.go:2350:\tc.SetKey(\"йцук\")\nheader_test.go:2356:\texpectedC2.SetKey(\"йцук\")\nheader_test.go:2402:\tc.SetKey(\"foobar\")\nheader_test.go:2418:\tc.SetKey(\"йцук\")\nheader_test.go:2531:\tc.SetKey(\"sid\")\nheader_test.go:2574:\tc.SetKey(\"foo\")\nheader_test.go:2593:\tc.SetKey(\"foo\")\nheader.go:1693://\tc.SetKey(key)\nheader.go:1705:\tc.SetKey(key)\nheader.go:1716://\tc.SetKey(key)\n```"
}
]Raw scan report for this file
The main risk in this file is not out-of-bounds memory access (the Go scanner checks slice bounds) but **unsanitized cookie data reaching HTTP header serialization**. Cookie values, names, paths, and domains are written back into `Set-Cookie`/`Cookie` headers without rejecting or encoding delimiter characters such as `;`, `=`, and CRLF. This can allow cookie attribute injection, forged cookie name/value pairs, or HTTP header splitting when untrusted input is reflected into response or request headers.
Key flows:
- `Parse` / `ParseBytes` store raw `src` substrings into `c.key`, `c.value`, `c.domain`, and `c.path`.
- Setters such as `SetValue`, `SetDomain`, `SetKey`, and `SetPath` store caller-controlled strings into the same fields.
- `AppendBytes` serializes those fields directly into `dst`.
- `appendResponseCookieBytes` and `appendRequestCookieBytes` serialize caller-provided `argsKV` values directly into headers.
`SetPath` removes newlines but does **not** remove semicolons, so it can still be used for cookie attribute injection. `SetKey`, `SetValue`, and `SetDomain` do not remove newlines at all.
```json
[
{
"severity": "high",
"title": "Cookie attribute/header injection via unsanitized fields in AppendBytes",
"function": "Cookie.AppendBytes",
"description": "AppendBytes writes c.key, c.value, c.domain, and c.path directly to dst without rejecting or percent-encoding reserved characters. If an attacker can influence any of these fields through setters or parsed input, a value containing ';' can inject additional Set-Cookie attributes such as Domain, Path, SameSite, HttpOnly, or Secure, and CR/LF can split the HTTP header."
},
{
"severity": "high",
"title": "Set-Cookie injection in response cookie serializer",
"function": "appendResponseCookieBytes",
"description": "This function appends kv.value directly into the Set-Cookie header with no validation or encoding. If argsKV is built from untrusted input, a value containing ';' can inject additional Set-Cookie attributes, and CR/LF can inject arbitrary response headers."
},
{
"severity": "medium",
"title": "Cookie header injection in request cookie serializer",
"function": "appendRequestCookieBytes",
"description": "This function appends kv.key and kv.value directly into the request Cookie header. Untrusted keys or values containing ';' can add forged name=value pairs, and CR/LF can break the request header stream."
},
{
"severity": "high",
"title": "Missing delimiter and newline sanitization in cookie setters",
"function": "Cookie.SetKey/SetValue/SetDomain/SetPath",
"description": "These setters store raw caller-controlled strings in cookie fields. SetPath only removes newlines and does not reject semicolons, while SetKey, SetValue, and SetDomain do not remove newlines at all. The stored values are later serialized verbatim by AppendBytes, enabling cookie attribute injection and CRLF header injection."
},
{
"severity": "medium",
"title": "ParseBytes can retain CRLF from raw input",
"function": "Cookie.ParseBytes",
"description": "ParseBytes treats src as a flat cookie string and only splits on '=' and ';'. If src is attacker-controlled and contains CR/LF, those bytes can be stored in key, value, domain, or path. Later serialization via AppendBytes can reflect them as injected header lines. It also treats whitespace-only input as an empty valid cookie."
},
{
"severity": "low",
"title": "Max-Age integer wrap can alter cookie lifetime",
"function": "Cookie.ParseBytes",
"description": "Max-Age is parsed into an int via ParseUint with no visible overflow guard. A crafted very large Max-Age value can wrap to zero or negative, causing the cookie to be treated as having no Max-Age or as immediately deleted, potentially altering client-side cookie lifetime."
},
{
"severity": "low",
"title": "Parsed SameSite and Partitioned attributes bypass safety invariants",
"function": "Cookie.ParseBytes",
"description": "Parsing SameSite=None or Partitioned does not enforce the Secure, and Partitioned Path=/, invariants applied by SetSameSite and SetPartitioned. A parsed or reconstructed cookie can therefore carry insecure attribute combinations when serialized."
},
{
"severity": "low",
"title": "Quote-unaware cookie scanner truncates values",
"function": "cookieScanner.next/nextRaw",
"description": "The scanner does not recognize quoted cookie values and splits on every semicolon. A crafted Cookie or Set-Cookie value containing a semicolon inside quotes can be truncated or split, which may alter authentication or session cookie values seen by the application."
}
]
```