-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Deprecate query string auth tokens #28390
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some minor suggestions
This PR aims to solve a security vulnerability in which auth tokens in URL query parameters are leaked to middleware applications that log URL information, including access logs, browser history, and analytics services (such as Google Analytics). More information here: https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url It is a major functional change, as token auth is likely the most common method for authentication. However, a migration to token in headers should be fairly straightforward for users. The target is to provide deprecation warnings for users starting in 1.22 (along with a gitea config setting that can be used to disable the setting immediately). The default setting will be to disable query-based authentication in 1.23, and then remove the setting in 1.24. |
Should we perhaps backport this to 1.21? |
Yeah, I think that's a great idea. |
I can create a PR which removes the token usage from the integration tests. There we use the parameter a lot. |
Co-authored-by: delvh <dev.lh@web.de>
Maybe we can have a warning, the support will be removed at some version, like 1.23. We can removed the support entirely at that time but not not opt-out. |
Doesn't make any difference. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
If lunny means a warning message at startup I think that's a good idea too - the more warnings the better
Backport #28390 by @jackHay22 ## Changes - Add deprecation warning to `Token` and `AccessToken` authentication methods in swagger. - Add deprecation warning header to API response. Example: ``` HTTP/1.1 200 OK ... Warning: token and access_token API authentication is deprecated ... ``` - Add setting `DISABLE_QUERY_AUTH_TOKEN` to reject query string auth tokens entirely. Default is `false` ## Next steps - `DISABLE_QUERY_AUTH_TOKEN` should be true in a subsequent release and the methods should be removed in swagger - `DISABLE_QUERY_AUTH_TOKEN` should be removed and the implementation of the auth methods in question should be removed ## Open questions - Should there be further changes to the swagger documentation? Deprecation is not yet supported for security definitions (coming in [OpenAPI Spec version 3.2.0](OAI/OpenAPI-Specification#2506)) - Should the API router logger sanitize urls that use `token` or `access_token`? (This is obviously an insufficient solution on its own) Co-authored-by: Jack Hay <jack@allspice.io> Co-authored-by: delvh <dev.lh@web.de>
* giteaofficial/main: [skip ci] Updated translations via Crowdin Fix possible nil pointer access (go-gitea#28428) Don't show unnecessary citation JS error on UI (go-gitea#28433) Do some missing checks (go-gitea#28423) Deprecate query string auth tokens (go-gitea#28390)
Maybe we shoud update the configuration cheat sheet? I noticed the warning log and tried to check more on https://docs.gitea.com/administration/config-cheat-sheet, but I found nothing and I had to read the code. |
Yeah, that was an oversite. I can patch that. |
As described [here](#28390 (comment)).
As described [here](go-gitea#28390 (comment)).
Backport #28485 by @kdumontnu As described [here](#28390 (comment)). Co-authored-by: Kyle D <kdumontnu@gmail.com>
Just for ref: this caused an issue in the helm-chart: https://gitea.com/gitea/helm-chart/pulls/590 |
## Changes - Add deprecation warning to `Token` and `AccessToken` authentication methods in swagger. - Add deprecation warning header to API response. Example: ``` HTTP/1.1 200 OK ... Warning: token and access_token API authentication is deprecated ... ``` - Add setting `DISABLE_QUERY_AUTH_TOKEN` to reject query string auth tokens entirely. Default is `false` ## Next steps - `DISABLE_QUERY_AUTH_TOKEN` should be true in a subsequent release and the methods should be removed in swagger - `DISABLE_QUERY_AUTH_TOKEN` should be removed and the implementation of the auth methods in question should be removed ## Open questions - Should there be further changes to the swagger documentation? Deprecation is not yet supported for security definitions (coming in [OpenAPI Spec version 3.2.0](OAI/OpenAPI-Specification#2506)) - Should the API router logger sanitize urls that use `token` or `access_token`? (This is obviously an insufficient solution on its own) --------- Co-authored-by: delvh <dev.lh@web.de>
As described [here](go-gitea#28390 (comment)).
… defined (go-gitea#28783) So we don't warn on default behavior - Fixes go-gitea#28758 - Follows go-gitea#28390 Signed-off-by: Yarden Shoham <git@yardenshoham.com>
… defined (go-gitea#28783) So we don't warn on default behavior - Fixes go-gitea#28758 - Follows go-gitea#28390 Signed-off-by: Yarden Shoham <git@yardenshoham.com>
### Description of the change With go-gitea/gitea#28390, Gitea 1.21.2 introduced warning log output within the result of `gitea admin <subcommand>` and therefore affects the current provisioning script. That script previously assumed a clean result set and was therefore doomed to fail at _some_ point. This introduces output sanitizing to trim such logs above the actual result table. ### Applicable issues - fixes #589 ### Additional information The non-sanitized output were only an issue for admin account provisioning, and only when the username matched one of these words (in case of #589 it was `gitea`): ```text .../setting/security.go:168:loadSecurityFrom() [W] Enabling Query API Auth tokens is not recommended. DISABLE_QUERY_AUTH_TOKEN will default to true in gitea 1.23 and will be removed in gitea 1.24. ``` LDAP and OAuth sources were not affected by this particular log line, but also processed non-sanitized result sets. Changing their code is a precaution. Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/590 Reviewed-by: pat-s <pat-s@noreply.gitea.com> Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com> Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>
## Changes - Add deprecation warning to `Token` and `AccessToken` authentication methods in swagger. - Add deprecation warning header to API response. Example: ``` HTTP/1.1 200 OK ... Warning: token and access_token API authentication is deprecated ... ``` - Add setting `DISABLE_QUERY_AUTH_TOKEN` to reject query string auth tokens entirely. Default is `false` ## Next steps - `DISABLE_QUERY_AUTH_TOKEN` should be true in a subsequent release and the methods should be removed in swagger - `DISABLE_QUERY_AUTH_TOKEN` should be removed and the implementation of the auth methods in question should be removed ## Open questions - Should there be further changes to the swagger documentation? Deprecation is not yet supported for security definitions (coming in [OpenAPI Spec version 3.2.0](OAI/OpenAPI-Specification#2506)) - Should the API router logger sanitize urls that use `token` or `access_token`? (This is obviously an insufficient solution on its own) --------- Co-authored-by: delvh <dev.lh@web.de>
As described [here](go-gitea#28390 (comment)).
… defined (go-gitea#28783) So we don't warn on default behavior - Fixes go-gitea#28758 - Follows go-gitea#28390 Signed-off-by: Yarden Shoham <git@yardenshoham.com>
Changes
Token
andAccessToken
authentication methods in swagger.DISABLE_QUERY_AUTH_TOKEN
to reject query string auth tokens entirely. Default isfalse
Next steps
DISABLE_QUERY_AUTH_TOKEN
should be true in a subsequent release and the methods should be removed in swaggerDISABLE_QUERY_AUTH_TOKEN
should be removed and the implementation of the auth methods in question should be removedOpen questions
token
oraccess_token
? (This is obviously an insufficient solution on its own)