Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not A Defect
-
None
-
Jenkins LTS 2.176.3
Description
Jenkins LTS 2.176.3 incorporated commit ace596, which factors the Session ID into the computation of CSRF crumbs; since a new Session ID is generated if none is provided, previously issued crumbs are rendered useless in the absence of a reusable Session ID. This currently prevents Swarm clients from connecting to Jenkins masters secured with the DefaultCrumbIssuer, since the generated crumb is immediately rendered useless.
I think a fix would involve the Swarm plugin using a persistent session ID on the client-side. I labeled this issue as "minor", because an easy workaround exists (setting hudson.security.csrf.DefaultCrumbIssuer.EXCLUDE_SESSION_ID to true on the Jenkins master). It should be noted, however, that this reduces the efficacy of the fixes to SECURITY-626 and SECURITY-1491.
Attachments
Issue Links
- is duplicated by
-
JENKINS-59305 Swarm Client failed to create a slave with response code: 403
-
- Closed
-
Hey Basil - Tried today with the latest versions of both the plugin and client; no dice - still seeing the issue, when I disable EXCLUDE_SESSION_ID.
I'll try to dig more and look into implementing an integration test, but I still think this makes some sense: The commit I cited in the original bug incorporates the "Session ID" (which as far as I can tell derives from the JSESSIONID cookie) into the crumb-generation logic. If we don't pass back the JSESSIONID (which we don't appear to), then our crumb will be invalidated. Example of the Set-Cookie header from the Jenkins master:
'Set-Cookie': 'ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE=; Path=/; Expires=Thu, 01-Jan-1970 00:00:00 GMT; Max-Age=0; Secure; HttpOnly,JSESSIONID.f443e328=node01s03czg5u9gagotkcld9tm98225.node0; Path=/; Secure; HttpOnly'
Note the JESSIONID.xyz component, which we don't seem to return to the master in subsequent requests.
Anyway, as I said - I'll try to dig more on my side.