Something about the clientSecret of GitHub

meteorlxy commented 5 years ago

What is the issue?

Currently, if we are using GitHub, we have to hard-code clientSecret in our js/html files, which has potential risks.

There are already some discussions about that:

In brief, hard-coding clientSecret will cause some security concerns.

Does it really matter?

Yes but no.

Impersonate you website?

Attackers may copy your clientId and clientSecret, but the platform will check the redirect_uri as well.

That means that, attackers can't mislead users to their fake sites with your clientId (unless something like DNS hijacking, which might be another story), so they can't get user's code on their sites with your clientSecret.

In addition, it's more convenient for "attackers" to create a new OAuth App than copy yours, and the target of the "attackers" is the platform but not your website.

From another perspective, your website is "static" and have nothing worth to be attacked...

So you don't need to worry about that.

Impersonate you OAuth App?

Github: OAuth Authorizations API - for example, if attackers get your client secret, they can revoke a grant of an user, so the user have to authorize your app again when he try to login on your website next time. It's possible if someone is aiming at your website, but it might not be so critical.

In brief, it does have security concerns, but not critical. This is why gitment and gitalk didn't fix that.

Plans of enhancement

But it's still an issue.

Currently:

clientSecret is only used for getting access_token
The API endpoint for getting access_token does not support CORS, so we have to use proxy for now

To completely solve this issue, you can use a private proxy to get access_token, and store your clientSecret in the proxy, rather than in your client code.

An existing project is https://github.com/prose/gatekeeper, which can be deployed on Heroku/Azure by yourself easily. But it's not compatible with our current proxy option

So Vssue is planning to:

Provide a similar project for this purpose
Or: Make the proxy option more flexible to support https://github.com/prose/gatekeeper

jonasfranz commented 5 years ago

Maybe use PKCE?

meteorlxy commented 5 years ago

@jonasfranz

As far as I know (limited though), PKCE is not supported by most of the platforms.

For now we can use Implicit Grant Type for this on GitLab and Bitbucket (GitHub does not support it) #22

BTW, if gitea can support Implicit Grant Type or PKCE, we can try to make use of it for sure 😄

jonasfranz commented 5 years ago

@meteorlxy gitea supports pkce

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

RehanSaeed commented 4 years ago

Any updates on gatekeeper? Do you recommend https://github.com/Rob--W/cors-anywhere instead? If so, are there some simple instructions to setting it up?

meteorlxy / vssue