#oauth

### Summary By combining two vulnerabilities (an `Open Redirect` and `session token sent as URL query parameter`) in Strapi framework is its possible of an unauthenticated attacker to bypass authentication mechanisms and retrieve the 3rd party tokens. The attack requires user interaction (one click). ### Impact Unauthenticated attackers can leverage two vulnerabilities to obtain an 3rd party token and the bypass authentication of Strapi apps. ### Technical details #### Vulnerability 1: Open Redirect ##### Description Open redirection vulnerabilities arise when an application incorporates user-controllable data into the target of a redirection in an unsafe way. An attacker can construct a URL within the application that causes a redirection to an arbitrary external domain. In the specific context of Strapi, this vulnerability allows the SSO token to be stolen, allowing an attacker to authenticate himself within the application. ##### Remediation If possible, applications shoul...

### Impact JupyterHub < 5.0, when used with `GlobusOAuthenticator`, could be configured to allow all users from a particular institution only. The configuration for this would look like: ```python # Require users to be using the "foo.horse" identity provider, often an institution or university c.GlobusAuthenticator.identity_provider = "foo.horse" # Allow everyone who has that identity provider to log in c.GlobusAuthenticator.allow_all = True ``` This worked fine prior to JupyterHub 5.0, because `allow_all` *did not* take precedence over `identity_provider`. Since JupyterHub 5.0, `allow_all` *does* take precedence over `identity_provider`. On a hub with the same config, now **all** users will be allowed to login, regardless of `identity_provider`. `identity_provider` will basically be ignored. This is a [documented change](https://jupyterhub.readthedocs.io/en/stable/howto/upgrading-v5.html#authenticator-allow-all-and-allow-existing-users) in JupyterHub 5.0, but is likely to catch m...

A flaw was found in Keycloak in the OAuth 2.0 Pushed Authorization Requests (PAR). Client provided parameters were found to be included in plain text in the KC_RESTART cookie returned by the authorization server's HTTP response to a request_uri authorization request. This could lead to an information disclosure vulnerability.

Previous to @2ca5bb1c2f11537be8f94ca6867d8d69789e744a (release [0.1.2](https://github.com/zf-fr/zfr-oauth2-server-module/tree/0.1.2)), tokens weren't checked for validity/expiration. This potentially caused a security issue if expired tokens were not deleted after the expiration time was past, allowing anyone to still use invalidated authentication credentials.

Versions of sensiolabs/connect prior to 4.2.3 are affected by a Cross-Site Request Forgery (CSRF) vulnerability due to the absence of the state parameter in OAuth requests. The lack of proper state parameter handling exposes applications to CSRF attacks during the OAuth authentication flow.

laravel/socialite versions prior to 2.0.9 are found to have an insecure state generation mechanism, potentially exposing the OAuth authentication process to security risks. The issue has been addressed in version 2.0.9 by ensuring that the state is generated using a truly random approach, enhancing the security of the OAuth flow.

laravel/socialite versions prior to 2.0.10 are susceptible to a security vulnerability related to state guessing during OAuth authentication. This vulnerability could potentially lead to session hijacking, allowing attackers to compromise user sessions. The issue has been addressed and fixed in version 2.0.10.

An open redirection vulnerability has been identified in the friendsofsymfony/oauth2-php library, which could potentially expose users to unauthorized redirects during the OAuth authentication process. This vulnerability has been addressed by implementing an exact check for the domain and port, ensuring more secure redirection.

Today we are releasing Grafana 8.3.10, 8.4.10, 8.5.9 and 9.0.3. This patch release includes a HIGH severity security fix for an Oauth takeover vulnerability in Grafana. Release v.9.0.3, containing this security fix and other patches: - [Download Grafana 9.0.3](https://grafana.com/grafana/download/9.0.3) - [Release notes](https://grafana.com/docs/grafana/next/release-notes/release-notes-9-0-3/) Release v.8.5.9, containing this security fix and other fixes: - [Download Grafana 8.5.9](https://grafana.com/grafana/download/8.5.9) - [Release notes](https://grafana.com/docs/grafana/next/release-notes/release-notes-8-5-9/) Release v.8.4.10, containing this security fix and other fixes: - [Download Grafana 8.4.10](https://grafana.com/grafana/download/8.4.10) - [Release notes](https://grafana.com/docs/grafana/next/release-notes/release-notes-8-4-10/) Release v.8.3.10, containing this security fix and other fixes: - [Download Grafana 8.3.10](https://grafana.com/grafana/download/8.3.10) #...

When a data source has the Forward OAuth Identity feature enabled, sending a query to that datasource with an API token (and no other user credentials) will forward the OAuth Identity of the most recently logged-in user. This can allow API token holders to retrieve data for which they may not have intended access. ### Impact All of the following must be true: * The Grafana instance has data sources that support the Forward OAuth Identity feature. Graphite users, for example. * Some data sources are not susceptible, like Prometheus, as they do not have support for this feature. * The option being available is not sufficient enough to determine if the data source is susceptible. * The Grafana instance has a data source with the Forward OAuth Identity feature toggled on. * The Grafana instance has OAuth enabled. * The Grafana instance has usable API keys. ### Patches The following Grafana versions have been patched: * `v8.3.4` * `v7.5.13` ### Workarounds Administrators of G...