3 ms·

> 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 ru

> 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.
  - winkeltripel 4y ago
    > Also, it operates at a scale that makes such validation infeasible. It's a choice to be at such scale that github cannot validate 3rd party auth. Gothub should accept fault for these incidents if they are not going to validate their partners. It's the exact same as third party sellers shipping counterfeits on Amazon. Choosing to achieve massive scale leaves quality, validation, and consumer protection behind.
  - anon84873628 4y ago
    GitHub is Microsoft. And as a provider of developer tools, weird to see such apologism for their inability to structure oauth scopes correctly and provide effective unambiguous UX for user consent. Let alone banning the user instead of the client app...
- 9wzYQbTYsAIc 4y ago
  > And "caveat emptor" is not the threat model you can get away with on the web. Caveat emptor is not a threat model, it is a risk mitigation. It is arguably the only mitigation directly in the hands of the consumer. And that the modern phrase is from a 2000+ year old “dead language” should certainly speak to the longevity, utility, and effectiveness of that mitigation. > 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 thankfully there are standards and RFC’s that indicate best practices that recommend that these security risks be considered and mitigated edit: see Rich Authorization Requests <https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html> for the “work in progress”
  - vintermann 4y ago
    When you run a service on the web, it's not enough to protect yourself. You must protect your users to the best of your ability. Threats against your users must be part of your threat model. If not, you won't keep them. They will leave. And saying "caveat emptor" will be about as effective at preventing that as saying "wingardium leviosa".
    - 9wzYQbTYsAIc 4y ago
      > When you run a service on the web, it's not enough to protect yourself Nothing but agreement there. Can you identify a specific recommendation by the IETF or W3C that was ignored, in this case? > And saying "caveat emptor" will be about as effective at preventing that as saying "wingardium leviosa". I had to look up that apparent reference to Harry Potter, but I disagree. Educating your users about phishing risks, aka “caveat emptor” in this context, is explicitly a best practice for mitigating these kinds of security risks on the open web.
K0balt 4y ago
Did you see how apparently inoffensive the permission granting sign in is? It looks very similar to a standard login. It would be very easy for anyone, regardless of knowledge, to blow right by that. The lack of distinctive labeling as not a standard sign in operation is really irresponsible on the part of GitHub here.

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.
- winkeltripel 4y ago
  > Also, it operates at a scale that makes such validation infeasible. It's a choice to be at such scale that github cannot validate 3rd party auth. Gothub should accept fault for these incidents if they are not going to validate their partners. It's the exact same as third party sellers shipping counterfeits on Amazon. Choosing to achieve massive scale leaves quality, validation, and consumer protection behind.
- anon84873628 4y ago
  GitHub is Microsoft. And as a provider of developer tools, weird to see such apologism for their inability to structure oauth scopes correctly and provide effective unambiguous UX for user consent. Let alone banning the user instead of the client app...
9wzYQbTYsAIc 4y ago
> And "caveat emptor" is not the threat model you can get away with on the web. Caveat emptor is not a threat model, it is a risk mitigation. It is arguably the only mitigation directly in the hands of the consumer. And that the modern phrase is from a 2000+ year old “dead language” should certainly speak to the longevity, utility, and effectiveness of that mitigation. > 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 thankfully there are standards and RFC’s that indicate best practices that recommend that these security risks be considered and mitigated edit: see Rich Authorization Requests <https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html> for the “work in progress”
- vintermann 4y ago
  When you run a service on the web, it's not enough to protect yourself. You must protect your users to the best of your ability. Threats against your users must be part of your threat model. If not, you won't keep them. They will leave. And saying "caveat emptor" will be about as effective at preventing that as saying "wingardium leviosa".
  - 9wzYQbTYsAIc 4y ago
    > When you run a service on the web, it's not enough to protect yourself Nothing but agreement there. Can you identify a specific recommendation by the IETF or W3C that was ignored, in this case? > And saying "caveat emptor" will be about as effective at preventing that as saying "wingardium leviosa". I had to look up that apparent reference to Harry Potter, but I disagree. Educating your users about phishing risks, aka “caveat emptor” in this context, is explicitly a best practice for mitigating these kinds of security risks on the open web.

K0balt 4y ago

Did you see how apparently inoffensive the permission granting sign in is? It looks very similar to a standard login. It would be very easy for anyone, regardless of knowledge, to blow right by that. The lack of distinctive labeling as not a standard sign in operation is really irresponsible on the part of GitHub here.