I think what brnt means is that he wants some links to open in an entirely different app and not in a browser. I don't see how phishing is applicable in this case. In fact it may be a good measure against it since you quickly see that it does not open in your usual app
I think mankyd knew that. I'm thinking the exploit would be installing a bad app that enforces redirects for mybank.com, youbank.com, usabank.com, ukbank.com, allbanks.com to their malicious app. Then the app just knows how to pretend to be the login screen for all these apps and bam you get a whole ton of passwords. The key thing would be for the app not to show the url of their malicious site.
Phones already do this though, don't they? I think Android at least allows redirecting links to apps, and I'm pretty sure Mac does as well.
Is there a bigger threat model people are worried about with extending the app schema to include normal URLs as well? Or do you just think the problem would be worse if the scope was broader?
Trying to figure out where people are drawing the line on this.
On iOS and macOS (I can't speak to Android but I'm fairly sure it's a similar mechanism), you're required to prove that a domain and app are linked before allowing URLs to open in your app. You do this by hosting a JSON file on your website that points to your app and specifies which kind of URLs should be redirected. E.g. see https://apple.com/.well-known/apple-app-site-association for how Apple.com does it.
This prevents malicious third-parties from opening bank.com in their own app, but of course it also prevents useful things like using a custom YouTube app.
Hrm. Mac computers allow this with Slack. The installed version can intercept links to messages in the browser and open them in the app instead of the website. So I don't think it's just phones doing this today.
And I guess Slack is signed on Mac via Gatekeeper, but it's not distributed through an app store.
I don't run Windows and I won't install Slack natively on my Linux boxes, so I can't check the other platforms. But I would be a little surprised if the same doesn't work on them. This is basically how mailto links work today, right?
On Linux, Slack installs a custom protocol handler, and includes a hidden iframe with the slack://RANDOMSTRING/magic-login/LONGRANDOMSTRING URL. I assume it's the same on Mac.
In this case mailto:// doesn't try to impersonate any app, but if it were to be done (for example) "skype://" I could install another app that overrides the current app protocol, and mislead the user and catch privileged data intended for the original app.
But of course, technically it's the exact same thing, it's just a layer above. So you have a point.
> In fact it may be a good measure against it since you quickly see that it does not open in your usual app
There's nothing preventing a bad actor from copying the existing banking app and attaching a backdoor, assuming local code execution capability - either re-sign it with a local codesign certificate or use runtime code injection/linker overrides.
A web app has always the URL bar and the banking site can rely on HSTS to prevent man-in-the-middle attacks.
