[JENKINS-73422] JENKINS-72636 breaks scripted downloads

[jenkins-infra-bot]

The change made for JENKINS-72636 breaks scripted downloads with wget
If you follow the documentation https://www.jenkins.io/doc/book/system-administration/authenticating-scripted-clients/#shell-with-wget and use the command

wget --auth-no-challenge \
    --user=user --password=apiToken \
    http://jenkins.example.com/job/yourjob/lastSuccessfulBuild/artifact/build_record.txt

wget will pass the username and password both for the initial request to the jenkins URL.
Upon receiving the redirect to the resource URL, wget will again supply the BASIC authentication.

The change made causes the download to fail with a 400 error and a cryptic error message in the logs `hudson.security.AccessDeniedException3: anonymous is missing the Run/Artifacts permission`

Currently a work around is to use a `.netrc` so that the credentials are only sent for the main jenkins domain and not the resource subdomain

---

Originally reported by sm__liam_baker, imported from: JENKINS-72636 breaks scripted downloads

• assignee: allan_burdajewicz
• status: Resolved
• priority: Minor
• component(s): core
• label(s): 2.462.3-fixed
• resolution: Fixed
• resolved: 2024-09-02T00:04:35+00:00
• votes: 0
• watchers: 3
• imported: 2025-11-24

Raw content of original issue

The change made for JENKINS-72636 breaks scripted downloads with wget
If you follow the documentation https://www.jenkins.io/doc/book/system-administration/authenticating-scripted-clients/#shell-with-wget and use the command

wget --auth-no-challenge \
    --user=user --password=apiToken \
    http://jenkins.example.com/job/yourjob/lastSuccessfulBuild/artifact/build_record.txt

wget will pass the username and password both for the initial request to the jenkins URL.
Upon receiving the redirect to the resource URL, wget will again supply the BASIC authentication.
The change made causes the download to fail with a 400 error and a cryptic error message in the logs `hudson.security.AccessDeniedException3: anonymous is missing the Run/Artifacts permission`
Currently a work around is to use a `.netrc` so that the credentials are only sent for the main jenkins domain and not the resource subdomain

[jenkins-infra-bot]

• Remote links associated with this issue:

  • jenkins #​9644
  • PR #​7462

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  Upon receiving the redirect to the resource URL, wget will again supply the BASIC authentication. 
  It is unclear how the URL to trigger a new build redirects to an artifacts resource root URL. Did you skip a bunch of steps in the middle, or provide a wrong URL?
  

Upon receiving the redirect to the resource URL, wget will again supply the BASIC authentication. 

It is unclear how the URL to trigger a new build redirects to an artifacts resource root URL. Did you skip a bunch of steps in the middle, or provide a wrong URL?

[jenkins-infra-bot]

sm__liam_baker:

• Original comment link
• Raw content of original comment:

  In fact the page contains no example for downloading an artifact using a script, only triggering a build.
  
  Let me fix that end point URL.
  
  What the script is doing is downloading an artifact created by the job using the API token. 
  wget then passes the token to the resource URL e.g. resource.jenkins.domain/static-files/tJhSwZX....=/build_record.txt
  However when a request with an Authorization header is sent to the resource URL, Jenkins returns a 400 Error
  

In fact the page contains no example for downloading an artifact using a script, only triggering a build.

Let me fix that end point URL.

What the script is doing is downloading an artifact created by the job using the API token.
wget then passes the token to the resource URL e.g. resource.jenkins.domain/static-files/tJhSwZX....=/build_record.txt
However when a request with an Authorization header is sent to the resource URL, Jenkins returns a 400 Error

[jenkins-infra-bot]

allan_burdajewicz:

• Original comment link
• Raw content of original comment:

  [Authorization - HTTP | MDN|https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization#browser_compatibility] only mentions the following about redirects:
  
  > This header is stripped from cross-origin redirects.
  
  Here the host differs on redirect, so the header should be stripped automatically by clients.. But then looking at the clients implementation, it gets interesting.
  
  curl seem to have this default behavior of stripping the authorization header on redirect by default, though whatever the host in the redirection.
  
  curl - HTTP authentication leak in redirects - CVE-2018-1000007
  
  But wget for example does not, there is actually a CVE because it sends the Authorization header on redirection, whatever the host:
  
  NVD - CVE-2021-31879 
  
  To sum up, curl is always stripping which is not actually necessary. curl is unaffected. wget is never stripping which is apparently a security issue.. In a way, clients that are affected probably are affected by a similar security issue.
  
  For the issue at stake, maybe we could revert the commit or maybe log a warning that Auth is used instead of failing the request ?
  

[Authorization - HTTP | MDN|https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization#browser_compatibility] only mentions the following about redirects:

> This header is stripped from cross-origin redirects.

Here the host differs on redirect, so the header should be stripped automatically by clients.. But then looking at the clients implementation, it gets interesting.

curl seem to have this default behavior of stripping the authorization header on redirect by default, though whatever the host in the redirection.

curl - HTTP authentication leak in redirects - CVE-2018-1000007

But wget for example does not, there is actually a CVE because it sends the Authorization header on redirection, whatever the host:

NVD - CVE-2021-31879

To sum up, curl is always stripping which is not actually necessary. curl is unaffected. wget is never stripping which is apparently a security issue.. In a way, clients that are affected probably are affected by a similar security issue.

For the issue at stake, maybe we could revert the commit or maybe log a warning that Auth is used instead of failing the request ?

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  log a warning
  One of the more critical ways to exploit CVE-2024-23897 ("Remote code execution via Resource Root URLs (Variant 2)" in https://www.jenkins.io/security/advisory/2024-01-24/ ) requires sending requests like are being prohibited by JENKINS-72636, so I'd rather not revert it if the motivation is an unresolved CVE in a different tool.
  
  Having a system property escape hatch to opt out of protection should be fine though.
  
  (Prohibiting authenticated requests is only a workaround as well, the real solution would be a change to how resource root URL works, including changes to Stapler.)
  

log a warning

One of the more critical ways to exploit CVE-2024-23897 ("Remote code execution via Resource Root URLs (Variant 2)" in https://www.jenkins.io/security/advisory/2024-01-24/ ) requires sending requests like are being prohibited by JENKINS-72636, so I'd rather not revert it if the motivation is an unresolved CVE in a different tool.

Having a system property escape hatch to opt out of protection should be fine though.

(Prohibiting authenticated requests is only a workaround as well, the real solution would be a change to how resource root URL works, including changes to Stapler.)

[jenkins-infra-bot]

allan_burdajewicz:

• Original comment link
• Raw content of original comment:

  I see. Makes sense. I have proposed [JENKINS-73422] Add escape hatch for Authenticated user access to Resource URL #9644.
  

I see. Makes sense. I have proposed #9644.

[jenkins-infra-bot]

sm__liam_baker:

• Original comment link
• Raw content of original comment:

  Thanks for the fix, we will wait for it to make it to LTS.
  I assume this is set as a JAVA opt at startup e.g.
  `-Djenkins.security.ResourceDomainRootAction.allowAuthenticatedUser=true` 
  

Thanks for the fix, we will wait for it to make it to LTS.
I assume this is set as a JAVA opt at startup e.g.
`-Djenkins.security.ResourceDomainRootAction.allowAuthenticatedUser=true`