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

Disable Jenkins API tokens by default

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Submitting as delegate for a Cisco pen-testing team
      This is an enhancement to improve the security posture of the default Jenkins install.

      Headline: Disable Jenkins API tokens by default
      Platforms: Jenkins
      Versions: 1.622
      CWE Tags: CWE-671, CWE-424

      Jenkins allows users to authenticate via multiple mechanisms, including an
      automatically generated API token. Despite the name, the API token provides
      users with a fully authenticated session (the same as if the user had logged in
      using a password).

      In many common usage scenarios, a user may never require an API token. For
      example, a user who exclusively accesses Jenkins via the web-based UI will never
      use an API token. Although probably less common, a user who exclusively
      utilizes the SSH-based Jenkins CLI will also never use an API token.

      In scenarios such as these, the existence of an active API token serves no
      purpose to the user and represents a weakness in that it broadens the overall
      attack surface. For this reason, API tokens should not be generated for users
      unless they explicitly request a token. Furthermore, individual users should
      have the ability to remove/disable existing API tokens. Lastly, Jenkins
      administrators should be able to remove a user's API token (e.g. if the token
      has been compromised) and disable the usage of API tokens system-wide.

      References:
      http://cwe.mitre.org/data/definitions/424.html
      http://cwe.mitre.org/data/definitions/671.html

        Attachments

          Issue Links

            Activity

            Hide
            danielbeck Daniel Beck added a comment -

            This is a good suggestion. Thank you.

            While security related, this is not a vulnerability, so I'll move it to the public JENKINS tracker unless someone objects.

            Show
            danielbeck Daniel Beck added a comment - This is a good suggestion. Thank you. While security related, this is not a vulnerability, so I'll move it to the public JENKINS tracker unless someone objects.
            Hide
            crlorent Craig Lorentzen added a comment -

            Moving to public is fine by me.

            Show
            crlorent Craig Lorentzen added a comment - Moving to public is fine by me.
            Hide
            jglick Jesse Glick added a comment -

            Jenkins administrators should be able to remove a user's API token (e.g. if the token has been compromised)

            This at least is already possible—at least, you can force it to be updated to a new random value.

            I suspect the whole token system could be moved into a plugin, which paranoid administrators could simply uninstall. TBD if the core API for registering a custom servlet filter is sufficiently powerful for this case.

            Show
            jglick Jesse Glick added a comment - Jenkins administrators should be able to remove a user's API token (e.g. if the token has been compromised) This at least is already possible—at least, you can force it to be updated to a new random value. I suspect the whole token system could be moved into a plugin, which paranoid administrators could simply uninstall. TBD if the core API for registering a custom servlet filter is sufficiently powerful for this case.
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            +1 for moving.
            It's a good proposal for security hardening

            Show
            oleg_nenashev Oleg Nenashev added a comment - +1 for moving. It's a good proposal for security hardening
            Hide
            jglick Jesse Glick added a comment -

            It would be handy to have a method in JenkinsRule.WebClient to logInViaApiToken(String username) which could be used for testing permission checks on API requests. (Plenty of tests already use login(String) for this purpose but it is slow as it needs to open the login HTML page and submit the form, when we could simply addRequestHeader to use token authentication without any actual login request.) However such a test utility would be broken by turning off tokens by default (or moving them to an optional plugin) unless some care was taken to ensure that Java-level calls to User.get(…).getProperty(ApiTokenProperty.class).getApiToken() continued to generate a token on demand.

            Show
            jglick Jesse Glick added a comment - It would be handy to have a method in JenkinsRule.WebClient to logInViaApiToken(String username) which could be used for testing permission checks on API requests. (Plenty of tests already use login(String) for this purpose but it is slow as it needs to open the login HTML page and submit the form, when we could simply addRequestHeader  to use token authentication without any actual login request.) However such a test utility would be broken by turning off tokens by default (or moving them to an optional plugin) unless some care was taken to ensure that Java-level calls to User.get(…).getProperty(ApiTokenProperty.class).getApiToken() continued to generate a token on demand.
            Hide
            wfollonier Wadeck Follonier added a comment -

            Correction released in 2.129.

            Show
            wfollonier Wadeck Follonier added a comment - Correction released in 2.129.

              People

              • Assignee:
                wfollonier Wadeck Follonier
                Reporter:
                crlorent Craig Lorentzen
              • Votes:
                2 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: