Prevent automatic OAuth grants for public clients #30790
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As detailed in Section 10.2 of RFC 6749 (The OAuth 2.0 Authorization Framework): > The authorization server SHOULD NOT process repeated authorization > requests automatically (without active resource owner interaction) > without authenticating the client [...]. Prior to this commit, Gitea would automatically issue authorization codes if the user previously granted access to the specific client. Especially with pre-registered OAuth clients using loopback interface redirects (like `git-credential-oauth`), this makes it possible for malicious applications with access to the same loopback interface and the ability to open a URL using the user's browser to impersonate public clients and get access to the user's account without manual interaction. This patch simply introduces an additional condition that prevents automatic grants if the application is not confidential.
GiteaBot
added
the
lgtm/need 2
pull-request-size
bot
added
the
size/XS
delvh
approved these changes
Apr 30, 2024
GiteaBot
added
lgtm/need 1
techknowlogick
added
backport/v1.21
wxiaoguang
approved these changes
May 2, 2024
GiteaBot
added
lgtm/done
wxiaoguang
added
the
reviewed/wait-merge
GiteaBot
pushed a commit
to GiteaBot/gitea
that referenced
this pull request
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 <[email protected]>
GiteaBot
removed
the
reviewed/wait-merge
GiteaBot
pushed a commit
to GiteaBot/gitea
that referenced
this pull request
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 <[email protected]>
silverwind
pushed a commit
that referenced
this pull request
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 <[email protected]> Co-authored-by: wxiaoguang <[email protected]>
silverwind
pushed a commit
that referenced
this pull request
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 <[email protected]> Co-authored-by: wxiaoguang <[email protected]>
zjjhot
added a commit
to zjjhot/gitea
that referenced
this pull request
May 3, 2024
* giteaofficial/main: (30 commits) Improve grep search (go-gitea#30843) Don't only list code-enabled repositories when using repository API (go-gitea#30817) Fix no edit history after editing issue's title and content (go-gitea#30814) Ignore useless error message "broken pipe" (go-gitea#30801) Fix JS error on pull request page (go-gitea#30838) Fix body margin shifting with modals, fix error on project column edit (go-gitea#30831) Improve repo button row layout (go-gitea#30668) refactor: merge ListActionTasks func to action.go file (go-gitea#30811) Prevent automatic OAuth grants for public clients (go-gitea#30790) Catch and handle unallowed file type errors in issue attachment API (go-gitea#30791) Fix incorrect message id for releaes email (go-gitea#30825) Add hover outline to heatmap squares (go-gitea#30828) Remove external API calls in `TestPassword` (go-gitea#30716) Upgrade chi-binding (go-gitea#30826) Improve context popup rendering (go-gitea#30824) Fix activity heat map padding & locale (go-gitea#30823) Fix issue card layout (go-gitea#30800) Fix branch selector UI (go-gitea#30803) Fix rounded border for segment followed by pagination (go-gitea#30809) Skip gzip for some well-known compressed file types (go-gitea#30796) ...
|
This change breaks oauth2 login for non-confidential clients: After at least one successful login, an application grant is created in the DB. As it isn't being used after this PR, an attempt starts every time to create a new grant, which fails because the DB already contains one, thus failing to authorize the OAuth client. Fix incoming.... |
|
Hmm .... my bad (approve without deep thinking). simple code should also have some tests .... 😭 |
|
-> #31015 |
|
Oh, I somehow missed this. Thank you for working on a fix! ❤️ |
lunny
added a commit
that referenced
this pull request
May 21, 2024
Do not try to create a new authorization grant when one exists already, thus preventing a DB-related authorization issue. Fix #30790 (comment) --------- Co-authored-by: Lunny Xiao <[email protected]>
GiteaBot
pushed a commit
to GiteaBot/gitea
that referenced
this pull request
May 21, 2024
Do not try to create a new authorization grant when one exists already, thus preventing a DB-related authorization issue. Fix go-gitea#30790 (comment) --------- Co-authored-by: Lunny Xiao <[email protected]>
GiteaBot
pushed a commit
to GiteaBot/gitea
that referenced
this pull request
May 21, 2024
Do not try to create a new authorization grant when one exists already, thus preventing a DB-related authorization issue. Fix go-gitea#30790 (comment) --------- Co-authored-by: Lunny Xiao <[email protected]>
lunny
added a commit
that referenced
this pull request
May 21, 2024
Backport #31015 by @denyskon Do not try to create a new authorization grant when one exists already, thus preventing a DB-related authorization issue. Fix #30790 (comment) Co-authored-by: Denys Konovalov <[email protected]> Co-authored-by: Lunny Xiao <[email protected]>
lunny
added a commit
that referenced
this pull request
May 21, 2024
Backport #31015 by @denyskon Do not try to create a new authorization grant when one exists already, thus preventing a DB-related authorization issue. Fix #30790 (comment) Co-authored-by: Denys Konovalov <[email protected]> Co-authored-by: Lunny Xiao <[email protected]>
DennisRasey
pushed a commit
to DennisRasey/forgejo
that referenced
this pull request
May 22, 2024
…30836)" This reverts commit 248a5b8. This commit introduces a regression descrdibed at go-gitea/gitea#30790 (comment) There is a commit to try and fix it, but it is similarly untested. Let's not accumulate regressions and wait until it is either field tested by humans in Gitea or a test is written. https://github.com/go-gitea/gitea/pull/31015/files
DennisRasey
pushed a commit
to DennisRasey/forgejo
that referenced
this pull request
May 28, 2024
Do not try to create a new authorization grant when one exists already, thus preventing a DB-related authorization issue. Fix go-gitea/gitea#30790 (comment) --------- Co-authored-by: Lunny Xiao <[email protected]> (cherry picked from commit 9c8c9ff6d10b35de8d2d7eae0fc2646ad9bbe94a)
DennisRasey
pushed a commit
to DennisRasey/forgejo
that referenced
this pull request
Jun 6, 2024
Do not try to create a new authorization grant when one exists already, thus preventing a DB-related authorization issue. Fix go-gitea/gitea#30790 (comment) --------- Co-authored-by: Lunny Xiao <[email protected]> (cherry picked from commit 9c8c9ff6d10b35de8d2d7eae0fc2646ad9bbe94a) (cherry picked from commit 07fe5a8)
DennisRasey
pushed a commit
to DennisRasey/forgejo
that referenced
this pull request
Jun 6, 2024
Do not try to create a new authorization grant when one exists already, thus preventing a DB-related authorization issue. Fix go-gitea/gitea#30790 (comment) --------- Co-authored-by: Lunny Xiao <[email protected]> (cherry picked from commit 9c8c9ff6d10b35de8d2d7eae0fc2646ad9bbe94a) (cherry picked from commit 07fe5a8)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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,
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/authorizeendpoint somehow (e.g., withxdg-openon Linux).Fixes #25061.