[JIRA] (JENKINS-60524) Clarification on 'Improved CSRF protection for Jenkins 2.176.2'

nkanekar@salesforce.com (JIRA)

unread,

Dec 18, 2019, 5:18:03 AM12/18/19

to jenkinsc...@googlegroups.com

Neha Kanekar created an issue

Jenkins /

JENKINS-60524

Clarification on 'Improved CSRF protection for Jenkins 2.176.2'

Issue Type:	Task
Assignee:	Wadeck Follonier
Components:	strict-crumb-issuer-plugin
Created:	2019-12-18 10:17
Environment:	Jenkins version : 2.190.3.2, Strict Crumb Issuer Plugin : 2.0.1
Priority:	Minor
Reporter:	Neha Kanekar

Regarding the Security advisory published here : https://jenkins.io/doc/upgrade-guide/2.176/#SECURITY-626, there's some improved CSRF protection (SECURITY-626).

1. Basically CSRF tokens (crumbs) are now only valid for the web session for which they were created. I want to understand here if there was any major issue with CSRF to introduce this change?

2. Also, to disable this improvement we can set the system property

hudson.security.csrf.DefaultCrumbIssuer.EXCLUDE_SESSION_ID to true.

Is this property setting a workaround to make CSRF protection backward compatible or is this going to be deprecated in future and crumb requests have to use cookies compulsorily?

Add Comment

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

wfollonier@cloudbees.com (JIRA)

unread,

Dec 20, 2019, 4:46:02 AM12/20/19

to jenkinsc...@googlegroups.com

Wadeck Follonier edited a comment on

JENKINS-60524

Re: Clarification on 'Improved CSRF protection for Jenkins 2.176.2'

Hello [~n_kanekar],
Not sure creating a ticket for that is relevant, it seems a mail to the dev list is better suited. Anyway, I will reply here ;)

1) There was no major issue before. The goal here is to limit the attack surface. If you steal a CSRF token (no known vulnerability to achieve that at the moment), the user had no way to "revoke" it. With the session binding, re-logging is a way to more forward. Think about it as an additionnal layer of protection that you do not need right now, but will happy to have if your token is compromised ;)

2) We really try hard to never break features during a security update, but sometime we have to correct some less secure behavior (or totally insecure one) and for those situations we are providing a way for legacy configuration to still work. It's highly recommended to not use the escape hatches for the long run but more for a short period of time, to have the time to adjust internal stuff etc.

There is no plan yet to remove the previous escape hatches, but it's not meant to be used forever. We will perhaps use some telemetry to understand which ones are really used or not and remove the unused ones.

If you have a particular situation when the session ID binding is important to not be used, please explain your scenario for us to better understand and perhaps to propose a different approach.

(feel free to re-open the ticket + ping me if you want to reply, I will not actively watch this ticket)

Add Comment

wfollonier@cloudbees.com (JIRA)

unread,

Dec 20, 2019, 4:46:03 AM12/20/19

to jenkinsc...@googlegroups.com

Wadeck Follonier commented on

JENKINS-60524

Re: Clarification on 'Improved CSRF protection for Jenkins 2.176.2'

Hello Neha Kanekar,
Not sure creating a ticket for that is relevant, it seems a mail to the dev list is better suited. Anyway, I will reply here

1) There was no major issue before. The goal here is to limit the attack surface. If you steal a CSRF token (no known vulnerability to achieve that at the moment), the user had no way to "revoke" it. With the session binding, re-logging is a way to more forward. Think about it as an additionnal layer of protection that you do not need right now, but will happy to have if your token is compromised

2) We really try hard to never break features during a security update, but sometime we have to correct some less secure behavior (or totally insecure one) and for those situations we are providing a way for legacy configuration to still work. It's highly recommended to not use the escape hatches for the long run but more for a short period of time, to have the time to adjust internal stuff etc.

There is no plan yet to remove the previous escape hatches, but it's not meant to be used forever. We will perhaps use some telemetry to understand which ones are really used or not and remove the unused ones.

If you have a particular situation when the session ID binding is important to not be used, please explain your scenario for us to better understand and perhaps to propose a different approach.