16

These days I see a lot of browser wrappers in software. For example:

  • when you purchase something in the Steam desktop application and use PayPal, you enter your PayPal security details in a browser frame provided by Steam. log into paypal in the Steam Desktop App
  • when you log in on the Figma Desktop App with Google, you enter your Google credentials in a browser provided by the Figma Desktop App Figma Desktop App login with Google

Like trusting my browser, I trust these applications to not mess with the website or frame in any way. For example injecting javascript, showing a phishing page, showing HTTPS when there's no secure connection.

What I'm worried about is users getting used to this kind of presentation. They're exposure to these kinds of browser wrappers might give them the idea that it's OK to trust these kinds of wrappers and freely enter any kind of information there. Not knowing that hijacked or malicious applications could trick users into giving up their details.

Question: am I missing something here or is this a trend that needs to be put to halt? (and instead just serve webpages in the users' preferred web browser)

luttje
  • 163
  • 4
  • 3
    The word "frames" in the city ntext of a browser typically refers to a frameset. Maybe you should call these browser wrappers, as they are external applications wrapping a browser. – Daisetsu Nov 08 '18 at 19:23
  • 1
    The trend to use a browser supposedly makes it more secure as the developer finds it more difficult to intercept data. The developer also does not need to handle the secure communication of data. Although, as you have pointed out a malicious program/app could still intercept data through js etc. so in actual fact it makes no difference to the end-result security, but it does optimise development. – Benjamin Goodacre Nov 09 '18 at 03:52
  • 1
    Importantly, this also affects `WKWebView` or `UIWebView` on iOS and `WebView` on Android – which are very common and used in many mobile applications. – caw Nov 10 '18 at 23:31
  • 1
    Sure, as a user, it’s always safer *not* to enter your credentials for service B in an application controlled by service A if you don’t fully trust service A. If service A’s application delegates authentication to your trusted desktop or mobile browser instead, where you can see the browser interface/chrome (e.g. the URL bar) and know which pieces you can trust (e.g. the displayed URL), that’s safer. But you cannot prevent developers from offering authentication to third-party services in browser wrappers. As long as their users accept it, it will continue. And in most cases, nothing happens. – caw Nov 10 '18 at 23:36
  • Thank you all above! I have corrected "frames" to "wrappers", thanks for that heads-up. Also from what I can tell we're aware it's potentially a problem, but are trusting the users to make the right choices. – luttje Nov 13 '18 at 17:18
  • Seems to me that so many web developers learned wen stuff it became the 1 size fits all fix for everything. On a related note, why does Openwhisper's Signal use a modified web browser for its desktop client? It's not alone, Threema decided to have a web app for it's pseudo-desktop program. – YetAnotherRandomUser Dec 03 '18 at 18:37
  • I think there need to be a more concrete distinction of trust here. You may trust the developer of these software in terms of they will not deliberately be malicious (you shouldn't install their app in the first place if this is the case); however you may not necessarily trust that the in-app browser has been correctly implemented to avoid common security pitfalls. For example, the developer may have set the in-app browser to silently accept invalid SSL certificate, or hide the URL bar to make the window looks cleaner, or they may use an outdated version with vulnerability, etc. – Lie Ryan Jan 09 '19 at 12:39

3 Answers3

3

Web wrappers within an app has become quite common among applications and is not going to change anytime soon. The following measures will be helpful for securing the account used here

  1. Login without password - For example, Google allows you to login using your phone, Microsoft allows you to authenticate from it's authenticator app. This will prevent anyone tracking your password.
  2. Use Two Factor Authentication - Even if the entered password is compromised your account will be safe.
  3. Don't reuse password of this account anywhere else.
  4. Change password frequently (at-least once in six months).

is this a trend that needs to be put to halt?

While the wrapper popup brings in some nice user experience, there are quite some alarming things such as hiding the location bar. Developers really need to stop hiding URL in authentication prompts. How am I supposed to know that I am on the right site.

Response to comments

but that isn't any different from any web browser.

You cannot hide the URL bar in modern browser popups.[1]

References

  1. StackOverflow - Hiding address bar in browser
Kolappan N
  • 2,662
  • 14
  • 26
  • 3
    Note that the Steam example does show the URL, as well as indicating HTTPS/HTTP status. You are still trusting the application to display this and not something else - but that isn't any different from any web browser. – razethestray Dec 04 '18 at 14:38
0

To answer your question, one need to know how this is implemented...

Let's think in Steam-way: how would i implement this kind of authentication in a desktop, probably C/C++/Java app ? For Google account authentication, i will rely on google's recommendations. After google it a bit, it looks like this is the official way to authenticate using Google for C++ (so, i guess, for desktop app). I guess that the same kind of SDK is available for other authentication providers (Facebook, ...).

The underlying internals are now in this authentication provider hands: if they felt comfortable with this mechanism, then i guess you should too. If tomorrow, this way (aka wrapper browser) become a real threat, then they will probably change implementation to something else.

The real threat, in fact, is that the application you mentioned is a native application that can access low-level windows drawing API. With that capabilities, it becomes easy to mimic a web-browser and make user feel they are using a safe, https protected, chrome instance.

So yeah, in my opinion, this is clearly a practice that should not be encouraged...

Usually, this kind of application offers the possibility to create a dedicated account on their platform, this is, in my opinion, the better option.

binarym
  • 744
  • 4
  • 8
0

From technical point of view, there is also risk of the wrapped-browsers not receiving [timely] patches. When the developers bundle the browser engine to their application, then it is up to authors of each to push its updates.

It is bad that wrapped-browsers are actively pushed by OAuth2.

user185953
  • 80
  • 10
  • OAuth2 actually discourages this, and recommends that the native browser is used. – Geir Emblemsvag Jan 09 '19 at 05:24
  • I don't think there is any "native browser" guaranteed to be available on Linux. Therefore I expect out-of-repository software to be very inclined to bundle the browser despite this discouragement. – user185953 Jan 09 '19 at 10:31
  • @user185953: While there is no native-browser guaranteed to be available (why would you need a graphical browser in a distro intended for a router, for example), most of the mainstream desktop environments would have xdg-open which would do the job in most situations. An out-of-repository software can include the xdg-utils scripts as part of the software if it's worried about unusual systems that might have a suitable browser but don't have xdg-utils installed. – Lie Ryan Jan 09 '19 at 12:47