[HN Gopher] Progressive Web Apps (PWAs) Phishing
___________________________________________________________________
Progressive Web Apps (PWAs) Phishing
Author : kolp
Score : 58 points
Date : 2024-06-11 17:44 UTC (2 days ago)
(HTM) web link (mrd0x.com)
(TXT) w3m dump (mrd0x.com)
| difosfor wrote:
| 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..
| kristiandupont wrote:
| 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.
| ghayes wrote:
| Ideally, the best defense here is a FIDO-compliant 2FA or
| Passkey that would properly not send a valid credential for a
| different domain.
| ffpip wrote:
| 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
| whartung wrote:
| 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.
| _factor wrote:
| This is hardly a problem if you have Google logged in already.
| You username doesn't pop up as an option? Ask questions.
| theteapot wrote:
| What's the difference between this and just having a button on
| your website that redirects to a spoof microsoft login page?
| codetrotter wrote:
| Because this one makes it look like there's a url bar with a
| Microsoft domain
| ajross wrote:
| 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.
| felipc wrote:
| 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.
| ajross wrote:
| > 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.
| felipc wrote:
| 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.
| Habgdnv wrote:
| > 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.
| ffpip wrote:
| 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.
| josephcsible wrote:
| Being a PWA lets you hide the real URL bar.
| erikerikson wrote:
| Does this fool tools like 1Password?
| phartenfeller wrote:
| 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!
| meiraleal wrote:
| 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.
| jeroenhd wrote:
| 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.
| toddmorey wrote:
| What makes this PWA specific rather than just "installable
| software"?
| toddmorey wrote:
| Ah, I'm thinking Windows maybe requires less permission to
| install a PWA?
| dzhiurgis wrote:
| This reminds me OAuth screens where you are not sure why your
| password manager doesn't work...
___________________________________________________________________
(page generated 2024-06-13 23:00 UTC)