[JIRA] (JENKINS-59229) csrf protection too strict?

[heyleke@gmail.com (JIRA)]

Jan Heylen created an issue

Jenkins / JENKINS-59229 csrf protection too strict? Issue Type: Bug Assignee: Unassigned Components: core Created: 2019-09-04 16:06 Environment: jenkins 2.176.3 lts docker image Labels: security Priority: Major Reporter: Jan Heylen tested as follows with 2.176.2 successfully: wget -q --auth-no-challenge --user jheylen --password XXXXXX --output-document - 'http://jenkins/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,":",//crumb)'  crumb=Jenkins-Crumb:1e7fe08f74e2ad6814e309af63986292 curl -X POST -H Jenkins-Crumb:1e7fe08f74e2ad6814e309af63986292 --silent --basic -u jheylen:XXXXXXX 'http://jenkins/me/descriptorByName/jenkins.security.ApiTokenProperty/generateNewToken?newTokenName=temp' API_token=1103e007f9659c28d25ee... But with 2.176.3, we get: Sep 04, 2019 3:51:40 PM hudson.security.csrf.CrumbFilter doFilter WARNING: Found invalid crumb 22bdf12008e1ee08ae29a897a00f669d. Will check remaining parameters for a valid one... Sep 04, 2019 3:51:40 PM hudson.security.csrf.CrumbFilter doFilter WARNING: No valid crumb was included in request for /descriptorByName/hudson.security.LDAPSecurityRealm$CacheConfiguration/fillTtlItems by jheylen. Returning 403. for every crumb retrieved with above workflow. Is this an issue in 2.176.3, or are we using the api/crumb in a wrong way?   Add Comment

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

[nneul@neulinger.org (JIRA)]

Nathan Neulinger commented on JENKINS-59229

Re: csrf protection too strict? Started getting this on my instance as well. In my case, changing my triggering code to maintain session cookies was sufficient to get it to work. Didn't find a "nice" way to do that with curl/wget though, so wound up switching to a perl based trigger. It seems like --cookie-jar SHOULD work, but didn't for me.  I believe it's related to this: https://jenkins.io/security/advisory/2019-07-17/#SECURITY-626

Add Comment

[nneul@neulinger.org (JIRA)]

Nathan Neulinger commented on JENKINS-59229

Re: csrf protection too strict?

Either way - it's clear that the change above has likely broken tons of legacy code that already was previously broken when enabling CSRF. Tons of examples on how to use it are now likely wrong/broken.

Add Comment

[heyleke@gmail.com (JIRA)]

Jan Heylen commented on JENKINS-59229

Re: csrf protection too strict?

ok, we'll try to change our scripts accordingly and I'll post the working version here afterwards, thx for the links, very useful, didn't seem to find them before :-s

Add Comment

[heyleke@gmail.com (JIRA)]

Jan Heylen resolved as Won't Fix

see https://jenkins.io/doc/upgrade-guide/2.176/#upgrading-to-jenkins-lts-2-176-3

Jenkins / JENKINS-59229 csrf protection too strict?

Change By: Jan Heylen Status: Open Resolved Resolution: Won't Fix

Add Comment

[nneul@neulinger.org (JIRA)]

Nathan Neulinger commented on JENKINS-59229

Re: csrf protection too strict?

Jan Heylen I do think this is something that they should be addressing since it seems like "outright break existing functionality" is something that shouldn't be sprung on users in a security update without any ability for an admin to say "Hey, I get this is a problem, but the fix is worse than the problem in terms of breakage – let me turn it off and have a chance to make the appropriate updates in my build system while you continue to generate WARNINGS internally, and when I (customer) am ready for it, I'll fully enable it – just like the option to enable CSRF protection at all."

Add Comment

[nneul@neulinger.org (JIRA)]

Nathan Neulinger commented on JENKINS-59229

Re: csrf protection too strict?

Never mind, I missed the option to put on the 'Strict Crumb Issuer' plugin to allow tuning.

Add Comment

[heyleke@gmail.com (JIRA)]

Jan Heylen commented on JENKINS-59229

Re: csrf protection too strict?

yes, indeed, planning to test the 'Strict Crumb Issuer' plugin to allow tuning. for this

Add Comment