Ruby/doorkeeper/2.0.0.rc3

Doorkeeper is vulnerable to replay attacks

The Doorkeeper gem before 4.2.0 for Ruby might allow remote attackers to conduct replay attacks or revoke arbitrary tokens by leveraging failure to implement the OAuth 2.0 Token Revocation specification.

Moderate severity vulnerability that affects doorkeeper

Withdrawn, accidental duplicate publish.

The Doorkeeper gem before 4.2.0 for Ruby might allow remote attackers to conduct replay attacks or revoke arbitrary tokens by leveraging failure to implement the OAuth 2.0 Token Revocation specification.

Doorkeeper Improper Authentication vulnerability

OAuth RFC 8252 says https://www.rfc-editor.org/rfc/rfc8252#section-8.6

the authorization server SHOULD NOT process authorization requests automatically without user consent or interaction, except when the identity of the client can be assured. This includes the case where the user has previously approved an authorization request for a given client id

But Doorkeeper automatically processes authorization requests without user consent for public clients that have been previously approved. Public clients are inherently vulnerable to impersonation, their identity cannot be assured.

Issue https://github.com/doorkeeper-gem/doorkeeper/issues/1589

Fix https://github.com/doorkeeper-gem/doorkeeper/pull/1646

Cross-site request forgery (CSRF) vulnerability in doorkeeper 1.4.0 and earlier.

Cross-site request forgery (CSRF) vulnerability in doorkeeper 1.4.0 and earlier allows remote attackers to hijack the user's OAuth autorization code. This vulnerability has been assigned the CVE identifier CVE-2014-8144.

Doorkeeper's endpoints didn't have CSRF protection. Any HTML document on the Internet can then read a user's authorization code with arbitrary scope from any Doorkeeper-compatible Rails app you are logged in.

Doorkeeper gem does not revoke tokens & uses wrong auth/auth method

Doorkeeper failed to implement OAuth 2.0 Token Revocation (RFC 7009) in the following ways:

1. Public clients making valid, unauthenticated calls to revoke a token would not have their token revoked
2. Requests were not properly authenticating the client credentials but were, instead, looking at the access token in a second location
3. Because of 2, the requests were also not authorizing confidential clients' ability to revoke a given token. It should only revoke tokens that belong to it.

The security implication is: OAuth 2.0 clients who log out a user expect to have the corresponding access & refresh tokens revoked, preventing an attacker who may have already hijacked the session from continuing to impersonate the victim. Because of the bug described above, this is not the case. As far as OWASP is concerned, this counts as broken authentication design.

MITRE has assigned CVE-2016-6582 due to the security issues raised. An attacker, thanks to 1, can replay a hijacked session after a victim logs out/revokes their token. Additionally, thanks to 2 & 3, an attacker via a compromised confidential client could grief other clients by revoking their tokens (albeit this is an exceptionally narrow attack with little value).

Doorkeeper Improper Authentication vulnerability

OAuth RFC 8252 says https://www.rfc-editor.org/rfc/rfc8252#section-8.6

the authorization server SHOULD NOT process authorization requests automatically without user consent or interaction, except when the identity of the client can be assured. This includes the case where the user has previously approved an authorization request for a given client id

But Doorkeeper automatically processes authorization requests without user consent for public clients that have been previous approved. Public clients are inherently vulnerable to impersonation, their identity cannot be assured.

Issue https://github.com/doorkeeper-gem/doorkeeper/issues/1589

Fix https://github.com/doorkeeper-gem/doorkeeper/pull/1646

Doorkeeper Gem for Ruby stores sensitive information in production logs

Doorkeeper Gem for Ruby contains a flaw in lib/doorkeeper/engine.rb. The issue is due to the program storing sensitive information in production logs. This may allow a local attacker to gain access to sensitive information.