paulk-asert opened a new pull request, #2811:
URL: https://github.com/apache/groovy/pull/2811
…her origin
With followRedirects and no confinement, redirect following was delegated to
the JDK client, which re-issued the request to the Location target carrying the
headers configured on the builder. Those headers are applied to every request,
so a token or key among them was sent to whatever origin a redirect named.
The platform cannot be relied on for this. Measured against a cross-host
redirect, on a chain that ends at a server which records what it received:
JDK 17.0.20 JDK 21.0.6 JDK 23.0.2
(2026-07) (2025-01) (2025-01)
Authorization stripped forwarded forwarded
Cookie stripped forwarded forwarded
Proxy-Authorization stripped stripped stripped
X-Api-Key forwarded forwarded forwarded
Two things follow. Whether the well known credential headers are protected
depends on the update level of the JDK in use, which an application cannot
choose. And a header the platform does not recognise is forwarded on every JDK,
while the builder's headers may hold anything the caller put there, so a policy
naming header names would repeat the same mistake at one remove.
Follow redirects here in every case rather than only under confinement, and
drop the caller's headers for good once a hop leaves the origin the request
started from. Same-origin redirects are unaffected, as is confinement, which
already rejected a cross-origin hop outright. A chain which returns to the
original origin does not get the headers back, since by then they have been
seen by another server.
Note this drops all of the caller's headers rather than a chosen few: which
of them carry credentials is not something this class can know.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
