• Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Major Major
    • core
    • jenkins 2.176.3 lts docker image

      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?

       

          [JENKINS-59229] 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

          Nathan Neulinger added a comment - 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

          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. 

          Nathan Neulinger added a comment - 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. 

          Jan Heylen added a comment -

          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

           

          Jan Heylen added a comment - 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  

          Jan Heylen added a comment -

          Jan Heylen added a comment - see https://jenkins.io/doc/upgrade-guide/2.176/#upgrading-to-jenkins-lts-2-176-3

          heyleke 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."

          Nathan Neulinger added a comment - heyleke  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."

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

          Nathan Neulinger added a comment - Never mind, I missed the option to put on the 'Strict Crumb Issuer' plugin to allow tuning.

          Jan Heylen added a comment -

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

          Jan Heylen added a comment - yes, indeed, planning to test the 'Strict Crumb Issuer' plugin to allow tuning. for this

            Unassigned Unassigned
            heyleke Jan Heylen
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: