Skip to content

Latest commit

 

History

History
58 lines (47 loc) · 4.65 KB

vulnerabilities-workflow-1.md

File metadata and controls

58 lines (47 loc) · 4.65 KB

Combined Vulnerability List

Unchecked Q‑Value Parsing Leading to MIME Type Confusion

  • Description: In the ParseAccept function (in autoneg.go), the code initializes each clause’s quality factor (Q) to 1.0 and then attempts to reassign it by parsing a parameter value using:

    a.Q, _ = strconv.ParseFloat(sp1, 32)

    Because the code ignores any error from strconv.ParseFloat, an attacker can supply a specially crafted Accept header with a malformed q‑value (for example, using a non‑numeric string such as "q=abc"). In such a case the parse operation fails and the quality factor resets (or becomes 0), which alters the intended ordering when sorting the list of media type clauses. When the application later uses the Negotiate function to decide which Content‑Type to send (by simply iterating over the sorted list and choosing the first match), this manipulation can force the selection of an alternative that may not be the secure or expected one.

  • Impact: If the negotiated Content‑Type is used without further validation—especially in scenarios where the Content‑Type is critical to safe browser rendering—a malicious client-controlled Accept header could cause a MIME type mismatch. This “MIME type confusion” may lead browsers to handle the response in an unintended manner and could open the door to attacks such as Cross-Site Scripting (XSS) or content injection.

  • Vulnerability Rank: High

  • Currently Implemented Mitigations: There is no error checking or validation when parsing the q‑value in the current implementation.

  • Missing Mitigations:

    • Input Validation: Validate that the value specified for “q” is strictly a numeric value before attempting to parse it.
    • Error Handling: Check the error returned by strconv.ParseFloat and, if parsing fails, either reject the header or set a safe default.
    • Content‑Type Whitelisting: Ensure that the negotiated Content‑Type is selected only from a strict whitelist of allowed values, regardless of the Accept header input.

  • Preconditions:

    • The application must expose HTTP endpoints that use this content negotiation library.
    • An attacker must be able to control the Accept header value in HTTP requests.
    • The server application uses the return value from Negotiate to set the Content‑Type header on responses.

  • Source Code Analysis:

    1. In ParseAccept, each media type clause is initialized with a quality factor Q set to 1.0.
    2. The code then splits header parameters (separated by “;”) and later looks for tokens such as “q”.
    3. When a “q” token is found, the code calls: 
      a.Q, _ = strconv.ParseFloat(sp1, 32)
      without checking for errors.
    4. If the parameter is malformed (e.g. "q=abc"), the parse fails silently and results in a quality factor of 0.0.
    5. The list of clauses is sorted in descending order based on Q (and some simple type comparisons), so a clause with a non‑numeric (“failed”) q‑value ends up deprioritized compared with others.
    6. Finally, in Negotiate, the function iterates over the sorted clauses and returns the first matching alternative from a server‑provided list. This means an attacker-influenced ordering can force the selection of an alternative that may be less safe.

  • Security Test Case:

    1. Setup: Deploy an instance of the application that uses the goautoneg library for content negotiation. Configure an endpoint so that it offers multiple Content‑Type alternatives (for example, a secure “text/html” and another “application/json” variant that may be interpreted insecurely in the given context).
    2. Craft the Request: Send an HTTP request with an Accept header deliberately crafted as follows: 
      Accept: text/html;q=abc, application/json
      Here, the malformed value q=abc will cause the quality factor for “text/html” to be parsed as 0.
    3. Execution: The server will call Negotiate, which will parse the header and sort the clauses. The clause for “text/html” (with a failed q‑value) will be deprioritized relative to “application/json” (which has an implicit quality factor of 1.0).
    4. Verification: Check the Content‑Type header in the HTTP response. If it is set to “application/json” instead of “text/html” (the expected secure alternative), then the vulnerability is confirmed.
    5. Repeat: Vary the malformed q‑value and observe the change in negotiated Content‑Type to further confirm the behavior.

Implementing proper input validation and error handling in the q‑value parsing is critical to mitigate this risk.