Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-59229

csrf protection too strict?

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Won't Fix
    • Component/s: core
    • Labels:
    • Environment:
      jenkins 2.176.3 lts docker image
    • Similar Issues:

      Description

      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?

       

        Attachments

          Activity

          Hide
          nneul 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

          Show
          nneul 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
          Hide
          nneul 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. 

          Show
          nneul 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. 
          Hide
          heyleke 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

           

          Show
          heyleke 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  
          Show
          heyleke Jan Heylen added a comment - see https://jenkins.io/doc/upgrade-guide/2.176/#upgrading-to-jenkins-lts-2-176-3
          Hide
          nneul Nathan Neulinger added a comment -

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

          Show
          nneul Nathan Neulinger added a comment - 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."
          Hide
          nneul Nathan Neulinger added a comment -

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

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

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

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

            People

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

              Dates

              Created:
              Updated:
              Resolved: