I place a lot of the blame for the success of this phishing attack with how the Chrome Web Store, and Google more broadly, is operated.
If you train your developers that you are willing to unilaterally and suddenly disable published extensions for editorial, non-security-related reasons (which the article's screenshots indicate was the excuse) - and that it's completely expected that such an action might occur on Christmas, and a well-founded one based on history - that's a poor developer experience.
And on top of that, if Google has the ability for an OAuth app to get extension upload permissions, without screaming as part of the OAuth authorization process "This will provide third parties unrelated to Google the ability to update extensions. Be sure that this is intended." - then that is bad OAuth design that exacerbates the above problem.
If you're designing a software supply chain, and you have a choice to allow updates over API, the onus is on you to either ensure your authentication UX causes spear phishing targets to think twice before they let themselves get pwned. And I get that there are certainly different teams working on the OAuth frontend and the Chrome Web Store backend - but if the backend team doesn't have the willpower and/or ability to have red-teamed this exact spear phishing situation, and have escalated their security concerns to the frontend team, that's an organizational failure.
Installed programs are the weakest link in the security of an OS like windows - should users not use programs? Users are just as likely to download a sketchy program as a sketchy extension, is that not even more severe of a risk?
User education and better marketplace policing are the solution, not silly blanket statements like that.
[+] [-] btown|1 year ago|reply
If you train your developers that you are willing to unilaterally and suddenly disable published extensions for editorial, non-security-related reasons (which the article's screenshots indicate was the excuse) - and that it's completely expected that such an action might occur on Christmas, and a well-founded one based on history - that's a poor developer experience.
And on top of that, if Google has the ability for an OAuth app to get extension upload permissions, without screaming as part of the OAuth authorization process "This will provide third parties unrelated to Google the ability to update extensions. Be sure that this is intended." - then that is bad OAuth design that exacerbates the above problem.
If you're designing a software supply chain, and you have a choice to allow updates over API, the onus is on you to either ensure your authentication UX causes spear phishing targets to think twice before they let themselves get pwned. And I get that there are certainly different teams working on the OAuth frontend and the Chrome Web Store backend - but if the backend team doesn't have the willpower and/or ability to have red-teamed this exact spear phishing situation, and have escalated their security concerns to the frontend team, that's an organizational failure.
[+] [-] mentalgear|1 year ago|reply
[+] [-] karmakaze|1 year ago|reply
> GraphQL Network Inspector
[+] [-] mrayycombi|1 year ago|reply
Amazing.
[+] [-] beardyw|1 year ago|reply
Which is why you shouldn't use them.
[+] [-] multimoon|1 year ago|reply
Installed programs are the weakest link in the security of an OS like windows - should users not use programs? Users are just as likely to download a sketchy program as a sketchy extension, is that not even more severe of a risk?
User education and better marketplace policing are the solution, not silly blanket statements like that.
[+] [-] devmate|1 year ago|reply
What do you think - what is more risky: a) manual update (and risk of 0day attacks) or b) auto-update (and risk supply-chain attacks)?
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] unknown|1 year ago|reply
[deleted]