Issue
How do I enable CSRF protection?
Environment
- CloudBees Jenkins Enterprise
- CloudBees Operation Center
Resolution
GOTO: Jenkins > Manage Jenkins > Configure Global Security and enable Prevent Cross Site Request Forgery exploits.
Select Default Crumb Issuer from Crumb Algorithm and save to apply changes and enable.
See the CSRF Protection Wiki page for more.
Issue
How do I generate a crumb?
Environment
- CloudBees Jenkins Enterprise
- CloudBees Operation Center
- wget
- cURL
Resolution
Using wget
wget --user=admin --password=admin --auth-no-challenge -q --output-document - 'http://localhost:8080/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,":",//crumb)'
The output is the crumb.
Parameters:
--user=<USERNAME>--password=<PASSWORD_OR_API_TOKEN>
Replace http://localhost:8080 with your Jenkins URL.
Using cURL
curl -u "admin:admin" 'http://localhost:8080/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,":",//crumb)'
The output is the crumb.
Parameters:
-u "<USERNAME>:<PASSWORD_OR_API_TOKEN>"
Replace http://localhost:8080 with your Jenkins URL.
Debugging Issues
Im seeing the following response:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>Error 404 Not Found</title>
</head>
<body><h2>HTTP ERROR 404</h2>
<p>Problem accessing /crumbIssuer/api/xml. Reason:
<pre> Not Found</pre></p><hr /><i><small>Powered by Jetty://</small></i><br/>
...
...
CSRF Protection is not enabled. GOTO: Jenkins > Manage Jenkins > Configure Global Security and enable Prevent Cross Site Request Forgery exploits.
Issue
How do I use an issued crumb in an API call.
Environment
- CloudBees Jenkins Enterprise
- CloudBees Operation Center
- cURL
- wget
Resolution
Using wget
The following example builds job someJob, utilising an issued crumb.
wget --user=admin --password=admin --auth-no-challenge --header=".crumb:bc22da3c06187f7c042abeb72419d835" --post-data="" -q http://localhost:8080/job/someJob/build
Parameters:
--user=<USERNAME>--password=<PASSWORD_OR_API_TOKEN>--header="<ISSUED_CRUMB_FOR_USER>"
Replace http://localhost:8080 with your Jenkins URL.
Using cURL
The following example builds job someJob, utilising an issued crumb.
curl -X POST -u "admin:admin" -H ".crumb:bc22da3c06187f7c042abeb72419d835" http://localhost:8080/job/someJob/build
Parameters:
-u "<USERNAME>:<PASSWORD_OR_API_TOKEN>"-H "<ISSUED_CRUMB_FOR_USER>"
Replace http://localhost:8080 with your Jenkins URL.
Debugging Issues
Im seeing the following response:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>Error 403 No valid crumb was included in the request</title>
</head>
<body><h2>HTTP ERROR 403</h2>
<p>Problem accessing /job/someJob/build. Reason:
<pre> No valid crumb was included in the request</pre></p><hr /><i><small>Powered by Jetty://</small></i><br/>
...
...
This is caused by an invalid crumb being used.
Issue
Does the crumb expire?
Environment
- CloudBees Jenkins Enterprise
- CloudBees Operation Center
Resolution
Once an user has received a crumb, it can re-used for all subsequent requests as long as this user stays in the same session. At code level, this dependency can be seen here.
Note :
- Session may expire on its own depending on Jenkins settings.
- Session might be aborted due to unexpected reasons, such as Failover of HA in CJP or SSO expiration
- So generally keeping the same crumb is safe for short command sequences, but not for scripts running for several hours
Issue
How is the crumb generated?
Environment
- CloudBees Jenkins Enterprise
- CloudBees Operation Center
Resolution
Using MD5. The crumb is a combination of user authentication (if authentication is applied), originating IP address and the crumb salt.
Issue
Is the crumb salt configurable?
Environment
- CloudBees Jenkins Enterprise
- CloudBees Operation Center
Resolution
Currently no. It is hard-coded.
Issue
How do I use Jenkins CSRF protection behind a reverse proxy?
Environment
- CloudBees Jenkins Enterprise
- CloudBees Operation Center
- Reverse Proxy (applies to all)
Resolution
See CSRF Protection, Gotchas section.
0 Comments