[JENKINS-55557] Add support for state parameter #107
Conversation
which mitigates CSRF attacks when using the authorization code grant flow of oAuth2
Generate a random string satisfying the specification's requirements without using Base64 so that the plugin can be used with installations using Java 7
|
Is there any interest in this ? Would someone like to review or give some feedback? |
|
This looks good to me. I'll test it; thank you for contributing 👍 |
This octomerge simplifies merging multiple pull requests. They've all been tested in conjunction and don't cause any upgrade issues.
|
This has been released in github-oauth 0.32 |
|
@jkakavas can you investigate https://issues.jenkins-ci.org/browse/JENKINS-57154 ? |
|
@samrocketman will take a look tomorrow my morning, thanks for the ping |
|
@samrocketman Given that the error described in https://issues.jenkins-ci.org/browse/JENKINS-57154 is about fetching the details of a user, maybe this bug could be a byproduct of #109 that explicitly touches cc @agentgonzo |
|
@samrocketman I have verified that 0.32 shows the problematic behavior that users describe in https://issues.jenkins-ci.org/browse/JENKINS-57154 even with the changes from this PR reverted. As such, I believe that something else that has changed between 0.31 was released and now is at fault. I'll probably find some time to troubleshoot further in the week, but maybe someone who is more accustomed with the plugin's codebase can offer some insights |
|
Ok thanks |
|
I’ll also debug it from my end and see if I can figure it out. |
|
Jenkins ver 2.176.1 We upgraded to We can't edit global settings, security settings, security permissions on jobs or even edit workspace permissions. "No valid crumb was included in the request" errors all around [EDIT] Upgrading this bug to CRITICAL if you don't mind. Restarted Jenkins after "downgrading" to github-oauth 0.29 and we are still on github-oauth 0.32, we have no workaround for this bug. We may be able to force CSRF disabled in Jenkins v2.176.1 by setting java startup option Thanks guys, CSRF implementations are never fun.
|
|
We should move the discussion about https://issues.jenkins-ci.org/browse/JENKINS-57154 in that issue, or in a relevant issue here as this specific PR seems to be unrelated to the reported issue. |
|
Hello... I am the first reporter of the issue... I didn't notice this issue was fixed... https://issues.jenkins-ci.org/browse/SECURITY-443 Can I get a credit for the issue?? All of message from jenkins went to my spam folder...so, I didn't notice about that:( In this case, can i still list my name on security advisory? |
|
Reporter Name was added on original report. https://issues.jenkins-ci.org/browse/SECURITY-443 Sorry for the delay... |
|
@Testtest1234test I have no way of verifying this is Takashi Suzuki's GitHub account. If this is your account then please comment in https://issues.jenkins-ci.org/browse/SECURITY-443 verifying that this is Takashi Suzuki's GitHub account? cc @daniel-beck |
Use of state parameter [1] when using the authorization code grant
flow of oAuth2, mitigates CSRF attacks as described in "OAuth 2.0
Threat Model and Security Considerations" [2]
[1] https://tools.ietf.org/html/rfc6749#section-4.1.1
[2] https://tools.ietf.org/html/rfc6819#section-4.4.1.8