|
Oauth2 Proxy Project : Security Vulnerabilities (CVSS score >= 4)
# |
CVE ID
|
CWE ID
|
# of Exploits
|
Vulnerability Type(s)
|
Publish Date
|
Update Date
|
Score
|
Gained Access Level
|
Access
|
Complexity
|
Authentication
|
Conf.
|
Integ.
|
Avail.
|
1 |
CVE-2021-21411 |
863 |
|
|
2021-03-26 |
2021-04-06 |
5.5 |
None |
Remote |
Low |
??? |
Partial |
Partial |
None |
OAuth2-Proxy is an open source reverse proxy that provides authentication with Google, Github or other providers. The `--gitlab-group` flag for group-based authorization in the GitLab provider stopped working in the v7.0.0 release. Regardless of the flag settings, authorization wasn't restricted. Additionally, any authenticated users had whichever groups were set in `--gitlab-group` added to the new `X-Forwarded-Groups` header to the upstream application. While adding GitLab project based authorization support in #630, a bug was introduced where the user session's groups field was populated with the `--gitlab-group` config entries instead of pulling the individual user's group membership from the GitLab Userinfo endpoint. When the session groups where compared against the allowed groups for authorization, they matched improperly (since both lists were populated with the same data) so authorization was allowed. This impacts GitLab Provider users who relies on group membership for authorization restrictions. Any authenticated users in your GitLab environment can access your applications regardless of `--gitlab-group` membership restrictions. This is patched in v7.1.0. There is no workaround for the Group membership bug. But `--gitlab-project` can be set to use Project membership as the authorization checks instead of groups; it is not broken. |
2 |
CVE-2021-21291 |
601 |
|
|
2021-02-02 |
2021-02-08 |
5.8 |
None |
Remote |
Medium |
Not required |
Partial |
Partial |
None |
OAuth2 Proxy is an open-source reverse proxy and static file server that provides authentication using Providers (Google, GitHub, and others) to validate accounts by email, domain or group. In OAuth2 Proxy before version 7.0.0, for users that use the whitelist domain feature, a domain that ended in a similar way to the intended domain could have been allowed as a redirect. For example, if a whitelist domain was configured for ".example.com", the intention is that subdomains of example.com are allowed. Instead, "example.com" and "badexample.com" could also match. This is fixed in version 7.0.0 onwards. As a workaround, one can disable the whitelist domain feature and run separate OAuth2 Proxy instances for each subdomain. |
3 |
CVE-2020-11053 |
601 |
|
Bypass |
2020-05-07 |
2020-05-13 |
5.8 |
None |
Remote |
Medium |
Not required |
Partial |
Partial |
None |
In OAuth2 Proxy before 5.1.1, there is an open redirect vulnerability. Users can provide a redirect address for the proxy to send the authenticated user to at the end of the authentication flow. This is expected to be the original URL that the user was trying to access. This redirect URL is checked within the proxy and validated before redirecting the user to prevent malicious actors providing redirects to potentially harmful sites. However, by crafting a redirect URL with HTML encoded whitespace characters the validation could be bypassed and allow a redirect to any URL provided. This has been patched in 5.1.1. |
4 |
CVE-2020-5233 |
601 |
|
|
2020-01-30 |
2020-04-09 |
5.8 |
None |
Remote |
Medium |
Not required |
Partial |
Partial |
None |
OAuth2 Proxy before 5.0 has an open redirect vulnerability. Authentication tokens could be silently harvested by an attacker. This has been patched in version 5.0. |
5 |
CVE-2020-4037 |
601 |
|
|
2020-06-29 |
2020-07-07 |
5.8 |
None |
Remote |
Medium |
Not required |
Partial |
Partial |
None |
In OAuth2 Proxy from version 5.1.1 and less than version 6.0.0, users can provide a redirect address for the proxy to send the authenticated user to at the end of the authentication flow. This is expected to be the original URL that the user was trying to access. This redirect URL is checked within the proxy and validated before redirecting the user to prevent malicious actors providing redirects to potentially harmful sites. This has been fixed in version 6.0.0. |
6 |
CVE-2017-1000070 |
601 |
|
|
2017-07-17 |
2017-07-20 |
5.8 |
None |
Remote |
Medium |
Not required |
Partial |
Partial |
None |
The Bitly oauth2_proxy in version 2.1 and earlier was affected by an open redirect vulnerability during the start and termination of the 2-legged OAuth flow. This issue was caused by improper input validation and a violation of RFC-6819 |
7 |
CVE-2017-1000069 |
352 |
|
CSRF |
2017-07-17 |
2017-07-20 |
6.8 |
None |
Remote |
Medium |
Not required |
Partial |
Partial |
Partial |
CSRF in Bitly oauth2_proxy 2.1 during authentication flow |
Total number of vulnerabilities : 7
Page :
1
(This Page)
|
|
CVE is a registred trademark of the MITRE Corporation and the authoritative source of CVE content is
MITRE's CVE web site.
CWE is a registred trademark of the MITRE Corporation and the authoritative source of CWE content is
MITRE's CWE web site.
OVAL is a registered trademark of The MITRE Corporation and the authoritative source of OVAL content is
MITRE's OVAL web site.
Use of this information constitutes acceptance for use in an AS IS condition.
There are NO warranties, implied or otherwise, with regard to this information or its use.
Any use of this information is at the user's risk.
It is the responsibility of user to evaluate the accuracy, completeness or usefulness of any information, opinion, advice or other content.
EACH USER WILL BE SOLELY RESPONSIBLE FOR ANY consequences of his or her direct or indirect use of this web site.
ALL WARRANTIES OF ANY KIND ARE EXPRESSLY DISCLAIMED. This site will NOT BE LIABLE FOR ANY DIRECT,
INDIRECT or any other kind of loss.