[rootvector2]

HTTPConduit.checkAllowedRedirectUri enforces http.redirect.allowed.uri with a plain newURL.startsWith(allowedRedirectURI), so with the allowed value https://api.example.com a server can answer 302 with Location: https://api.example.com@evil.example/ (or https://api.example.com.evil.example/) and the conduit follows it, re-applying the configured AuthorizationPolicy so Basic credentials are sent to the other host. Found while reviewing the conduit redirect checks, and the new HTTPConduitAllowedRedirectUriTest reproduces it with two local servers. The prefix check now also requires the redirect URI's authority to equal the allowed URI's authority.

[reta]

There are 2 properties in play here:

• AUTO_REDIRECT_SAME_HOST_ONLY: this one only allow redirects to the same scheme/host and will address your concern I believe
• AUTO_REDIRECT_ALLOWED_URI: freestyle prefix match (the user could make the prefix as strict as possible)

Hope it makes sense, thank you

[rootvector2]

Makes sense. With http.redirect.same.host.only set, the @evil.example and .evil.example redirects are already rejected, and a configured value with a trailing / (e.g. https://api.example.com/) closes it for http.redirect.allowed.uri too. So this is a config concern rather than a bug in the check. Happy to close this, or turn it into a short doc note on the property that the value is a raw prefix match, whichever you prefer.

[reta]

I will update docs shortly, seems like we never documented those, the pr could be closed, thanks @rootvector2

[rootvector2]

Sounds good, closing this one. A note that http.redirect.allowed.uri is a raw prefix match, so the value should end with /, would cover the case.

[reta]

https://cxf.apache.org/docs/client-http-transport-including-ssl-support.html