Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Prevent automatic OAuth grants for public clients #30790

Merged
merged 3 commits into from
May 2, 2024
Merged

Prevent automatic OAuth grants for public clients #30790

merged 3 commits into from
May 2, 2024

Conversation

archer-321
Copy link
Contributor

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,

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.

@archer-321
Prevent automatic OAuth grants for public clients
e8bc0f8 
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 GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Apr 30, 2024
@pull-request-size pull-request-size bot added the size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. label Apr 30, 2024
@github-actions github-actions bot added the modifies/go Pull requests that update Go code label Apr 30, 2024
@GiteaBot GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Apr 30, 2024
@techknowlogick techknowlogick added backport/v1.21 This PR should be backported to Gitea 1.21 backport/v1.22 This PR should be backported to Gitea 1.22 type/bug labels May 1, 2024
@GiteaBot GiteaBot added lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels May 2, 2024
@wxiaoguang wxiaoguang enabled auto-merge (squash) May 2, 2024 16:08
@wxiaoguang wxiaoguang added the reviewed/wait-merge This pull request is part of the merge queue. It will be merged soon. label May 2, 2024
@wxiaoguang wxiaoguang merged commit 5c542ca into go-gitea:main May 2, 2024
26 checks passed
@GiteaBot GiteaBot added this to the 1.23.0 milestone May 2, 2024
GiteaBot pushed a commit to GiteaBot/gitea that referenced this pull request May 2, 2024
@archer-321 @wxiaoguang @GiteaBot
Prevent automatic OAuth grants for public clients (go-gitea#30790)
7e2d614 
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 GiteaBot mentioned this pull request May 2, 2024
Merged
@GiteaBot GiteaBot removed the reviewed/wait-merge This pull request is part of the merge queue. It will be merged soon. label May 2, 2024
GiteaBot pushed a commit to GiteaBot/gitea that referenced this pull request May 2, 2024
@archer-321 @wxiaoguang @GiteaBot
Prevent automatic OAuth grants for public clients (go-gitea#30790)
b3f428d 
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 GiteaBot mentioned this pull request May 2, 2024
Merged
silverwind pushed a commit that referenced this pull request May 2, 2024
@GiteaBot @archer-321 @wxiaoguang
Prevent automatic OAuth grants for public clients (#30790) (#30835)
1389fa8 
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 pull request May 2, 2024
@GiteaBot @archer-321 @wxiaoguang
Prevent automatic OAuth grants for public clients (#30790) (#30836)
6d83f5e 
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>
zjjhot added a commit to zjjhot/gitea that referenced this pull request May 3, 2024
@zjjhot
Merge remote-tracking branch 'giteaofficial/main'
6e5359c 
* 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)
  ...
@yardenshoham yardenshoham added the backport/done All backports for this PR have been created label May 5, 2024
@denyskon
Copy link
Member

This change breaks oauth2 login for non-confidential clients:
grafik

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

@wxiaoguang
Copy link
Contributor

Hmm .... my bad (approve without deep thinking). simple code should also have some tests .... 😭

@denyskon denyskon mentioned this pull request May 18, 2024
Merged
@denyskon
Copy link
Member

-> #31015

@archer-321
Copy link
Contributor Author

Oh, I somehow missed this. Thank you for working on a fix! ❤️

lunny added a commit that referenced this pull request May 21, 2024
@denyskon @lunny
use existing oauth grant for public client (#31015)
9c8c9ff 
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 <xiaolunwen@gmail.com>
GiteaBot pushed a commit to GiteaBot/gitea that referenced this pull request May 21, 2024
@denyskon @lunny @GiteaBot
use existing oauth grant for public client (go-gitea#31015)
49117e8 
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 <xiaolunwen@gmail.com>
@GiteaBot GiteaBot mentioned this pull request May 21, 2024
Merged
GiteaBot pushed a commit to GiteaBot/gitea that referenced this pull request May 21, 2024
@denyskon @lunny @GiteaBot
use existing oauth grant for public client (go-gitea#31015)
8e6c1e6 
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 <xiaolunwen@gmail.com>
@GiteaBot GiteaBot mentioned this pull request May 21, 2024
Merged
lunny added a commit that referenced this pull request May 21, 2024
@GiteaBot @denyskon @lunny
use existing oauth grant for public client (#31015) (#31042)
e3390e2 
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 <kontakt@denyskon.de>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
lunny added a commit that referenced this pull request May 21, 2024
@GiteaBot @denyskon @lunny
use existing oauth grant for public client (#31015) (#31041)
ec4fa23 
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 <kontakt@denyskon.de>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
DennisRasey pushed a commit to DennisRasey/forgejo that referenced this pull request May 22, 2024
@earl-warren
Revert "Prevent automatic OAuth grants for public clients (#30790) (#…
6771312 
…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
@denyskon @earl-warren
use existing oauth grant for public client (#31015)
07fe5a8 
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 <xiaolunwen@gmail.com>
(cherry picked from commit 9c8c9ff6d10b35de8d2d7eae0fc2646ad9bbe94a)
DennisRasey pushed a commit to DennisRasey/forgejo that referenced this pull request Jun 6, 2024
@denyskon @earl-warren
use existing oauth grant for public client (#31015)
0c770d5 
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 <xiaolunwen@gmail.com>
(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
@denyskon @earl-warren
use existing oauth grant for public client (#31015)
97a0d90 
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 <xiaolunwen@gmail.com>
(cherry picked from commit 9c8c9ff6d10b35de8d2d7eae0fc2646ad9bbe94a)
(cherry picked from commit 07fe5a8)
@denyskon denyskon mentioned this pull request Jun 21, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@wxiaoguang wxiaoguang wxiaoguang approved these changes

@delvh delvh delvh approved these changes

Assignees
No one assigned
Labels
backport/done All backports for this PR have been created backport/v1.21 This PR should be backported to Gitea 1.21 backport/v1.22 This PR should be backported to Gitea 1.22 lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. modifies/go Pull requests that update Go code size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. type/bug
Projects
None yet
Milestone
1.23.0
Development

Successfully merging this pull request may close these issues.

OAuth should require user consent for every public client authorization
7 participants
@archer-321 @denyskon @wxiaoguang @delvh @techknowlogick @yardenshoham @GiteaBot