Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge from 0.11.x #824

Merged
merged 12 commits into from
Apr 19, 2018
Merged

Merge from 0.11.x #824

merged 12 commits into from
Apr 19, 2018

Conversation

aeneasr
Copy link
Member

@aeneasr aeneasr commented Apr 19, 2018

No description provided.

arekkas and others added 12 commits February 7, 2018 18:55
This patch resolves a vulnerability in the consent flow. This vulnerability
affects versions 0.10.0 ~ 0.11.5 only. Versions < 0.10.0 are not affected.

The vulnerability can be exploited as follows:

1. Malice initiates an OAuth 2.0 Authorization Code Flow:
  https://hydra/oauth2/auth?client=...
2. Hydra redirects malice to the consent app and appends consent
  id "example-id": https://consent-app/?consent=example-id
3. Malice convinces Bob to open url https://consent-app/?consent=example-id
  and authorize the access request.
4. The consent app would redirect Bob back to
  `https://hydra/oauth2/auth?client=...&consent=example-id`. However,
  through some means, Malice is able to prevent redirection of Bob's
  user agent.
5. Malice accesses the original auth code url and appends the consent id:
  `https://hydra/oauth2/auth?client=...&consent=example-id`
6. As the consent request is granted but not claimed, and because Malice's
  user agent contains the valid CSRF token, Malice receives an authorize
  code that is meant to be issued to Bob.
7. Malice can now act on Bob's behalf.

For this attack to work, the following preconditions must be met:

1. Malice must be able to convince Bob to access the forged consent url.
2. Malice must be able to convince Bob to grant the forged consent request.
3. Malice must be able to prevent the consent app's redirect after
  successful consent request acceptance.
4. Malice must be able to perform this attack within the expiry (10 minutes)
  of the consent request.

For these reasons, an exploit for this vulnerability is not likely,
but possible.

This patch closes the described vulnerability by requiring a
`consent_csrf` value additional to the `consent` value in the query
parameters of the authorization url. Without that value, the authorization
code flow will not be successful. The `consent_csrf` is transmitted out-of-band
to the consent app and not accessible to Malice. Let's revisit the example
from above:

1. Malice initiates an OAuth 2.0 Authorization Code Flow:
  https://hydra/oauth2/auth?client=...
  - Hydra creates the consent request id and an additional CSRF token
    which is stored in the database and the encrypted cookie. Malice
    is not able to see the CSRF token.
2. Hydra redirects malice to the consent app and appends consent
  id "example-id": https://consent-app/?consent=example-id
3. Malice convinces Bob to open url https://consent-app/?consent=example-id
  and authorize the access request.
4. The consent app would redirect Bob back to
  `https://hydra/oauth2/auth?client=...&consent=example-id&consent_csrf=csrf_token`.
  The redirection URL is only accessible to the consent app and Bob's user agent.
  However, through some means, Malice is able to prevent redirection of Bob's
  user agent.
5. Malices does not know the value for `consent_csrf`, accessing
  `https://hydra/oauth2/auth?client=...&consent=example-id` without
  setting `consent_csrf` causes the request to fail and the consent to
  be revoked.

This patch does not introduce breaking changes. Upgrading to the version
which contains this patch does not require any code changes or deployment
changes.
Previously, it was impossible to refresh OpenID Connect ID Tokens. This is now possible as the factory has been added to the oauth2 factory in the host process.

Closes #794
Add docs/sdk/php.md

Signed-off-by: Philip Nicolcev <[email protected]>
…ase in cleartext (#820)

This release resolves a security issue (reported by [platform.sh](https://www.platform.sh)) related to the fosite storage implementation in this project. Fosite used to pass all of the request body from both authorize and token endpoints to the storage adapters. As some of these values are needed in consecutive requests, the storage adapter of this project chose to drop all of the key/value pairs to the database in plaintext.

This implied that confidential parameters, such as the `client_secret` which can be passed in the request body since fosite version 0.15.0, were stored as key/value pairs in plaintext in the database. While most client secrets are generated programmatically (as opposed to set by the user) and most popular OAuth2 providers choose to store the secret in plaintext for later retrieval, we see it as a considerable security issue nonetheless.

The issue has been resolved by sanitizing the request body and only including those values truly required by their respective handlers. This also implies that typos (eg `client_secet`) won't "leak" to the database.

There are no special upgrade paths required for this version.

This issue does not apply to you if you do not use an SQL backend. If you do upgrade to this version, you need to run `hydra migrate sql path://to.your/database`.

If your users use POST body client authentication, it might
be a good move to remove old data. There are multiple ways of doing that. **Back up your data before you do this**:

1. **Radical solution:** Drop all rows from tables `hydra_oauth2_refresh`, `hydra_oauth2_access`, `hydra_oauth2_oidc`,
`hydra_oauth2_code`. This implies that all your users have to re-authorize.
2. **Sensitive solution:** Replace all values in column `form_data` in tables `hydra_oauth2_refresh`, `hydra_oauth2_access` with
an empty string. This will keep all authorization sessions alive. Tables `hydra_oauth2_oidc` and `hydra_oauth2_code`
do not contain sensitive information, unless your users accidentally sent the client_secret to the `/oauth2/auth` endpoint.

We would like to thank [platform.sh](https://www.platform.sh) for sponsoring the development of a patch that resolves this issue.
This issue solves a broken update with godep and properly includes
the 0.17.0 fosite patch.
# Conflicts:
#	Gopkg.lock
#	Gopkg.toml
#	UPGRADE.md
#	cmd/server/handler_oauth2_factory.go
#	oauth2/consent_strategy.go
#	oauth2/consent_strategy_test.go
#	oauth2/fosite_store_memory.go
#	oauth2/fosite_store_test.go
#	oauth2/fosite_store_test_helpers.go
#	sdk/php/.swagger-codegen/VERSION
#	sdk/php/swagger/README.md
#	sdk/php/swagger/autoload.php
#	sdk/php/swagger/docs/Api/HealthApi.md
#	sdk/php/swagger/docs/Api/JsonWebKeyApi.md
#	sdk/php/swagger/docs/Api/OAuth2Api.md
#	sdk/php/swagger/lib/Api/HealthApi.php
#	sdk/php/swagger/lib/Api/JsonWebKeyApi.php
#	sdk/php/swagger/lib/Api/OAuth2Api.php
#	sdk/php/swagger/lib/Api/PolicyApi.php
#	sdk/php/swagger/lib/Api/WardenApi.php
#	sdk/php/swagger/lib/ApiClient.php
#	sdk/php/swagger/lib/ApiException.php
#	sdk/php/swagger/lib/Configuration.php
#	sdk/php/swagger/lib/Model/ConsentRequest.php
#	sdk/php/swagger/lib/Model/ConsentRequestAcceptance.php
#	sdk/php/swagger/lib/Model/ConsentRequestManager.php
#	sdk/php/swagger/lib/Model/ConsentRequestRejection.php
#	sdk/php/swagger/lib/Model/Context.php
#	sdk/php/swagger/lib/Model/Firewall.php
#	sdk/php/swagger/lib/Model/Group.php
#	sdk/php/swagger/lib/Model/GroupMembers.php
#	sdk/php/swagger/lib/Model/Handler.php
#	sdk/php/swagger/lib/Model/InlineResponse200.php
#	sdk/php/swagger/lib/Model/InlineResponse401.php
#	sdk/php/swagger/lib/Model/JoseWebKeySetRequest.php
#	sdk/php/swagger/lib/Model/JsonWebKey.php
#	sdk/php/swagger/lib/Model/JsonWebKeySet.php
#	sdk/php/swagger/lib/Model/JsonWebKeySetGeneratorRequest.php
#	sdk/php/swagger/lib/Model/KeyGenerator.php
#	sdk/php/swagger/lib/Model/Manager.php
#	sdk/php/swagger/lib/Model/OAuth2Client.php
#	sdk/php/swagger/lib/Model/OAuth2ConsentRequest.php
#	sdk/php/swagger/lib/Model/OAuth2TokenIntrospection.php
#	sdk/php/swagger/lib/Model/Policy.php
#	sdk/php/swagger/lib/Model/PolicyConditions.php
#	sdk/php/swagger/lib/Model/RawMessage.php
#	sdk/php/swagger/lib/Model/SwaggerAcceptConsentRequest.php
#	sdk/php/swagger/lib/Model/SwaggerCreatePolicyParameters.php
#	sdk/php/swagger/lib/Model/SwaggerDoesWardenAllowAccessRequestParameters.php
#	sdk/php/swagger/lib/Model/SwaggerDoesWardenAllowTokenAccessRequestParameters.php
#	sdk/php/swagger/lib/Model/SwaggerGetPolicyParameters.php
#	sdk/php/swagger/lib/Model/SwaggerJsonWebKeyQuery.php
#	sdk/php/swagger/lib/Model/SwaggerJwkCreateSet.php
#	sdk/php/swagger/lib/Model/SwaggerJwkSetQuery.php
#	sdk/php/swagger/lib/Model/SwaggerJwkUpdateSet.php
#	sdk/php/swagger/lib/Model/SwaggerJwkUpdateSetKey.php
#	sdk/php/swagger/lib/Model/SwaggerListPolicyParameters.php
#	sdk/php/swagger/lib/Model/SwaggerListPolicyResponse.php
#	sdk/php/swagger/lib/Model/SwaggerOAuthConsentRequestPayload.php
#	sdk/php/swagger/lib/Model/SwaggerOAuthIntrospectionRequest.php
#	sdk/php/swagger/lib/Model/SwaggerRejectConsentRequest.php
#	sdk/php/swagger/lib/Model/SwaggerRevokeOAuth2TokenParameters.php
#	sdk/php/swagger/lib/Model/SwaggerUpdatePolicyParameters.php
#	sdk/php/swagger/lib/Model/TokenAllowedRequest.php
#	sdk/php/swagger/lib/Model/WardenAccessRequest.php
#	sdk/php/swagger/lib/Model/WardenAccessRequestResponse.php
#	sdk/php/swagger/lib/Model/WardenTokenAccessRequest.php
#	sdk/php/swagger/lib/Model/WardenTokenAccessRequestResponse.php
#	sdk/php/swagger/lib/Model/WellKnown.php
#	sdk/php/swagger/lib/Model/Writer.php
#	sdk/php/swagger/lib/ObjectSerializer.php
@aeneasr aeneasr merged commit 4b86ef5 into 1.0.x Apr 19, 2018
@aeneasr aeneasr deleted the 1.0.x-2 branch April 19, 2018 16:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants