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

Add Whitelist to "Cross Site Request Forgery"

    Details

    • Similar Issues:

      Description

      A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

      Out of the box, Jenkins 2.x enables a security feature called "Prevent Cross Site Request Forgery exploits" that rejects all POST requests that don't have a valid 'crumb' token associated with them. This is a great security feature.

      Since most Git hosting services don't have any mechanism to retrieve or handle a crumb, that means that their POST requests get blocked on a Jenkins installation with default settings. "Prevent Cross Site Request Forgery exploits" needs to be manually disabled in order to allow the host's webhooks to work with Jenkins out-of-the-box, or a service-specific plugin needs to be installed.

      There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works (and lets us keep CSRF enabled), but it means that every hosting service needs its own special Jenkins plugin just to trigger a remote SCM poll. It also means that a lot of smaller or self-hosted services get left in the dust.

      Would it be possible to add a configurable domain-name whitelist to the CSRF protection feature? That would let a Jenkins installation receive POST requests from specific servers and still keep general CSRF protection in-place. This could maybe take the form of a text-box on the "Configure Global Security" page where we could add whitelisted domains.

      This is a general-purpose fix that would permanently solve all issues of this general type:
      https://issues.jenkins-ci.org/browse/JENKINS-33878
      https://issues.jenkins-ci.org/browse/JENKINS-30384
      https://issues.jenkins-ci.org/browse/JENKINS-25421
      https://issues.jenkins-ci.org/browse/JENKINS-22474
      https://issues.jenkins-ci.org/browse/JENKINS-20140
      https://issues.jenkins-ci.org/browse/JENKINS-10263
      https://issues.jenkins-ci.org/browse/JENKINS-14372

        Attachments

          Activity

          nrclark Nick Clark created issue -
          nrclark Nick Clark made changes -
          Field Original Value New Value
          Description A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_, which rejects all POST requests that don't have a valid 'crumb' token associated with them.

          Since most Git hosts don't have any mechanism to retrieve or handle a crumb, that means that _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works, but it means that every hosting service needs a specific Jenkins plugin in order to allow POST webhooks to work if CSRF protection is enabled.

          Would it be possible to add a domain-name whitelist to the CSRF protection feature? That would allow a Jenkins administrator to allow POST requests from specific servers and still keep CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.
          A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_, which rejects all POST requests that don't have a valid 'crumb' token associated with them.

          Since most Git hosts don't have any mechanism to retrieve or handle a crumb, that means that _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works, but it means that every hosting service needs a specific Jenkins plugin in order to allow POST webhooks to work if CSRF protection is enabled.

          Would it be possible to add a domain-name whitelist to the CSRF protection feature? That would allow a Jenkins administrator to allow POST requests from specific servers and still keep CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This would be a general-purpose fix that would solve all issues of the type, and would help prevent new ones as new hosting services crop up.
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372
          nrclark Nick Clark made changes -
          Description A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_, which rejects all POST requests that don't have a valid 'crumb' token associated with them.

          Since most Git hosts don't have any mechanism to retrieve or handle a crumb, that means that _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works, but it means that every hosting service needs a specific Jenkins plugin in order to allow POST webhooks to work if CSRF protection is enabled.

          Would it be possible to add a domain-name whitelist to the CSRF protection feature? That would allow a Jenkins administrator to allow POST requests from specific servers and still keep CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This would be a general-purpose fix that would solve all issues of the type, and would help prevent new ones as new hosting services crop up.
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372
          A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_, which rejects all POST requests that don't have a valid 'crumb' token associated with them.

          Since most Git hosts don't have any mechanism to retrieve or handle a crumb, that means that _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works, but it means that every hosting service needs a specific Jenkins plugin in order to allow POST webhooks to work if CSRF protection is enabled.

          Would it be possible to add a domain-name whitelist to the CSRF protection feature? That would allow a Jenkins administrator to allow POST requests from specific servers and still keep CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This is a general-purpose fix that would solve all issues of the type, and would help prevent new ones as new hosting services crop up.
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372
          nrclark Nick Clark made changes -
          Description A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_, which rejects all POST requests that don't have a valid 'crumb' token associated with them.

          Since most Git hosts don't have any mechanism to retrieve or handle a crumb, that means that _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works, but it means that every hosting service needs a specific Jenkins plugin in order to allow POST webhooks to work if CSRF protection is enabled.

          Would it be possible to add a domain-name whitelist to the CSRF protection feature? That would allow a Jenkins administrator to allow POST requests from specific servers and still keep CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This is a general-purpose fix that would solve all issues of the type, and would help prevent new ones as new hosting services crop up.
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372
          A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_, which rejects all POST requests that don't have a valid 'crumb' token associated with them.

          Since most Git hosts don't have any mechanism to retrieve or handle a crumb, that means that _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works, but it means that every hosting service needs a specific Jenkins plugin in order to allow POST webhooks to work if CSRF protection is enabled.

          Would it be possible to add a domain-name whitelist to the CSRF protection feature? That would allow a Jenkins administrator to allow POST requests from specific servers and still keep CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This is a general-purpose fix that would solve all issues of this general type:
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372
          nrclark Nick Clark made changes -
          Description A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_, which rejects all POST requests that don't have a valid 'crumb' token associated with them.

          Since most Git hosts don't have any mechanism to retrieve or handle a crumb, that means that _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works, but it means that every hosting service needs a specific Jenkins plugin in order to allow POST webhooks to work if CSRF protection is enabled.

          Would it be possible to add a domain-name whitelist to the CSRF protection feature? That would allow a Jenkins administrator to allow POST requests from specific servers and still keep CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This is a general-purpose fix that would solve all issues of this general type:
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372
          A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_, which rejects all POST requests that don't have a valid 'crumb' token associated with them.

          Since most Git hosts don't have any mechanism to retrieve or handle a crumb, that means that _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works, but it means that every hosting service needs a specific Jenkins plugin in order to allow POST webhooks to work if CSRF protection is enabled.

          Would it be possible to add a domain-name whitelist to the CSRF protection feature? That would allow a Jenkins administrator to allow POST requests from specific servers and still keep CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This is a general-purpose fix that would permanently solve all issues of this general type:
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372
          nrclark Nick Clark made changes -
          Rank Ranked higher
          nrclark Nick Clark made changes -
          Description A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_, which rejects all POST requests that don't have a valid 'crumb' token associated with them.

          Since most Git hosts don't have any mechanism to retrieve or handle a crumb, that means that _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works, but it means that every hosting service needs a specific Jenkins plugin in order to allow POST webhooks to work if CSRF protection is enabled.

          Would it be possible to add a domain-name whitelist to the CSRF protection feature? That would allow a Jenkins administrator to allow POST requests from specific servers and still keep CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This is a general-purpose fix that would permanently solve all issues of this general type:
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372
          A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_ that rejects all POST requests that don't have a valid 'crumb' token associated with them. This is a great security feature.

          Since most Git hosts don't have any mechanism to retrieve or handle a crumb, that means that _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work with Jenkins out-of-the-box.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works (and lets us keep CSRF enabled), but it means that every hosting service needs its own special Jenkins plugin just to trigger a remote SCM poll.

          Would it be possible to add a domain-name whitelist to the CSRF protection feature? That would allow a Jenkins administrator to allow POST requests from specific servers and still keep CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This is a general-purpose fix that would permanently solve all issues of this general type:
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372
          nrclark Nick Clark made changes -
          Description A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_ that rejects all POST requests that don't have a valid 'crumb' token associated with them. This is a great security feature.

          Since most Git hosts don't have any mechanism to retrieve or handle a crumb, that means that _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work with Jenkins out-of-the-box.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works (and lets us keep CSRF enabled), but it means that every hosting service needs its own special Jenkins plugin just to trigger a remote SCM poll.

          Would it be possible to add a domain-name whitelist to the CSRF protection feature? That would allow a Jenkins administrator to allow POST requests from specific servers and still keep CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This is a general-purpose fix that would permanently solve all issues of this general type:
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372
          A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_ that rejects all POST requests that don't have a valid 'crumb' token associated with them. This is a great security feature.

          Since most Git hosts don't have any mechanism to retrieve or handle a crumb, that means that _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work with Jenkins out-of-the-box.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works (and lets us keep CSRF enabled), but it means that every hosting service needs its own special Jenkins plugin just to trigger a remote SCM poll.

          Would it be possible to add a configurable domain-name whitelist to the CSRF protection feature? That would let a Jenkins installation receive POST requests from specific servers and still keep CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This is a general-purpose fix that would permanently solve all issues of this general type:
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372


          nrclark Nick Clark made changes -
          Description A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_ that rejects all POST requests that don't have a valid 'crumb' token associated with them. This is a great security feature.

          Since most Git hosts don't have any mechanism to retrieve or handle a crumb, that means that _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work with Jenkins out-of-the-box.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works (and lets us keep CSRF enabled), but it means that every hosting service needs its own special Jenkins plugin just to trigger a remote SCM poll.

          Would it be possible to add a configurable domain-name whitelist to the CSRF protection feature? That would let a Jenkins installation receive POST requests from specific servers and still keep CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This is a general-purpose fix that would permanently solve all issues of this general type:
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372


          A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_ that rejects all POST requests that don't have a valid 'crumb' token associated with them. This is a great security feature.

          Since most Git hosts don't have any mechanism to retrieve or handle a crumb, that means that _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work with Jenkins out-of-the-box.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works (and lets us keep CSRF enabled), but it means that every hosting service needs its own special Jenkins plugin just to trigger a remote SCM poll.

          Would it be possible to add a configurable domain-name whitelist to the CSRF protection feature? That would let a Jenkins installation receive POST requests from specific servers and still keep general CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This is a general-purpose fix that would permanently solve all issues of this general type:
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372


          nrclark Nick Clark made changes -
          Description A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_ that rejects all POST requests that don't have a valid 'crumb' token associated with them. This is a great security feature.

          Since most Git hosts don't have any mechanism to retrieve or handle a crumb, that means that _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work with Jenkins out-of-the-box.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works (and lets us keep CSRF enabled), but it means that every hosting service needs its own special Jenkins plugin just to trigger a remote SCM poll.

          Would it be possible to add a configurable domain-name whitelist to the CSRF protection feature? That would let a Jenkins installation receive POST requests from specific servers and still keep general CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This is a general-purpose fix that would permanently solve all issues of this general type:
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372


          A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_ that rejects all POST requests that don't have a valid 'crumb' token associated with them. This is a great security feature.

          Since most Git hosts don't have any mechanism to retrieve or handle a crumb, that means that _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work with Jenkins out-of-the-box.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works (and lets us keep CSRF enabled), but it means that every hosting service needs its own special Jenkins plugin just to trigger a remote SCM poll. It also means that a lot of smaller or self-hosted services get left in the dust.

          Would it be possible to add a configurable domain-name whitelist to the CSRF protection feature? That would let a Jenkins installation receive POST requests from specific servers and still keep general CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This is a general-purpose fix that would permanently solve all issues of this general type:
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372


          nrclark Nick Clark made changes -
          Description A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_ that rejects all POST requests that don't have a valid 'crumb' token associated with them. This is a great security feature.

          Since most Git hosts don't have any mechanism to retrieve or handle a crumb, that means that _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work with Jenkins out-of-the-box.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works (and lets us keep CSRF enabled), but it means that every hosting service needs its own special Jenkins plugin just to trigger a remote SCM poll. It also means that a lot of smaller or self-hosted services get left in the dust.

          Would it be possible to add a configurable domain-name whitelist to the CSRF protection feature? That would let a Jenkins installation receive POST requests from specific servers and still keep general CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This is a general-purpose fix that would permanently solve all issues of this general type:
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372


          A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_ that rejects all POST requests that don't have a valid 'crumb' token associated with them. This is a great security feature.

          Since most Git hosting services don't have any mechanism to retrieve or handle a crumb, that means that their POST requests get blocked on a Jenkins installation with default settings. _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work with Jenkins out-of-the-box.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works (and lets us keep CSRF enabled), but it means that every hosting service needs its own special Jenkins plugin just to trigger a remote SCM poll. It also means that a lot of smaller or self-hosted services get left in the dust.

          Would it be possible to add a configurable domain-name whitelist to the CSRF protection feature? That would let a Jenkins installation receive POST requests from specific servers and still keep general CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This is a general-purpose fix that would permanently solve all issues of this general type:
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372


          nrclark Nick Clark made changes -
          Description A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_ that rejects all POST requests that don't have a valid 'crumb' token associated with them. This is a great security feature.

          Since most Git hosting services don't have any mechanism to retrieve or handle a crumb, that means that their POST requests get blocked on a Jenkins installation with default settings. _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work with Jenkins out-of-the-box.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works (and lets us keep CSRF enabled), but it means that every hosting service needs its own special Jenkins plugin just to trigger a remote SCM poll. It also means that a lot of smaller or self-hosted services get left in the dust.

          Would it be possible to add a configurable domain-name whitelist to the CSRF protection feature? That would let a Jenkins installation receive POST requests from specific servers and still keep general CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This is a general-purpose fix that would permanently solve all issues of this general type:
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372


          A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

          Out of the box, Jenkins 2.x enables a security feature called _"Prevent Cross Site Request Forgery exploits"_ that rejects all POST requests that don't have a valid 'crumb' token associated with them. This is a great security feature.

          Since most Git hosting services don't have any mechanism to retrieve or handle a crumb, that means that their POST requests get blocked on a Jenkins installation with default settings. _"Prevent Cross Site Request Forgery exploits"_ needs to be manually disabled in order to allow the host's webhooks to work with Jenkins out-of-the-box, or a service-specific plugin needs to be installed.

          There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works (and lets us keep CSRF enabled), but it means that every hosting service needs its own special Jenkins plugin just to trigger a remote SCM poll. It also means that a lot of smaller or self-hosted services get left in the dust.

          Would it be possible to add a configurable domain-name whitelist to the CSRF protection feature? That would let a Jenkins installation receive POST requests from specific servers and still keep general CSRF protection in-place. This could maybe take the form of a text-box on the _"Configure Global Security"_ page where we could add whitelisted domains.

          This is a general-purpose fix that would permanently solve all issues of this general type:
          https://issues.jenkins-ci.org/browse/JENKINS-33878
          https://issues.jenkins-ci.org/browse/JENKINS-30384
          https://issues.jenkins-ci.org/browse/JENKINS-25421
          https://issues.jenkins-ci.org/browse/JENKINS-22474
          https://issues.jenkins-ci.org/browse/JENKINS-20140
          https://issues.jenkins-ci.org/browse/JENKINS-10263
          https://issues.jenkins-ci.org/browse/JENKINS-14372


          Hide
          danielbeck Daniel Beck added a comment -

          Specific endpoints in Jenkins can opt out of requiring CSRF crumbs. That's the approach that should be taken here, rather than burden the admin with something they're likely ill-equipped to deal with.

          Show
          danielbeck Daniel Beck added a comment - Specific endpoints in Jenkins can opt out of requiring CSRF crumbs. That's the approach that should be taken here, rather than burden the admin with something they're likely ill-equipped to deal with.
          danielbeck Daniel Beck made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Won't Fix [ 2 ]
          oleg_nenashev Oleg Nenashev made changes -
          Component/s security [ 15508 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              nrclark Nick Clark
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: