Token security?

(árpád Magosányi) #1

I am using a personal token in a public project in one organization, to send reports to sonar when building.
I cannot find a way to set the permissions related to a token and I am concerned that people knowing my token can get information about my private project in another organization.
Is it a legitimate concern?
If not, why not?
If yes, how can I generate a token for a project, or with specific permissions?

1 Like
(Gilbert Rebhan) #2

Hi,

there are already strict permissions for your personal token.
Even a Sonarqube admin does only see there is a token for a user and its name and is able to delete it. For security reasons you’ll see the contents of your token only right after creation in Sonarqube web ui, https://yoursonarhost/account/security/
But if you’re using it with IDE plugin Sonarlint you will see its content in plain text in its config dialog.
If you don’t put in on a memo at your monitor and keep your script that contains your token in a safe place you don’t have to be concerned. After all, in case of doubt you’re always able to revoke your personal token and create a new one.

Regards,
Gilbert

1 Like
(árpád Magosányi) #3

Having to keep the the token secret is kind of makes the whole reason of its existence (to delegate some rights securely) pointless, so I do not take it as an answer.
So there is no other way than to create fake github users and delegate rights to them.
I am not sure that it is not against github’s policy.

(Gilbert Rebhan) #4

Hi,

sorry, but i do not really understand what you’re asking for. Reading your first posting i believed you were talking about usertoken in Sonarqube. Now you mentioned Github.
When using a buildserver, e.g. Jenkins you will have one technical user Jenkins runs with. To be able to access your sources, you have to configure several credentials in Jenkins, e.g. for your github repo.
The code scan will be part of the Jenkins build and publishes the result to Sonarqube.
The Sonarqube server knows nothing about your github token.
Could you clarify your questions a little further ?
Seems you have a github repository and you want to build it and do a code scan with Sonarqube.
Do you have a Sonarqube on premise or do you use Sonarcloud.io ?
Should everyone see the results in Sonarqube or should it be private ?
etc. …

Regards,
Gilbert

1 Like
(árpád Magosányi) #5

I am talking about user token. It turned out that sonar beats the reason of the user token by not providing access control related to it. A possible workaround is to create a fake user (either in github or bitbucket), give it the needed permissions and generate a token for that user. But creating fake users is probably against the github/bitbucket policy.
It seems I have to go without sonar, because it is unable to provide adequate security.

(Gilbert Rebhan) #6

Hi,

still don’t get it, Github user token or Sonarqube user token ?
AFAIK, the Github user token ( i have a Github user) is secure and so
is the Sonarqube (i’m Sonarqube admin).

//Gilbert

(árpád Magosányi) #7

Sonar user token. No, it is not secure: the whole point of the token is to delegate rights. And one does not want to delegate all the rights, especially not admin rights and read rights to private code. And the token must be given to someone/something. The whole point of its existence is that you give it away, and in some (practically all) cases to an entity which you do not trust as much as yourself.
So it is totally irrelevant how well it is protected within sonar, as its sole purpose is to exist outside sonar.
I have explained two times how this issue is related to github/bitbucket as sonar’s authentication providers. If you think you have the reading comprehension skills necessary to understand it, read my previous comments about it.
As an example I use the token in a shippable job. While I had only open source projects, I just inserted the token in the repo, because the possible damage value was low. Now the best I could figure out is that I give it to the job as a key/value integration. It is not in the source code, and lives as an environment variable during those builds which run in my name. The attack vector here is that a contributor can show the environment variables in the build output, revealing the token to anyone having right to it. But I can be wise and not allow builds revealing environment variables, right?
No. Pull requests to my repos and organisations run with that key, before I had a chance to check the commits. And I could just overlook something. And this is true to my open source repos, where anyone can issue a pull request.
So it is easy for even a script kiddie to gain access to my sonar key. With which it can see all my code even in the closed source projects, and can also configure stuff, e.g. hide critical vulnerabilities in my code.
This is a vulnerability with which one can gain administrative privileges as a remote unauthenticated user (registering to github/bitbucket is not a burden), with minimal knowledge.
It is in the highest vulnerability ranking according to any vulnerability classification.
Not exactly secure.
Gilbert, are you a sonar employee? If you are, then you are responsible to convey this information to the appropriate people at the enterprise. If not, happy hacking.

And of course I will cease to use sonar before I will have any code in my private repositories which I am liable to protect.

(Colin Mueller) #8

Hi, this is a community for civil conversation, so consider this a warning.

Back to the original question – while the purpose of scoped tokens is to limit a token to have certain permissions, that is not the overall purpose of token-based authentication.

However, I agree that being able to scope permissions for a token would be useful! It’s a point that has been raised before (Security concern on user tokens) and you should feel free to more formally Suggest a feature (https://community.sonarsource.com/c/suggestions)

That said, it’s my understanding that many CI providers, such as Azure Devops and Bitbucket Cloud include ways to define “Secret” variables, which are generally stored as environment variables (At least Azure Devops take it as far as to not make these secrets avilable to PR builds from forks). Can you help me understand the attack vector this represents if the token isn’t being piped out to the build output? Maybe I’m missing something, and I’m asking this with honest intent and curiosity.

Colin

2 Likes
(árpád Magosányi) #10

The token can be piped out of the build in a countless number of ways. The most obvious is to show the environment variables in the build, but test code running could also do anything with it.
I would take a an unauthenticated remote admin vulnerability a bit more serious than that.
What is the formal way to report a vulnerability to sonar?