3 ms·

This is probably a bad security practice. When you click mybank.com, you don't want it silently redirecting to mybank.phishing.com. Links are explicit. You cou

by mankyd 5y ago

This is probably a bad security practice. When you click mybank.com, you don't want it silently redirecting to mybank.phishing.com. Links are explicit. You could always right up a trivial browser extension to do this on a case by case basis if you really desire.

mqus 5y ago
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
- mschuster91 5y ago
  > 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.
  - mqus 5y ago
    > There's nothing preventing a bad actor from copying the existing banking app and attaching a backdoor Getting an app to a user is imho FAR more difficult than showing him a website. (Fake ones even more so) How easily would you click on a link if I would provide it here vs How easily would you install a new program if I provided you a link here?
- CobsterLock 5y ago
  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.
  - danShumway 5y ago
    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.
    - ivanmontillam 5y ago
      Yes, but phones do have curated mobile app stores. Not the case with desktop computers, so it's dangerous.
      - danShumway 5y ago
        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? See https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler/Web-based_protocol_handlers https://developer.mozilla.org/en-US/docs/Web/API/Navigator/r...
        ivanmontillam 5y ago
        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.
        notriddle 5y ago
        > Hrm. Mac computers allow this with Slack. 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.

by mankyd 5y ago

mqus 5y ago

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

mschuster91 5y ago
> 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.
- mqus 5y ago
  > There's nothing preventing a bad actor from copying the existing banking app and attaching a backdoor Getting an app to a user is imho FAR more difficult than showing him a website. (Fake ones even more so) How easily would you click on a link if I would provide it here vs How easily would you install a new program if I provided you a link here?
CobsterLock 5y ago
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.
- danShumway 5y ago
  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.
  - ivanmontillam 5y ago
    Yes, but phones do have curated mobile app stores. Not the case with desktop computers, so it's dangerous.
    - danShumway 5y ago
      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? See https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler/Web-based_protocol_handlers https://developer.mozilla.org/en-US/docs/Web/API/Navigator/r...
      - ivanmontillam 5y ago
        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.
      - notriddle 5y ago
        > Hrm. Mac computers allow this with Slack. 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.