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.

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

Secrets exposed in properties for the mirror URL #7616

Closed
2 of 7 tasks
ghost opened this issue Jul 25, 2019 · 3 comments · Fixed by #7651
Closed
2 of 7 tasks

Secrets exposed in properties for the mirror URL #7616

ghost opened this issue Jul 25, 2019 · 3 comments · Fixed by #7651
Labels
topic/security Something leaks user information or is otherwise vulnerable. Should be fixed!

Comments

@ghost
Copy link

ghost commented Jul 25, 2019

  • Gitea version (or commit ref): 1.8.3
  • Git version: 1.8.3.1
  • Operating system: Red Hat Enterprise Linux 7.6
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
  • Log gist:

Description

When creating a mirror of a downstream git repo, https mirroring is the only option, and when using an authenticated mirror you must supply credentials for the mirror. These credentials then become part of the properties in the administration section of the mirror, and the password is displayed in plain clear text. This was confirmed on https://try.gitea.io and I have provided a screenshot that shows this security issue that exposes secrets in plain clear text with no option to mask the secret.

Screenshots

secrets-plain-clear

@silverwind
Copy link
Member

silverwind commented Jul 25, 2019

Basic auth credentials must be stored in plaintext somewhere and it's vital for verification to have them accessible in the UI. What could maybe be done is that users with non-owner permissions get to only see masked credentials, or even hide the whole URL from them.

@ghost
Copy link
Author

ghost commented Jul 25, 2019

I don't think it is vital to verify the password if it can easily be tested, and/or changed, but this isn't my main concern. There could simply be a toggle to unmask if that is a community need. I am more concerned that a drive-by unprivileged user could see the secrets, since they are not masked by default. Here is an example of how Atlassian Bamboo handles credentials, keeping the password field masked at all times, even while typing it in.

bamboo-masked-credentials

Here is an example of how Lastpass uses an unmasking toggle, keeping the password masked by default.

lastpass-masked-passwd

@silverwind
Copy link
Member

Agree, a simple protection against shoulder surfers would be good to have there.

@lunny lunny added the topic/security Something leaks user information or is otherwise vulnerable. Should be fixed! label Jul 29, 2019
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
topic/security Something leaks user information or is otherwise vulnerable. Should be fixed!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants