基于Android平台的手机订餐系统app设计与开发外文翻译资料

ABSTRACT

Android apps are becoming more and more personalizable, dealing with a userrsquo;s personally identifiable information. Such apps have a responsibility to protect this sensitive information that they send over the Internet. Recent research has showed that many applications are not protecting this information in transit. This work shows that developers are not implementing SSL correctly, thus leaving applications vulnerable to Man-In-The-Middle attack. This work identifies multiple reasons why developers use SSL incorrectly. We present an analysis of 240 open source and 13,000 popular free Android applications downloaded from the official Google Play Store. We show that a majority of SSL vulnerabilities in Android applications arise from incorrect implementation of SSL Pinning and residual active debug code in the deployed version of the application. We present solutions based on specification of SSL verification policy in the Android Manifest file. Our results show that using such configuration based solutions is a effective approach to mitigate SSL vulnerabilities in Android applications.

Chapter 1 Introduction

Smartphones are increasingly becoming an important part of our lives [28]. We have seen an increase in the usage of smartphones in our daily lives. A recent report by Flurry analytics [1] showed that 80% of the time spent on using the smartphones is spent inside applications. These applications are becoming more and more personalizable dealing with more and more user data. Since smartphones are resource constrained, their applications are written to suit a particular goal. Most of the computationally intensive functionality happens in the back-end servers and is presented to the user via a front-end client on the device. These clients transfer user data to and from these servers. These applications are handling various kinds of sensitive user data for example, banking applications deal with bank account numbers and passwords, social networking applications deal with contacts and photographs, etc. This data needs to be protected while in transit. To protect sensitive user data over the network from malicious entities applications use SSL

SSL stands for Secure Sockets Layer. It is the de facto standard for communicating securely over the Internet. SSL allows an application to connect to a server after verifying its identity. The security of SSL connections depend on correctly validating the SSL certificates presented by the server while establishing the connection. The main purpose of SSL is to provide end-to-end security between the client and the server.

A critical part of establishing a secure SSL connection is authenticating the server. If there is no authentication, it means there is no guarantee that the client is talking to the intended server. Server authentication takes place during the SSL handshake between the client and the server. When the server presents its public-key certificate the client is responsible to verify the certificate, to ensure that it is valid and signed by a trusted third party i.e. a Certificate Authority (CA) and that it has not expired. In the case of smartphone applications, it is the application that does the verification for the end user. The server may also verify the identity of the client. After successful completion of the handshake, a key is exchanged between the client and the server, which is used for encrypting the communications between them.

Up until the past few years, SSL was used predominantly by web browsers. There were a handful of web browsers and multiple eyes scrutinizing their behavior. Hence the SSL implementations for the desktop browsers have evolved and improved over the last two decades and many SSL related vulnerabilities have been discovered and fixed. However,this has changed with the advent of smartphones. Smartphone applications are able to browse web pages natively. SSL is increasingly being used in non-browser software, like WebViews [18] for Android. While using SSL in non-browser software the developer has to be careful to ensure that he is implementing all the checks necessary for creating a secure communication channel between the client and the server. Each application can have its own way of implementing SSL verification and validation checks. There are thousands of smartphone applications and very few people scrutinizing the implementation of SSL checks in each application. Thus there is no standard way of implementing SSL as there was while using SSL in web browsers. Thus it is possible that not every implementation of SSL is correct.

Last year, research has highlighted the flaws prevalent in the use of SSL in mobile and nonbrowser softwares. Fahl et al. [24] show how incorrect use of SSL in Android applications leave them vulnerable to Man-in-the-Middle (MITM) attacks. They were able to extract personal and financial information from certain apps that had incorrectly used SSL. Georgiev et al. [29] attribute a majority of SSL coding errors to the lack of conformity in the SSL APIrsquo;s provided by various libraries and lack of adequate documentation.

While Fahl et al. demonstrate the perversion of SSL coding errors in Android applications, they do not categorize the errors into ones introduced due to intentional developer code or ones introduced due to incorporation of a third party library. There is a need to differentiate between these errors because it will help in determining the solution to prevent vulnerabilities caused due to these errors. If a majority of these errors are caused due to the incorporation of certain libraries, we can emphasize the need for the creators of these libraries to make the necessary changes. On the other hand, if the errors are caused in majority by intentional developer code, then we need to identify the reasons why developers are choosing to do so and propose solutions to prevent the same. In either case, thes

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

摘要

Android应用正变得越来越个性化，很多时候会处理用户的个人身份信息。这样的应用程序有责任保护人们通过互联网发送的敏感信息。最近的研究已经表明，许多应用并不保护在途信息。这项工作表明，开发者执行SSL（安全套接层）不正确，从而让应用程序容易受到中间人攻击。这项工作是确定开发人员使用SSL不当的多种原因。我们提出的240分析开源13,000流行的免费Android应用程序从谷歌官方下载。我们表明，在Android应用程序大多数SSL漏洞从出现不正确执行SSL和剩余活动调试代码的部署版本应用。我们基于在SSL验证策略的规范提出解决方案Android清单文件。我们的研究结果表明，采用这种基于配置的解决方案是一个有效的办法，以减轻Android应用SSL漏洞。

1. 简介

智能手机正日益成为我们生活的重要组成部分。我们已经看到了智能手机在我们日常生活中的使用频率大增。最近的一份报告由Flurry 分析显示，人们使用智能手机的80％的时间是花在的应用程序上。这些应用正变得越来越个性化并且具有越来越多的用户数据。由于智能手机资源受限，他们的应用程序被写入以适应特定目标。大多数的计算密集的功能发生在后端服务器并经由设备上的前端客户端呈现给用户。这些客户机从这些服务器上转移用户数据。这些应用程序处理的各种敏感用户数据例如，银行应用处理银行帐号和密码，社交网络应用程序处理联系人和照片等，这些数据需要在传输过程中得到保护。为了保护敏感的用户数据免于恶意攻击，应用程序使用SSL（安全套接层）。

SSL代表安全套接字层。在互联网上，它是用于安全通信的实际上的标准。 SSL允许应用程序核实其身份后，再连接到服务器。SSL连接的安全性与否取决于正确验证所提交的SSL证书服务器在建立连接。 SSL的主要目的是在客户端和服务器之间保证终端到终端的安全。

建立一个安全的SSL连接的关键部分是验证服务器。 如果没有认证，它意味着无法保证客户机正在联络预服务器。服务器身份验证发生在客户端和服务器之间SSL握手期间。服务器将其公钥证书的提供给客户端，客户端负责验证该证书，以确保它是有效的和由受信任的第三方即证书签署机构（CA），并且它没有过期。在智能手机应用的情况下，它是的应用程序，不验证为最终用户。服务器还可以验证客户端的身份。握手成功完成后，一个键是在客户端和服务器之间交换，其用于在它们之间进行加密通信。

直到过去几年中，SSL是在Web浏览器主要使用。当时有少数Web浏览器认真检查自己的行为。因此，在过去的二十年中SSL桌面浏览器的应用已经发展和完善并且许多SSL相关的漏洞已经被发现并修复。然而，这种情况随着智能手机的出现已经改变。智能手机应用程序能够本地浏览网页。SSL正越来越多地在非浏览器软件中使用，比如Android网页视图。而在非浏览器软件中使用SSL的时候，开发者要小心以确保在创建客户端和服务器之间的安全通信信道实现所有必要的检查。每个应用程序可以有其自己的实现SSL的验证的方法和验证检查。有成千上万的智能手机应用程序但是极少数人审议SSL的检查在每一个应用程序的执行。因此，有没有标准实现SSL作为，而在网络浏览器使用SSL存在方式。因此，有可能不是每一个SSL的执行是正确的。

去年，有调查发现，在移动和非浏览器软件的使用普遍存在SSL的缺陷。Android应用程序不正确地使用SSL会使他们容易受到中间人（MITM）攻击。他们能够提取某些错误地使用SSL的应用程序的个人和财务信息。大多数SSL编码错误的在各图书馆和缺乏足够的文档提供的SSL的API与合同不符。

而Fahl等展示了SSL编码在Android应用程序错误的反常行为，他们不分类的错误，可能是由于开发人员有意的编写代码或引入第三方库。有必要区分这些错误，因为这能确定防止一些由于这些错误而引起的攻击。如果大多数错误都是由于某些确定库的引入，我们可以强调我们需要让这些库的创建者作出必要的变化。在另一方面，如果多数错误是由于开发人员有意的代码编写造成的，那么我们需要了解为什么开发人员都选择这样做，并提出解决方案，以防止同样的事故。在这两种情况下，这些错误导致应用程序容易受到中间人攻击。如果SSL连接被攻破，攻击者能够访问存储在应用程序中的用户敏感的个人信息。我们的工作重点是在程序开发人员程序开发过程中产生的漏洞。

当开发人员正在使用既不被自己信任也不被证书颁发机构信任的SSL证书时，他们需要在自己的应用中自定义SSL代码。由于这些证书不被系统信任，开发人员要编写它执行证书验证和主机名验证特定的自定义的代码。能够使用任何证书中的一个方法是，不执行任何SSL检查。信任某些证书的另一种方法是使用SSL Pinning。 SSL Pining是一种技术，它允许开发者信任少数或许不被系统所信任的特定证书。虽然这种技术允许开发人员使用他们自己的证书，如果写入实现SSL Pining代码是不正确的，它会让应用程序容易受到中间人攻击。我们的第一个假设是，SSL漏洞由于引入了不被Android系统所信任的SSL证书，这种漏洞可以通过将属性添加到应用程序，通知使用SSL Pining的系统特定证书的Android清单文件来防止这些漏洞（或CA）或一组证书（或CA的）。这减轻了选择使用SSL Pining的相关开发人员的负担。

开发人员经常在应用程序部署之前使用的开发服务器调试程序，在服务器上测试是一种常见的做法，这些服务器上经常有自定义的证书来避免在调试程序的过程中使用昂贵的SSL证书。由于这些服务器使用自签名证书，开发者可以禁用应用程序中的SSL检查或添加覆盖默认SSL检查并且不执行任何验证的新文件。

我们的假设是，一些SSL漏洞是由于开发人员不将所有的调试代码从应用上移除导致的，让应用程序很容易受到中间人攻击，并且可以通过SSL验证连接到应用程序的Android清单文件中的调试标志来避免此漏洞。这将通知系统，如果应用程序是在调试模式下，系统应禁用SSL检查，当从清单中移除调试标志之后，系统应该自动重新启动以前被禁止的SSL检查。这样就不需要开发人员记住他们在哪里禁用了SSL检查。

我们的研究重点是从上述两方案中提到的由开发所引入SSL漏洞。为了确定到底哪些Android应用SSL漏洞是由开发人员所造成的，我们从谷歌的Play Store中下载了13000流行的免费应用程序和并从F-Droid 库中下载240种开源应用程序，并研究它们相对于SSL用法的性质。特别是，我们分析了应用程序的漏洞，来抵抗由于开发人员错误引用SSL借口产生的中间人攻击。在这项工作中，我们选择学习Android应用程序有两个原因。首先，有开源的Android应用程式，允许我们直接查看应用的源代码。这使我们能够更深入地了解开发人员的编码过程及处理。其次，对于Android的多种工具，它允许我们反编译封闭源代码的应用程序。我们已经提供了正确使用SSL的代码风格并且能够识别在Android应用中错误使用SSL的方法。我们还展示了开发人员一些错误的使用SSL的做法。

1. SSL概述

2.1安全套接层（SSL）

SSL是用于在客户端和服务器之间提供终端到终端的加密的安全协议。在应用层实现创建SSL连接（证书验证和主机名验证）时执行安全检查。这就是为什么这些检查的实现是在应用程序中编码。该协议提供保密性，完整性和真实性。它采用对称加密来提供完整机密性和消息认证码。服务器主机名验证是SSL的重要组成部分，它提供真实性的连接。在本节中，我们给出了SSL的工作和中间人攻击的简要概述。

2.11握手

SSL握手是通过该客户端和服务器建立安全连接的协议。在SSL握手发生时，客户端（Alice）发起与服务器（Bob）连接的请求。在接收到请求的时候，Bob送他的SSL证书给Alice。Bob可以随意问爱丽丝她的证书，如果他想确认自己真的与Alice通信。后双方当事人已经验证对方的证书，他们将协商要用于本次通信的密码规范。Alice然后从提取Bob的公钥（PKB）并选择将被用于生成该会话的会话密钥（SK）的随机数（R）的。她用PKB加密R并把它发送给Bob。然后，Bob的SK使用R和双方之间的通信与SK加密的其余部分产生。

1. 确认

-a：服务器证书

-b：信托链

1. 验证服务器身份
2. 产生会话秘钥

Alice（客户机） Bob（服务器）

1. 生成客户端秘钥

【可选】：验证客户端证书

（1）客户端问候

-a：请求连接

-b：密码规范

（2）服务器端问候

-a：服务器证书，CA证书列表

-b：密码协商

-c：【可选】：客户端证书请求

（6）客户端秘钥交换

【可选】：客户端证书

加密回话

2.1.2信任链

在此SSL握手协议中，有两个步骤确认和保证连接的有效性和真实性，即Alice验证Bob的证书（证书验证和信任链），爱丽丝验证Bob的身份（主机名验证）。

在SSL握手，当Bob向Alice发送他的证书时，他也将包括一个书列表，包含发行人的证书颁发机构（CA），谁签字Bob的证书和所有中级证书颁发机构，包括根证书颁发机构。这个过程，沿着绿树证书颁发机构被称为信任链。Alice验证第一个证书是Bob的证书。然后Alice试图建立从底部开始证书链。每个证书必须由CA在其上方树（父CA）并且根CA应该是CA的爱丽丝信托一人签署。Alice也要验证证书是否过期，并且该CA证书有“CA”中的“基本限制”字段位设置。如果任根CA是不是其中一人爱丽丝信托或中级CA的证书之一，是无效的，应该关闭连接，因为它不被信任。

2.1.3主机名验证

如果建立信任链，Alice下一步要做的就是使用主机名验证Bob的身份。如果主机名是可用的，客户机必须检查其对服务器的身份作为服务器的证书呈现。如果类型DNS名称的SubjectAltName扩展存在，必须使用其作为身份。 否则，必须使用（最具体）通用名称的证书的主题场。虽然使用通用名是现行做法，但是它要被废弃并且鼓励认证机构使用DNS名称来代替。通用名称字段应该只进行检查，以确保向后兼容性。

一旦Alice创建服务器标识符的列表，她就尝试匹配Bob的完全限定域名的标识符。匹配使用由RFC6125[47]中指定的匹配规则进行的。如果给定类型的一个以上的同一性存在于证书中（例如，多于一个DNSNAME名称，在该组中的任何一个匹配被认为是可以接受的。）的名称可以含有被认为是匹配任何单个的通配符*域名组件或部分片段。例如，*.a.com匹配foo.a.com但不阻止foo.a.com。 Alice可以使用直接字符串比较或者找一个通配符形成标识符的列表。通配符匹配的规则是相当复杂的，特别是如果它们是由国际特殊字符。

2.1.4证书吊销

我们的工作重点放在服务器身份的不正确验证上面，但是证书验证的完整过程涉及到要进行更多的检查。它们是安全的必要条件，但不是或者不完全是软件的处理不当。

其中的一项措施就是检查证书吊销列表（CRL）。有几个原因吊销证书。为得到妥协证书或不再被授权使用该证书的证书的用户私有密钥是其中的一些。确保用户知道哪些证书被吊销的一种方法是使用CRL。这涉及到搜索CA定期发出签署CRL。CRL是一个带时间标记列表标识由CA或CRL发放签名的吊销证书。CRL会在公共库中免费提供。每个吊销证书是由它的证书序列号在CRL中标识。当客户端检查服务器证书的有效性时，他们也应该获得最近的CRL，并检查该证书序列号在不在CRL上。从客户端到客户端的“近期适当”可能会有所不同。

CRL是对于大多数应用实用，但有些情况下可能不适合使用它们的使用可能不合适。CRL不能实时操作。在这样例如频繁的CRL过期，CRL的大尺寸或需要证书即时撤销的情况下，CRL的实现证书撤销机制不足。并不是所有的浏览器实现CRL检查各种SSL证书。在一个现代浏览器通过Spiderlabs使用证书吊销的报道中，保罗Kehrer展示，涉及使用CRL的延迟影响的浏览器，如果CA服务器已关闭或CRL响应时间过长，他们不得不忽视的撤销信息时。此外，并非所有的浏览器检查各种SSL证书的CRL。Safari浏览器，需要用户选择，表示CRL检查“要求对所有证书”选项。

2.2中间人攻击

中间人就是攻击者截取客户端和服务器（受害者）之间连接的攻击。攻击者在受害者之间的建立独立连接并传递他们之间的信息，使他们相信，他们正在通过安全连接互相交谈。这种攻击只有在攻击者可以伪装的受害者不知情时成功。这依赖于通讯方缺乏足够的相互认证。

在中间人攻击时，攻击者可以截获客户端和服务器之间的消息。在被动MITM攻击中，攻击者窃听SSL通道并且浏览信息，而在主动攻击中，攻击者会篡改消息。执行这种攻击的方法之一是，如果攻击者在受害者的附近，他（她）可以使用

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

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