compare scheme in redirect same-authority check#848
Conversation
| if (h1 == null || h2 == null) { | ||
| return false; | ||
| } | ||
| if (!h1.getSchemeName().equalsIgnoreCase(h2.getSchemeName())) { |
There was a problem hiding this comment.
A scheme change makes the origins different, but does not by itself require rejecting the redirect.
There was a problem hiding this comment.
agreed, and that's the intent here. the scheme mismatch only marks the origins as different, it doesn't reject the redirect on its own. an https to http hop still goes through unless there's an authorization or cookie header to protect, exactly as it already behaves for a differing host or port. the last assertion in the added test covers the plain https to http redirect staying allowed.
There was a problem hiding this comment.
Fair enough. Still, this changes the boundary from authority to origin and extends the existing rejection policy to scheme changes. That needs a clear rationale, and the method should be renamed to isSameOrigin.
2 participants
DefaultRedirectStrategy decides whether to keep the Authorization and Cookie headers on a redirect by comparing the current and new targets, but isSameAuthority only looks at the host name and the resolved port and leaves the scheme out. A response that redirects from https to http on the same host and the same explicit port, say https://host:8443/ to http://host:8443/, is treated as the same origin, so those credentials are retained and end up being sent in the clear. I've added the scheme to that comparison so a cross-scheme downgrade counts as a different origin and the sensitive headers are stripped as they already are for a different host or port.