英语原文共 17 页，剩余内容已隐藏，支付完成后下载完整资料

Android应用程序https实施调查：问题和对策

第三部分翻译

3.HTTPS滥用的深入原因分析

在本节中，我们将研究有损SSL/TLS实施安全性的问题，特别是基于Android的设备。首先，我们将介绍使用当前Android HTTPS实现的SSL不安全的主要原因。尽管开发商希望确保应用程序的唯一指导是Android系统中的一些基本框架，但安全性必须通过手动将自定义安全功能集成到项目中，同时保留功能和连贯的形式。这个过程可能是临时的，容易出错，重复和不精确[43]，如上一节所示，漏洞和差错是猖獗和积极利用的。修补这些缺陷的第一步是确定其起源。存在根植于移动应用开发范例，服务器配置，Android文档，SSL/TLS库，SSL TLS协议和应用程序消费者的问题。广泛的研究已经确定了每个因素的根本原因。本节将进一步调查这些原因。

3.1。开发人员滥用HTTPS

在审查的文件中，HTTPS配置中最常报告的缺陷是由于开发人员的疏忽。有这样一个问题便是生产应用程序中留下的调试代码。这个问题不是新的，它已被列入通用弱点枚举[44]中，绕过标准程序来使应用程序在开发中运行的剩余代码和片段对应用程序安全性有着广泛的影响[8]，讽刺的是，剩下的调试代码可能违反其模型系统应该负担的保护。 HTTPS无法避免开发故障，程序的作者会遗漏易受攻击的代码，或者在其应用程序中特别是在Android上安排有意的覆盖。这可能是以下情况的形式，为了使应用程序填充和显示开发人员的数据，必须设置证书验证以允许来自模拟服务器的数据流。这允许作者确保应用程序的其他组件正常运行，但是除非重新启动证书检查，否则会使HTTPS连接容易受到攻击。这种情况发生在不幸的频率，因为有一些简单的机制，我们稍后会讨论，以防止在生产应用中出现无意的剩余调试代码。开发人员需要顶级安全性，也希望他们的产品在开发中正常运行[24]，这会导致复杂设置（如SSL/TLS）的问题。如前所述，HTTPS通信范例中最重要的部分是存在有效的证书和认可的证书颁发机构。当运行服务器和应用程序时，开发人员可以使用自签名证书来构建其服务器进行开发，并且在获得正确的CA签署的证书或绕过此选项时，忘记更改应用程序的验证过程，以备其他原因[39,45]在调试时运行没有SSL/TLS保护的应用程序显然是无害的，但一旦这些应用程序向公众开放，数据被盗窃的风险就极大。除了检查代码本身，向开发人员讲述他们的错误和安全漏洞，可以更全面地了解这些基于开发人员的缺陷的原因。 Fahl等进行的一项研究[24]显示了受访开发者的几个趋势。

（i）开发商犯错误。在联系过错的开发商时，许多人接受了建议并修正了错误。但其他人则拒绝承认这个缺陷是一个问题[39]，这些错误是可以理解的。 Android是一个复杂的系统，即使使用高级图书馆，公钥密码术也不容易掌握。本次调查中开发人员的惊人拒绝和否认可能是由于错误地执行代码而感到尴尬。然而，对于开发人员愿意并且不愿意承认SSL配置错误的应用程序，似乎很明显，开发过程中的代码覆盖率有所下降。

（ii）另一个解释可能是对SSL/TLS安全性主题的冷漠或简单的无知。 Xie等人的一篇论文[14]发现，尽管许多实验参与者对软件安全性有一般的了解和认识，但这些知识与参与者报告的实际做法和行为之间存在差距。尽管有一般的安全知识，但他们无法给出他们个人安全实践的具体例子。在同一研究中，谢等人注意到“不是我的责任”态度普遍存在。开发人员经常依赖其他人，流程或技术来处理应用程序的安全方面。当这些软件作者如此忙于其产品的纯粹功能和可行性以及即将到期的时限时，显而易见的是，安全帽在团队的另一个成员上看起来更好。不幸的是，代码审查和质量保证只有到目前为止，特别是在回顾性地考察应用程序时。在理想情况下，从设计到部署的开发过程的每一步都考虑到安全性。如本报告所示，在许多开发环境中并不是这样。

（iii）在线论坛和用户到用户资源可能不是开发人员滥用SSL的原因，但它们允许开发人员发现绕过安全措施以解决错误的方法。一个这样的网站是堆栈溢出。通常，解决问题的时候，提出问题的开发人员错误地写了一大堆代码。在这些情况下，堆栈溢出以重要的，积极的方式运作。但是，

SSL错误的情况下，在不配置服务器的情况下停止错误的最简单的方法是停止应用程序抛出错误。图3和4显示了Android SSL证书到期覆盖的示例。虽然大多数受访者解释说，这些解决方案在给出示例覆盖之前不应该在生产环境中使用，但是一些答案，如图1所示。 4，不提供这个上下文。由于这个原因，这个答案很可能得到了负面的反馈。然而，给出了近10,000观看次数，这个解决方案几乎可以肯定地在开发人员的生产应用中。周到的答案往往与这些网站上的安全性较低的响应相结合，从而允许有害的编程范例在线开发。例如，开发人员可能会要求通过Apache HttpClient中的UntrustedCertificate错误，并且答案可能是使用定制SSLSocketFactory来信任所有主机[47]当然，那些回答问题或其他社区成员的人可能会强调这不应该在生产中运行，但解决方案仍然是以绝望的开发人员快速找到工作的方式呈现的-周围。 Stack Overflow等网站不鼓励应用设计人员自定义SSL/TLS实现，以使用自签名证书并接受生产中的所有主机，但它们会显示开发人员如何在测试中使用它们[39]，Stackoverflow不能被指责Android也不能开放的开发风格。这些情况下的错误是开发人员忘记删除替代代码，或忽略在生产应用程序中使用接受所有策略的警告。

尽管Android开发和生产应用程序中存在许多缺陷，但没有实际证据表明，与其他类似情况相比，Android开发人员比SSL更为笨拙。 iOS应用程序的调查显示，这两个平台具有相当数量的SSL/TLS漏洞[39]。所谓的围墙花园方法似乎没有解决开发人员滥用HTTPS的问题。将开发人员知识缺乏与不正确的SSL连接相关联可能是有意义的，但是说Android特定的开发范例会导致这些错误是不正确的。如果发现有任何缺陷，那么移动应用程序的缺乏监督就是缺乏监督。另一个更具社会因素的因素可能会导致这些开发人员的错误，从而影响HTTPS呼叫的安全性。谢等[14]表明开发人员环境（团队成员，支持人员，经理等）有可能导致他们犯错误的问题。一个这样的问题是错误的信任过程。这涉及到软件安全只是在代码审查阶段进行追溯或调查。其次，有一种感觉，一个软件工程师如果没有专门的工作，就不需要知道漏洞。这就像设计后端而不注意前端。软件不是上下文的，最终项目中的所有组件都需要在该过程的每个步骤进行设计，开发和审查。团队的每个成员都应该意识到他们正在做什么，以创建最准确和统一的产品。最后，对开发人员最为认可的是存在外部约束，从而在人类层面上影响工作流和编程过程。这些包括最后期限，客户期望，政府政策以及阻止开发商按照自己想象的方式创建产品的任何限制因素。当预算紧缩或截止日期接近时，当客户的主要焦点是功能和设计[14]时，适当的安全性可能是一个不幸的牺牲[14]。除了缺少对HTTPS标准的理解之外，这些外部约束潜在地阻碍了开发人员的解决方案开发人员面临压力，最后期限，不完善的支持系统，以及公钥基础设施和Android的复杂性。这个系统一定会出现错误和错误的配置。当用户数据必须依赖于这个强调的作者时，会有严重的影响。虽然这些开发人员创建的应用程序是这个系统的突破点，但Android SSL连接中的开发人员错误和一般不安全性还有几个原因。

3.2。服务器配置错误

在TLS系统的另一端是HTTPS服务器。设置Apache HTTPS服务器并不困难[48]。此外，这些服务器的安全性可以轻松设置得更高[49]，尽管如此，前100万网站中只有45％支持HTTPS [50]。此外，在HTTPS上操作的系统可能存在可能完全危及SSL安全性的缺陷。 Korczynski等人[51]发现即使在一小部分互联网服务中，TLS协议的某些内容也被忽略或误用。这些大量被贩运的网站收到大量的流量和金融交易，这使得TLS的端到端实施更加强大。 SSL服务器探测[52,53]在积极的TLS实施和健康的密码使用方面呈现出上升的趋势，然而越来越依赖加密的数据流使得服务器端的协议的严格遵守在整个互联网域的有效安全性。 HTTPS服务器频繁发生的错误是使用自签名证书。自签证书，没有权限备份其有效性的证书在测试情况下工作良好，但是当服务器需要接受来自公共Internet的请求时，这些虚假证书是不安全的。在这种情况下，必须获得或购买从认证机构签发的证书。这些服务器将以与任何流量相同的方式处理Android流量，并导致移动流量的陷阱与桌面客户端一样。事实上，服务器配置最常见的问题是证书安装的不当操作[40]，证书管理不是一个自动化过程。从认证机构申请证书后，该证书将通过电子邮件发送给在请求中发送的公司。然后必须手动安装此证书，以便客户端相信服务器实际上是正确的。当证书在两年或三年的寿命期满后，必须顺利过渡到新的证书，以确保最大的正常运行时间。 Vra-tonjic 等人 [54]发现，在许多其他违规行为中，82.4％的被调查服务器使用过期或其他无效证书。再次，在Heartbleed错误之后的日子里，只有10％的易受攻击的服务器取代了潜在的受损证书。在这10％中，另有14％的用户重复使用了可能泄露的私钥[50,55]，这些情况证明了系统运营商在使用证书方面的困难。事实上，这些不正确执行的证书的流行对开发者和依赖安全Internet连接的服务有直接的影响。如果由于SSL错误，开发人员无法连接到其控制之外的服务器，则唯一的操作过程将是降低其应用程序的验证参数。 SSL连接的两端需要保持最高级别的安全性。为了在所有平台上接受开发人员的采用，系统必须显示合理级别的一致功能。证书管理是SSL的棘手和复杂的一个方面，需要进一步的研究，工具和观点才能实现可靠的状态。新兴技术在新兴业务世界中使证书管理更加棘手。内容传送网络（CDN）是分布在大型公共网站上的分布式服务器场。 CDN的服务器作为主要的Web服务器的代理，在直接的客户端 - 服务器关系的中间。这个中间人服务器必须被服务器信任，但是目前的任何方法都违反了SSL协议[15]。必须为X.509协议和认证机构行业创新创新方法，以应对扩展网站的挑战，以及需要证书正确安装的不断增加的重要网站池。在服务器正确安全之前，所有客户端应用程序的安全性将受到影响。开发人员会警惕使用协议，Android上的默认Internet连接方法将不会是HTTPS，直到它像清晰HTTP一样简单实现。

3.3。缺少HTTPS文档

除了SSL连接的物理限制之外，开发人员面临的问题之一是缺乏适当的文档，也是应用程序安全性重要性的基础。开发人员对安全软件开发的交互式支持研究很少[14]。这些信息对于揭示开发人员正确的方法，并指出他们以安全的Internet连接创建的方式至关重要。虽然Android平台自豪于使用易用性，但令人惊讶的是令人困惑。例如，对应用程序间沟通漏洞的金融应用程序的手动分析得出的结论是，由于开发人员对Android的复杂性造成困惑，造成了几个缺陷[56]，作者表示，他们认为这些错误是由安全意识开发人员表示，Android的Intent系统令人困惑和棘手的安全使用。这个与SSL/TLS在目的和架构上完全分离的主题表明，Android是一个复杂的系统，难以从前端开发人员的角度来理解。现有文档和教程没有有效地覆盖他们的受众。接近“复杂性”的问题并不是一次更新才能发生的事情。然而，为了进一步提高Android应用的安全性和正确的开发实践，操作系统的维护者必须努力抽象出复杂性或提出更好的文档。进一步的研究必须涉及技术文档理解背后的心理学，特别是对于Android。训练不足的一个例子也是最关键的。针对SSL/TLS的Android开发人员培训缺乏适当的示例和实现。安全性培训靠近屏幕底部，列出了用户界面和性能培训[12]。一般来说，协议或公钥密码术的说明最少。在流行的SSL/TLS库中缺乏稳固的文档也是一个问题[37]。 OpenSSL库文档[11]是一个肉色的网页，可以是相当吓人的。这可能是StackOverflow的快速代码段更具吸引力。在几个着名的图书馆中，有一些普遍混淆的API的例子。这将在下一小节中讨论。为了履行其在SSL实施中的作用，库必须为不是加密专家的开发者创建文档。主要的安全破坏方法，如AllowAllHostnameVerifier应该被记录为仅用于测试目的[57]。最后，编码中存在一些通常的障碍，需要进行细分，以便开发人员能够在其产品中正确构建安全的编程原理。 Ko等人的研究[58]已经提出了阻止解决问题的编程环境的要素的发现。这项研究的主要内容是，在许多主要的IDE和编程语言编译器中存在最小错误报告基础架构。似乎没有太多文档存在的隐形规则，编程接口的差异会干扰问题解决的自然流程。图书馆不仅需要更多的信息，而且应用程序开发工具应该足够聪明，以确定安全漏洞或通知开发人员最佳做法。一个坚实的文档来源可以响应用户的混淆，并有效地传达最简单而安全的解决方案。

3.4。 SSL/TLS库中的缺陷

理想的Android HTTPS库将使开发人员无需编码工作即可正确使用SSL，并防止他们通过定制来破坏证书验证[39]。这将是一个模型，其中认证机构的套接字生成和管理是分配给程序员的唯一职责。这将弥合建立HTTPS连接所需的控制设施之间的差距，使得无需让程序员参与已经复杂的HTTPS环境中每个基本接口的开发[29]。此外，API应允许在应用程序中进行一些放松的证书验证正在测试存在数十个库和SSL/TLS抽象框架，使HTTPS更易于使用。尽管Cairns等人的目标是使系统更加平易近人而其他人则表明主要的SSL/TLS库仍然过于复杂和低级[17,59]。 Fahl等声称没有可靠的库提供简单的SSL使用[39]。事实上，似乎对API的沮丧是开发人员使用StackOverflow找到解决方案的指导因素。 Georgiev 等人对由于

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[28184]，资料为PDF文档或Word文档，PDF文档可免费转换为Word