[Security] GitHub Access Token stored in sessionStorage

[captn3m0]

I understand why this decision was made: convenience. I have written a similar cms in the past and made the same choice that you did (Basic Auth over OAuth).

However, hubpress seems to be storing access tokens in sessionStorage. While its admirable that you are trying to reduce risk by limiting the scope (to just public_repo), I dont think this is enough.

From the GitHub Docs:

public_repo: Grants read/write access to code, commit statuses, and deployment statuses for public repositories and organizations.

Why do I think this is insecure?

GitHub pages allows for multiple websites on the same domain. This can be achieved via CNAMEs as well as multiple repos on the same account. Here's a hypothetical scenario:

There is an organization for an open source organization. Lets call it X. Now X org uses best practices and uses teams for access management. They have lots of Static sites, and someone decides to try hubpress for one of them.

They get hubpress setup very easily on a particular repo called docs. A few of their colleagues try it out and it works perfectly. Some of these people are not just on the docs team, but on multiple other teams and organizations.

Now, there is a rogue developer (who doesn't have access to the docs repo), but has access to any single repo on the same organization. All GitHub repos can have a gh-pages, which will get published automatically. This rogue developer just pushes a rogue script, which reads the data in sessionStorage and sends him the access token. He gets any other developer to open the site, and gets the token.

docs repo: x.github.io/docs/ rogue repo: x.github.io/rogue/

sessionStorage is shared across both. Any JS that executes on the rogue site can access secrets stored by the first.

People have asked this question on various forums and it is not recommended.

I have been dealing with the same issues, and the current best solution I can think of is to store the token in sessionStorage but encrypt it with a user passphrase, so that using the token requires knowledge of the passphrase. Yes, JS crypto is insecure, but I think this should reduce the risk somewhat.

[anthonny]

Hi @captn3m0 ! :+1:

It's my opinion but in an organization i think it's not really good that someone like this rogue can create this repository.

But you're right, i have a solution to handle with this problem. I have to define a roadmap, but it pretty sure that problem will be a priority

[captn3m0]

The iojs organization has 83 public members. The actual number is probably above 100. Many of these were added to a localization repo just because they asked politely on twitter/github. There was no vetting process of any sort involved.

Also, sessionStorage can be read by any Javascript added to the page. Yes, so can cookies, but we have a workaround for that called httponly. However, that goes into the entire trusted vs untrusted js debate, so I don't think its a very good argument.

Nice to see its on the roadmap. I'd love to hear more details.

[jaredmorgs]

Is this still the case with 0.7.0 @anthonny or has this sessionStorage issue been resolved?

[anthonny]

Yes it is still the case @jaredmorgs :( I was sure to have a solution when i answered to @captn3m0, but finally i have not implemented it yet.

I had a look at other lib like satellizer https://github.com/sahat/satellizer#authsetstoragetypetype and they also also use sessionStorage.

I can't use cookies httpOnly in my case.

Here is the solution i was thinking about:

• When the user login with his credentials i create a new token
  • I can add a description, actually it is something like bloghubpressio-Chrome-OS-X-10123-64-bit,
  • After the token is created i cannot read it anymore with the API
  • But i could add a random hash in the description, for example: 682cbfba:bloghubpressio-Chrome-OS-X-10123-64-bit
• Then i store the token crypt with the hash

And when i refresh the page, i can browse tokens with the API to get description, get the key and uncrypt the token to be able to target the API.

Wdyt @captn3m0?

My apologize for not having answered earlier

[captn3m0]

I'm unclear about the solution you've proposed. My understanding:

1. You store a secret with the token description
2. And store the actual Access Token encrypted using this secret in sessionStorage
3. Read the token description from the API again to get the secret, decrypt the sessionStorage and use the access token as normal.

I'm unsure how would (3) work. How do you list the tokens from the GitHub API if you don't have auth?

[anthonny]

..., my bad ...

Yes you are right, if the user refresh i cannot get the list of tokens so he must relog

If you have another idea

[captn3m0]

I can't think of any easy way out here. Some ideas:

1. You can use the WebCrypto API to encrypt and store the key safely, and ask the user for a passphrase when you want to read it. The downside is that every refresh you loose the key, and have to ask the user again.
2. You create a separate browser extension that handles the origin/path->PAT mappings. It verifies that the origin+path asking for the PAT is the same as the one that stored it.

For now, I'd recommend pointing this out in the README as clearly as possible so that users are aware of a possible security risk while installing hubpress.

Something like:

We recommend you install hubpress on a separate-domain, which is not shared with any other services. Any other javascript running on the same origin will have access to the token hubpress stores on the client side, and can use it for malicious purposes. As such, please ensure that the domain is not shared by any other service.

[anthonny]

My favourite idea is the first one because i can add an option in the setting to activate/desactivate the crypto. Most of the HubPress users are alone on their repository and do not "need" to encrypt their token.

But for users who needs, they can activate and effectively they will have to put their passphrase at every refresh. I suppose that they do not refresh every minutes, so it is not really a problem