Fix CRLF injection in Connection.connect via target_host parameter

[cursor]

Summary

Fixes a CRLF injection vulnerability in RubyProxyHeaders::Connection#connect where the target_host and target_port parameters are interpolated directly into the raw HTTP CONNECT request line without validation for control characters (CR, LF, NUL).

Problem

The build_connect_request method constructs a CONNECT request by directly interpolating target_host:

"CONNECT #{target_host}:#{target_port} HTTP/1.1"
"Host: #{target_host}:#{target_port}"

If a consuming application passes user-derived input as the target hostname, an attacker can inject CRLF sequences to smuggle HTTP requests or headers through the proxy.

While validate_header! was already applied to proxy header values (since v0.2.1), this same validation was missing for the request-line target parameters.

Fix

• Added validate_connect_target! private method that checks both target_host and target_port against INVALID_HEADER_VALUE_RE (rejects CR, LF, NUL)
• Validation runs at the top of connect(), before any network I/O (fail fast)
• Added RSpec coverage for CR, LF, NUL in target_host and CR in target_port

Impact

This is a defense-in-depth fix. Exploitation requires a consuming application to pass unsanitized user input directly as a target hostname to Connection.connect(). The fix ensures the library rejects malicious input regardless of the caller's validation practices.

  

[cursor]

Left a non-blocking comment: approval criteria were met (Bugbot/Security Agent not present; CI passed; no policy-required human review), but GitHub blocked bot self-approval on this PR. Existing human approval remains; no reviewers were assigned.

  

_{Sent by Cursor Approval Agent: dependabot approver}