#oauth

Bitbucket Branch Source Plugin 886.v44cf5e4ecec5 and earlier prints the Bitbucket OAuth access token as part of the Bitbucket URL in the build log in some cases. Bitbucket Branch Source Plugin 887.va_d359b_3d2d8d does not include the Bitbucket OAuth access token as part of the Bitbucket URL in the build log.

**In order to be exploited you must have both OAuth2 and Password auth methods enabled.** A possible attack scenario could be: - a malicious actor register with the targeted user's email (it is unverified) - at some later point in time the targeted user stumble on your app and decides to sign-up with OAuth2 (_this step could be also initiated by the attacker by sending an invite email to the targeted user_) - on successful OAuth2 auth we search for an existing PocketBase user matching with the OAuth2 user's email and associate them - because we haven't changed the password of the existing PocketBase user during the linking, the malicious actor has access to the targeted user account and will be able to login with the initially created email/password To prevent this for happening we now reset the password for this specific case if the previously created user wasn't verified (an exception to this is if the linking is explicit/manual, aka. when you send `Authorization:TOKEN` with the OA...

### Impact A MFA bypass in the Firefly III OAuth flow may allow malicious users to bypass the MFA-check. This allows malicious users to use password spraying to gain access to your Firefly III data using passwords stolen from other sources. As OAuth applications are easily enumerable using an incrementing id, an attacker could try sign an OAuth application up to a users profile quite easily if they have created one. The attacker would also need to know the victims username and password. ### Patches Problem has been patched in Firefly III v6.1.17 and up. ### Workarounds - Use a unique password for your Firefly III instance, - Store your password securely, i.e. in a password manager or in your head. ### References - https://owasp.org/www-community/attacks/Password_Spraying_Attack - https://www.menlosecurity.com/what-is/highly-evasive-adaptive-threats-heat/mfa-bypass

### 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.