10

An untrained end user who uses a mobile web browser is vulnerable to phishing and can't easily verify the the authenticity (or security) of a website among other issues. Also, it is very easy to prevent even a knowledgeable user from detecting MITM by hiding the HTTPS icon, replacing it with a favicon, or many other tricks since most many browsers completely hide the entire URL.

  1. Is a native application (perhaps with certificate/root cert validation) really the only way to achieve reliable, secure interaction with my back end services over HTTPS?

  2. Should I train my end users to not use a web browser, and use an "app" that is hard-coded to my URLs and optionally does additional certificate validation to reduce MITM risk?

  3. Should my web server go as far as detecting a mobile session, and prevent them from authenticating?

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • 1
    The mobile web browser can of course verify the authenticity as good as a "normal" one. The problem, as stated in the linked question, is that it may not show this information or let the site hide the real result. Of course that can be dangerous, but it's no "hackable" TLS/SSL. – ordag Mar 09 '12 at 16:22
  • And what makes you assume that the native app would be more secure? Often it's really just a way of "hiding" the browser. But overall, this would be a usability tradeoff - for some, it would be annoying, and for others unusable (e.g. are you going to have a native app for WP7?). As usual, it depends on the usual tradeoffs, e.g. for a bank this might make sense, but otherwise not (perhaps). – AviD Mar 13 '12 at 11:42
  • Besides, if you're really worried about this, why dont you just get a more secure mobile OS...? ;) – AviD Mar 13 '12 at 11:45
  • @AviD Do any "secure mobile OS's" exist? ;) ... also I'd like people to think of this question not regarding their own personal device, but from a business who can't control what devices people use, but knows that fake "browser" pages have been created (akin to ebay hacks). Aside from spoofing a rogue app+icon, a dedicated app would ensure the user is connecting to my site and not a phishing site. In addition it could validate the SSL certificate (or chain) as well. Something a browser won't do as well. ([See DigiNotar CA hack](http://security.stackexchange.com/q/2268/396)) – makerofthings7 Mar 13 '12 at 13:04
  • @makerofthings7 - Windows Phone 8, Windows Phone 7, iOS, and Android are all secure. In all cases the certificate and security status ( i.e. https connection or http connection ) information is displayed to the user. There are many cases where a banking application was vulerable to Man in the Middle attacks because of a flaw in the program itself. – Ramhound Feb 06 '13 at 13:05
  • A website can act like a native app using javascript and the browser, so nope. – ChocolateOverflow Jun 29 '20 at 07:58

4 Answers4

3

A web app and a web browser both have the same problem- an attacker can subvert the data they send or receive.

I would not encourage forcing a user to use an app over a browser- I would take it the wrong way of a company tried to force me. I might not want to install an app, as part of my security policy.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
  • ...what if the App clearly displayed the connection security? No fudging the URL is possible since it's hard-coded in the app. – makerofthings7 Mar 09 '12 at 22:23
  • I'm just emphasizing web apps since the browser can't see the URL clearly, and also the HTTPS status. I suppose in theory an app could use a client certificate (or additional encryption/CA Thumbprint checks) to ensure a safe connection – makerofthings7 Mar 09 '12 at 22:26
3

No. there is absolutely no difference.

At the end of the day you need to expose the ablity for clients to query information and make state chagnes. The problems that an API that a mobile device uses is very similar to the problems that an API that a javascript/html browser uses.

You still have problems like insecure direct object reference and sql injection.

rook
  • 46,916
  • 10
  • 92
  • 181
1

If you are a web site developer looking to protect your users from phishing, there are some steps you can take.

The key step I would take is don't rely upon passwords. You can use, for instance, a secure persistent cookie, sent over HTTPS, to authenticate the user. SSL client cert authentication would be another example of a user authentication method that is resistant to phishing attacks because it does not rely upon passwords. If you prefer, you can additionally request a password, but you should not rely solely upon a password entered into a mobile browser. There are two reasons for this: first, passwords are phishable, and as you say, the decks are stacked against users; and second, entering passwords into a mobile device is a poor user experience, given the state of most soft keyboards.

If you are a user looking to protect yourself, there is a different set of defenses available to you, such as using a dedicated app, launching the site from a bookmark, and that sort of thing. However, it is probably not feasible for website operators to expect to train all of their users to follow those steps.

D.W.
  • 98,420
  • 30
  • 267
  • 572
0

Yes, in a way, as a mobile can protect user sessions a bit more.

i.e.

  • No risk of phishing, as the mobile app only connects to its own API.
  • No cross-domain issues (CSRF, SSL attacks that require cross-domain requests like POODLE or BREACH).
  • If web controls are not used at all, no risk of XSS.
  • No Same Origin Policy issues with cookies (as HTTPS and HTTP cookies have the same origin), so cookies can't be poisoned by a MITM over plain HTTP (see this answer for more details).

The downside is the user has to trust you a bit more as they are installing a fully executable application on their device rather than something as sandboxed as a web session.

Community
  • 1
SilverlightFox
  • 33,408
  • 6
  • 67
  • 178