5 ms·

Now I haven't gone through this process with github, but for other pages where I have gone through it, the issuer doesn't just hand out scopes like candy. It's

Now I haven't gone through this process with github, but for other pages where I have gone through it, the issuer doesn't just hand out scopes like candy. It's not enough that the user gives an app permission to act on my behalf, the issuer (in this case github) also has to give the app permission to ask for these scopes in the first place. Github definitively messed up in giving the nopecha app permission to ask users for permission to star on their behalf. If stars are important enough for them to ban users over, they should be very careful about letting third party apps request this scope from their users.

execveat 4y ago
For context, in order to star projects on user's behalf you'd need to request public_repos scope[1], so the UI will look like this: https://github.com/login/oauth/authorize?client_id=33a703d019e0d23730ea&scope=public_repo https://github.com/login/oauth/authorize?client_id=33a703d01... (I used a random client_id from google search). As you can notice, the UI does not mention stars at all. [1] public_repo: Limits access to public repositories. That includes read/write access to code, commit statuses, repository projects, collaborators, and deployment statuses for public repositories and organizations. Also required for starring public repositories. (https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps https://docs.github.com/en/developers/apps/building-oauth-ap...)
- Borgz 4y ago
  Wow, this is really bad. The words "read and write" are hidden unless you click on the arrow next to "Repositories". I'm surprised this hasn't been used for malicious purposes until now.
- ilyt 4y ago
  That [1] is how "ask only for e-mail", "proper" "just" SSO looks like. While sure it isn't immediately expected to access "stars" feature when you give public repo access... ...you're giving it fucking repo access. That's WAY more (on a "how bad it can be if you get hacked") permissions than just starring.
- xgbi 4y ago
  > That includes read/write access to code [on public repos owned by the user] What the hell, imagine logging-in with your account, you as a maintainer of a large public repo, and failing to understand clearly that you are giving a 3rd party the possibility of commiting on your behalf. Seriously there should be a big red warning on all scopes apart from the "none" one.
- jrochkind1 4y ago
  I believe github doens't even have a scope that gives read access but not write access. So we users have been trained to just grant that scope to people who really only need read access, because it's the only thing that works. And in general trained not to even pay attention to those scopes anymore -- on github specifically -- because they are such a mess, and third-parties routinely need scope overreach to do what they want. So I do think github is broken here in a way that predictably leads to problems like above. They need better more granular scopes (and have for years; I don't understand why with their resources they haven't prioritized it), and then they need a better UI for making sure the user understands what they are granting, differentiating between read vs write, etc. Without that... it's only a matter of time until something much worse happens, like someone abuses a scope to insert malware in someone else's repo. I would not be surprised if it's happened already but hasn't been publicly known. BUT, also... you sign up for a service that will for-pay get around captchas for you so you can automate access to a site where the captchas are intended to prevent automated access, and then you're just shocked that this service would do something unethical...
9wzYQbTYsAIc 4y ago
> the issuer doesn't just hand out scopes like candy GitHub isn’t doing the handing out, it is the user doing the handing out. I don’t blame the user, as a rule, but in this type of scenario, the user (a consumer of development tools) shouldn’t be excused, in my opinion. This would be like a doctor complaining for getting sued for malpractice by a patient of a nurse under the doctor, while the doctor neglected to review the patient chart and neglected to take the time to speak with the nurse. caveat emptor All that said, I would hope that bad actors that get caught, effectively phishing for GitHub credentials, using a technique like this end up being banned from GitHub.
- vintermann 4y ago
  As I said, before the app even can ask for a scope, github has to give that app permission to ask for a scope. I have written some integrations against altinn, the Norwegian government's portal for basically anything official. Getting approval for a scope there is a process, as well it should be. If I write an app that lets users send construction applications to the local municipality on the user's behalf, do you think I can just sneak in a request for permission to change the user's address, name and bank account registrations as well? No. There are scopes for that (I assume), but my app won't get to request them, no matter how much the user would be willing to give them. And "caveat emptor" is not the threat model you can get away with on the web. Sure, it would be great for me as a dev if I could just disavow responsibility for cross site scripting attacks and other attempts to misuse the user's credentials. But I'm a user too, and it would NOT be fun as a user.
  - samus 4y ago
    Github is not the Norwegian government though. Github is not a gateway to public bureaucracy or to public services. It provides repository hosting, project management, and integration with build tools and similar services. Fostering a wide ecosystem is a core part of their business strategy, and as such applications are only validated superficially. Also, it operates at a scale that makes such validation infeasible. Furthermore, the audience of Github is decidedly more technical than a government website or social media platforms. IMHO it can be expected that its users step through authentication flows a bit more carefully. Github should act more decisive when applications turn out to be malicious though. The Laissez-faire policy of frictionless integration of applications has to be balanced with effective procedures to react to malicious uses.
Already__Taken 4y ago
API scopes could totally use some mandatory standards. You can't make a digital ocean token to simply edit DNS without full delete-all-your-VM's & charge thousands access. Similarly we shouldn't bill for service accounts, especially when they're documented as the way to limit API token access. It's self-defeatist like taxing longer passwords.
- danuker 4y ago
  Finetuned permissions cost to implement. GitHub doesn't have them (maybe we wouldn't have seen this post if it had). Therefore if you want them, pay up or do it yourself.
  - Already__Taken 4y ago
    Fine, put that behind my $x/mo account + service accounts. $x/mo * Service accounts is dumb.
  - masklinn 4y ago
    > Finetuned permissions cost to implement. GitHub doesn't have them (maybe we wouldn't have seen this post if it had). They exist for github apps, and they're being rolled out for PATs alongside forced expiration: https://github.blog/2022-10-18-introducing-fine-grained-personal-access-tokens-for-github/ https://github.blog/2022-10-18-introducing-fine-grained-pers... Not sure there's any way for them to happen for oauth apps though. And even if they do, they're opt-in for the app and the old broad scope will remain. At best the broad scopes would only be accessible to old apps grandfathered in but that ain't much (there's probably a billion abandoned oauth applications you could purchase for that grandfathering).
  - josephcsible 4y ago
    That's not a practical suggestion, since GitHub isn't self-hosted or open-source.
- ilyt 4y ago
  Well, it is PITA to implement so I'm not surprised really...
sbergot 4y ago
No this is standard procedure. You have to register the permissions you are going to request to github. But github is not going to inspect your app and checks that they are indeed required. Github's responsibility is to ask consent to the user and display all the requested permissions. If the user accepts then Github has done its work. This is how all oidc providers work.
- vintermann 4y ago
  It is not how Oauth2 needs to work, or should work. OIDC is (or should be) about the user's identity only. It's for third partiets to know who you are, not for third parties to act on your behalf. If the screen to give a 3rd party permission to identify you, looks like the screen to give a 3rd party sweeping permission to act on your behalf, that's github's responsibility and problem. It would also be a good reason for responsible 3rd parties to ditch github for identity, if they don't address it. (Another matter is that the big public OIDC providers' eagerness to let you use them might be a lot about tracking.)
  - 9wzYQbTYsAIc 4y ago
    OAuth is definitely about scope. See the latest draft for OAuth Rich Authorization Requests (“work in progress”): https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html edit: you might be mixing up / conflating Open Authorization (an authorization standard - authorization scopes are in scope) with Open Identity (an authentication standard - authorization scopes are out of scope) edit 2: It probably doesn’t help disambiguate which auth is which when the same company is providing both the authentication service and the authorization service.
    - vintermann 4y ago
      Why is everyone linking this draft? It's got very little to do with what we're discussing. Yes, of course OAuth is about scopes! But OIDC is a protocol built on top of OAuth2 which is for identity only. You get no permission to act on the user's behalf from the OICD scopes, only read access to information you need to identify them. This whole problem only happened because 1. Github is an OIDC provider, allowing you to identify yourself to websites around the world. 2. Github ALSO uses OAuth2 to delegate permissions to the user's stuff on their own site. 3. The one looks too much like the other. OP probably thought he was just showing ID, but what he was doing was giving the site sweeping permission to act on his behalf, which the site promptly misused. The problem here starts already at 2. That anyone can create an integration and ask for OICD scopes, is one thing, but why do they make it so easy to hand out their own scopes? There are not that many third party apps that have a legitimate need to act on the user's behalf. Maybe some continuous integration stuff? But even that should only have access to the user's own repositories. Nothing I can think of has a legitimate need to go around starring random repositories.
piscataway 4y ago
If stars are so important that any program that can auto-check stars is inherently fraudulent, then why allow any official third party API the ability to click on stars? Shouldn't that always be something you explicitly have to click?

execveat 4y ago

For context, in order to star projects on user's behalf you'd need to request public_repos scope[1], so the UI will look like this: https://github.com/login/oauth/authorize?client_id=33a703d019e0d23730ea&scope=public_repo https://github.com/login/oauth/authorize?client_id=33a703d01... (I used a random client_id from google search). As you can notice, the UI does not mention stars at all. [1] public_repo: Limits access to public repositories. That includes read/write access to code, commit statuses, repository projects, collaborators, and deployment statuses for public repositories and organizations. Also required for starring public repositories. (https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps https://docs.github.com/en/developers/apps/building-oauth-ap...)

Borgz 4y ago
Wow, this is really bad. The words "read and write" are hidden unless you click on the arrow next to "Repositories". I'm surprised this hasn't been used for malicious purposes until now.
ilyt 4y ago
That [1] is how "ask only for e-mail", "proper" "just" SSO looks like. While sure it isn't immediately expected to access "stars" feature when you give public repo access... ...you're giving it fucking repo access. That's WAY more (on a "how bad it can be if you get hacked") permissions than just starring.
xgbi 4y ago
> That includes read/write access to code [on public repos owned by the user] What the hell, imagine logging-in with your account, you as a maintainer of a large public repo, and failing to understand clearly that you are giving a 3rd party the possibility of commiting on your behalf. Seriously there should be a big red warning on all scopes apart from the "none" one.
jrochkind1 4y ago
I believe github doens't even have a scope that gives read access but not write access. So we users have been trained to just grant that scope to people who really only need read access, because it's the only thing that works. And in general trained not to even pay attention to those scopes anymore -- on github specifically -- because they are such a mess, and third-parties routinely need scope overreach to do what they want. So I do think github is broken here in a way that predictably leads to problems like above. They need better more granular scopes (and have for years; I don't understand why with their resources they haven't prioritized it), and then they need a better UI for making sure the user understands what they are granting, differentiating between read vs write, etc. Without that... it's only a matter of time until something much worse happens, like someone abuses a scope to insert malware in someone else's repo. I would not be surprised if it's happened already but hasn't been publicly known. BUT, also... you sign up for a service that will for-pay get around captchas for you so you can automate access to a site where the captchas are intended to prevent automated access, and then you're just shocked that this service would do something unethical...

9wzYQbTYsAIc 4y ago

> the issuer doesn't just hand out scopes like candy GitHub isn’t doing the handing out, it is the user doing the handing out. I don’t blame the user, as a rule, but in this type of scenario, the user (a consumer of development tools) shouldn’t be excused, in my opinion. This would be like a doctor complaining for getting sued for malpractice by a patient of a nurse under the doctor, while the doctor neglected to review the patient chart and neglected to take the time to speak with the nurse. caveat emptor All that said, I would hope that bad actors that get caught, effectively phishing for GitHub credentials, using a technique like this end up being banned from GitHub.

vintermann 4y ago
As I said, before the app even can ask for a scope, github has to give that app permission to ask for a scope. I have written some integrations against altinn, the Norwegian government's portal for basically anything official. Getting approval for a scope there is a process, as well it should be. If I write an app that lets users send construction applications to the local municipality on the user's behalf, do you think I can just sneak in a request for permission to change the user's address, name and bank account registrations as well? No. There are scopes for that (I assume), but my app won't get to request them, no matter how much the user would be willing to give them. And "caveat emptor" is not the threat model you can get away with on the web. Sure, it would be great for me as a dev if I could just disavow responsibility for cross site scripting attacks and other attempts to misuse the user's credentials. But I'm a user too, and it would NOT be fun as a user.
- samus 4y ago
  Github is not the Norwegian government though. Github is not a gateway to public bureaucracy or to public services. It provides repository hosting, project management, and integration with build tools and similar services. Fostering a wide ecosystem is a core part of their business strategy, and as such applications are only validated superficially. Also, it operates at a scale that makes such validation infeasible. Furthermore, the audience of Github is decidedly more technical than a government website or social media platforms. IMHO it can be expected that its users step through authentication flows a bit more carefully. Github should act more decisive when applications turn out to be malicious though. The Laissez-faire policy of frictionless integration of applications has to be balanced with effective procedures to react to malicious uses.

Already__Taken 4y ago

API scopes could totally use some mandatory standards. You can't make a digital ocean token to simply edit DNS without full delete-all-your-VM's & charge thousands access. Similarly we shouldn't bill for service accounts, especially when they're documented as the way to limit API token access. It's self-defeatist like taxing longer passwords.

danuker 4y ago
Finetuned permissions cost to implement. GitHub doesn't have them (maybe we wouldn't have seen this post if it had). Therefore if you want them, pay up or do it yourself.
- Already__Taken 4y ago
  Fine, put that behind my $x/mo account + service accounts. $x/mo * Service accounts is dumb.
- masklinn 4y ago
  > Finetuned permissions cost to implement. GitHub doesn't have them (maybe we wouldn't have seen this post if it had). They exist for github apps, and they're being rolled out for PATs alongside forced expiration: https://github.blog/2022-10-18-introducing-fine-grained-personal-access-tokens-for-github/ https://github.blog/2022-10-18-introducing-fine-grained-pers... Not sure there's any way for them to happen for oauth apps though. And even if they do, they're opt-in for the app and the old broad scope will remain. At best the broad scopes would only be accessible to old apps grandfathered in but that ain't much (there's probably a billion abandoned oauth applications you could purchase for that grandfathering).
- josephcsible 4y ago
  That's not a practical suggestion, since GitHub isn't self-hosted or open-source.
ilyt 4y ago
Well, it is PITA to implement so I'm not surprised really...

sbergot 4y ago

No this is standard procedure. You have to register the permissions you are going to request to github. But github is not going to inspect your app and checks that they are indeed required. Github's responsibility is to ask consent to the user and display all the requested permissions. If the user accepts then Github has done its work. This is how all oidc providers work.

vintermann 4y ago
It is not how Oauth2 needs to work, or should work. OIDC is (or should be) about the user's identity only. It's for third partiets to know who you are, not for third parties to act on your behalf. If the screen to give a 3rd party permission to identify you, looks like the screen to give a 3rd party sweeping permission to act on your behalf, that's github's responsibility and problem. It would also be a good reason for responsible 3rd parties to ditch github for identity, if they don't address it. (Another matter is that the big public OIDC providers' eagerness to let you use them might be a lot about tracking.)
- 9wzYQbTYsAIc 4y ago
  OAuth is definitely about scope. See the latest draft for OAuth Rich Authorization Requests (“work in progress”): https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html edit: you might be mixing up / conflating Open Authorization (an authorization standard - authorization scopes are in scope) with Open Identity (an authentication standard - authorization scopes are out of scope) edit 2: It probably doesn’t help disambiguate which auth is which when the same company is providing both the authentication service and the authorization service.
  - vintermann 4y ago
    Why is everyone linking this draft? It's got very little to do with what we're discussing. Yes, of course OAuth is about scopes! But OIDC is a protocol built on top of OAuth2 which is for identity only. You get no permission to act on the user's behalf from the OICD scopes, only read access to information you need to identify them. This whole problem only happened because 1. Github is an OIDC provider, allowing you to identify yourself to websites around the world. 2. Github ALSO uses OAuth2 to delegate permissions to the user's stuff on their own site. 3. The one looks too much like the other. OP probably thought he was just showing ID, but what he was doing was giving the site sweeping permission to act on his behalf, which the site promptly misused. The problem here starts already at 2. That anyone can create an integration and ask for OICD scopes, is one thing, but why do they make it so easy to hand out their own scopes? There are not that many third party apps that have a legitimate need to act on the user's behalf. Maybe some continuous integration stuff? But even that should only have access to the user's own repositories. Nothing I can think of has a legitimate need to go around starring random repositories.

piscataway 4y ago

If stars are so important that any program that can auto-check stars is inherently fraudulent, then why allow any official third party API the ability to click on stars? Shouldn't that always be something you explicitly have to click?