On the Usability (In)Security of In-App Browsing Interfaces in Mobile Apps

Nowadays, mobile applications (or apps) are heavily used in our daily life. Although most app functionalities are self-contained, it is not uncommon for users to open (external) web URLs in their app UIs (user interfaces). For example, a user may need to open a URL sent from her friends in a chat app like Whatsapp or WeChat, or need to open a URL embedded in an email when using Gmail. To satisfy such URL opening requirements in non-browser apps, one could offload the task to the system built-in browser apps. While this is simple for developers, it hurts user-friendliness due to the potential constant switching from the subject app to a system browser app. As a result, many high-profile apps choose to provide their own in-app browsing interfaces, or IABIs, for a seamless user experience.

However, if not designed or customized well, IABIs could introduce serious usability security issues. The major reason is that IABIs are typically simplified implementations of browsing interfaces lacking security indicators as opposed to “full-service” and standalone browsers with well-thought usability security designs. For example, an IABI may not display the full URL domain name or simply miss the HTTP(S) indicator. Motivated by this intuition, we conduct the first empirical study in this paper on the usability (in)security of in-app browsing interfaces in both Android and iOS apps. To this end, we collect and analyze a dataset of 25 high-profile mobile apps that contain IABIs, such as WeChat, Twitter, Gmail, LinkedIn, and Reddit. To make our results representative, these apps are selected from five common app categories, including Chat, Social, Mail, Business, and News.

Atop this dataset, we perform a systematic analysis that comprises eight carefully designed security tests (T1$\sim$T8 in three categories) and covers the entire course of interacting with an in-app web page in IABIs including page opening, displaying, and navigating. First, before a user opens a URL, we test whether the subject app provides sufficient URL information to enable end users to make informed decisions on opening the URL in a trustworthy manner (T1). Second, after the web page is loaded, we test whether the IABI provides enough security indicators for end users to validate the trustworthiness of the displayed page. This includes whether the URL itself (T2), an HTTPS (secure) indicator (T3), and an HTTP (insecure) warning (T4) are displayed in the title/address bar, whether a security alert is prompted for URLs with TLS errors (T5), and whether IABIs could defend against phishing URLs with a fake HTTPS lock icon (T6) and a long sub-domain name (T7). Third, during navigation of the web page, we test whether IABI could give a specific warning if the browsed page asks users to input passwords in a (potentially phishing) login form (T8).

Although our analysis focused on the apps’ performance rather than a study with direct end users, our cross-platform analysis results show the following major security findings:

• •

  About 30% of the tested apps do NOT display the complete URL, thus fail to provide enough information for a user to trustfully open an URL. Most of these apps omit the scheme (HTTP or HTTPS), while two apps (Weibo and Quora) completely hide the URL. Another 30% of the apps, despite outputting the full URL, display additional favicon or title information, which enables attackers to craft a fake favicon/title to mislead users.

• •

  Nearly all custom IABIs have various problems in providing sufficient indicators to faithfully display an in-app page to users, whereas ten IABIs that are based on Chrome Custom Tabs or SFSafariViewController are generally secure. Specifically, among the 15 apps implementing their own IABIs, over half do not display the domain name in the address bar, and nearly none provide HTTP(S) indicators, which makes them fail to defeat phishing with a lock emoji or a long subdomain.

• •

  Only a few IABIs, from the QQ, and QQ Mail apps, give specific warnings to remind users of dangerous operations (e.g., password inputting) during navigating a login page.

To understand developers’ reaction to our findings and to potentially provide our recommendations on fixing severe IABI issues, we issued security reports to all affected apps (details in Section 5). Most developers acknowledged our findings and agreed with our assessment. In particular, Instagram had fixed its issues as we reported and LinkedIn would patch it in its future versions. However, we also found that developers’ willingness and readiness to fix usability security issues are rather low compared to fixing technical vulnerabilities. Specifically, they refused to recognize them as vulnerabilities and were not willing to patch or improve their risky IABIs. Nevertheless, to help mitigate risky IABIs and guide future designs, we propose a set of secure IABI design principles in Section 6.

To sum up, we make the following contributions in this paper:

• •

  (Problem and analysis in §2-§3) We summarized the attack surfaces on interacting with an IABI and performed a systematic analysis with eight security tests.

• •

  (Measurement results in §4) We obtained cross-platform analysis results and their three major security findings by extensively testing 25 high-profile mobile apps.

• •

  (Reporting and defense in §5-§6) We reported our findings to affected vendors and analyzed their responses. We further proposed a set of IABI design principles.

When we are using mobile apps to, e.g., chat with friends, read posts on social platforms, or read emails, we often need to open a URL link. In order to provide a “one-stop” service to keep users within the app interface without the need of switching to a web browser, many apps have implemented their own in-app browsing interfaces (IABIs) which typically use the underlying browsing engines to load the web content.

Figure 1 shows a typical process of opening a URL in an IABI. Sometimes the IABI may also contain an address bar to display the information related to the web page. Moreover, as shown in Figure 2, apps have three ways to handle an URL request when a user clicks the URL. First, some apps choose to jump out of the app and open a browser app to display the web page. This situation is out of the scope of our paper because they do not contain in-app browsing interfaces. The second way is to customize a browsing interface based on the Chrome Custom Tabs (CCT) (CCT, 2021a) and SFSafariViewController (SF) (SFS, 2021) libraries. The third way is to create their own IABIs, which display the web page in the form of WebView (for Android) (Web, 2021) or UIWebView (for iOS) (UIW, 2021) instances. Next, we explain the relevant terms in more details.

IABI (in-app browsing interface) and its address bar. We refer to the UI design of the entire screen when a mobile app opens a web page as the In-App Browsing Interface (IABI). In this paper, we mainly focus on the usability problems of IABIs’ address bars.

Underlying browsing engines. The implementation of IABIs typically uses one of the following browsing engines:

• •

  Chrome Custom Tabs (CCT in Android) (CCT, 2021a; Steiner, 2018)

• •

  SFSafariViewController (SF in iOS) (SFS, 2021; Steiner, 2018)

• •

  WebView (in Android) (Web, 2021; Luo et al., 2011)

• •

  UIWebView (in iOS) (UIW, 2021; Wu and Chang, 2015) and

• •

  Custom browser engines implemented in native code (Wu and Chang, 2014).

Chrome Custom Tabs and SFSafariViewController. CCT is supported by Chrome, which is a web browser developed by Google. A mobile app can send a special intent to Chrome to launch a CCT to open websites without implementing a built-in browser engine by themselves, assuming that Chrome is installed on the smartphone. Chrome also provides well-encapsulated APIs for developers to make some limited browsing UI customization, such as color and animation. Similarly, iOS has SF supported by Safari for developers to incorporate into their apps easily.

WebView and UIWebView. Although CCT and SF provide convenient ways for a developer to implement IABI, one could choose, instead, to use lower-level display engines WebView and UIWebView (or even custom engines in native code (Wu and Chang, 2014)) for more comprehensive control over the UI. They allow developers to monitor specific events (e.g., loading and navigating) upon triggering of which developers can gather event information and make corresponding responses. The lower-level implementation of this design provides developers with very flexible control of the UI, which also implies more opportunities for design mistakes.

To reveal the usability security issues of IABIs in real-world applications, we analyze the IABIs in three phases corresponding to opening, displaying, and navigating a web page; see Figure 2. We design detailed security tests (T1 $\sim$ T8) to reveal security properties of the design of IABIs in real-world applications. URLs tested include those provided by https://badssl.com/ and homepages of Google and Facebook.

1. (1)

   https://badssl.com

2. (2)

   http://http.badssl.com

3. (3)

   https://expired.badssl.com

4. (4)

   https://wrong.host.badssl.com

5. (5)

   https://self-signed.badssl.com

6. (6)

   http://lock-title.badssl.com

7. (7)

   https://long-extended-subdomain-name-containing-m any-letters-and-dashes.badssl.com

8. (8)

   http://http-login.badssl.com

9. (9)

   https://google.com

10. (10)

    https://m.facebook.com/login/

In this section, we will explain the details of our security tests T1 $\sim$ T8 and then describe in detail how the individual tests are performed in each stage.

We begin this section with an overview of the test apps used in our analysis (Section 4.1). Section 4.2, 4.3, and 4.4 cover our analysis results on IABIs handling of URLs before web page opening, during web page opening, and during web page navigation, respectively.

To understand developers’ reaction on our findings and to potentially provide our recommendations on fixing severe IABI issues, we issued security reports to all affected apps including WeChat, FB Messenger, QQ, Snapchat, Instagram (fixed as we reported), Weibo, 163 Mail, QQ Mail, Alipay, LinkedIn, Toutiao, and Baidu, through their bug bounty programs or security contact emails³³3Apps using CCT/SF are generally secure; so we skip them. We failed to locate any feedback channel for KakaoTalk and Zhihu and therefore have to skip them as well.. Most of the apps acknowledged our findings and agreed with our assessment, but refused to recognize them as vulnerabilities, i.e., they consider the reported issues out of the scope of their bug bounty programs. By analyzing their responses in detail as follows, we find that developers’ willingness and readiness to fix usability security issues are rather low compared to fixing technical vulnerabilities, which is a puzzle in usability security research.

Facebook’s response. While the Facebook app performs well in nearly all the tests, the other two apps from the same company, namely FB Messenger and Instagram, did not use the same IABI design and failed in our tests T3$\sim$T4 and T6$\sim$T8 (see §4). When we prepared the security reports for these two apps on 4 February 2021, we found that the latest version of Instagram had changed its IABI design to display a lock icon and an exclamation mark to indicate the HTTPS and HTTP pages, respectively. This suggests that they also noticed this problem (before our reporting) and made an improvement. Therefore, we focus on the response to our reports to FB Messenger.

There are two key points in the response given by the Facebook security team. First, they appreciated our report but said that our report does not qualify for their bug bounty program due to the social engineering nature of our reported attacks. Second, they already have a URL detection system called Linkshim, which could detect potentially malicious URLs and thus defend against IABI attacks. While we agree that the reported IABI usability issues would not cause the same security consequences as in the technical WebView vulnerabilities (e.g., (Luo et al., 2011; Wu and Chang, 2014, 2015; Li et al., 2017a; Yang et al., 2019)), the usability weaknesses in FB Messenger’s IABIs we demonstrated in §4 definitely give attackers ample rooms to successfully launch phishing attacks. Moreover, it is a puzzle to see that different apps developed by the same company make vastly different security decisions for seemingly the same component.

Snapchat’s response. Compared with Facebook, the security team of Snapchat is more concerned on IABIs’ usability security issues with the following response (despite that a priority fix would not be issued as similar to FB Messenger): “While this attack scenario is quite interesting, we would consider this to be more of a defense-in-depth issue, rather than a discrete security vulnerability in Snapchat itself. Per our program rules, we generally don’t accept issues pertaining to ‘Reports solely indicating a lack of a possible security defense’. While we appreciate your suggestions here, we don’t feel that this poses a severe enough risk to warrant a priority fix, and as such we’ll be closing this report as Informative. We do appreciate your efforts here, and we hope you’ll continue reporting security issues to us in the future.”

LinkedIn’s response. Compared to Facebook and Snapchat, the response from LinkedIn’s security team is more positive. Specifically, they consider patching it in the future versions of the LinkedIn app: “Thank you for your detailed email and report, we appreciate it. We regularly review incoming reports to identify opportunities to improve our member experience and their safe interactions on the platform. We have taken note of these items and included it for consideration in our future roadmaps. Once again, we appreciate the detail and effort that went into this research & report.”

Some Chinese IT companies’ responses. We also received responses from a few large Chinese IT companies, including Tencent (developing QQ, WeChat, and QQ Mail apps), Alibaba (developing Alipay), ByteDance (developing Toutiao), Sina (developing Weibo), NetEase (developing 163 Mail), and Baidu. Most of them did not take our security reports seriously — either indicating that it was a known problem (by Tencent) or simply closed our reports without an explanation (by Sina). The only exception goes to ByteDance, whose security team responded that they just followed “the industry’s standard” but will report this issue to their product team.

All these responses suggest a play down from app developers when it comes to IABI usability security concerns.

In this section, we propose a set of secure IABI design principles and corresponding code-level implementations in this section to help mitigate risky IABIs and guide future designs. Here we provide implemenations in Android as examples, and iOS developers can use corresponding counterparts in iOS.

Firstly, we recommend the use of Chrome Custom Tabs and SFSafariViewController for their good performance in our tests presented in this paper except for T8. The implementation guides are CCT (CCT, 2021b) and SF (SFS, 2021). Comparing to building one’s own IABI, CCT/SF are easy to incorporate with little effort while achieving outstanding security design and optimized loading speed.

However, CCT and SF also have their limitations. CCT failed to provide an extra prompt to alert users when entering passwords on the web page. And they can only provide some basic customization options while developers may need deeper customization to fit in with their apps. In some region, Chrome (and therefore CCT) is not available, e.g., in the mainland China market.

Considering these shortcomings of CCT/SF, we propose the following IABI design principles for those developers who need their own IABI implementation. We devide them into three parts: design principles before opening the URL, on page displaysing and on page navigating. Considering these shortcomings of CCT/SF, we propose the following IABI design principles for developers who need their own IABI implemenation. We devide them into three parts: design principles before opening the URL, on page displaysing, and on page navigating.

1. 1.

   Before Opening the URL: In the chatting, posting, email UI and other possible UI that display the clickable URL, IABIs:

   1. a)

      SHOULD display the complete URL and corresponding indicators of URL schemes. It would be GOOD that the indicator be more intuitive and eye-catching than title and favicon.

   2. b)

      SHOULD NOT display any extra pre-loading information (e.g., favicion and title), unless that URL can be trusted.

2. 2.

   On Page Displaying. After the user taps the URL, developers could adopt the following five principles to better avoid the potential usability security issues on page displaying:

   1. a)

      SHOULD display the full URL in the address bar to show the page origin. Developers can get the URL of the current page through WebView.getURL() or the arguments in the event handlers of WebViewClient (e.g., onPageFinished, shown in Listing 1).

   2. b)

      SHOULD display the HTTP and HTTPS indicators, which are intuitive for users to identify insecure web pages, potentially in conjunction with the scheme text in the URL. To this end, developers can override the onPageFinished method (onp, 2021). Here we provide a simple example in Listing 1.

      ⬇

      1public void onPageFinished(WebView view, String url){

      2 …

      3 //Display url on the title bar.

      4 addressBar.setText(url);

      5 //obtain the scheme

      6 String scheme = URL(url).getProtocol();

      7 if(scheme.equals(”https”)){

      8 /*Display the HTTPS indicator*/

      9 }else{

      10 /*Display the insecure indicator*/

      11 }

      12 …

      13}

   3. c)

      SHOULD NOT directly open URLs with certificate errors.

      1. a.

         Show a prompt, like a dialog box or a special page, which informs end users about SSL errors.

      2. b.

         Provide end users with the option to continue opening the URL in a covert manner, e.g., as in CCT which only shows the continue option after clicking on the “Advanced button” (Case 2 in Figure 7).

      To handle the certificate errors in the WebView, developers can override the event handler WebViewClient.onReceiv- edSslError (onR, 2021), and show a dialog to inform the user about the error.

   4. d)

      SHOULD handle the lock emoji in the title with extra care by:

      1. a.

         Replacing it with the text to avoid misinterpreting as the HTTPS indicator; or

      2. b.

         Disallowing emoji; or

      3. c.

         Avoiding displaying the title.

      Developers can override the onPageFinished method, obtain the title of the web page by WebView.getTitle(), and detect the emoji code in the title. For example, the Unicode of the lock emoji is U+1F512. Another choice is to disallow all the unicode in the title. We do not recommend it as it will greatly damage the user experience.

   5. e)

      SHOULD handle the long subdomain name with extra care. by:

      1. a.

         Providing scrolling capability for end uses to read the complete domain name; or

      2. b.

         Prioritizing the display of domain name over subdomain name.

      To scroll the TextView (displaying the URL/domain name)in Android apps, developers can set its attribute in the layout xml file:  android:ellipsize=‘‘marquee’’.
      To Prioritize the domain name, developers can set the attribute to:  android:ellipsize=‘‘start’’.

3. 3.

   On Page Navigating. When the user tries to enter the password or other sensitive information in an web page, IABIs:

   1. a)

      SHOULD show an additional warning regardless of HTTPS or HTTP pages. Case 2 in Figure 9 is a good example.
      To detect the input box of the password and username, developers can utilize the interaction between the Java and JavaScript code, i.e., using WebView.loadUrl() to execute JavaScript code to detect the ‘password’ type within the web page and give a corresponding prompt. An example is shown in Listing 2.

   ⬇

   1webView.loadUrl(

   2”javascript:(function(){” +

   3 ”var objs=document.getElementsByTagName(\”input\”);”

   4+ ”for(var i=0;i<objs.length;i++)” +”{”

   5 + ”var type = objs[i].getAttribute(\”type\”);”

   6 + ”if(type==\”password\”){”

   7 + ”objs[i].onfocus=function(){”

   8 + ”PROMPT_TO_ENTERING_PASSWORD”

   9 +”}”

   10 + ”}”

   11 +”}”

   12 + ”})()”);

In this section, we discuss threats to the validity of our study and limitations. Specifically, the major threats are that we did not conduct a user study to evaluate IABIs and our ratings are subjective assessments solely based on designs of the apps’ user interfaces and corresponding logic. Additionally, we discuss our limitations on the lack of a large dataset, automatic testing, and evaluation of the IABI design principles.

User study. The usability problems mentioned in this paper are not verified in a study with end users, resulting in the lack of direct confirmation of our findings. For example, in T6, we did not test whether an end user is actually misled by the fake lock emoji in the title, even though an expert analysis on the app’s user interface strongly suggests the possibility. A possible extension of this work is to design an IABI app practicing GOOD IABI principles and compare end user reactions with those from popular apps tested in this paper.

Ratings. Our evaluations, in particular, the setting of various ratings, are based on previous work (Amrutkar et al., 2015, 2013, 2012) and World Wide Web (W3C) guidelines on mobile browsers (W3C, 2021). We believe that some of these settings are subjective assessments and do not advocate the uniqueness of such settings.

Dataset. We conducted tests only on a relatively small dataset with 25 mobile apps. However, these apps are all the most popular ones containing IABIs and are used in daily life. Therefore, we believe that they capture IABIs’ representative behaviors experienced by end users. It is worth noting that we do not consider the apps that do not have IABIs, such as Whatsapp and Signal, because they jump to default browsers when opening a web page.

Towards automatic testing. Our manual testing limits the scalability of this paper. Here we explain briefly why an automatic testing is non-trivial with either dynamic or static approaches.

Unlike existing work on generic dynamic analysis of mobile apps, our analysis of IABI behavior requires triggering specific behavior of mobile apps. This typically mandates signing up an account with each app and triggering the processing of specific URLs, which is, to say the least, non-trivial. For example, we cannot find a unified (dynamic) way of precisely locating the (all) chat UI of each app.

Static analysis also encounters specific challenges, e.g., locating the HTTP and HTTPS indicators, which typically do not present themselves as layout files but images. Therefore, it is non-trivial to perform backward tracing to find the relationship between these indicators and the web pages.

Evaluating design principles. The principles in Section 6 present lessons learned from our systematic analysis of the 25 high-profile apps, but they have not been tested in real-world app development or end-product user studies. We hope that our study can bring attention to the community and promote more research on the principles and guidelines for IABIs development.

In this section, we review some closely related works on the security indicators in regular mobile browsers, the general mobile WebView and TLS security.

Security Indicators in Mobile Browsers. Amrutkar et al. (Amrutkar et al., 2015) first measured the adequacy of critical security indicators in mobile browsers. They found that mobile browser’s UI designs failed to meet many security guidelines. Luo et al. (Luo et al., 2017) revealed a number of UI vulnerabilities among mobile browsers, which attackers can use to better social engineer users and collect sensitive information. Wu et al. (Wu et al., 2006) evaluated the usability of mobile browsers’ address bars for security guarantees. Different from these studies on standalone mobile browser apps, our study is the first one targeting security indicators in in-app browsing interfaces (IABIs). Moreover, we show that the problems become worse when it comes to IABIs, as many developers only care about the main functionality of the app without putting too much effort into the design of browsing interfaces.

Mobile WebView Security. Android WebView had been vulnerable to various attacks. Luo et al. performed the first study on the attacks of WebView (Luo et al., 2011, 2013), followed by the file-based cross-zone scripting attack (Wu and Chang, 2014) and access control problem by Georgiev et al. (Georgiev et al., 2014). Wu and Chang (Wu and Chang, 2015) further studied the WebView vulnerabilities on the iOS platform. There are also many techniques to prevent private data from leaking through JavaScript, for example, BavelView (Rizzo et al., 2018), Spartan Jester (Sexton et al., 2017), and HybriDroid (Lee et al., 2016). Most of the past research focused on the interaction between Java and JavaScript but not on the usability security of the in-app browsing interfaces. For example, Li et al. (Li et al., 2017b) proposed attacks that utilize browsing interfaces for cross-app navigation from another WebView. Similarly, Yang et al. (Yang et al., 2019) found that iframe can navigate the WebView to untrusted web pages.

Mobile App TLS Security. Many Android apps use SSL/TLS to transmit sensitive information securely, but developers often use their own, potentially insure, implementation to verify the certificate. Georiev et al. showed that SSL certificate validation is completely broken in various popular apps and libraries (Georgiev et al., 2012). Thus, many previous works studied the potential security threats caused by the inadequate or insecure use of TLS in mobile browsers. They provided various tools to detect potential vulnerabilities against Man-In-The-Middle attacks caused by inadequate use of SSL/TLS, including the dynamic MalloDroid (Fahl et al., 2012) and SMV-Hunter (Sounthiraraj et al., 2014) and the static Amandroid (Wei et al., 2014) and BackDroid (Wu et al., 2021). In this paper, we find that most of the apps that use their own IABIs do not have any security indicators about the schemes the website is using, to the extent that the users cannot identify whether the current web page they are browsing meet the TLS requirement.

In this paper, we conducted the first empirical study on the usability (in)security of in-app browsing interfaces (IABIs) in both Android and iOS apps. Atop a dataset of 25 high-profile mobile apps that contain IABIs, we performed a systematic analysis that comprises eight security tests and covers all the attack surfaces from opening, displaying, to navigating an in-app web page. We obtained three major security findings, including about 30% of the tested apps fail to provide enough URL information before users open the URL, nearly all custom IABIs have various problems in providing sufficient indicators to faithfully display an in-app page to users, and only a few IABIs give specific warnings to remind users of dangerous operations (e.g., password inputting) during navigating a login page. To help mitigate risky IABIs and guide future designs, we reported our findings to affected vendors, analyzed their responses, and proposed a set of secure IABI design principles.