Ruby/doorkeeper/4.2.0

Doorkeeper subject to Incorrect Permission Assignment

Doorkeeper version 4.2.0 and later contains a Incorrect Access Control 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 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

Doorkeeper is vulnerable to stored XSS and code execution

Doorkeeper version 2.1.0 through 4.2.5 contains a Cross Site Scripting (XSS) vulnerability in web view's OAuth app form, user authorization prompt web view that can result in Stored XSS on the OAuth Client's name will cause users interacting with it will execute payload. This attack appear to be exploitable via The victim must be tricked to click an opaque link to the web view that runs the XSS payload. A malicious version virtually indistinguishable from a normal link. This vulnerability appears to have been fixed in 4.2.6, 4.3.0.

Doorkeeper gem has stored 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.

If 3rd parties are allowed to create OAuth clients in the app using Doorkeeper, upgrade to the patched versions immediately.

Additionally there is stored XSS in the nativeredirecturi form element.

DWF has assigned CVE-2018-1000088.

Doorkeeper gem does not revoke token for public clients

Any OAuth application that uses public/non-confidential authentication when interacting with Doorkeeper is unable to revoke its tokens when calling the revocation endpoint.

A bug in the token revocation API would cause it to attempt to authenticate the public OAuth client as if it was a confidential app. Because of this, the token is never revoked.

The impact of this is the access or refresh token is not revoked, leaking access to protected resources for the remainder of that token's lifetime.

If Doorkeeper is used to facilitate public OAuth apps and leverage token revocation functionality, upgrade to the patched versions immediately.

Credit to Roberto Ostinelli for discovery, Justin Bull for the fixes.

DWF has assigned CVE-2018-1000211.

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