-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
OAuth should require user consent for every public client authorization #25061
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
topic/security
Something leaks user information or is otherwise vulnerable. Should be fixed!
Comments
This is equivalent to https://www.cve.org/CVERecord?id=CVE-2023-34246 in another OAuth implementation |
I think this should be easy to resolve... I'll maybe open PR soon |
wxiaoguang
added a commit
that referenced
this issue
May 2, 2024
This commit forces the resource owner (user) to always approve OAuth 2.0 authorization requests if the client is public (e.g. native applications). As detailed in [RFC 6749 Section 10.2](https://www.rfc-editor.org/rfc/rfc6749.html#section-10.2), > The authorization server SHOULD NOT process repeated authorization requests automatically (without active resource owner interaction) without authenticating the client or relying on other measures to ensure that the repeated request comes from the original client and not an impersonator. With the implementation prior to this patch, attackers with access to the redirect URI (e.g., the loopback interface for `git-credential-oauth`) can get access to the user account without any user interaction if they can redirect the user to the `/login/oauth/authorize` endpoint somehow (e.g., with `xdg-open` on Linux). Fixes #25061. Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
GiteaBot
pushed a commit
to GiteaBot/gitea
that referenced
this issue
May 2, 2024
This commit forces the resource owner (user) to always approve OAuth 2.0 authorization requests if the client is public (e.g. native applications). As detailed in [RFC 6749 Section 10.2](https://www.rfc-editor.org/rfc/rfc6749.html#section-10.2), > The authorization server SHOULD NOT process repeated authorization requests automatically (without active resource owner interaction) without authenticating the client or relying on other measures to ensure that the repeated request comes from the original client and not an impersonator. With the implementation prior to this patch, attackers with access to the redirect URI (e.g., the loopback interface for `git-credential-oauth`) can get access to the user account without any user interaction if they can redirect the user to the `/login/oauth/authorize` endpoint somehow (e.g., with `xdg-open` on Linux). Fixes go-gitea#25061. Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
GiteaBot
pushed a commit
to GiteaBot/gitea
that referenced
this issue
May 2, 2024
This commit forces the resource owner (user) to always approve OAuth 2.0 authorization requests if the client is public (e.g. native applications). As detailed in [RFC 6749 Section 10.2](https://www.rfc-editor.org/rfc/rfc6749.html#section-10.2), > The authorization server SHOULD NOT process repeated authorization requests automatically (without active resource owner interaction) without authenticating the client or relying on other measures to ensure that the repeated request comes from the original client and not an impersonator. With the implementation prior to this patch, attackers with access to the redirect URI (e.g., the loopback interface for `git-credential-oauth`) can get access to the user account without any user interaction if they can redirect the user to the `/login/oauth/authorize` endpoint somehow (e.g., with `xdg-open` on Linux). Fixes go-gitea#25061. Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
silverwind
pushed a commit
that referenced
this issue
May 2, 2024
Backport #30790 by archer-321 This commit forces the resource owner (user) to always approve OAuth 2.0 authorization requests if the client is public (e.g. native applications). As detailed in [RFC 6749 Section 10.2](https://www.rfc-editor.org/rfc/rfc6749.html#section-10.2), > The authorization server SHOULD NOT process repeated authorization requests automatically (without active resource owner interaction) without authenticating the client or relying on other measures to ensure that the repeated request comes from the original client and not an impersonator. With the implementation prior to this patch, attackers with access to the redirect URI (e.g., the loopback interface for `git-credential-oauth`) can get access to the user account without any user interaction if they can redirect the user to the `/login/oauth/authorize` endpoint somehow (e.g., with `xdg-open` on Linux). Fixes #25061. Co-authored-by: Archer <archer@beezig.eu> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
silverwind
pushed a commit
that referenced
this issue
May 2, 2024
Backport #30790 by archer-321 This commit forces the resource owner (user) to always approve OAuth 2.0 authorization requests if the client is public (e.g. native applications). As detailed in [RFC 6749 Section 10.2](https://www.rfc-editor.org/rfc/rfc6749.html#section-10.2), > The authorization server SHOULD NOT process repeated authorization requests automatically (without active resource owner interaction) without authenticating the client or relying on other measures to ensure that the repeated request comes from the original client and not an impersonator. With the implementation prior to this patch, attackers with access to the redirect URI (e.g., the loopback interface for `git-credential-oauth`) can get access to the user account without any user interaction if they can redirect the user to the `/login/oauth/authorize` endpoint somehow (e.g., with `xdg-open` on Linux). Fixes #25061. Co-authored-by: Archer <archer@beezig.eu> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
project-mirrors-bot-tu bot
pushed a commit
to project-mirrors/forgejo-as-gitea-fork
that referenced
this issue
Jan 23, 2025
…o-gitea#30836) Backport go-gitea#30790 by archer-321 This commit forces the resource owner (user) to always approve OAuth 2.0 authorization requests if the client is public (e.g. native applications). As detailed in [RFC 6749 Section 10.2](https://www.rfc-editor.org/rfc/rfc6749.html#section-10.2), > The authorization server SHOULD NOT process repeated authorization requests automatically (without active resource owner interaction) without authenticating the client or relying on other measures to ensure that the repeated request comes from the original client and not an impersonator. With the implementation prior to this patch, attackers with access to the redirect URI (e.g., the loopback interface for `git-credential-oauth`) can get access to the user account without any user interaction if they can redirect the user to the `/login/oauth/authorize` endpoint somehow (e.g., with `xdg-open` on Linux). Fixes go-gitea#25061. Co-authored-by: Archer <archer@beezig.eu> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com> (cherry picked from commit 6d83f5e)
project-mirrors-bot-tu bot
pushed a commit
to project-mirrors/forgejo-as-gitea-fork
that referenced
this issue
Jan 23, 2025
This commit forces the resource owner (user) to always approve OAuth 2.0 authorization requests if the client is public (e.g. native applications). As detailed in [RFC 6749 Section 10.2](https://www.rfc-editor.org/rfc/rfc6749.html#section-10.2), > The authorization server SHOULD NOT process repeated authorization requests automatically (without active resource owner interaction) without authenticating the client or relying on other measures to ensure that the repeated request comes from the original client and not an impersonator. With the implementation prior to this patch, attackers with access to the redirect URI (e.g., the loopback interface for `git-credential-oauth`) can get access to the user account without any user interaction if they can redirect the user to the `/login/oauth/authorize` endpoint somehow (e.g., with `xdg-open` on Linux). Fixes go-gitea#25061. Co-authored-by: wxiaoguang <wxiaoguang@gmail.com> (cherry picked from commit 5c542ca) (cherry picked from commit 1b088fa)
project-mirrors-bot-tu bot
pushed a commit
to project-mirrors/forgejo-as-gitea-fork
that referenced
this issue
Jan 23, 2025
This commit forces the resource owner (user) to always approve OAuth 2.0 authorization requests if the client is public (e.g. native applications). As detailed in [RFC 6749 Section 10.2](https://www.rfc-editor.org/rfc/rfc6749.html#section-10.2), > The authorization server SHOULD NOT process repeated authorization requests automatically (without active resource owner interaction) without authenticating the client or relying on other measures to ensure that the repeated request comes from the original client and not an impersonator. With the implementation prior to this patch, attackers with access to the redirect URI (e.g., the loopback interface for `git-credential-oauth`) can get access to the user account without any user interaction if they can redirect the user to the `/login/oauth/authorize` endpoint somehow (e.g., with `xdg-open` on Linux). Fixes go-gitea#25061. Co-authored-by: wxiaoguang <wxiaoguang@gmail.com> (cherry picked from commit 5c542ca) (cherry picked from commit 1b088fa)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
Following OAuth spec https://datatracker.ietf.org/doc/html/rfc8252#section-8.6
However Gitea's AuthorizeOAuth only asks for consent on the first authorization. This behaviour is the same for both public clients and confidential clients. Correct would be to ask for consent on the first authorization for confidential clients, and every authorisation for public clients.
gitea/routers/web/auth/oauth.go
Lines 465 to 494 in af3deb0
Gitea Version
HEAD
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
reading code
Database
None
The text was updated successfully, but these errors were encountered: