【论文总结】On the Usability (In)Security of In-App Browsing Interfaces in Mobile Apps

论移动应用中的应用内浏览界面的可用性（非）安全性

摘要:
对于网络URL，许多移动应用建立了应用内浏览界面（IABI），通过避免在主体应用和系统内置浏览器应用之间切换实现了用户友好性，但IABI如果设计的不好，可能会导致可用性安全风险。在本文中，对Android和iOS应用中的应用内浏览界面的可用性（in）安全性进行了首次实证研究。从包括Facebook和Gmail在内的五个常见应用类别中收集了25个高知名度的移动应用的数据集，通过八个精心设计的安全测试得到了三个主要的安全发现：
（1）大约30%的被测应用未能提供足够的URL信息，让用户在打开URL时做出明智的决定；
（2）几乎所有的自定义IABI在提供足够的指标以向用户显示应用页面内容时都存在各种问题，而基于 Chrome自定义标签和SFSafariViewController的十个IABI则普遍安全；
(3) 只有少数IABI给出了警告，提醒用户在浏览（潜在的网络钓鱼）登录页面时输入密码的风险。
同时，为了帮助减轻有风险的IABI并指导 我们提出了一套安全的IABI设计原则。

IABI：
In-App Browsing Interfaces的缩写，指的是移动应用程序中内置浏览器界面。这些界面允许用户在应用程序内部直接打开和浏览网页，而不必离开应用程序并使用独立的浏览器应用程序。
可用性安全风险:
指的是在保护系统安全性的同时，可能会对用户使用体验造成负面影响或限制。例如，过于复杂或繁琐的身份验证步骤、访问控制机制等都可能导致用户放弃使用该应用程序。因此，在设计和实现应用程序时需要平衡安全防御和用户可用性之间的关系，以确保最佳的用户体验同时也能够保证系统安全。

一、简介

1.起因

移动应用程序在日常生活中被大量使用，虽然大多数应用程序功能是自成一体的，但用户仍存在在应用程序的UI中打开外部网络URL的需求。为了满足非浏览器应用程序中的URL访问需求，可以奖该任务简单的交给系统内置的浏览器程序实现，但这样有损用户体验，因此许多高知名度的应用程序选择提供自己的应用内浏览界面或IABI以提高用户体验。

2.存在的问题

IABIs通常是缺乏安全指示的浏览界面的简化实现，与“全功能”和独立浏览器具有经过深思熟虑的可用性安全设计不同。例如，IABI可能不会显示完整的URL域名或仅错过HTTP（S）指标。因此如果IABIs设计或定制不好，可能会引入严重的可用性安全问题。

3.尝试

收集和分析了五个常见的应用程序类别，包括聊天，社交，邮件，商业和新闻中包含IABI的25个高知名度移动应用程序的数据集，例如微信，Twitter，Gmail，LinkedIn和Reddit。在此数据集上，执行了系统化的分析，包括八个精心设计的安全测试（三个类别中的T1〜T8）并涵盖在IABIs中与In-App网页交互的全部过程，包括页面打开、显示和导航。
首先，在用户打开URL之前，我们测试该主题应用程序是否提供足够的URL信息，以使最终用户能够以可信赖的方式做出开放URL的决策（T1）。第二，当网页加载后，我们测试IABI是否为最终用户提供足够的安全指示符，以验证显示页面的可信度。这包括在标题/地址栏中是否显示URL本身（T2）、HTTPS（安全）指示符（T3）和HTTP（不安全）警告（T4），是否为TLS错误的URL提示安全警报（T5），以及IABI能否通过伪造的HTTPS锁定图标（T6）和长子域名（T7）来防御钓鱼URL。第三，在浏览网页时，我们测试IABI是否可以在浏览页面要求用户在（潜在的网络钓鱼）登录表单中输入密码时提供特定的警告（T8）。

4.测试结果

<1>约30％的测试应用程序没有显示完整的URL，无法为用户提供足够的信息来信任地打开URL。其中大多数应用程序省略了方案（HTTP或HTTPS），而微博和Quora完全隐藏了URL。尽管输出了完整的URL，还有30％的应用程序显示额外的favicon或标题信息，这使攻击者能够制作虚假的图标/标题来误导用户。
<2>几乎所有自定义IABI在向用户提供足够的指示符以忠实地向用户显示应用页面方面存在各种问题，而基于Chrome Custom Tabs或SFSafariViewController的十种IABI通常是安全的。具体而言，在15个实现自己的IABI的应用程序中，超过一半没有在地址栏中显示域名，几乎没有提供HTTP（S）指示符，这使它们无法锁定表情符号或长子域名来防御钓鱼。
<3>只有少数IABI（来自QQ和QQ Mail应用程序）在浏览登录页面时提供特定的警告，提醒用户危险操作（例如输入密码）。

制作虚假的图标/标题来误导用户：
假冒图标：攻击者可以在URL中使用额外的参数来指定一个不存在的favicon文件，并使用与受害者网站相似的图标来迷惑用户。
虚假标题：攻击者可以使用额外的参数来指定一个虚假的页面标题，甚至可能欺骗用户点击想象中的网站链接。
攻击者可能会利用这些漏洞，制作出虚假的网站链接来欺骗用户，让用户误认为链接所指向的是一个合法的网站。
锁定表情符号或长子域名来防御钓鱼：
锁定表情符号：在电子邮件或短信中，钓鱼者可能会使用与正常字符相似的表情符号来伪装页面链接或电子邮件地址。通过锁定所有可用的表情符号并将它们替换为文本字符，可以有效防止这种攻击。
锁定长子域名： 钓鱼者通常会使用类似于公司名称、银行或其他机构的长子域名进行钓鱼攻击。通过锁定这些长子域名并拒绝任何来自它们的电子邮件和网站访问，可以有效地防御这种攻击。

二、背景

移动应用程序在日常生活中被大量使用，虽然大多数应用程序功能是自成一体的，但用户仍存在在应用程序的UI中打开外部网络URL的需求。为了满足非浏览器应用程序中的URL访问需求，可以奖该任务简单的交给系统内置的浏览器程序实现，但这样有损用户体验，因此许多高知名度的应用程序选择提供自己的应用内浏览界面或IABI以提高用户体验。
在IABI中打开一个URL的典型过程(引用自 On the Usability (In)Security of In-App Browsing Interfaces in Mobile Apps 图1):

当用户点击URL时，应用程序有三种方法来处理URL请求.
<1>一些应用程序选择跳出应用程序 并打开一个浏览器应用来显示网页。这种情况是 这种情况不在我们的论文范围之内，因为它们不包含应用内的 浏览界面。
<2>第二种方式是定制一个浏览 第二种方式是基于Chrome自定义标签（CCT）和SFSafariViewController（SF）库定制一个浏览界面。
<3>第三种方式是创建自己的 第三种方法是创建自己的IABI，以WebView的形式显示网页。(Android）或**UIWebView（iOS）**实例的形式显示网页。

Chrome自定义标签（CCT）和SFSafariViewController（SF）库：
CCT是由Chrome支持的，它是由Google开发的网络浏览器。移动应用可以向Chrome发送一个特殊的意图，启动CCT来打开网站，而不需要自己实现一个内置的浏览器引擎，前提是Chrome已经安装在智能手机上。Chrome还为开发者提供了封装良好的API，以进行一些有限的浏览UI定制，如颜色和动画。同样地，iOS也有Safari支持的SF，供开发者轻松地纳入他们的应用程序中。
WebView和UIWebView：
尽管CCT和SF为开发者实现IABI提供了方便的方法，但人们可以选择使用较低级别的显示引擎WebView和UIWebView（甚至是本地代码中的自定义引擎[26]）来对用户界面进行更全面的控制。它们允许开发者监控特定的事件（例如，加载和导航），在这些事件被触发后，开发者可以收集事件信息并做出相应的反应。这种设计的低级实现为开发者提供了非常灵活的UI控制，这也意味着有更多的设计错误的可能。

三、问题剖析

本部分针对打开前、显示、浏览网页三个阶段对IABI进行分析。

1.打开前阶段风险分析

打开前应用程序如何显示网址(T1):
最简单的设计是只显示网站的URL而不显示其他内容。一些应用程序可能会在URL下面显示一个盒子，里面有关于网页的额外信息，例如，标题和图标。T1是在应用程序中打开网页过程中不可缺少的一步 中不可或缺的步骤。由于它不是IABI的一部分，我们无法将其与移动浏览器进行比较。而且现有的工作也没有提供任何 关于它的设计原则。因此，我们根据其他测试的标准，给它一个良好的评级.这可能是反直觉的，但是我们发现，只显示URL而不显示任何其他信息的设计实际上可能是一个好的设计。因为任何显示的额外信息（例如，图标） 有可能被攻击者利用来提供 误导性的信息。
测试:
为了进行测试，我们将所有测试的URL输入到主题应用程序中 并检查相应的显示。注意，在这个时候应用程序还没有打开网站,但一些应用程序可能会预先加载网站，以获得关于该网站的简要信息。

2.显示页面阶段风险分析

在显示相应的Web内容时，不同的应用程序可能具有自己的地址栏设计，本阶段主要包括以下六个测试：
1)T2：地址栏是否显示URL（使用URL9）。最终用户需要此信息以了解页面的来源。不同的设计包括显示URL和/或域名。
23) T3和T4：如何处理URL中的HTTPS和HTTP协议（使用URL1和URL2）。 HTTPS指示符非常直观，用户可以识别网页是否符合TLS要求。 IABI应在HTTP和HTTPS网页中都显示相应的指示器。 如果IABI仅显示HTTPS指示器但不显示HTTP页面的指示器，则在打开另一个HTTPS页面并看到指示器之前，用户可能不知道HTTP页面不安全。
4) T5：如何处理SSL错误（使用URL3〜5）。测试的SSL错误包括过期的证书、错误的主机和自签名证书。不同的设计包括阻止访问、提示给最终用户选项或在没有任何警告的情况下访问网页。
5)T6：如何显示带锁的表情符号的标题（使用URL6）。显示锁表情符号可能会使最终用户误认为它是带有HTTPS协议的安全网页。
6)T7：如何显示具有长子域名的URL（使用URL7）。仅显示长子域名而不带上域名可能会给人以访问受信任域的错觉。

对T2〜T7的评级基于现有工作中移动浏览器安全指示器和原则的评估，这些工作根据世界广泛 Web（W3C）指南概述的最佳实践进行系统分析。以下为从这些指南中提取出的适用于IABI的原则:
1）身份信号：可用性。安全指示器应始终通过主要或辅助接口向用户显示网站的身份。我们认为，IABI至少应显示网页的基本身份，即域名。因此，在T2中，我们为显示Web页面的URL或域名分配了GOOD评级。
2）错误消息：中断/前进选项/抑制交互。这三个原则要求错误警告必须中断用户当前的任务，并抑制用户与目标网站交互。同时，警告必须为用户提供明显的选项（不能仅继续）。因此，在T5中，我们测试IABI如何对错误的证书（如错误的主机、过期或自签名证书）做出反应。我们的GOOD评级与此指南一致，即在用户打开SSL错误页面之前，显示带有继续或不继续选项的提示。唯一的区别是我们稍微放松了要求，并允许IABI直接停止加载该页面而不提供选项。对于直接打开具有证书错误的页面的设计，我们给出BAD评级。对于将问题移交给独立浏览器的设计，我们分配NEUTRAL，这是“懒惰”但不会妥协安全性的方式。
3）TLS指示器：可用性。TLS指示器应始终通过主要或辅助接口向用户显示。因此，我们进行T3和T4测试，以测试地址栏上是否显示HTTPS和HTTP指示器。 GOOD评级是显示指示器（锁/惊叹号图标），以显示页面是否符合TLS要求。不显示任何指示器的设计是BAD设计。虽然显示方案（“https：//”或“http：//”）也可以作为指示器，但不像图标那样直观，因此收到NEUTRAL得分。
4）TLS指示器：内容和指示器接近度。不应以混淆托管内容或浏览器指示符的方式显示内容。在本文中，我们进行T6和T7测试，以测试标题中的锁表情符号和长子域名是否会使用户混淆。根据此指南，IABI不应允许锁定表情符号模仿HTTPS指示器或允许长子域名误导用户，这是T6和T7的GOOD评级。我们将NEUTRAL定义为同时显示安全指示器和锁表情符号（T6）。在T7中，NEUTRAL不显示域名（尽管在T2中这是BAD设计），BAD设计指忽略这一原则并允许这两个项目误导用户。

3.浏览网页阶段风险分析

分析：
当用户在应用程序的IABI中浏览网页时，在登录表格中输入用户名和密码信息是很危险的，因为IABI比独立的浏览器更容易受到网络钓鱼攻击，因此，设计良好的IABI应该给出具体和额外的警告，以提醒用户在浏览登录表格时输入密码的风险 。此外，它们不仅应该涵盖不安全的HTTP登录页面，而且还应该涵盖具有合法登录页面但不合法证书的HTTPS。这是因为 攻击者可以通过简单地使用CA颁发的（有效的）证书来伪造一个带有热门网页标题的钓鱼网页 (例如，alibaba.com)，只需使用CA颁发的(有效)证书 在一个类似的域名（如alibababa.com）上，从而满足TLS要求。
测试:
测试IABIs在登录页面导航时是否会显示与非登录页面正常行为不同的特定或额外警告(T8)。使用URL8和URL10进行此测试，它们分别是示例HTTP和HTTPS登录页面。请注意，对于Facebook和FB Messenger，我们使用我们大学的HTTP登录页面，因为URL10已经是Facebook的登录页面。对于每个IABI，我们导航到两个登录页面、输入用户名和密码，并检查IABI在操作中是否显示了特定警告。
具体而言，如果被测试的IABI在HTTP和HTTPS登录页面上都提供了特定警告，则我们给予GOOD评级。相反，如果该IABI至少对一个登录页面显示警告或两个页面都没有这样的警告，则我们分别给出NEUTRAL和BAD评级。

四、结果分析

1.打开前的可用性风险

结果分成三个级别分析:
好:
最常见的方式是显示完整的URL（约占我们的主题应用程序的50%我们的主题应用程序）；本文认为这是一种好的做法，因为终端用户可以看到完整的URL，而不会被恶意制作的faviconsor标题所误导。
中:
一些应用程序可能会显示相应网页的额外信息，包括标题、域、favicon，甚至一些页面内容。尽管这些额外的信息可能对合法的URL有帮助，但在其他情况下也可能产生误导。例如，在图3中LINE的案例中就显示了一个假的锁形图标。（引用自 On the Usability (In)Security of In-App Browsing Interfaces in Mobile Apps 图3）

坏:
这个类别指的是不显示完整URL的应用程序（包括缺少HTTP/HTTPS方案的情况）。例如，Snapchat只显示标题、favicon和域名（并看到看起来像锁的favicon）。Twitter和Quora（案例6和7）的URL的方案被剥离，只剩下域名。微博（案例8）为每个URL显示一个相同的标签，没有提供足够的URL信息。

在IOS中的情况：
大多数应用程序在安卓和iOS上的表现完全相同。在本分析中，大多数应用程序在安卓和iOS上的表现完全相同，但VK俄罗斯除外。安卓版本只显示完整的URL（好），而其 iOS版本则同时显示标题和域名（中）。

2.网页显示时的可用性风险

这部分主要关注在标题和地址栏上，我们首先检查了加载网页时的URL显示（T2），然后测试了4种类型的URL：HTTP (T3）、HTTPS（T4）、SSL错误（T5）和特殊情况（T6和T7）的4种URL。

1)T2(页面打开时显示的URL):

正确显示URLs的重要性与T1相似，但有三个明显的区别:

1. T2只关注URL的显示 而把方案指标的分析留给了T3∼T5。
2. 网页重定向对网页打开时的URL显示提出了额外的要求。
3. 页面的预览不再增加任何可用性或功能，因为实际的页面已被打开。

Chrome自定义标签和SFSafariViewController在该部分的做法：
Chrome自定义标签（CCT）和SFSafariViewController（SF）都在其地址栏中显示域名，这被认为是一个好的设计。

参考Chrome自定义标签和SFSafariViewController在该部分的做法，我们同样把结果分成两个级别：
好:
显示完整的URL或其域名。18个应用中总共有8个安卓应用满足这一要求。

坏:
其他10个主题应用程序只显示网页的标题，没有显示URL（或域名）。网页的标题，而没有显示URL（或域名），例如163Mail，甚至根本就没有标题/地址栏，例如百度，这是一个糟糕的设计。一个有趣的观察是 这10个主题应用中的9个来自中国。

网页重定向评估：
评估显示，所有的主题应用程序都通过了这个测试。

Chrome自定义标签和SFSafariViewController：
我们首先看一下成熟的浏览器是如何处理URL显示的。Chrome自定义标签（CCT）和SFSafariViewController（SF）都会在其地址栏中显示域名，这被认为是一个好的设计。对CCT的定制允许显示或隐藏标题（使用API setShowTitle(true)）。

2)T3(HTTPS指示器)：

应用程序通常以文本（URL中的 “https”）或锁定图标的形式提供HTTPS指标。

Chrome自定义标签和SFSafariViewController在该部分的做法：
Chrome自定义标签和SFSafariViewController都使用一个锁形图标作为HTTPS的指示器，而这个图标是 该图标不能被应用开发者定制或移除。

同样我们将测试的应用分为三个类别：
好:
即Chrome自定义标签和SFSafariViewController在该部分的做法，类似的设计可以在Facebook、FB Messenger和KakaoTalk这三个应用程序中找到自己的IABI实现。
中：
些应用程序依靠完整URL的方案部分（文本 “https”）来表示正在使用HTTPS协议，这可能不是很直观，但对高级用户来说已经足够。
坏：
没有任何HTTPS指示器（文本或锁定图标）。令人惊讶的是，我们发现在18个有自己的IABI实现的Android应用中，有12个属于这个类别，包括Facebook公司开发的Instagram(虽然Facebook和FB Messenger是GOOD）。

在IOS中的情况：
iOS版的Snapchat在其自己的IABI实现中显示一个锁的图标 IABI的实现，而其安卓版本没有任何 指标。其他应用程序在T2方面有相同的行为 在安卓和iOS上有相同的行为。

3)T4(HTTP指示器)：

适当的HTTPS指标不应免除应用程序显示 HTTP指示器/提示。换句话说，HTTP指标应始终显示，无论是否存在 HTTPS指标。

Chrome自定义标签和SFSafariViewController在该部分做法:
CCT当URL不符合TLS要求时，使用一个感叹号图标来代替锁定图标；这个图标非常直观，可以给用户一个明确的警告。与HTTPS的锁定图标一样，这个感叹号图标不能被开发者定制或删除。SFSafariViewController使用文本 "不安全 "作为指示。在这个测试中，它们都得了GOOD。

同样我们将测试的应用分为三个类别：
好：
与HTTPS指标的分析类似，一个好的设计应该总是为HTTP显示一个不安全的指标。不幸的是，Facebook是这个测试中唯一一个得到GOOD设计得分的应用。
中：
显示完整的URL和文本 "http "的方案部分，也是为了达到不那么直观的界面的目的，在我们的分析中被认为是中。LINE和Twitter属于这个类别。
坏:
没有任何HTTP指标的设计被认为是坏的。设计，在18个应用程序中，有15个有自己的IABI实现，包括FB Messenger，属于这个类别。

在IOS中的情况：
Facebook是这里唯一一个在iOS应用程序上的HTTP指标方面具有良好设计的应用程序。

4)T5(证书错误)：

一个应用程序应该在证书出错时通知终端用户。我们用含有这种证书错误的URL来测试所有的主体应用程序，并检查其相应的提示。

Chrome自定义标签和SFSafariViewController在该部分的做法:
由于大多数普通终端用户没有必要的技术背景来做出明智的决策，当他们遇到证书错误时，CCT和SF（以及相应的完整浏览器）都引入了“扭曲”的路径供终端用户浏览网页。图7中第2和第4种情况展示了这些“扭曲”路线的设计示例，在这些情况下，终端用户需要选择“高级”或“显示详细信息”，然后才能获得继续浏览的选项。我们认为这些是最佳安全可用性实践下良好的设计。（引用自 On the Usability (In)Security of In-App Browsing Interfaces in Mobile Apps 图7）

CCT和SF选择在所有使用CCT/SF实现的应用程序中记住此类终端用户操作。换句话说，如果一个用户已经选择在任何其他使用CCT/SF应用程序上浏览同一URL，则具有CCT/SF实现的应用程序将跳过证书错误警告。虽然CCT/SF实现通常被认为是良好且符合最佳安全可用性规范的，但这样做会牺牲安全性以提高易用性。

同样我们将测试的应用分为三个类别：
好:
那些拒绝打开页面或向终端用户提示各种选项的应用程序被认为是好的。在这种“好”的定义下，除了拥有自己IABI实现的3个应用程序外，所有其他应用程序都属于此类别。其中有7个应用程序只是拒绝打开页面，还有8个应用程序提示用户并提供继续进行的选项。
中:
Twitter选择启动系统默认的 浏览器来处理有证书错误的网页，虽然负担是转移到了默认浏览器上，但我们认为 这个设计是可以接受的（中）。
坏:
忽略证书错误或直接打开不安全的网页都被认为是BAD设计。在这个类别中，例如支付宝（Alipay），它直接打开一个带有错误主机证书的网页，以及知乎（Zhihu），不管是否存在证书错误都会不加区别的显示访问外部网站的提示。

在IOS中的情况：
所有的iOS主题应用程序都提供了良好的设计，包括支付宝和知乎(它们的安卓版本是“坏”的)。

5，6)T6&T7(特殊URLs)：

T6和T7关注的是特殊的URL，其中例如锁形表情符号是标题的一部分，以及使用了扩展的子域名称等情况。

Chrome自定义标签和SFSafariViewController在这部分的做法;
对于T6,CCT可以配置标题是否可见。当标题可见时，锁定的表情符号 (的一部分）和感叹号图标（使用的是HTTP 协议）紧挨着出现，这很令人困惑但也不是太糟糕，因为警告就在那里。在没有页面标题的情况下，无论是由于CCT的开发者配置还是由于SF的使用，HTTP警告都在那里，没有任何混淆。关于T7，CCT和SF都显示了URL的后缀（修剪了长的子域），这意味着CCT
和SF对T7攻击是免疫的.

同样我们将测试的应用分为三个类别：
好:
最初“好”的判断是通过检测标题中锁（或类似）表情符号的使用，并将其替换为不含糊的文字或符号。不幸的是，没有一个主题应用程序有类似的设计（甚至CCT/SF的实现也没有）。因此，我们只将他们自己的不显示标题的IABI实现视为“好”的设计。除了那些选择不显示标题的CCT应用程序，只有Facebook和KakaoTalk在这个测试中拥有一个“好”的设计。在T7中，我们认为那些优先显示域名而不是子域名的设计是好的。LINE是我们测试中唯一一个“好”的。
中:
当标题中的锁形表情符号被显示出来时，如果完整的URL或HTTP指示器（如感叹号图标）也被显示出来，那么我们认为它是中性的，因为这样终端用户仍然有办法知道这个页面是不安全的。这方面的例子包括CCT实施、LINE和Twitter。在评估T7时，我们发现在18个有自己的IABI实现的应用程序中，有9个只显示页面的标题，而没有显示URL，严格来说，这并没有在扩展子域上有所欠缺，但仍有误导性。因此，我们将其归类为中性。
坏:
在T6中，有11个应用程序在显示锁的表情符号时没有任何HTTP 指示器或显示完整的URL。最终 终端用户很有可能被锁住的表情符号所误导，因此我们认为这种设计是不良的。我们认为这样的设计是坏的。关于T7，有8个主题应用程序 显示子域名称，而域名却不见了。
在IOS中的情况：
多数应用程序在其安卓和iOS版本上有类似的行为。但FB Messenger的iOS应用除外。它的地址栏上只有域名，对T6来说被认为是一个好的设计，对于T7，FB Messenger iOS应用同时显示域名的头部和尾部，这也是一个好的设计。另一方面，LinkedIn的iOS应用在显示子域名方面存在问题(“坏”)，而它的安卓对应程序只显示标题（“中”）。

2.网页导航时的可用性风险

这部分主要是看一个主题应用程序的IABI实现在网页导航过程中对危险操作（例如，密码输入）的反应。具体来说，T8测试IABI是否会在登录页面上显示一个特定的或额外的警告，而不是在非登录页面上的正常行为 在非登录页面上的正常行为。

Chrome自定义标签和SFSafariViewController在该部分做法:
在浏览HTTP和HTTPS登录页面时，CCT没有为密码输入提供任何额外的警告。也就是说，它的行为与之前的T3和T4相同；因此，我们认为CCT在这个测试中的评级为"坏"。相比之下，SF的表现略好于CCT。如图9中的案例5所示，当终端用户浏览HTTP登录页面时，SF通过将其颜色改为红色来突出显示 “不安全”（通常显示在所有的HTTP页面），这对终端用户来说更引人注目，然而，SF在HTTPS登录页面上没有特定的警告。因此，我们把SF在T8上的表现定为“中”。

同样我们将测试的应用分为三个类别：
好：
我们认为那些为HTTP和HTTPS登录页面提供特定警告的设计是好的。QQ邮箱（案例2）和QQ（都是由腾讯开发的）在用户输入用户名或密码到HTTP（URL8）和 HTTPS(URL10)网页时，都会显示这样的提示，这是好的。
中：
一些应用程序在浏览HTTP登录页面时显示一个额外的警告（除了正常的HTTP指示器），但在HTTPS登录页面上却没有提供任何警告。我们将这些应用程序的IABI评为中性。对于所有测试的应用程序，我们发现只有使用SF的应用程序 使用SF的应用程序有这样的性能。
坏：
其他应用程序在T8中的得分是“坏”，包括微信。也是由腾讯开发的，但它们在这个测试中没有显示任何警告。这个测试中没有显示任何警告，经过进一步调查，我们发现，如果该域名在微信的开发者平台上注册，其他两个应用程序使用的这个反欺诈提示可以在微信中被删除。因此，也许有些开发者已经在该平台上注册了这个域名，所以提示被删除。
在IOS中的情况：
拥有自己的IABI实现的iOS应用程序的行为与它们的Android版本相同。

五、应用开发者的回应

不重要，略~~

六、安全的IABI设计原则

本文提出了一套安全的IABI设计原则和相应的代码级实现，以帮助减轻有风险的IABI并指导未来的设计。本文提供了Android中的实现作为例子，而iOS开发者可以在iOS中使用相应的对应方法。
推荐使用Chrome自定义标签和SFSafariViewController，因为它们在本文介绍的测试中表现良好，除了T8。实现指南是CCT和SF。与建立自己的IABI相比，CCT/SF很容易加入，只需很少的努力，同时实现了出色的安全设计和优化的加载速度。然而，CCT和SF也有其局限性。CCT未能提供额外的提示来提醒用户在网页上输入密码。而且它们只能提供一些基本的定制选项，而开发者可能需要更深入的定制，以适应他们的应用程序。
在某些地区，Chrome浏览器（因此也包括CCT）是不可用的，例如在中国大陆市场。考虑到CCT/SF的这些缺点，我们为那些需要自己的IABI实现的开发者提出以下IABI设计原则：

1.打开URL之前

在聊天、发帖、电子邮件用户界面 和其他可能显示可点击的URL的用户界面IABI应该满足:
1)示完整的URL和相应的URL方案的指标,指标应该比标题和favicon更直观和醒目
2) 不应显示任何额外的预加载信息（例如，favicion和标题），除非该URL可以被信任。

2.在页面上显示时

在用户点击URL之后，开发者可以采用以下五个原则来更好地避免页面显示时潜在的可用性安全问题：
1)应该在地址栏中显示完整的URL，以便显示页面的来源。开发者可以通过WebView.getURL()或WebViewClient事件处理程序中的参数获得当前页面的URL。或WebViewClient的事件处理程序（例如，onPageFinished、 如清单1中所示）。
2) 应该显示HTTP和HTTPS指标，这对用户识别不安全的网页是很直观的，可能与URL中的方案文本一起显示。为此，开发者可以重写onPageFinished 方法.
3) 不应该直接打开有证书错误的URL,可以按以下方式实现:
<1>. 显示一个提示，如一个对话框或一个特殊页面、告知终端用户SSL错误。
<2>. 以隐蔽的方式向终端用户提供继续打开URL的选项，例如在CCT中只在点击 "高级按钮 "后显示继续选项。
为了处理WebView中的证书错误，开发者可以覆盖事件处理程序WebViewClient.onReceivedSslError[8]，并显示一个对话框来告知用户错误的情况。
4) 应该特别小心地处理标题中的锁定表情符号，例如：
<1>将其替换为文本，以避免被误解为HTTPS指标；或
<2> 不允许使用表情符号；
<3>避免显示标题；
开发人员可以覆盖onPageFinished方法，通过WebView.getTitle()获得网页的标题，并检测标题中的emoji代码。另一个选择是不允许在标题中出现所有的unicode。我们不推荐这样做，因为这将大大损害用户体验。
5）应该格外小心地处理长的子域名称，例如:
<1>为终端用户提供滚动功能来阅读完整的域名；
<2>.优先显示域名而不是子域名称。

2.在页导航中时

不管是HTTPS还是HTTP页面都应该显示一个额外的警告
为了检测密码和用户名的输入框，开发者可以利用Java和JavaScript代码之间的交互。JavaScript代码，即使WebView.loadUrl()来执行JavaScript代码来检测网页中的 "密码 "类型，并给出相应的提示。

七、讨论(不足)

1.用户研究

本文提到的可用性问题没有在对终端用户的研究中得到验证，导致我们的研究结果没有得到直接的确认。例如，在T6中，我们没有测试终端用户是否真的被标题中的假锁表情符号所误导，尽管专家对该应用的用户界面的分析强烈暗示了这种可能性。这项工作的一个可能的延伸是设计一个践行好的 IABI原则的IABI应用，并将终端用户的反应与本文中测试的流行应用的反应进行比较。

2.评分

我们的评估，特别是各种评级的设置，是基于以前的工作[9-11]和万维网（W3C）关于移动浏览器的指南。我们认为，其中一些设置是主观的评估，并不提倡这种设置的唯一性。

3.数据集

我们只对一个相对较小的数据集进行了测试，其中有25个移动应用程序。然而，这些应用程序都是包含IABI的最流行的应用程序，并在日常生活中使用。因此，我们相信它们能够捕捉到终端用户所经历的IABIs的代表性行为。值得注意的是，我们没有考虑那些没有IABI的应用程序，如Whatsapp和Signal，因为它们在打开网页时跳转到默认浏览器。

4.面向自动测试

我们的人工测试限制了本文的可扩展性。
**为什么用动态或静态方法进行自动测试不可行：**与现有的移动应用程序的通用动态分析工作不同，我们对IABI行为的分析需要触发移动应用程序的具体行为。这通常需要在每个应用程序上注册一个账户，并触发对特定URL的处理，至少可以说这是不容易的。例如，我们无法找到一个统一的（动态）方式来精确定位每个应用程序的（所有）聊天用户界面。静态分析也遇到了特殊的挑战，例如，定位HTTP和HTTPS指标，这些指标通常不以布局文件的形式出现，而是以图像的形式出现。因此，要找到HTTP和HTTPS的指示器是非常困难的。

5.评估设计原则

虽然本文介绍了从我们对25个高知名度的应用程序的系统分析中获得的经验，但它们还没有在现实世界的应用程序开发中得到检验。或最终产品的用户研究中得到检验。我们希望我们的研究能够引起 引起社会的关注，并促进更多关于 我们希望我们的研究能够引起社会的关注，并促进更多关于IABI开发的原则和指导方针的研究。

七、总结

在本文中，对Android和iOS应用程序中的应用内浏览界面（IABI）的可用性（in）安全性进行了首次实证研究。在一个包含IABI的25个高知名度移动应用的数据集上，我们进行了系统的分析，包括8个安全测试，涵盖了从打开、显示到导航应用内网页的所有攻击面。得到了三个主要的安全发现，包括大约30%的测试应用 未能在用户打开URL之前提供足够的URL信息 几乎所有的自定义IABI都有各种问题，无法提供 几乎所有的自定义IABI都存在各种问题，无法提供足够的指标来向用户忠实地显示应用内的网页、 只有少数IABI提供具体的警告来提醒用户 只有少数IABI在浏览登录页面时给出具体的警告来提醒用户危险的操作（例如，输入密码）。登录页面时的危险操作（如密码输入）。为了帮助减少有风险的IABI并指导未来的设计，我们向受影响的供应商报告了我们的发现，分析了他们的反应、 并提出了一套安全的IABI设计原则。

个人思考

一、个人总结

本文主要探讨了非浏览器移动应用在处理URL时，为了提升用户体验而使用了自建的应用内浏览界面，但这种自建的IABI并不像浏览器一样机制健全，在设计时并不完善，从而产生了一系列可能的安全问题，为此本文从8个方面(T1~T8)测试了当前的25个主流应用软件，通过从网络搜集合适的评价标准，对25个应用进行测试比对，从而分析产生的安全问题和对应的最合适的设计标准，并汇总成了一套比较合适的IABI设计准则。

二、思路剖析

1.文章首先从移动应用程序在打开URL时是使用自建的IABI下手
2.相比浏览器IABI的安全机制难以得到保证，因此从多个方面分析可能的安全问题
3.通过选择相对专业的处理方式（Chrome自定义标签和SFSafariViewController的做法）比对应用自建的IABI，分析出可能的问题
4.从可能的问题下手依次比对25个主流软件中存在的问题，并对比专业的处理方式。
5.针对产生的问题制定出一套相对完善的IABI设计规则

三、大胆揣测

1.比对专业处理URL的浏览器和自建的IABI，一方面从程序大小上就可以看出IABI相比浏览器肯定更加轻便，但也是因为轻便，所以功能机制肯定也不如浏览器全面，因此我们可以通过对比浏览器发现IABI缺失的部分，从而针对这些缺失的功能下手(应该会有很多除了过文章中所提的8点以外的功能缺失从而导致的安全问题)，看看这些方面是否会有安全缺陷。
2.本文只研究了移动端中存在的问题，实际上这些IABI不仅在移动端存在，在主机端也同样存在，在主机端又是否会存在不一样的情况呢？
3.本文探讨了内置IABI打开URL可能存在的问题，我们是否可以倒过来想，当我们打开真正的内置IABI的URL时，是否有可能被恶意程序伪造顶替？从而被钓鱼欺诈?