Cookie attribute/header injection via unsanitized fields in AppendBytes

[
  {
    "finding_title": "Cookie attribute/header injection via unsanitized fields in AppendBytes",
    "verdict": "INVALID",
    "reasoning": "The report claims that `AppendBytes` allows Cookie attribute injection because it writes `c.key`, `c.value`, `c.domain`, and `c.path` directly to `dst` without sanitizing reserved characters like `;` or `\\r\\n`. While it is true that `AppendBytes` does not perform percent-encoding or rejection of these characters, the threat model for a library (swesweep-fasthttp) defines the trust boundary as the public API and the data passed to it. The `Cookie` setters (`SetKey`, `SetValue`, `SetDomain`, `SetPath`) are the entry points for constructing the `Cookie` object that is later serialized. The responsibility for validating or sanitizing the input strings (e.g., rejecting `;` in a cookie name or value) lies with the host application calling these setters, not with the low-level serialization function `AppendBytes`. `AppendBytes`'s contract is to faithfully serialize the current state of the `Cookie` object. If a host application passes malicious data to `SetKey` or `SetValue`, that is a misuse of the API by the host, not a vulnerability in the library's parser or serializer. Furthermore, the standard library `net/http` also does not sanitize cookie values in `AppendBytes` (it relies on the caller to pass valid input). Therefore, the lack of sanitization in `AppendBytes` is not a security vulnerability in the library itself, but rather a documentation/precondition issue for the host. The library correctly parses untrusted input in `ParseBytes`, but the serialization path assumes the `Cookie` object contains valid data.\n\nCRUX: AppendBytes is a serialization function that assumes the Cookie object fields contain valid data; sanitization of input is the responsibility of the host application calling the setters, not the library's serializer.\nGREP: func (c *Cookie) AppendBytes",
    "elapsed": 158.2,
    "tokens": 7523,
    "tokens_in": 7123,
    "tokens_out": 400,
    "cost_usd": 0.00419166,
    "file": "cookie.go",
    "round": 1,
    "grep_used": true,
    "grep_results": "GREP `func (c *Cookie) AppendBytes (simplified to: AppendBytes)`:\n```\ncookie.go:281:// AppendBytes appends cookie representation to dst and returns\ncookie.go:283:func (c *Cookie) AppendBytes(dst []byte) []byte {\ncookie.go:353:\tc.bufK = c.AppendBytes(c.bufK[:0])\ncookie_test.go:447:func TestCookieAppendBytes(t *testing.T) {\ncookie_test.go:452:\ttestCookieAppendBytes(t, c, \"\", \"bar\", \"bar\")\ncookie_test.go:453:\ttestCookieAppendBytes(t, c, \"foo\", \"\", \"foo=\")\ncookie_test.go:454:\ttestCookieAppendBytes(t, c, \"ффф\", \"12 лодлы\", \"ффф=12 лодлы\")\ncookie_test.go:457:\ttestCookieAppendBytes(t, c, \"a\", \"b\", \"a=b; domain=foobar.com\")\ncookie_test.go:460:\ttestCookieAppendBytes(t, c, \"aa\", \"bb\", \"aa=bb; domain=foobar.com; path=/a/b\")\ncookie_test.go:463:\ttestCookieAppendBytes(t, c, \"xxx\", \"yyy\", \"xxx=yyy; expires=Tue, 10 Nov 2009 23:00:00 GMT; domain=foobar.com; path=/a/b\")\ncookie_test.go:466:func testCookieAppendBytes(t *testing.T, c *Cookie, key, value, expectedS string) {\ncookie_test.go:469:\tresult := string(c.AppendBytes(nil))\nuri.go:740:\t\tdst = u.queryArgs.AppendBytes(dst)\nuri.go:862:\tu.fullURI = u.AppendBytes(u.fullURI[:0])\nuri.go:866:// AppendBytes appends full uri to dst and returns the extended dst.\nuri.go:867:func (u *URI) AppendBytes(dst []byte) []byte {\nargs.go:136:\ta.buf = a.AppendBytes(a.buf[:0])\nargs.go:162:// AppendBytes appends query string to dst and returns the extended dst.\nargs.go:163:func (a *Args) AppendBytes(dst []byte) []byte {\nheader.go:2417:\th.bufV = h.AppendBytes(h.bufV[:0])\nheader.go:2459:// AppendBytes appends response header representation to dst and returns\nheader.go:2461:func (h *ResponseHeader) AppendBytes(dst []byte) []byte {\nheader.go:2549:\th.bufV = h.AppendBytes(h.bufV[:0])\nheader.go:2595:// AppendBytes appends request header representation to dst and returns\nheader.go:2597:func (h *RequestHeader) AppendBytes(dst []byte) []byte {\n```"
  },
  {
    "finding_title": "Cookie attribute/header injection via unsanitized fields in AppendBytes",
    "verdict": "INVALID",
    "reasoning": "The vulnerability report claims that `AppendBytes` in `cookie.go` allows injection of cookie attributes because it does not sanitize fields like `c.key`, `c.value`, `c.domain`, and `c.path`. To be a security vulnerability in the library, an attacker must be able to control these fields through untrusted input reaching a public API. \n\n1. **Data Flow Analysis**: \n   - **Parsing Path**: When the library parses an incoming `Set-Cookie` or `Cookie` header (e.g., via `Cookie.ParseBytes` or internal parsing in `request.go`), the `cookieScanner` splits the input by `;` and `=`. This ensures that `c.key`, `c.value`, `c.domain`, and `c.path` extracted from a single header line cannot contain the literal `;` or `=` characters that define attribute boundaries. If an attacker sends `Set-Cookie: a=b; Domain=evil.com`, the parser correctly identifies `a` as key, `b` as value, and `Domain` as a separate attribute. It does *not* set `c.value` to `b; Domain=evil.com`. \n   - **Setter Path**: The `Set*` methods (e.g., `SetValue`, `SetDomain`) accept strings/bytes from the host application. The host application is a trusted component that constructs the response. If the host application passes a malicious string containing `;` to `SetValue`, that is considered a bug in the host application (misuse of the API), not a vulnerability in the fasthttp library. The library's role is to serialize the object as defined by its setters. \n\n2. **Threat Model**: The threat model states that the library is reusable code where the *host application* handles untrusted sources. The library must validate inputs passed to its public parsers. Since `ParseBytes` correctly isolates fields, it prevents injection during parsing. The serialization function `AppendBytes` assumes the internal state is valid, which is consistent with the library's design (it's a serializer, not a sanitizer). \n\n3. **Conclusion**: Since the parsing logic effectively neutralizes injection attempts from untrusted HTTP headers by splitting on delimiters, and the setters are controlled by the trusted host, the lack of sanitization in `AppendBytes` is not an exploitable security vulnerability in the library itself. It is a code quality/design choice consistent with other HTTP libraries (like `net/http`).\n\nCRUX: The parser (cookieScanner) splits input on ';' and '=', preventing attackers from injecting new attributes into c.key, c.value, c.domain, or c.path via untrusted header input.\nGREP: func (s *cookieScanner) nextRaw",
    "elapsed": 212.9,
    "tokens": 8894,
    "tokens_in": 8312,
    "tokens_out": 582,
    "cost_usd": 0.00523704,
    "file": "cookie.go",
    "round": 2,
    "grep_used": true,
    "grep_results": "GREP `func (s *cookieScanner) nextRaw (simplified to: cookieScanner)`:\n```\ncookie.go:382:\tvar s cookieScanner\ncookie.go:514:\tvar s cookieScanner\ncookie.go:526:type cookieScanner struct {\ncookie.go:530:func (s *cookieScanner) nextRaw(key, val *[]byte) bool {\ncookie.go:568:func (s *cookieScanner) next(key, val *[]byte) bool {\n```"
  },
  {
    "finding_title": "Cookie attribute/header injection via unsanitized fields in AppendBytes",
    "verdict": "INVALID",
    "reasoning": "The report claims that `AppendBytes` allows injection because it does not sanitize fields. To be a valid vulnerability, an attacker must be able to reach this state via untrusted input. I analyzed the data flows:\n\n1. **Parsing Path (Untrusted Input):** When `Cookie.ParseBytes` processes a `Set-Cookie` header, it uses `cookieScanner.nextRaw`. This scanner iterates through bytes and splits on `;` and `=`. Specifically, `nextRaw` extracts the `val` (value) as the substring between delimiters. Therefore, if an attacker sends `Set-Cookie: id=123; Domain=evil.com`, the scanner assigns `c.value = \"123\"` and `c.domain = \"evil.com\"`. The `;` character itself acts as the delimiter and is not included in the `val` slice. Consequently, `c.value` cannot contain a raw `;` from a parsed header. If the parsed cookie is subsequently re-serialized via `AppendBytes`, the fields are clean of the delimiter characters that would cause attribute injection. CR/LF characters within a header line are generally stripped or cause parse errors in HTTP headers before reaching this logic, but even if present, they would be part of the value, not creating new attributes in the output structure in a way that bypasses the initial parse structure (though header smuggling is a separate vector, the scanner's logic for `;` specifically prevents attribute injection from the parsed fields).\n\n2. **Setter Path (Trusted Input):** The `Set*` methods (e.g., `SetValue`, `SetDomain`) accept input from the host application. According to the threat model, the host application is a trusted entity that constructs the response. If the host application passes a string containing `;` to `SetValue`, that is a bug in the host application's logic, not a vulnerability in the library. The library's contract is to serialize the state of the object as defined by the setters. The library is not responsible for sanitizing input provided by the trusted host code unless it is part of the public parsing/decoding API surface which handles untrusted network data. `AppendBytes` is a serialization helper, not a parser.\n\n3. **Comparison with Standard Library:** `net/http` behaves similarly; `http.Cookie` does not sanitize `Value` in `Set` or `String()`/`Append`. The responsibility lies with the developer to ensure values are valid.\n\nSince the only way to get untrusted data into these fields is via parsing, and the parser structurally prevents the specific injection vector (injection of `;` into values) by using it as a delimiter, and the alternative path (setters) requires trusted input, the reported vulnerability is not exploitable by an external attacker through the library's public untrusted-input APIs.\n\nCRUX: The cookieScanner.nextRaw function uses ';' as a delimiter, ensuring that parsed cookie values (c.value) and other fields cannot contain raw ';' characters from untrusted input, thus preventing attribute injection via the parse-serialize round-trip. Setter-based injection requires trusted host input.\nGREP: func (s *cookieScanner) nextRaw",
    "elapsed": 205.4,
    "tokens": 9091,
    "tokens_in": 8415,
    "tokens_out": 676,
    "cost_usd": 0.005562299999999999,
    "file": "cookie.go",
    "round": 3,
    "grep_used": true,
    "grep_results": "GREP `func (s *cookieScanner) nextRaw (simplified to: cookieScanner)`:\n```\ncookie.go:382:\tvar s cookieScanner\ncookie.go:514:\tvar s cookieScanner\ncookie.go:526:type cookieScanner struct {\ncookie.go:530:func (s *cookieScanner) nextRaw(key, val *[]byte) bool {\ncookie.go:568:func (s *cookieScanner) next(key, val *[]byte) bool {\n```"
  },
  {
    "finding_title": "Cookie attribute/header injection via unsanitized fields in AppendBytes",
    "verdict": "INVALID",
    "reasoning": "The vulnerability report claims that `AppendBytes` allows cookie attribute injection because it does not sanitize `c.key`, `c.value`, `c.domain`, or `c.path`. To be a valid vulnerability in this library, an attacker must be able to inject these unsanitized fields via untrusted input or through the public API in a way that causes meaningful harm.\n\n1. **Attack Path Analysis**: \n   - **Parsing Path**: When fasthttp parses an incoming `Set-Cookie` header via `ParseBytes`, it uses `cookieScanner.nextRaw`. This function splits the input on `;` and `=`. Consequently, the `value` extracted for the cookie (which becomes `c.value`) will not contain `;` or `=` characters, as they act as delimiters. For example, `Set-Cookie: user=John; Domain=evil.com` results in `c.value = \"John\"` and `c.domain = \"evil.com\"`. The attacker cannot inject `;` into `c.value` via this path.\n   - **Setter Path**: The public setters (`SetValue`, `SetDomain`, etc.) accept data from the host application. According to the threat model for a reusable library, the host application is the entity responsible for handling untrusted source data. If the host application passes a malicious string containing `;` to `SetValue`, that is a failure of the host application to sanitize its input, not a vulnerability in fasthttp's serialization logic. Fasthttp's contract for `AppendBytes` is to faithfully serialize the state of the `Cookie` object.\n\n2. **Defense Verification**: The parser `cookieScanner` effectively prevents the specific injection vector (inserting `;` into the value field) by using `;` as a structural delimiter. There is no path where untrusted network input directly populates `c.value` with a `;` character that would then be serialized into a new attribute. CR/LF injection is typically handled by lower-level HTTP header parsing or is prevented by the fact that headers are line-based, but even if present, the specific 'attribute injection' via `;` is structurally impossible from the parse path.\n\n3. **Conclusion**: The bug pattern (lack of sanitization in serializer) exists, but it is not reachable by an external attacker in a way that constitutes a library vulnerability. The input to the serializer is either controlled by the trusted host (via setters) or sanitized by the parser's delimiter logic (via `ParseBytes`). Therefore, this is a code quality/design observation consistent with other HTTP libraries (like `net/http`), not a security vulnerability in fasthttp.\n\nCRUX: The cookieScanner splits input on ';', preventing untrusted input from containing ';' in c.value, and the setter path relies on trusted host input, making the lack of sanitization in AppendBytes not a security vulnerability.\nGREP: func (s *cookieScanner) nextRaw",
    "elapsed": 88.6,
    "tokens": 9754,
    "tokens_in": 9133,
    "tokens_out": 621,
    "cost_usd": 0.00569886,
    "file": "cookie.go",
    "round": 4,
    "grep_used": true,
    "grep_results": "GREP `func (s *cookieScanner) nextRaw (simplified to: cookieScanner)`:\n```\ncookie.go:382:\tvar s cookieScanner\ncookie.go:514:\tvar s cookieScanner\ncookie.go:526:type cookieScanner struct {\ncookie.go:530:func (s *cookieScanner) nextRaw(key, val *[]byte) bool {\ncookie.go:568:func (s *cookieScanner) next(key, val *[]byte) bool {\n```"
  },
  {
    "finding_title": "Cookie attribute/header injection via unsanitized fields in AppendBytes",
    "verdict": "INVALID",
    "reasoning": "The vulnerability report claims that `AppendBytes` allows cookie attribute injection because it does not sanitize `c.key`, `c.value`, `c.domain`, or `c.path` (e.g., rejecting `;` or `%`). While `AppendBytes` indeed performs raw appending of these fields, the threat model for a reusable library defines the trust boundary at the public API surface where untrusted input enters the library (parsers/decoders). \n\n1. **Data Flow from Untrusted Input (Parsing):** When an attacker sends a crafted `Set-Cookie` header (e.g., `Set-Cookie: user=bad; Domain=evil.com`), it is processed by `Cookie.ParseBytes` using `cookieScanner.nextRaw`. The scanner splits the input on `;` and `=`. This means `c.value` will be set to `bad`, and `Domain=evil.com` will be parsed as a separate attribute, setting `c.domain`. The `;` character acts as a delimiter and is not included in the value slice. Therefore, `c.value` cannot contain a raw `;` originating from an untrusted HTTP header via the parsing path. If the library later re-serializes this cookie using `AppendBytes`, the fields are structurally clean of the delimiter characters that would cause attribute injection in a new header context.\n\n2. **Data Flow from Trusted Input (Setters):** The setters like `SetValue` and `SetDomain` are called by the host application. According to the threat model, the host application is the component responsible for handling untrusted source data and sanitizing it before passing it to the library for serialization. If the host application passes a malicious string containing `;` to `SetValue`, that is a misuse of the API by the trusted host, not a vulnerability in the library's logic. The library's contract for `AppendBytes` is to faithfully serialize the state of the `Cookie` object. \n\n3. **Defense Verification:** The primary defense against injection from untrusted network input is the delimiter-based parsing in `cookieScanner`. By verifying that `nextRaw` treats `;` as a split point, we confirm that the specific injection vector (injection of `;` into the value field via parsing) is prevented. CR/LF injection is typically handled by lower-level HTTP header parsing or is not feasible via the parse path in a way that results in attribute injection in the serialized output. \n\nSince the untrusted input path (parsing) structurally prevents the specific characters needed for attribute injection from residing in the cookie fields, and the trusted input path (setters) assumes the host sanitizes the data, the lack of sanitization in `AppendBytes` is not a security vulnerability reachable by an external attacker through the library's public untrusted-input APIs. It is a code quality/design observation consistent with other HTTP libraries.\n\nCRUX: The cookieScanner.nextRaw function uses ';' as a delimiter, ensuring that parsed cookie values (c.value) and other fields cannot contain raw ';' characters from untrusted input, thus preventing attribute injection via the parse-serialize round-trip. Setter-based injection requires trusted host input.\nGREP: func (s *cookieScanner) nextRaw",
    "elapsed": 107.1,
    "tokens": 10474,
    "tokens_in": 9796,
    "tokens_out": 678,
    "cost_usd": 0.006148319999999999,
    "file": "cookie.go",
    "round": 5,
    "grep_used": true,
    "grep_results": "GREP `func (s *cookieScanner) nextRaw (simplified to: cookieScanner)`:\n```\ncookie.go:382:\tvar s cookieScanner\ncookie.go:514:\tvar s cookieScanner\ncookie.go:526:type cookieScanner struct {\ncookie.go:530:func (s *cookieScanner) nextRaw(key, val *[]byte) bool {\ncookie.go:568:func (s *cookieScanner) next(key, val *[]byte) bool {\n```"
  }
]