require POSTs during sign-in (CVE-2015-9284) #1815
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
CVE-2015-9284 was a bit of a doozy. Essentially, a service provider (oauth "client") ought to accept authentication initiations by POST with a token from itself to protect against cross-site forgeries. Details so far on omniauth/omniauth issue 809. This change does the following: 1. upgrades omniauth and adds a new omniauth-rails_csrf_protection gem The new gem twiddles with OmniAuth's middleware to require POSTing to the auth endpoints it adds to the app and wires up checking for a valid token during the middleware processing. The omniauth gem itself is framework agnostic, so the current solution is a new Rails-flavored library. 2. updates all Supermarket's links to OAuth2 providers to use POST Pretty easy update to link_to "buttons" in the views. 3. display a page on /sign-in with a login button Because the endpoint that actually signs a user is /auth/chef-oauth2, a route and sessions controller action was made to redirect there for a friendlier URL path. But you can't redirect POSTs, yo. So, now that we're POSTing, if someone lands on /sign-in some how, display a button for logging in via Chef Server. This can be the place where more buttons are added if we ever decide to implement multi-auth. 4. redirects to /sign-in changed from 301 to 302 Browsers take permanent redirects at their word and seem to never forget them. Nothing is really permanent on the internet. Signed-off-by: Robb Kidd <rkidd@chef.io>
Signed-off-by: Robb Kidd <rkidd@chef.io>
robbkidd
force-pushed
the
robb/auth-update
branch
from
b685095
to
3cb36b8
Compare
Signed-off-by: Robb Kidd <rkidd@chef.io>
marcparadise
approved these changes
Jun 17, 2019
marcparadise
approved these changes
Jun 17, 2019
marcparadise
approved these changes
Jun 17, 2019
robbkidd
added
Aspect: Security
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
CVE-2015-9284 was a bit of a doozy. Essentially, a service provider (oauth "client") ought to accept authentication initiations by POST with a token from itself to protect against cross-site forgeries. Details so far on omniauth/omniauth issue 809.
This change does the following:
The new gem twiddles with OmniAuth's middleware to require POSTing to
the auth endpoints it adds to the app and wires up checking for a valid
token during the middleware processing. The omniauth gem itself is
framework agnostic, so the current solution is a new Rails-flavored
library.
Pretty easy update to link_to "buttons" in the views.
Because the endpoint that actually signs a user is /auth/chef-oauth2, a
route and sessions controller action was made to redirect there for a
friendlier URL path. But you can't redirect POSTs, yo. So, now that
we're POSTing, if someone lands on /sign-in some how, display a button
for logging in via Chef Server. This can be the place where more buttons
are added if we ever decide to implement multi-auth.
Browsers take permanent redirects at their word and seem to never forget
them. Nothing is really permanent on the internet.
Types of changes
New feature (non-breaking change which adds functionality)Breaking change (fix or feature that would cause existing functionality to change)Chore (non-breaking change that does not add functionality or fix an issue)Checklist: