apply cookies from redirect hops to the hops that follow

[liquidsec]

When following redirects, a cookie set by one hop is now sent on the later hops of the same request, the way a browser does.

This is what lets a login or bot-check page resolve. Those hand you a cookie along with the redirect, and the cookie has to be on the next request to count for anything. Without it you land back on the same page, or loop. It's a coverage fix: on those targets we were reporting whatever the redirect bounced us to instead of the actual response.

The jar is request-scoped. It's created in send_inner and dropped when the request returns, so nothing carries into the next request and two concurrent requests can never see each other's cookies. A batch of 500 URLs runs 500 independent jars, so every result stays reproducible on its own. This is deliberately narrower than httpx and requests, where redirect forwarding and cross-request persistence are the same client-wide jar and you can't have one without the other.

Every HTTP path funnels through send_inner, so this covers request(), request_batch(), request_batch_stream(), and download() without per-path plumbing. It does not apply to raw_connect() (no HTTP layer to read or build) or to requests using resolve_ip / request_target (that path doesn't follow redirects at all).

Cookie selection follows RFC 6265, which matters beyond correctness. A cookie with no Domain is host-only, a Domain that doesn't cover the host that set it is rejected, Path has to match on a segment boundary, and Secure cookies never go over plain HTTP. That's what stops a redirect from being used to walk a session cookie onto an unrelated host. Chain cookies merge into a caller-supplied Cookie header rather than being sent as a second one.

Pass redirect_cookies=False, or --no-redirect-cookies on the CLI, to revert to the previous behavior.

Covered by 17 unit tests on the jar plus 7 end-to-end tests that drive a real server through a 302 and read the second hop off the socket.

Heads up for anyone diffing scan output: results will move on targets that set a cookie and redirect. That's the fix working.

[en0f]

Comments:

Domain accepts public suffixes → cookie crosses hosts (src/cookies.rs:134-144)

domain_matches is a pure suffix-plus-label-boundary check with no public-suffix list, and §5.3 step 5 (reject a Domain that is a public suffix) isn't implemented anywhere. So Domain=com sent from any *.com host passes step 6 and is stored with host_only: false.

Repro against the code as written:

hop 1 GET https://attacker.com/x
302 Location: https://victim.com/
Set-Cookie: session=forced; Domain=com; Path=/
hop 2 GET https://victim.com/ -> Cookie: session=forced

domain_matches("attacker.com", "com") → not equal, not an IP, "attacker.com".len() > 3, ends with com, byte at index 8 is . → true. Then on hop 2 domain_matches("victim.com", "com") → true again. Same for co.uk, github.io, s3.amazonaws.com, etc.

This is the exact property the PR body and the module doc claim to guarantee ("stops a redirect from being used to walk a session cookie onto an unrelated host" / "never sent to a host it doesn't belong to"). It doesn't hold. Two directions matter: an attacker-controlled hop forcing a cookie onto a real target, and a real target that sets an over-broad Domain (harmless in browsers because they reject it, so servers do ship this) having its session cookie handed to an attacker-controlled redirect target under the same suffix.

ip_host_cannot_widen_via_domain and domain_not_covering_the_setting_host_is_rejected both pass and neither covers this. a domain=com case would fail today.

Fix needs either a PSL dependency (publicsuffix/psl) or, if you don't want the dep, a floor: reject a Domain attribute with no dot, and reject when the attribute has fewer labels than a hardcoded set of common two-label suffixes.