Progressive Web Apps (PWAs) Phishing
mrd0x.com
mrd0x.com
As the commenter upthread conjectured, this is indeed perfectly isomorphic to fooling a user into loading and interacting with a faked web page. That's a real threat! But it's clearly not a new threat with PWAs and IMHO this article is mostly just spun clickbait. This isn't remotely a novel vulnerability.
If you look at the screenshot, it's a perfectly valid interpretation for a non tech-savvy user to interpret that as "realhealthysnacks is asking me to install a legitimate Microsoft application".
Now change the simplified example for a real one from a SaaS product login page with several "Login with ..." buttons, and one of them triggers this.
What... does that mean? A website with a malicious owner is illegitimate by definition. :)
But more to the point, this logic is circular. You're saying PWAs are subject to attack by malicious actors because their users can be attacked by websites controlled by malicious owners. Which is... true. But specious, and true of regular web pages and apps and every other kind of software.
I'm not seeing where you're getting anything novel here at all. If you let people run software written by other people you need some kind of protection against people being fooled by bad software. That is obviously a very hard problem with only imperfect solutions. But those solutions do exist, and that protection exists here in PWAs and needs to be evaded, in a form that is entirely analogous to the way you have to validate a web page you're looking at.
The situation is this: You go to some web store. You click "Sign In With Microsoft" (or Google, or Facebook, etc.). You expect the site to be able to know your Microsoft/Google/Facebook email address. You don't expect the site to be able to take over your entire Microsoft/Google/Facebook account.
So it's a site you trust enough to use, but you don't trust it enough to give it control over your other accounts. This phishing attack gives it control over your other accounts.
Most of the time, that requires a convincingly-looking URL to redirect from website A to the phishing page. (e.g. micr0softlogin.com)
This attack doesn't require that, it all stays in the website A which they user may find legitimate. (or it could be a legitimate one that has been compromised)
Another aspect of this is that PWAs have a helpful anti-phishing feature which actually displays a URL bar when you navigate to a different domain. Which is entirely twisted by this because by staying in website A that's exactly when the URL bar will be hidden, letting the attacker to place a fake one there.
But agreed that there are only imperfect solutions to this sort of thing.
One of those imperfect solutions is training users to always check the URL bar. PWAs let the attacker inject a fake URL bar AND hide the real URL bar.
microsoft.com is legitimate website. The owner of microsoft.com however get your browsing history, reboot your PC during weekends when your rendering is almost complete, put random adware on your PC without asking you, injects adware into various websites, i'm too lazy to list all the rest but you get the picture. Legitimate website with a malicious owner.
This isn't "clickbait". This author is a known security researcher. The word "new" or "novel" doesn't occur in the writeup. They are simply documenting how something works.
They've been writing about this type of thing for years now.
Perhaps the PWA forces an overlay of the real apex domain at the top or in a top corner?
For most PWAs, the title is simply the apex domain without the TLD with some kind of capitalization. There are a few slightly more complex cases, such as Google Maps (google.com/maps) and YouTube Music (music.youtube.com). Even in these cases, there is an obvious relationship between URL and title.
You could try the manifest data, (the data for the PWA app) tied more to the html and dns. Making it harder to impersonate other sites.
You could also go a more extreme route and have something like PWA app signing like other kinds of apps.
Using a browser-integrated password manager or passkey will usually prevent this attack, though.
I think that this is a fairly legitimate attack vector and it's sad because I really want to be able to hide the url bar in my PWAs through custom styling to make it look more like a real native app.
Also the thing about the URL won’t have much practical difference for the user. The reason is that a lot of the flows can redirect through different domains. For example, when I sign in with Google into a third party site, I often see a redirect through the YouTube domain.
So users are not expecting full fidelity to the domain.
However, as with every phishing attack, the user must ignore small (security related) hints.
But since the trick requires the user to go to a malicious website to install this app, it seems to me that the user might similarly be tricked into entering credentials on that website.
You would enter your credentials on something that (according to a url bar) is Facebook.com