Rack: Forwarded Header semicolon injection enables Host and Scheme spoofing

## Summary `Rack::Utils.forwarded_values` parses the RFC 7239 `Forwarded` header by splitting on semicolons before handling quoted-string values. Because quoted values may legally contain semicolons, a header such as: ```http Forwarded: for="127.0.0.1;host=evil.com;proto=https" ``` can be interpreted by Rack as multiple `Forwarded` directives rather than as a single quoted `for` value. In deployments where an upstream proxy, WAF, or intermediary validates or preserves quoted `Forwarded` values differently, this discrepancy can allow an attacker to smuggle `host`, `proto`, `for`, or `by` parameters through a single header value. ## Details `Rack::Utils.forwarded_values` processes the header using logic equivalent to: ```ruby forwarded_header.split(';').each_with_object({}) do |field, values| field.split(',').each do |pair| pair = pair.split('=').map(&:strip).join('=') return nil unless pair =~ /\A(by|for|host|proto)="?([^"]+)"?\Z/i (values[$1.downcase.to_sym] ||= []) << $2 end end ``` The method splits on `;` before it parses individual `name=value` pairs. This is inconsistent with RFC 7239, which permits quoted-string values, and quoted strings may contain semicolons as literal content. As a result, a header value such as: ```http Forwarded: for="127.0.0.1;host=evil.com;proto=https" ``` is not treated as a single `for` value. Instead, Rack may interpret it as if the client had supplied separate `for`, `host`, and `proto` directives. This creates an interpretation conflict when another component in front of Rack treats the quoted value as valid literal content, while Rack reparses it as multiple forwarding parameters. ## Impact Applications that rely on `Forwarded` to derive request metadata may observe attacker-controlled values for `host`, `proto`, `for`, or related URL components. In affected deployments, this can lead to host or scheme spoofing in derived values such as `req.host`, `req.scheme`, `req.base_url`, or `req.url`. Applications that use those values for password reset links, redirects, absolute URL generation, logging, IP-based decisions, or backend requests may be vulnerable to downstream security impact. The practical security impact depends on deployment architecture. If clients can already supply arbitrary trusted `Forwarded` parameters directly, this bug may not add meaningful attacker capability. The issue is most relevant where an upstream component and Rack interpret the same `Forwarded` header differently. ## Mitigation * Update to a patched version of Rack that parses `Forwarded` quoted-string values before splitting on parameter delimiters. * Avoid trusting client-supplied `Forwarded` headers unless they are normalized or regenerated by a trusted reverse proxy. * Prefer stripping inbound `Forwarded` headers at the edge and reconstructing them from trusted proxy metadata. * Avoid using `req.host`, `req.scheme`, `req.base_url`, or `req.url` for security-sensitive operations unless the forwarding chain is explicitly trusted and validated.

Quoted source text, attributed separately from HOL analysis.