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.
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.
eranation|4 years ago
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.
brianfletcher|4 years ago
fortran77|4 years ago
hikerclimber1|4 years ago
[deleted]
netr0ute|4 years ago
yjftsjthsd-h|4 years ago