10 ms·

It probably wasn’t actually a standard “sign in with GitHub”, minimal SSO flow, it was likely an OAuth2 authorization code flow, where OP granted them explicit

by yashap 4y ago

It probably wasn’t actually a standard “sign in with GitHub”, minimal SSO flow, it was likely an OAuth2 authorization code flow, where OP granted them explicit access to do things like star repos. Like, the button on the nopecha site may have said “sign in with GitHub”, but it actually kicked off and authorization code flow with GitHub, where you’re granting nopecha access to do GH things on your behalf. And OP just didn’t read things carefully enough, clicked through without looking. This is a dead giveaway: > i logged in, clicked through a bunch of pages because its the same drill everytime For SSO, “login with GitHub” type flows, there’s no “clicking through a bunch of pages” post sign-in - you aren’t granting them access to your GH account, you’re just letting GH tell the site “yup, this is person X”. What OP describes sounds like explicitly granting a 3rd party access to your GitHub account, and OP was just being sloppy - I’d strongly bet the pages said things like “do you want to grant nopecha access to star repos on your behalf”, and OP clicked “yes”. If there’s any lesson here, it’s to read things more carefully, and not just freely give out access to your accounts to sketchy websites.

2Gkashmiri 4y ago
no i did not because when i click on “sign in with GitHub” flow, that is the only thing i expect to happen. whatever the dev added to the workflow is what i assumed to be needed for the login to happen
- Aeolun 4y ago
  That’s kinda your own fault. You could have known they were going to be able to star repos on your behalf if you’d read carefully. What is strange is that you are banned for an action someone else took. That doesn’t make any sense.
- yashap 4y ago
  As I said, it’s a lesson to read more carefully. If you’re granting a sketchy website broad access to your accounts without even reading what you’re granting, bad things are guaranteed to happen. Also, seems like you’re probably a developer? If so, SSO, OAuth2, OIDC, etc. are worth learning about. You seem to be confusing/conflating SSO and OAuth2 authorization code flows, when they’re reasonably different things.
- netheril96 4y ago
  GitHub could not control what lies other websites tell. They can have a button saying “Sign in with GitHub”but totally not signing in with GitHub. That said GitHub should have banned that website for lying and abusing instead of OP.
  - easyorgmode 4y ago
    This proves the point that these third party "Sign in with" buttons are really dangerous. It makes a possibly dodgy website look more secure and legit by using a well known provider like Github for the login process. In addition, it potentially exposes data from that well known provider, which is often sensitive data, as in the case of Github.
- vel0city 4y ago
  When I double click on free_cookies.exe which I got from totallyawesomenotavirus.com I expect my computer to start giving me chocolate chip cookies. Or maybe I shouldn't just take everything at face value and pay attention to what I'm doing.
  - scarface74 4y ago
    And how has that worked out for the last 40 years.
iforgotpassword 4y ago
I've always had at least one confirmation page where it stated what data would be shared with the 3rd party and what kind of access they get to my account.
- yashap 4y ago
  True, there’s often a “GitHub will have access to your email address” type confirmation in SSO flows, as that’s basically what SSO is (it’s GH telling a 3rd party “yup this is bob@example.com, feel free to log them into your site as bob@example.com”). However, what you won’t see in a standard SSO flow is anything along the lines of “GitHub will be able to star repositories on your behalf.” If you’re seeing those kind of messages, you aren’t doing a minimal SSO flow (just having GH vouch for your identity), you’re granting access to a 3rd party to do things with your GH account.
BoorishBears 4y ago
I was with you until the last two sentences. I'll honestly never get that point of view: it's an evolutionary disadvantage to not fall for these kinds of attacks. Our intelligence is largely predicated on how easily we can pattern match and filter out "excess" information. So OP being bombarded with a list of harmless permissions along with one deceptively dangerous one (deceptive because they wouldn't expect to lead to being pwn'd anyways, since it's stars) and granting is not being sloppy, it's being an intelligent person. Github is large enough to have UX experts who know this stuff, and at the very least if stars are grounds for being banned, they should be grouping it with dangerous permissions and using more confirmations. And even better... they should just rate limit starring! How often is someone going to star 500 of someone's repos legitimately that rate limiting would ruin everyone's day?
- yashap 4y ago
  FWIW, I agree GH shouldn’t have banned OP. But … I’m pretty sure they weren’t giving out access to control OP’s account through a standard SSO flow, as OP assumed. Massively more likely, OP just didn’t pay attention, and granted said access explicitly during an OAuth2 authorization code flow.
  - BoorishBears 4y ago
    My entire point is that they did explicitly grant the permissions and that if you see a dialog like this: https://i.stack.imgur.com/Iol8j.png https://i.stack.imgur.com/Iol8j.png And you're ready to hand over even the first 3 items there, you're not likely to assume or even notice that github stars about to get you knocked out of orbit. I know this is a place of hubris but it almost comes across as a strange lack of self-awareness that this many people actually think they'd have caught that.
- sennight 4y ago
  > ..is not being sloppy, it's being an intelligent person. No, that is being an intelligent ape reacting to a twitching bush by running up a tree on the chance that a predator is behind the bush. The tables have turned since then. Back then the analytical ape would have gotten eaten and not passed his genes on, but there is no longer a biological imperative to mindlessly react to things.
Aeolun 4y ago
Giving a website access to star repos through the API for my convenience is not anything I should be banned over though.
- yashap 4y ago
  That I do agree with.
- gernb 4y ago
  from github's pov you starred the repos. You signed up for a service the stars repos. it could have been starallthereposforme.com and you signing up a granting them permission to star repos is exactly what you wanted. So girhub is correctly assuming you wanted those repos starred. If you didn't want them starred you shouldn't have given the site permission to star
  - tgsovlerkhgsel 4y ago
    GitHub should be able to tell that this was an abusive service doing it though. Legally they might be in the right, but punishing victims of social engineering further doesn't seem like a fair or smart business decision.
    - olabyne 4y ago
      yep, it is easy for them to know if the star was the user itselft OR a third party app through the API...
    - wikfwikf 4y ago
      But an 'abusive service' might still involve misconduct by the user in question. Suppose there is a service which allows you to watch free porn videos as long as you hand over permissions to star a bunch of repos using your account. Clearly, the service is abusive and should be banned. But isn't it also quite fair for Github to penalize the users? They knew they were handing over something of value when they authorized the access. Either they chose to exchange their genuine 'Github clout' for something they wanted, or their accounts are spammy in the first place (for example, if they created an account solely to access that service).
2Gkashmiri 4y ago
if i go with your argument, "what wrong did i commit" if i allowed an application a legitimate action of managing stars? how did i know beforehand the app was going to abuse this very action because there are other commenters saying that stars manage action is a legitimate, non-sinister action in itself so where was i sloppy?
- yashap 4y ago
  I agree you should not have been banned - I think GH was wrong there. You got taken advantage of, you weren’t being malicious. However, getting banned is pretty minor compared to the other bad things that can happen if you grant sketchy websites access to your accounts without reading what you’re granting.
- dbt00 4y ago
  I'm sorry you lost access to your github account, but let's be fair. This is not a legitimate application for managing your stars, this is a page that was committing fraud and probably requested access to your account in exchange for committing further fraud on your behalf. You were already logged in. Why did you log in again with github? Because it asked you to, and promised you more rewards if you did?
  - machinawhite 4y ago
    > Why did you log in again with github? Sorry I'm somone else but I'd just go and assume it was because they are human, not a terminator, and their eyes do not have an integrated HUD talking with GitHub's backend with status indicators showing each currently authenticated account??? You want this kind of correctness you have to write software in Rust or something. "You're holding it wrong" lol
    - fknorangesite 4y ago
      It's a bog-standard oauth2 authentication flow. I'm positive GitHub showed OP the list of permissions that this sketchy third-party app was requesting, and OP granted those permissions. Yes, you are supposed to read the dialogs. OP really got got, and that sucks. But it's literally why that permissions checklist step - that they ignored - exists.
nailer 4y ago
> probably wasn’t actually a standard “sign in with GitHub”, minimal SSO flow, it was likely an OAuth2 authorization code flow This is accurate, but oauth2 is the standard sign in with GitHub. oauth is literally designed as an authorisation mechanism to allow people to do things on your behalf, the ability to authorise access was later repurposed into an authentication mechanism.
vintermann 4y ago
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.
  - 4y ago
grumple 4y ago
Github does not separate starring. It falls under the public_repo scope, which is one of the fundamental scopes. Source: https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps#requested-scopes-and-granted-scopes https://docs.github.com/en/developers/apps/building-oauth-ap... "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."
- masklinn 4y ago
  FWIW under the new fine-grained permission model (used by github apps, and the fine-grained personal access tokens currently in beta) "starring" is its own account-level permission: https://docs.github.com/en/rest/overview/permissions-required-for-fine-grained-personal-access-tokens?apiVersion=2022-11-28#starring https://docs.github.com/en/rest/overview/permissions-require...
nullfield 4y ago
Maybe, just maybe, if companies like GitHub would read the fucking RFC’s for “OAuth is not for authentication” they’d get somewhere. We at least/even have OIDC for that now.

by yashap 4y ago

2Gkashmiri 4y ago

no i did not because when i click on “sign in with GitHub” flow, that is the only thing i expect to happen. whatever the dev added to the workflow is what i assumed to be needed for the login to happen

Aeolun 4y ago
That’s kinda your own fault. You could have known they were going to be able to star repos on your behalf if you’d read carefully. What is strange is that you are banned for an action someone else took. That doesn’t make any sense.
yashap 4y ago
As I said, it’s a lesson to read more carefully. If you’re granting a sketchy website broad access to your accounts without even reading what you’re granting, bad things are guaranteed to happen. Also, seems like you’re probably a developer? If so, SSO, OAuth2, OIDC, etc. are worth learning about. You seem to be confusing/conflating SSO and OAuth2 authorization code flows, when they’re reasonably different things.
netheril96 4y ago
GitHub could not control what lies other websites tell. They can have a button saying “Sign in with GitHub”but totally not signing in with GitHub. That said GitHub should have banned that website for lying and abusing instead of OP.
- easyorgmode 4y ago
  This proves the point that these third party "Sign in with" buttons are really dangerous. It makes a possibly dodgy website look more secure and legit by using a well known provider like Github for the login process. In addition, it potentially exposes data from that well known provider, which is often sensitive data, as in the case of Github.
vel0city 4y ago
When I double click on free_cookies.exe which I got from totallyawesomenotavirus.com I expect my computer to start giving me chocolate chip cookies. Or maybe I shouldn't just take everything at face value and pay attention to what I'm doing.
- scarface74 4y ago
  And how has that worked out for the last 40 years.

iforgotpassword 4y ago

I've always had at least one confirmation page where it stated what data would be shared with the 3rd party and what kind of access they get to my account.

yashap 4y ago
True, there’s often a “GitHub will have access to your email address” type confirmation in SSO flows, as that’s basically what SSO is (it’s GH telling a 3rd party “yup this is bob@example.com, feel free to log them into your site as bob@example.com”). However, what you won’t see in a standard SSO flow is anything along the lines of “GitHub will be able to star repositories on your behalf.” If you’re seeing those kind of messages, you aren’t doing a minimal SSO flow (just having GH vouch for your identity), you’re granting access to a 3rd party to do things with your GH account.

BoorishBears 4y ago

I was with you until the last two sentences. I'll honestly never get that point of view: it's an evolutionary disadvantage to not fall for these kinds of attacks. Our intelligence is largely predicated on how easily we can pattern match and filter out "excess" information. So OP being bombarded with a list of harmless permissions along with one deceptively dangerous one (deceptive because they wouldn't expect to lead to being pwn'd anyways, since it's stars) and granting is not being sloppy, it's being an intelligent person. Github is large enough to have UX experts who know this stuff, and at the very least if stars are grounds for being banned, they should be grouping it with dangerous permissions and using more confirmations. And even better... they should just rate limit starring! How often is someone going to star 500 of someone's repos legitimately that rate limiting would ruin everyone's day?

yashap 4y ago
FWIW, I agree GH shouldn’t have banned OP. But … I’m pretty sure they weren’t giving out access to control OP’s account through a standard SSO flow, as OP assumed. Massively more likely, OP just didn’t pay attention, and granted said access explicitly during an OAuth2 authorization code flow.
- BoorishBears 4y ago
  My entire point is that they did explicitly grant the permissions and that if you see a dialog like this: https://i.stack.imgur.com/Iol8j.png https://i.stack.imgur.com/Iol8j.png And you're ready to hand over even the first 3 items there, you're not likely to assume or even notice that github stars about to get you knocked out of orbit. I know this is a place of hubris but it almost comes across as a strange lack of self-awareness that this many people actually think they'd have caught that.
sennight 4y ago
> ..is not being sloppy, it's being an intelligent person. No, that is being an intelligent ape reacting to a twitching bush by running up a tree on the chance that a predator is behind the bush. The tables have turned since then. Back then the analytical ape would have gotten eaten and not passed his genes on, but there is no longer a biological imperative to mindlessly react to things.

Aeolun 4y ago

Giving a website access to star repos through the API for my convenience is not anything I should be banned over though.

yashap 4y ago
That I do agree with.
gernb 4y ago
from github's pov you starred the repos. You signed up for a service the stars repos. it could have been starallthereposforme.com and you signing up a granting them permission to star repos is exactly what you wanted. So girhub is correctly assuming you wanted those repos starred. If you didn't want them starred you shouldn't have given the site permission to star
- tgsovlerkhgsel 4y ago
  GitHub should be able to tell that this was an abusive service doing it though. Legally they might be in the right, but punishing victims of social engineering further doesn't seem like a fair or smart business decision.
  - olabyne 4y ago
    yep, it is easy for them to know if the star was the user itselft OR a third party app through the API...
  - wikfwikf 4y ago
    But an 'abusive service' might still involve misconduct by the user in question. Suppose there is a service which allows you to watch free porn videos as long as you hand over permissions to star a bunch of repos using your account. Clearly, the service is abusive and should be banned. But isn't it also quite fair for Github to penalize the users? They knew they were handing over something of value when they authorized the access. Either they chose to exchange their genuine 'Github clout' for something they wanted, or their accounts are spammy in the first place (for example, if they created an account solely to access that service).

2Gkashmiri 4y ago

if i go with your argument, "what wrong did i commit" if i allowed an application a legitimate action of managing stars? how did i know beforehand the app was going to abuse this very action because there are other commenters saying that stars manage action is a legitimate, non-sinister action in itself so where was i sloppy?

yashap 4y ago
I agree you should not have been banned - I think GH was wrong there. You got taken advantage of, you weren’t being malicious. However, getting banned is pretty minor compared to the other bad things that can happen if you grant sketchy websites access to your accounts without reading what you’re granting.
dbt00 4y ago
I'm sorry you lost access to your github account, but let's be fair. This is not a legitimate application for managing your stars, this is a page that was committing fraud and probably requested access to your account in exchange for committing further fraud on your behalf. You were already logged in. Why did you log in again with github? Because it asked you to, and promised you more rewards if you did?
- machinawhite 4y ago
  > Why did you log in again with github? Sorry I'm somone else but I'd just go and assume it was because they are human, not a terminator, and their eyes do not have an integrated HUD talking with GitHub's backend with status indicators showing each currently authenticated account??? You want this kind of correctness you have to write software in Rust or something. "You're holding it wrong" lol
  - fknorangesite 4y ago
    It's a bog-standard oauth2 authentication flow. I'm positive GitHub showed OP the list of permissions that this sketchy third-party app was requesting, and OP granted those permissions. Yes, you are supposed to read the dialogs. OP really got got, and that sucks. But it's literally why that permissions checklist step - that they ignored - exists.

nailer 4y ago

> probably wasn’t actually a standard “sign in with GitHub”, minimal SSO flow, it was likely an OAuth2 authorization code flow This is accurate, but oauth2 is the standard sign in with GitHub. oauth is literally designed as an authorisation mechanism to allow people to do things on your behalf, the ability to authorise access was later repurposed into an authentication mechanism.

vintermann 4y ago

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.
- 4y ago

grumple 4y ago

Github does not separate starring. It falls under the public_repo scope, which is one of the fundamental scopes. Source: https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps#requested-scopes-and-granted-scopes https://docs.github.com/en/developers/apps/building-oauth-ap... "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."

masklinn 4y ago
FWIW under the new fine-grained permission model (used by github apps, and the fine-grained personal access tokens currently in beta) "starring" is its own account-level permission: https://docs.github.com/en/rest/overview/permissions-required-for-fine-grained-personal-access-tokens?apiVersion=2022-11-28#starring https://docs.github.com/en/rest/overview/permissions-require...

nullfield 4y ago

Maybe, just maybe, if companies like GitHub would read the fucking RFC’s for “OAuth is not for authentication” they’d get somewhere. We at least/even have OIDC for that now.