Package Instance

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

Incorrect Permission Assignment for Critical Resource
Doorkeeper contains a vulnerability in Token revocation API's authorized method that can result in Access tokens are not revoked for public OAuth apps, leaking access until expiry.

Doorkeeper application secret information disclosure vulnerability
Information disclosure vulnerability. Allows an attacker to see all
Doorkeeper::Application model attribute values (including secrets) after
authorizing an application to their user.

An application is vulnerable if the authorized applications controller is
enabled (GET /oauth/authorized_applications.json).

Recommended additional hardening for >= 5.1 is to enable application secrets
hashing. This would render the exposed secret useless.

XSS on authorization consent view
Stored XSS on the OAuth Client's name will cause users being prompted for consent via the `implicit` grant type to execute the XSS payload. The XSS attack could gain access to the user's active session, resulting in account compromise. Any user is susceptible if they click the authorization link for the malicious OAuth client. Because of how the links work, a user cannot tell if a link is malicious or not without first visiting the page with the XSS payload. In addition, there is stored XSS in the `native_redirect_uri` form element.

Broken token revocation, wrong auth/auth method
Doorkeeper failed to implement OAuth Token Revocation (RFC ) in the following ways: Public clients making valid, unauthenticated calls to revoke a token would not have their token revoked Requests were not properly authenticating the *client credentials* but were, instead, looking at the access token in a second location 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 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).