面向流行移动平台的移动健康应用服务器安全评估

介绍

移动健康应用

无处不在的互联网和移动设备促进了新的和强大的应用程序。移动医疗(mHealth)描述的是与医疗保健相关的移动设备使用情况[1]。虽然一些应用程序提供用户定制的健康信息，但其他应用程序可以方便患者和医疗保健专业人员之间的沟通，或者提供药品销售商店系统。移动医疗应用对安全性的要求更高。除了保护使用应用程序收集的患者健康数据的重要性之外，通过确保通信伙伴的真实性和传输数据的机密性，还必须保护来自应用程序的信息不受未经授权的内容更改(因此必须保持数据完整性)。与基于浏览器的网站或Web应用程序相比，(本地)移动应用程序使用的连接的安全性对用户来说并不透明。Web浏览器既显示使用了安全连接，更重要的是，还突出显示了连接安全问题[2]。

在早期的研究中，研究了以客户为中心的移动应用程序的传输安全问题[3.];本研究的重点是移动健康应用程序的服务器基础设施的安全性。

服务器安全

大多数应用程序的功能依赖于通过互联网与远程服务器进行通信。HTTP是移动应用中客户端-服务器通信的标准[4]，不提供任何安全功能[5]。通过公共基础设施的通信可能被观察、修改或重定向。这会危及应用程序显示的数据的完整性以及从服务器发送和接收数据的机密性，还可能使恶意方冒充服务器。此外，公共可达服务器还必须保证可用性[6]。

客户机和服务器之间的基础结构代表一个不受信任的媒介。在通信双方之间具有特权地位的任何第三方都可以读取和修改交换的所有数据。在这种情况下，特权位置是它们(网桥、路由器和网关)之间路径上的任何一跳[7]。一种常见的攻击媒介是一种叫做地址解析协议(ARP)欺骗的技术。7，8]。这使得攻击者能够接收到通常发送给本地网络上的路由器的所有请求。第三方位于客户端和服务器之间，可以读取和修改消息的攻击称为中间人攻击(MitM)。最近另一个针对Wi-Fi保护接达(WPA) 2无线网络客户端的MitM攻击是密钥重装攻击(KRACK) [9]。较旧或未修补的协议，例如WPA及有线等效私隐协议(WEP)，亦容易受到攻击，因此可启用通讯解密或MitM设置[10，11]。对于Wi-Fi基础设施的攻击，需要与目标的物理距离接近。攻击者至少需要在受害者的接入点范围内。对于KRACK攻击，攻击者需要靠近受害者的设备。

为确保透过不受信任的媒介传送的数据的机密性和完整性，我们采用了传输层安全(TLS)协议[12]。它是当今互联网安全基础设施的重要组成部分。TLS是为底层通信通道的真实性、完整性和机密性保护而设计的，它通过非对称和对称加密提供安全身份验证、数据完整性保护和机密性。TLS位于传输控制协议(TCP)/互联网协议(IP)栈的应用层，可以封装和保护HTTP连接。tls安全的HTTP连接称为HTTP安全(HTTPS)连接[13]。

给定特定的服务器和客户端配置，TLS可以设置为提供前向保密[14]。这意味着，如果将来密钥被泄露，过去的通信仍然是安全的，并且不能仅使用泄露的凭据进行解密。

如果没有服务器的这个安全包装真实性，与服务器交换的信息的保密性和发送到应用程序的数据的完整性就不能得到保证，应用程序可能会显示任意的文本、图片或视频数据。由于攻击者可能会向应用程序提供任意输入，因此也可以利用缺失的完整性使应用程序解码图像、视频或其他可能利用解码器漏洞的数据。例如，Android设备上的Stagefright漏洞利用依赖于Android操作系统处理修改过的媒体文件[15]。

TLS及其前身安全套接字层(SSL)协议并非没有安全缺陷。自引入以来，在协议的不同层或协议的实现中发现了多个漏洞，并被利用来破坏其安全性[16]。为确保伺服器(以及病人)的安全，伺服器营运商必须对新威胁进行特别审查及保持警觉[17]。对新漏洞的发布做出快速反应是至关重要的。恶意的第三方只需要测试所有已知漏洞的可利用性，就可以找到攻击服务器-客户端通信的方法。一些著名的例子是关于降级遗留加密的填充Oracle (POODLE)， Heartbleed，以及最近于2017年12月公开的Bleichenbacher的Oracle威胁(ROBOT)的回归[18-20.]。为了解决SSL及其后续TLS中新发现的安全问题，会定期发布新版本的协议。使用较新的版本可以避免旧版本的已知安全缺陷。

TLS依靠数字证书向客户端验证服务器的身份[12，21]。这些证书必须由证书颁发机构(ca)颁发(和签名)，并且具有多个特征，必须对这些特征进行检查，才能使证书对给定域有效。一些特征是证书必须(1)为所请求的域颁发，(2)具有有效的从日期和日期必须在当前日期之前，(3)有一个有效期至日期以后，且(4)不得撤销。

可以根据CA的证书吊销列表检查证书的吊销状态。由于ca是信任链的根，它们必须负责任地运行。有一些ca提供免费的证书服务(例如，Linux基金会的让我们加密)，而其他机构则对其发出的证明书收费[22]。服务器证书的管理和相应私钥的保管对于服务器所能提供的安全性也是至关重要的。

有关互联网连接系统所面临的保安威胁的概览，请浏览“开放Web应用程序保安计划”[23]。项目收集信息、工具和最佳实践，以避免常见的安全问题。OWASP Top 10和OWASP mobile Top 10与本文所述的研究密切相关[24，25]。虽然不是所有的漏洞都是相关的，但是这些列表是设计测试的一个有价值的起点。

之前的工作

在之前的研究中，从客户端角度研究了移动健康应用程序的传输安全[3.]。该研究检查了iOS和Android客户端应用程序与服务器之间交换的数据，并在安全考虑下对其进行了评估。这也包括TLS和TLS版本的使用。此外，还考虑了客户端对服务器证书的验证。研究发现，在所有53款测试应用中，有40%存在严重问题。

现有文献还评估了b谷歌Play Store和苹果App Store中移动健康应用程序的元数据[26]。这项研究没有进行测试或技术分析。一项针对中国流行移动应用程序的研究发现，97%的被调查应用程序不提供信息安全[27]。作者将他们的调查限于评估现有文件和审计报告的可用性。

另一项研究集中在22个移动健康应用程序上，发现其中18个应用程序通过互联网发送未加密的数据[28]。

由于移动应用并不局限于现有的HTTP(S)实现，因此研究Android应用中的HTTPS实现是相关的[29]。该出版物讨论了TLS部署和服务器配置中的常见缺陷。

在物联网领域，现有研究分析了儿童联网玩具在安全和隐私方面的问题[30.]。作者还注意到玩具与后端服务器通信时的严重传输安全问题。

多年来，服务器一直被用于为基于internet的服务提供网站和接口。服务器的目的是为移动健康应用程序提供数据和功能，这只是它们最近的一个用例。由于它们固有的暴露于公共基础设施(互联网)，它们总是提供一个有吸引力的攻击面。因此，有关问题和服务器安全配置的知识广为流传[5，6，31，32]。有关互联网上SSL/TLS安全的概览，请浏览Qualys SSL Lab的SSL Pulse网站[33]。

移动医疗应用程序正受到媒体的关注，并在处理患者数据方面进行了报道。34]。政府主动建立一个中央地方，就私隐事宜(除其他标准外)对应用程序进行评级。[35]。PrivacyScore有类似的目标，并提供一个可配置的界面，以测试网站的一些安全和隐私问题[36]。

现有的研究主要考虑移动健康应用程序的非技术特征，应用程序的客户端实现，或者仅仅使用任何加密。相比之下，本研究将侧重于移动健康应用程序使用的服务器配置。

方法部分将描述如何选择测试的应用程序。此外，本文还介绍并解释了服务器的传输安全问题，并列出了用于测试这些问题的工具。在Results部分中，显示了经过测试的应用程序。在列出汇总结果之前解释测试方法。这些结果将被讨论，并指出共同的问题。

方法

应用程序选择

在之前的研究中，我们选择了来自3个不同欧洲应用商店的免费应用。由于欧洲不同国家的应用在用户行为上存在差异，所以我们只选择了来自德国应用商店排行榜的免费应用。3.]。德国下载量排行榜上的许多应用在其他国家的应用商店中都很受欢迎。我们将在结果部分讨论国际可用和流行应用程序与仅在德国商店前列表中的应用程序之间的差异。为了减轻任何平台依赖的偏见，Android和iOS的应用程序都经过测试。

相关服务器安全注意事项

HTTP本身以明文形式传输信息，不进行任何加密。它是一个应用层协议，可以通过在安全TLS连接上使用来保护[4，12，13]。TLS及其前身SSL旨在确保通信伙伴的真实性、各方之间的机密性和传输数据的完整性。为了实现这一点，TLS使用非对称加密和公钥基础设施(PKI)进行身份验证和密钥材料交换。对称加密用于有效载荷数据加密[37，38]。

SSL和TLS使用版本号。由于早期版本的协议存在严重的安全问题，本文将考虑SSL或TLS的版本[16，18]。由于结构性漏洞，SSL 2.0被认为是不安全的[39]， POODLE漏洞使第三方能够从受SSL 3.0保护的流量中恢复明文[40，41]。除了SSL 2.0和SSL 3.0，如果服务器(和客户端)配置正确，较新的TLS版本没有已知的安全漏洞。由于缺乏适当的配置，旧版本如TLS 1.0容易受到改进的POODLE攻击和其他漏洞的攻击[18]。另一个TLS 1.0漏洞只能由客户端有效缓解:针对SSL/TLS的浏览器漏洞(BEAST) [42]。尽管大多数现代浏览器都减轻了这个问题，但协议的安全性在服务器端仍然无法控制。TLS 1.1及更高版本的协议不易受到此类攻击，并可在服务器端配置为使用安全密码[43]。最近的版本包含了被认为更安全的改进。使用SSL/TLS和最低支持的版本号将是评估的一部分。我们还评估了对最近批准的TLS 1.3(2018年8月)的支持，并在结果部分中提到了它[44]。

为确保使用HTTPS及防止协议降级攻击，可使用HTTP严格传输安全(HSTS) [45]。降级攻击的目的是让客户机使用不安全的HTTP连接连接到服务器。这使得恶意的第三方能够执行MitM攻击，从而读取和修改敏感信息。为了使用HSTS，服务器发送一个特殊的头来响应请求。这告诉客户端只通过安全的HTTPS连接进行连接。为了使HSTS工作，客户机和服务器都必须支持它。尽管HSTS对于基于浏览器的Web应用程序最为重要，但许多应用程序都包含使用平台浏览器组件的Web组件。此外，网络版本的应用程序也经常存在。服务器响应中存在的HSTS标头将在Results部分中列出。

为了更好地理解以下考虑因素，需要对TLS握手有一个基本的了解[12]。本描述将只关注最常见的服务器身份验证情况。

客户端通过发送一个客户你好消息。这包括它支持的最高TLS版本、一个随机值、建议的压缩方法以及它支持的密码套件。反过来，服务器用选择的协议版本、密码套件、压缩方法和一个随机值进行应答。在一个证书信息，服务器也发送它的证书。客户机现在创建一个预主密钥，用服务器的公钥对其加密，然后将其发送到服务器。双方都根据预主密钥生成主密钥和会话密钥。客户端发送更改密码规格消息发送到服务器，通知服务器它将使用会话密钥进行散列和消息加密。后面跟着a客户端完成消息。服务器接收此消息，对其他消息切换为对称加密，并发送一个服务器完成消息。

在TLS握手期间，客户端使用来自其证书的服务器公钥来加密预主密钥。加密算法依赖于协商的密码套件。服务器发送的证书适合协商的密码套件:例如，如果选择的密码套件包含椭圆曲线Diffie Hellman(ECDHE)算法进行密钥交换，证书必须包含一个椭圆曲线(EC)公钥[46，47]。正如在TLS握手中所解释的，密钥交换的安全性对于连接的安全性至关重要。如果攻击者能够解密premaster如果密码被暴力破解，TLS连接的安全性就会受到损害。为了增加难度，使用的算法以及公钥的密钥长度都很重要。一种常用的算法是RSA (Rivest-Shamir-Adleman)算法[48]。密钥大小从1024位到4096位不等。已经证明1024位的密钥不能提供足够的安全性[49]。此外，2048位是通常推荐的RSA密钥下限。在TLS握手期间增加的复杂性和负面的性能影响是使用较长密钥的缺点。较新的算法，如EC算法，确实需要更小的密钥，对客户端和服务器的计算需求更少，同时提供同等的安全性[47，49]。密钥算法和长度是评估的一部分。

与握手相关的另一个方面是密码套件的选择。服务器有许多支持的密码套件[12，50]。当客户端发送其可能的密码套件列表时，服务器选择它支持的一个。最安全的密码套件应该在客户端和服务器之间协商。可以将服务器配置为具有密码套件的优先顺序[17]。如果存在，服务器将选择客户端支持的优先级最高的套件。服务器是否具有首选顺序是研究结果的一部分，因为所选择的密码套件对于用户流量的加密非常重要。

出于同样的原因，将考虑支持的密码套件列表。虽然不常见，但在最坏的情况下，密码套件可能根本没有为TLS通信定义加密。其他密码套件定义了可以被加密攻击的算法，不应该再使用。本节没有列出所有密码及其漏洞，但是使用不安全的密码套件是评估的一部分。

服务器的身份验证基于服务器的证书[12，21，51]。证书必须符合某些标准才能被客户认为是有效的。它必须是为所请求的域颁发的，不能过期或被撤销，并且必须是可信的。在PKI中，客户端信任ca颁发的根证书。这些ca使用相应的私钥对服务器(或其他子ca)的证书进行签名。当客户端验证服务器证书的有效性时，它将从服务器证书开始遵循此信任链，直到引用客户端受信任根证书中的一个证书。证书(链)问题也是本研究的一部分。

旧的SSL和TLS版本容易受到某些破坏其安全性的攻击。除了旧版本的漏洞之外，与实现相关的问题(如Heartbleed等)也是相关的。心脏出血是流行的OpenSSL加密软件库中的一个问题。如果库没有打补丁，攻击者就可以从服务器读取内存内容。另一个最近(2017年12月)发现的攻击利用RSA实现中的一个问题，使攻击者(ROBOT)可以观察到密钥交换[19]。支持RSA密钥交换的服务器，如果使用易受攻击的实现，就有被攻击的风险。52]。前面讨论的BEAST漏洞的一个相关漏洞也支持针对TLS 1.2的攻击。它被命名为“容易的压缩比信息泄露”(CRIME)，并与使用数据压缩的协议(如HTTPS)使用cookie一起工作[53]。它可以用来观察和使用客户端的身份验证cookie来实现进一步的攻击。该漏洞可以在客户端和服务器端进行抵消。通过超文本自适应压缩的浏览器侦察和泄露(BREACH)攻击是CRIME的一种变体，可以达到类似的效果[53]。有关已知针对TLS的攻击的全面概述，可参阅互联网工程任务组(IETF)的征求意见稿(RFC) [53]。在测试期间会考虑对已知攻击的脆弱性。

由于服务器的物理位置对适用法律有影响，因此本研究将考虑服务器的位置。具体来说，这项研究列出了服务器是否在欧盟(EU)境内，因为处理属于欧洲公民的数据的服务提供商在欧盟以外托管这些数据并仍然遵守《一般数据保护条例》(GDPR)是相当困难的。[54，55]。明确的例外情况是欧盟以外符合gdpr的服务器受欧盟-美国隐私保护的保护[54，56]。正如限制部分所提到的，本研究没有区分欧盟以外符合gdpr的服务器，服务器只是被列出位于欧盟以外的地区。

选择合适的测试工具

测试的第一步是找出哪个应用程序与哪个后端通信。与之前的研究类似，BProxy工具被用来促进第一个测试阶段[3.，57]。该软件在运行应用程序的设备和互联网之间充当代理。它是开源的，可以在GitHub上找到[57]。代理会对来自该设备的所有流量进行分析，并生成报表。由于本研究关注的是服务器端传输安全方面，因此仅对应用程序通信的服务器域名和不安全连接的使用感兴趣。由于代理记录进出设备的所有流量，过滤是必要的，以找出哪些域是应用程序后端的一部分。检查流量以区分与应用程序相关的服务器和其他服务器。为了便于正确分类，使用了断开连接服务，并对结果进行了手动检查，类似于先前出版物的方法[3.，58]。

为了测试域名后面的服务器，我们选择了testssl脚本和Qualys SSL Labs测试套件[59，60]。testssl脚本使用OpenSSL从本地计算机对目标服务器执行测试。它生成一个逗号分隔值(CSV)文件，其中包含域的所有发现。脚本检查一些相关的特征，包括所有描述的相关关注点。该脚本被积极开发和维护，以包含对最近发现的漏洞的测试。在测试时，ROBOT攻击相对较新，并且已经包含在testssl脚本的开发版本中[19，59]。SSL Labs测试套件是用于SSL/ tls相关测试的基于web的工具。Qualys SSL Labs还为测试自动化提供了一个命令行参考实现[61]。结果包括与testssl脚本相似的属性，但重要的是分配了一个分级分数a到f。这个分数是对观察到的特征和漏洞进行自动评估的结果。关于如何计算这个分数的指南，以及SSL实验室如何评估安全特征的严重性，可以在GitHub上找到[62]。此评级指南由Qualys定期更新，并且可以在前面提到的指南中找到变更日志。评级由多个考虑因素组成，包括除第一个项目之外的所有项目表1:(1)服务器使用的证书的有效性和可信度，(2)支持的协议(SSL 1.0到TLS 1.3)，(3)支持的密钥交换算法(旧算法由于安全问题得分较低)，以及(4)支持的密码套件(如果不支持安全的，最新的密码套件，等级会更低)。

每个类别的得分在0到100之间。这些分数被合并，结果是服务器的单一总分。任何一项得分为0，总分为0分。虽然分数低导致整体结果较低，但类别中的0表示存在致命的安全问题。根据Qualys SSL实验室的服务器评级指南，在支持的协议类别中计算分数的示例如下:

1. 从最佳协议的得分开始。
2. 将最差协议的得分相加。
3. 将总数除以2 [62]。

表2在撰写本文时，列出了Qualys SSL Labs为每个支持的协议版本分配的分数。例如，只有在只支持SSL 2.0的情况下，这个类别中的0才会出现。由于这是一个过时且不安全的版本，因此0分是合理的。其他类别以类似的方式进行评估。

不能被分数捕获的服务器配置由特殊规则来解释，以纠正计算的分数[62]。一个被评为B的服务器的例子，在每个类别中的得分可以观察到图1。

‎ 查看此图

基于一组不断更新的规则的总体得分，以及用于服务器安全评估的2个源的附加安全性是使用testssl(版本:2.9.5dev)和Qualys SSL Labs套件(版本:1.32.6)的原因。为了确定服务器的物理位置，我们使用了基于web的服务[63，64]。为了聚合结果，选择了一致的逻辑。对于负面观察(例如低于a范围的评级，包括来自Qualys SSL Labs的评级a +， a和a -)，记录给定类别中最差的观察结果。对于积极的观察，应用相反的逻辑:当至少有一个服务器支持该特性时，应用程序的一个类别被视为支持积极特性(如HSTS和TLS 1.3)。

限制

作为本研究的一部分执行的测试侧重于传输安全性和服务器端TLS配置中的弱点。这项研究并没有对发现的每一台服务器进行全面的渗透测试。虽然可用性是服务器的一个重要特征，但这个属性并不是我们测试的一部分，因为测试拒绝服务(DOS)加固需要对DOS攻击进行阶段性测试[6]。如果没有每个应用开发者的合作，这在法律上是不可能的[65]。

由于本研究侧重于服务器端，因此没有测试应用程序中的正确证书验证，也没有分析流量是否有任何类型的泄露信息。

不能正常运行的应用程序无法进行功能测试，并在应用程序选择过程中被删除。这包括阻止我们的测试工具进行流量检查的应用程序。这些应用程序可能使用证书固定来确保服务器的身份。

应用程序测试是手动执行的。不能保证完整的功能覆盖。特别是付费墙背后的功能(游戏邦注:如应用内部购买或类似设施)仍未经过测试。

将服务器分类为功能性后端或其他是通过基于web的服务进行的，该服务保留了已知广告和跟踪服务器的列表，但在某种程度上，必须手动执行[58]。对不确定情况下的分类进行了谨慎检查，但仍可能包含错误。

服务器的位置很难确定。服务器可能位于欧盟内部，尽管我们使用基于web的服务进行的测试确实声明了不同的位置。服务器通常用于回答来自不同地区的请求。来自欧盟内部的请求可能由爱尔兰的服务器应答，而来自美国的请求可能由位于美国的服务器处理。

位于欧盟以外的服务器可能会受到欧盟-美国隐私保护的保护[56]。这允许机构将数据存储在欧盟以外，但仍遵守适用的欧盟法律[54]。由于作者没有直接的方法来检查服务器是否是隐私保护的一部分或以其他方式符合GDPR，因此本研究中没有进行这种区分。

正确的证书验证依赖于可靠的PKI。研究显示，核证机关基于域名系统(DNS)的域验证并非总是可靠的，并可能被滥用，让核证机关为任意域颁发证书[66，67]。拥有请求的域名的有效证书的攻击者可以冒充一个真实的服务器，即使客户端应用了正确的证书验证。由于这是CA的责任，而应用程序提供商在这方面没有控制权，因此本研究不会进一步解决此问题。

结果

应用程序选择

为了选择一组移动健康应用程序样本，我们将Android和iOS应用程序商店中下载次数最多的免费应用程序列表作为起点。的医疗类别被选中是因为它最有可能包含移动健康应用程序。在之前的研究中，来自3个不同国家的应用程序发现了类似的客户端安全问题[3.]。不同国家商店的应用程序之间的行为差异并未被发现。在这项研究中，我们考虑了来自德国谷歌Play商店的30款应用和来自iOS AppStore的30款应用(总共60款应用)。2018年8月31日，应用商店分析网站AppAnnie生成了热门下载榜单[68]。在网站上注册后，可以查看特定日期的热门列表。的医疗类别包括实现广泛功能的应用程序。出于这个原因，两个应用商店的应用都被分类了。中的所有子类别医疗中列出并定义了类别多媒体附录1。本研究选择的5个子类别是(1)生育、怀孕和为人父母;(二)药品信息、购药情况、合规情况;(3)借鉴学习;(四)协商、沟通、互动;(5)健康、健身和监测。

为了提高多样性，我们选择了这两个类别中排名最高的6款应用。如果选定的应用无法在测试设备上进行测试，则选择同一类别中第二受欢迎的应用。这是9个应用的情况。在这60个应用程序中，有26个(26/60,43%)在法国、英国或美国的500强榜单中至少有一个，涵盖了国际上相关的移动健康应用程序的一部分。应用商店的顶级位置、开发者信息和应用的子分类都可以在上面看到多媒体附录2和3.。

执行测试

为了帮助并行应用测试，我们分别测试了iOS和Android应用。两个平台的所有应用程序都是从各自的应用商店下载并安装在设备上(iPhone 7上的iOS 11.4.1和Nexus 7上的Android 6.0.1)。在任何测试之前，应用程序都被停止和重新启动。如前所述，设备被设置为对所有HTTP/S流量使用HTTP代理。BProxy工具用于编译相关域的列表。

许多应用程序与过多的端点进行通信。此外，Android或iOS操作系统还通过HTTP/S连接进行通信，用于多种目的，包括获取邮件、检查更新和发送分析数据。为了过滤在应用程序测试期间观察到的域，使用多个应用程序运行来尝试区分应用程序流量和背景与应用无关的流量。此外，进行了手动过滤。来自操作系统的服务调用(例如邮件服务器通信)被忽略。必要时，为应用程序创建一个帐户并为测试激活。

使用bash脚本依次测试每个剩余的域，使用testssl脚本[59]。Qualys SSL实验室服务器测试基于web的工具提供了一个批量应用程序编程接口(API)来测试多个域。这两个工具都返回JavaScript对象符号格式文件[59，69]。为了达到生成信息丰富且易于理解的结果的目标，决定区分后端、广告或跟踪器或分析、外部内容和其他服务器。功能后端类别包括直接为应用程序提供功能内容的服务器，通过应用程序的输入执行操作，并且似乎在应用程序开发人员的控制之下。所有其他的服务器被分类到第二类其他服务器，包括所有提供广告、跟踪用户活动和/或为应用程序提供商提供有关应用程序使用信息的分析服务的一部分的服务器。分类通过评估域名和使用BProxy分析HTTP/S流量来执行。分类为其他使用断开连接服务改进了服务器，532个服务器中有311个(58.5%)其他服务器列表[58]。

图2显示所描述的工作流的图形表示形式。为了帮助评估和编译结果摘要，使用了R编程语言(版本3.4.2)[70]。阴性和阳性观察分别收集。在编制摘要期间，测试期间对服务器的负面或正面观察结果将被计算为整个结果功能或其他对于一些分析，这些集合被组合起来，以获得一般医疗应用的结果。

‎ 查看此图

总结的结果

测试的60个应用程序与823个不同的服务器进行通信。可以观察到与应用程序通信的服务器数量分布表3。所有应用程序都与功能后端之外的服务器进行通信。跨两个平台的应用程序与其他服务器通信的中位数为18.5。Android应用的中位数(24.5)是iOS应用(11)的两倍多。在最引人注目的案例中，一款安卓应用程序与82人进行了通信其他超出其功能后端的服务器。

为了便于对总体结果进行评价，将结果分为阳性结果和阴性结果，并在表4和5。这些列表列出了函数和其他后端的结果。由于功能性后端提供与应用程序功能直接相关的请求，所以这些是最有趣的结果。

安全测试的详细结果可在多媒体附录2和3.。他们列出了每个应用程序和每个功能的调查结果。详情请参阅多媒体附录4和5。这些附录中的表格包含了每个应用程序到服务器的连接数，这些服务器显示了本研究的一部分安全特征。

在测试的应用程序中，有28个(28/ 60,47 %)使用的服务器至少有一个功能后端被Qualys SSL Labs评为非a级。相比之下，有48款(48/ 60,80%)应用使用广告、分析或外部内容提供商(其他)获得低于a的评级。

关于TLS 1.2的支持，只有8个(8/ 60,13 %)应用程序使用了不提供TLS 1.2的功能后端服务器(3个iOS应用程序和5个Android应用程序)。除了一个应用程序外，所有应用程序都只使用了提供TLS 1.2的其他服务器。

在使用12个(12/ 60,20 %)应用程序时，观察到没有设置密码顺序的功能后端服务器。其他没有密码命令的服务器被5个(5/ 60.8%)应用程序使用。

结果发现，14个应用程序(14/ 60,23%)使用的功能后端没有为所请求的域名提供有效证书。这还包括由于任何原因(证书链问题和域名不匹配)而无法进行适当验证的证书。其他服务器上也有20个(20/ 60,33 %)应用出现了这个问题。

我们发现有9个(9/ 60,15 %)应用程序使用功能性后端服务器，而这些后端服务器由于存在漏洞而被Qualys SSL Labs降级。更多应用与其他被降级的后端应用进行交流(15/60,25%)。导致降级的漏洞与服务器端支持某些密码套件或未修补的实现有关[62]。对贵宾犬攻击的脆弱性是导致降级的最明显问题。这些表格多媒体附录2和3.可以咨询更多信息。

在测试期间，我们发现有45个(45/ 60,75%)应用程序似乎使用了欧盟以外的一些功能后端服务器。对于所有60个(60/60,100%)应用来说也是如此。

除了4个(4/ 60.7%)应用程序之外，所有应用程序在至少一个功能正常的后端服务器上都支持前向保密。除了2个(2/ 60,3 %)应用程序外，至少有一个后端服务器支持该功能。

在测试期间，我们还记录了应用程序与服务器之间完全不安全的连接。在20个(20/ 60,33%)应用程序与功能后端服务器通信期间观察到这一点，在18个(18/ 60,30%)应用程序与功能后端服务器通信期间观察到这一点其他后端服务器。

在对测试数据的评估过程中，一些应用程序显示出特别严重的问题，并且导致了列表中列出的许多问题表4。例如，一家应用提供商总共提供了4个应用(2个iOS和2个Android应用)。所有这些应用程序都与不支持最新TLS版本的后端进行通信。此外，发现这些应用程序混合使用未受保护的HTTP和受保护的HTTPS连接与后端进行通信，进一步破坏了通信的安全性。

结果发现，在291个功能正常的后端服务器中，有15.1%的服务器被Qualys SSL Labs评为A级以下。在测试的532个非后端服务器中，18.8%的评级低于A范围。Qualys SSL Labs的SSL Pulse网站列出了服务器常用的安全特性。他们总结了这些数据，并显示了评级低于a范围的服务器的百分比。在2018年9月的统计数据中，在139849台服务器中，37.75%的服务器被评为非a级。卡方检验(alpha= 0.05)显示，移动健康应用程序的测试服务器的评分明显高于SSL Pulse观察到的服务器(P<。001for both functional backends as well as others) [33]。

每个子类别之间还进行了卡方检验，以确定与非a级服务器通信的应用程序的数量。在这些统计测试中，iOS和Android应用以及功能和其他服务器没有区别。人们发现参考与学习在这两种情况下进行测试时，应用程序的评分明显更低生育、怀孕和为人父母(α= . 05;P= .02点),药品信息、购物、合规(α= . 05;P= . 01)应用程序。其他类别之间无显著差异。对比国际应用和只出现在德国榜单上的应用，我们发现国际应用的表现要好得多(alpha= 0.05;P= 03)。在这个测试中，任何在美国、英国或法国排名前500的应用都被认为是国际性的。

观察可以观察到的有规律接触的域表6，这10个最受欢迎的服务器背后的服务从许多被测试的应用程序中接收数据，并能够重建一个全面的用户档案。

许多广告和分析公司运营多个二级域名。使用断开连接。我们的列表显示，大量被请求的域名属于bb0和Facebook的服务[58]。谷歌在概述中非常普遍。几乎所有(55/60,92%)应用程序都在谷歌API域下与服务器通信，10个最常观察到的二级域中有8个属于该公司。

在接受测试的60款应用中，有17款为某些广告或追踪服务提供了用户可控的退出选项。在早期的研究中，这些选择被认为是可取的[3.]。

至于积极的观察，在与功能后端服务器通信时，有9个(9/ 60,15%)应用程序支持TLS 1.3，与其他后端服务器通信时有38个(38/ 60,63%)应用程序支持TLS 1.3。在27个(27/ 60,45%)应用程序中至少有一个功能后端服务器支持HSTS，在45个(45/ 60,75%)应用程序中至少有一个功能后端服务器支持HSTS。很高的百分比其他人分类的部分原因在于计算结果的方式。其他服务器的数量通常高于功能后端服务器的数量，并且使用布尔或连接将积极观察结果组合在一起。要进一步了解应用程序后端有多少服务器显示了哪种安全特性，请参考多媒体附录4和5。

讨论

主要研究结果

一些后端显示有问题的特征。最有问题的情况是无效的服务器证书。在这些情况下，客户端无法区分真实服务器证书和试图进行MitM攻击的第三方证书。使用过时的TLS协议版本可能会导致显示或发送到服务器的数据出现完整性、真实性和机密性问题。受影响的应用程序确实促进了医疗和药物信息和互动检查，以及患者与医疗保健专业人员的沟通。后一种情况可以暴露患者信息，并使医疗保健专业人员能够向患者捏造答案。

与浏览器相比，移动平台上的应用程序有一个缺点:它们可以(并且确实)向用户隐藏传输安全问题。虽然私有数据可能在没有正确保护连接的情况下被发送到服务器，但开发人员可以选择忽略这些问题。另一方面，当一个网站只能通过不安全的连接连接时，浏览器会显示安全警告，并使用户更难进行交互[71]。苹果的应用传输安全的努力是朝着正确的方向迈出的一步，但仍然允许例外的应用指定的url。72]。评估移动操作系统监控来自应用程序的所有流量并警告用户不安全连接的可能性可能是进一步工作的目标。

那些本地化、可用且在德国应用商店以外的地区取得成功的应用，意味着拥有更多资源的大型组织。这些组织还需要投入更多的资源来维护他们的服务器(安全)。国际流行应用的表现明显更好的观察结果证实了这一预期。

正如m thing等人在研究中所讨论的[3.]，在医疗应用程序中使用广告和跟踪服务可能会构成挑战。这些服务让应用开发者能够深入了解应用的使用情况。但这些服务也会收集数据，用于进一步盈利和数据挖掘。73]。由于医疗(患者)数据在特殊管辖范围内受到保护，并且出于道德原因应予以保护，因此必须对使用任何第三方服务进行审查。对于许多应用程序，测试显示使用了来自不同服务的大量服务器。大量应用程序使用相同的服务进行广告或分析，这可能会带来问题。这些服务可以跨多个应用收集用户信息[73，74]。另一个需要注意使用第三方服务的原因是，大量用于广告或跟踪的服务器在Qualys SSL Labs中获得了非a级评级(占所有应用的48%)。

看看关于服务器位置的结果，所有(60/60,100%)应用被使用其他欧盟以外的服务器。在查看源数据时，可以观察到这些服务器通常与跟踪、分析和广告相关。

数据还揭示了仅考虑服务器设置时无法直接看到的严重问题:观察到应用程序在与同一服务器通信时使用完全不安全的连接或混合使用安全和不安全的连接。尽管后端服务器可能被设置为使用最先进的TLS和证书，但这总是会破坏潜在的安全性，并将用户数据置于危险之中。

前向保密的广泛支持(功能性:15%，其他:63%)可以被视为积极的，因为它可以防止未来未经授权的敏感数据解密，并为连接攻击带来性能负担。支持HSTS的服务器中的高数量(功能性:45%，其他:88%)可以帮助减轻协议降级和cookie劫持攻击。

在本研究的前期准备阶段，以及到目前为止讨论的测试之前，测试了40个移动健康应用程序。最受欢迎的20个应用程序医疗来自德国iOS和Android应用商店的游戏类型也采用了与本文所述非常相似的方法进行测试。这40款应用的描述、分类和总结结果可以在多媒体附录6。每个应用在Android和iOS测试的详细结果可以在多媒体附录7和8,分别。一些应用程序在两次测试中都进行了测试。尽管早期的结果显示，获得Qualys SSL Labs评级低于a范围的功能后端数量较少(2018年初为28%，2018年9月为47%)，但也有可观察到的积极发展。2018年初，在一个无功能的后端中可以观察到机器人攻击的漏洞，但在后来的测试中得到了修复。获得低于a范围评级的后端相对增加，可能是由于分类的差异，但也可归因于Qualys SSL Labs评级计算算法的变化[62]。这种动态是TLS部署的安全生态系统的快节奏特性的特征。虽然服务器由一些提供商维护，但新漏洞的发现和旧漏洞的重新发明导致了新的威胁，这使得服务器管理员和(移动健康)应用程序提供商必须保持警惕。从服务器的等级来看，其明显的安全性恶化可能表明应用程序提供商在保持其TLS部署安全方面的步伐较慢。

常见的安全问题和建议

下面列出并总结了常见的安全问题。提出预防、缓解或减轻影响的建议:

1. 应用程序被发现使用没有有效证书的服务器，无论是用于其功能后端还是用于其他目的。这是有问题的，因为这意味着应用程序中缺少或错误的证书验证。当客户机不期望从服务器获得有效凭证时，任何攻击者都可以提供同样无效的证书并冒充服务器。这会导致MitM攻击。强烈建议使用受信任的CA，并为要保护的域颁发有效证书。
2. 许多应用程序通过不安全的渠道与服务器通信。为了发现和防止应用程序和用户使用不安全的连接，可以将服务器配置为使用HSTS。此外，应该检查客户端应用程序，并删除任何不安全的URL方案。
3. 在多个应用程序的服务器后端发现了不安全的服务器配置，这表明Qualys SSL Labs的评级较低。这包括缺少一组密码顺序和对易受攻击的密码套件的支持。可以利用这些漏洞破坏使用TLS提供的安全性。不安全的服务器配置可能会随着时间而改变。任何时候发现新的漏洞和/或被广泛利用，服务器操作员都应该更新其服务器的配置。要使服务器配置尽可能安全，应了解基本的安全问题[5]，安装服务器端安全补丁，并且应该使用类似Qualys SSL Labs服务器测试的服务对域进行测试[60]。
4. 大多数应用使用多个广告或分析服务器。这不仅增加了应用程序(对于医疗应用程序)使用的数据和处理器时间，而且由于分析数据可能会破坏用户或患者的隐私，因此问题尤其严重。例如，寻找与怀孕相关内容的患者可能怀孕了。此外，大多数此类服务似乎都位于欧盟以外，而且大多数应用使用的至少一台此类服务器被Qualys SSL Labs评为低于a级。虽然广告和分析服务在移动应用中很常见，但移动健康应用开发者应该彻底重新考虑使用此类第三方服务和框架[73-75]。一种可能的折衷办法是为用户提供选择退出功能[3.]。

结论

我们对流行子类的现代移动健康应用程序进行了深入测试，并分析了它们的行为。虽然移动健康应用程序的服务器表现明显优于一般服务器，但大多数应用程序与不同运营商的大量不同服务器进行通信。据观察，这些服务器和与它们的连接通常不如与应用程序功能后端的连接安全。其中一些服务器背后的服务(广告和应用分析)也应该在用户或患者数据保护方面被批判性地看待。几乎一半的应用程序与不提供安全TLS设置的功能后端进行通信(非a级Qualys SSL Labs评级)。

在少数应用程序中观察到的最严重的问题可能会暴露患者与医疗保健专业人员的通信，被利用来向用户显示虚假或有害信息，或用于向应用程序发送数据，从而进一步损坏设备。这些问题包括通过完全不安全的连接进行通信、安全连接和不安全连接的混合、服务器使用的无效证书、证书链验证问题、缺少对现代TLS版本的支持以及未修补的漏洞。

将本研究的结果与以往的研究结果进行比较可以看出，服务器的安全性很大程度上依赖于漏洞的存在和传播。处理(潜在的)敏感信息的移动医疗应用程序提供商应该更有兴趣保持其服务器的最新状态并修补漏洞。

应用程序开发人员可以使用前一节提出的建议来改进他们的运输安全设置，防止将患者和/或用户置于危险之中。