Progressive Web Apps (PWAs) Phishing(mrd0x.com)
mrd0x.com
Progressive Web Apps (PWAs) Phishing
https://mrd0x.com/progressive-web-apps-pwa-phishing/
43 comments
What's the difference between this and just having a button on your website that redirects to a spoof microsoft login page?
Because this one makes it look like there’s a url bar with a Microsoft domain
No it doesn't. You need to fool the user into installing an app that loads from your own domain. Now that obviously isn't impossible, but it requires getting the user to ignore or be mislead by the clearly-displayed URL in the web page and/or installer UI.
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.
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.
Nope, it's much more insidious than that. The user is already on your website, which could be a legitimate website with a malicious owner.
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.
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.
> legitimate website with a malicious owner.
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.
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.
>legitimate website with a malicious owner.
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.
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.
I don't understand the answers to your "what is a legitimate website with a malicious owner" question, but I kinda see this as the same concern as downloading a phone app that requests an OAuth login via a native webview. You can't always see the true URL of that login page. But it comes back to what I think is your main point -- you've already downloaded something malicious from the get-go. But I guess there's some damage control if you can spot a fake login page and remove the install.
Yeah it still needs a malicious person to run the attack of course, but it's a different attack vector. Phishing consists of making the user believe they are in a different website than they are at.
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.
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.
> That is obviously a very hard problem with only imperfect solutions.
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.
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.
> What... does that mean?
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.
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.
i like your reasoning
> 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.
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.
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.
I'm not a security pro, but the claim about "spun clickbait" doesn't hold for me. I thought it was new to me, and an attack possibility that I hadn't considered before reading. I do think I "validate" sites pretty well before doing any serious things there (logins, transactions, etc).
You're correct that it's not clickbait. This author is a known security researcher who specializes in this type of thing. It's just another type of attack that they've writing about.
A PWA can have the familiar "Sign in with google" button now, which pops up a similar page as shown in the article, but with accounts.google.com in the fake URL bar.
Being a PWA lets you hide the real URL bar.
How could this be stopped? Blocking images or rendering that mimics a real URL bar would be challenging.
Perhaps the PWA forces an overlay of the real apex domain at the top or in a top corner?
Perhaps the PWA forces an overlay of the real apex domain at the top or in a top corner?
When installing a PWA, check whether URL and title match and warn the the user otherwise.
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.
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.
I think that it’s pretty hard to stop with the current state of PWA installation.
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.
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.
That's indeed a tricky one. Even tho I work with PWAs I could see myself being misled by this with a github credential. Good remind to only connect third party services with access tokens.
Many applications will obtain such a token through an OAuth flow of some kind.
Using a browser-integrated password manager or passkey will usually prevent this attack, though.
Using a browser-integrated password manager or passkey will usually prevent this attack, though.
Nah, it won't because it happens all the time that my password manager doesn't recognize the current url because the auth signin flow had so many weird urls in it that I had to save the url manually and now it's not the right url so I copy out the password manually instead of autofilling it. This was actually the case for my Google account which I created through gmail but then my gmail password wasn't using the right url for all the other google services. Now that I think about it, this was also the case for my Microsoft account that I got a long time ago through hotmail.
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.
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.
Your right about simple password managers, but passkeys do prevent this flaw.
Surely you could pull this trick just by using full screen mode couldn't you? And all that requires is any user interaction.
Does this fool tools like 1Password?
No as the page's URL is still not the real login URL. The shown address bar is just a fake with styled website content if I understood it correctly. Really smart!
I don’t things is much worse than OAuth itself. You just have to make a login with Google/Facebook/X button.
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.
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.
Yes, but I found it a little earlier. ( 4 years ago)
https://github.com/0x1235/PWA_Spoofing_PoC
[deleted]
What makes this PWA specific rather than just “installable software”?
PWAs are generally considered safe to install because they are just a website (running in a sandbox) plus some fancy desktop integration. Normal software you install doesn't run in a sandbox and has much more capabilities.
However, as with every phishing attack, the user must ignore small (security related) hints.
However, as with every phishing attack, the user must ignore small (security related) hints.
Ah, I’m thinking Windows maybe requires less permission to install a PWA?
It's "installed" through the browser, and it runs in the browser. So a PWA is just a browser app that maybe runs in a window with no browser chrome so it feels more native.
I think you could do the same in native apps? So yeah, not much you can do about uncareful users. I suppose you could use something like an App store to provide some checks and a little more security. But then you're likely to run into monopolies again..
I guess the argument would be that a screened app store would block such a malicious app.
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.
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.
No, the malicious website would have a "Sign in with Facebook".
You would enter your credentials on something that (according to a url bar) is Facebook.com
You would enter your credentials on something that (according to a url bar) is Facebook.com
Ideally, the best defense here is a FIDO-compliant 2FA or Passkey that would properly not send a valid credential for a different domain.
This looks a lot like a Oauth request, where you are redirected to sign-in. You check the URL and enter the creds, with the assumption that you are using "Sign in with Microsoft" to login to the site since this is how that login flow works
That’s the thing. For a desktop app, they can pop up a chromeless web view with the Oauth login page. You can’t vet the authenticity at all.
[deleted]
This reminds me OAuth screens where you are not sure why your password manager doesn’t work…