Minor 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
[JENKINS-37150] Add Whitelist to "Cross Site Request Forgery"
| Description |
Original:
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. |
New:
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 |
| Description |
Original:
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 |
New:
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 |
| Description |
Original:
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 |
New:
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 |
| Description |
Original:
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 |
New:
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 |
| Rank | New: Ranked higher |
| Description |
Original:
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 |
New:
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 |
| Description |
Original:
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 |
New:
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 |
| Description |
Original:
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 |
New:
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 |
| Description |
Original:
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 |
New:
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 |