Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to avoid leaking your customer's source code with GitHub apps

roadie.io

Post reply on HN
Print view View original

1–9 of 9 posts

Re: How to avoid leaking your customer's source code with GitHub apps

#4

Post by eranation »

Good article and agree with the recommendations, I'm trying to understand the attack flow though. You perform an actual installation and get a valid authorization code, but replace the actual installation ID with another (that the user has no access to)?

This is a major issue then from GitHub's side. I think what GitHub should do is just like with Oauth apps, allow you to provide a state (assuming the flow is starting from the SaaS app, not from the GitHub marketplace, I assume you can't send a state since it's sort of like an "IdP initiated" flow in case you start the installation from the github marketplace, but they should let you opt out and require a state. There is a reason why things like PKCE and such exist.

Re: How to avoid leaking your customer's source code with GitHub apps

#5

Post by brianfletcher »

eranation wrote: post #4

Good article and agree with the recommendations, I'm trying to understand the attack flow though. You perform an actual installation and get a valid authorization code, but replace the actual installation ID with another (that the user has no access to)? This is a major issue then from GitHub's side. I think what GitHub should do is just like with Oauth apps, allow you to provide a state (assuming the flow is startin…

If you use the setup url callback, you don't get any authorization code just an installation id and the setup action. So there is no means to verify that the user honestly owns the installation that they are providing. Because the number is so short, it's easy to guess every combination.

Re: How to avoid leaking your customer's source code with GitHub apps

#6

Post by eranation »

brianfletcher wrote: post #5
eranation wrote: post #4

Good article and agree with the recommendations, I'm trying to understand the attack flow though. You perform an actual installation and get a valid authorization code, but replace the actual installation ID with another (that the user has no access to)? This is a major issue then from GitHub's side. I think what GitHub should do is just like with Oauth apps, allow you to provide a state (assuming the flow is startin…

If you use the setup url callback, you don't get any authorization code just an installation id and the setup action. So there is no means to verify that the user honestly owns the installation that they are providing. Because the number is so short, it's easy to guess every combination.

Right, agree and understand 100%, but if I do the authorization code flow (which I agree all apps should do) - is the 2nd check (of using the received token to check the user can access that installation) required? if they didn't have permission to install it, the callback wouldn't happen? I am feeling they imply a 3rd, interim diagram flow where you do the authorization code (instead of the setup URL that they should probably remove due to the risk) - but without the GET /user/installations check - I am trying to understand if they had a POC of that being exploitable (e.g. using a valid code but sending a different installation ID)

Re: How to avoid leaking your customer's source code with GitHub apps

#7

Post by brianfletcher »

eranation wrote: post #6
brianfletcher wrote: post #5

Earlier quoted context omitted.

If you use the setup url callback, you don't get any authorization code just an installation id and the setup action. So there is no means to verify that the user honestly owns the installation that they are providing. Because the number is so short, it's easy to guess every combination.

Right, agree and understand 100%, but if I do the authorization code flow (which I agree all apps should do) - is the 2nd check (of using the received token to check the user can access that installation) required? if they didn't have permission to install it, the callback wouldn't happen? I am feeling they imply a 3rd, interim diagram flow where you do the authorization code (instead of the setup URL that they shoul…

Oh yeah I see what you mean. That sounds like we can optimize there. It's probably unlikely that a completely valid installation id and code comes back for the wrong app? I'm probably clutching at straws. Maybe the app is uninstalled by the time the redirect makes it back. Also unlikely. You are probably right that it is redundant.
Post reply on HN