本报告的样本与数据均来自于蒲公英专家测试自开始服务以来的服务对象，样本来自社交、电商、直播、金融、工具、教育、医疗、智能硬件、游戏等多个种类的三万余款 App （截止于 2017 年 3 月 10 日），蒲公英测试团队的所有工程师都是 ISTQB （国际软件测试资质认证委员会）认证工程师，所以本样本有着极高的权威性和专业性。

继上周为大家介绍了注册登录模块中经常出现且易被忽视的问题后，本周为大家报告的是蒲公英的工程师在测试过程中经常遇到的，在搜索框与文本框最容易出现的几个问题。

• 搜索框内特殊信息导致 App 闪退的问题

特殊信息大概可分为以下几类：

1. 在搜索框中不输入任何信息直接搜索 2.输入全部为空的信息 3.特殊字符 4.字符数量过多的搜索关键字 5.emoji 表情符号

在处理以上几种特殊信息时，一部分进行测试的 App 会出现闪退现象。

值得注意的是，测试中尤其需要对字符中包含单引号的搜索进行关注，这种情况下出现的崩溃相比较其他的类型的关键字更为频繁，搜索敏感词汇时的表现也同样需要关注。

• 字符超出搜索框的问题

在搜索框输入字符过多的关键字时，一部分 App 会出现字符显示在搜索框之外的情况，造成了该 App 的 UI 显示问题。

• 搜索历史的显示问题

在很多 App 的搜索功能中，在搜索框输入任意关键字搜索后， App 会自动保存历史搜索的关键字，对于开发者来讲，这里仍旧需要注意搜索关键字字符长度的问题。

如果输入的搜索关键字字符数量很多时，请注意 App 自动保存的搜索历史显示是否正常，有没有出现 UI 显示问题。

一般情况下，搜索历史只会保存最新的几条记录，但是部分经过蒲公英测试工程师测试的 App 没有对此做任何的限制。如果没有做限制的话，那么在搜索历史下方还有其他 App 内容显示的时候可能会造成 UI 显示重叠；如果搜索历史下方没有任何内容，那么保存了过多的搜索历史信息后，之前的搜索历史可能会被更新的搜索历史“挤出”屏幕外，导致显示不完整或者 UI 显示不美观等现象；也有一小部分 App 会出现重复显示搜索历史的问题。

• 未处理空白字符的问题

在搜索框的测试流程中，经常会有 App 未对搜索关键词前后的空格进行处理，从而导致搜索结果不全。

• ####编辑框的有效性校验不完整

以某 App 为例，在该 App 中本应输入手机号码的编辑框却可以随意的输入任何类型的信息，包括汉字、大小写字母、表情与错误格式的手机号码。

这种问题就是因为对编辑框的有效性校验不完整所导致的，如果在注册的时候没有对输入的手机号码进行有效性验证，那么就可以随意的发送无效的验证码，从而造成经济损失。

蒲公英的测试工程师建议开发者们在开发过程中对于各类型的编辑框在输入信息后都要自动进行有效性验证，以确保输入信息的有效性。

• 对输入框的输入长度校验不完整

该问题与前文所说的搜索框的问题类似。蒲公英的测试工程师在测试过程中经常遇到因为在编辑框输入较长的信息保存成功后导致显示出的信息与 App 内其他内容显示重叠、覆盖等 UI 问题。

• 对于特殊字母 /表情符号的校验问题

该问题的表现形式为：在 App 内某个编辑框输入不识别的字符保存成功后查看，应用将不识别的字符显示为“？？”。

比较常见的情况是，在某 App 中的用户昵称编辑框内输入 emoji 表情符号，保存成功后查看， emoji 表情符号全部显示为“？？”，这对于很多喜欢在昵称中加入 emoji 表情的用户不太友好，开发者需要多加注意。

• 换行操作导致 UI 异常

该问题具体表现为：在编辑框输入信息时使用换行输入的方式输入信息后，文本框会出现显示不完整或者 UI 显示异常的问题。

很多 App 中的编辑框不能折行显示，但是在输入字符的时候可以使用换行输入的方式输入多行字符（类似在电脑上输入信息的时候使用回车换行输入多行信息），导致输入字符保存成功后只能显示已输入的第一行字符，或输入的字符显示出来的字体缩小，在固定大小的编辑框内将所有输入的字符显示出来。

• 有关拷贝粘贴功能的问题

以某 App 为例，在该 App 的禁止直接输入非数值数据文本框字段进行操作时，使用手机内的拷贝粘贴功能尝试输入特殊字符时却可以正常保存成功。

绝大部分 App 的手机号码编辑框弹出的虚拟键盘的确是直接输入数字，但是蒲公英的测试工程师提醒开发者，必须考虑到是否可以在该编辑框内使用拷贝粘贴的方式输入非数字类型的信息。

以上九个问题是蒲公英的测试工程师在 App 的搜索框与文本框的测试过程中最容易出现的问题，建议开发者们在今后的开发过程中多加注意。

编辑框虽小，其中的学问并不小。

本报告的样本与数据均来自于蒲公英专家测试自开始服务以来的服务对象，样本中共有社交、电商、直播、金融、工具、教育、医疗、智能硬件、游戏等多个门类的三万余款 App （截止于 2017 年 3 月 10 日），蒲公英的测试工程师均已获得国际软件测试资质认证委员会（ ISTQB ）认证证书，以确保报告的问题和数据真实可信。

本测试报告对 App 出现的 Bug 按照不同模块进行了归类与整理，分为了注册登录、搜索、文本框输入、刷新与加载、权限等部分，那么本周首先为大家报告的是蒲公英的测试工程师在检测过程中，注册登录模块最容易出现的几个问题。

• 注册时弹出的键盘为 A ，但是登录时弹出的键盘为 B

比如在某 App 的注册界面时，点击密码输入框后弹出的键盘可以输入汉字，设置汉字为密码，但在登录过程中输入密码时无法输入汉字，这就出现了该应用无法登录的问题。

该问题的出现概率极低，在测试过程中出现的概率约为 3%，属于缺陷级问题， App 的核心功能已经实现但是存在阻碍。

……点此查看余下全文

那么，大家在开发 App 注册登录模块的时候遇到过哪些文中没有提到或者令你哭笑不得的 Bug 呢？

什么是版本控制功能

Bug 管理云支持版本控制功能，版本控制功能是指，您可以将您在 Bug 管理云上的项目进行代码仓库托管。当您项目中有问题的改动和修正时，我们会将您的改动信息同步到该问题的下方以方便查看，记录，保存和再次检查。

支持哪些代码仓库的托管

Bug 管理云目前支持两种代码仓库的托管：

• Github ： https://github.com

• Bitbucket: https://bitbucket.org

如何使用版本控制功能

1.在项目设置中，点击「版本控制」，选择代码仓库类型（ Github/Bitbucket ）；

2.点击代码仓库之后，进行登录。 Github 账户可直接在 Bug 管理云中登录， Bitbucket 账户需要跳转到 Bitbucket 进行登录；

3.登录成功后，会为您显示出您的代码仓库位置和仓库 webhook 的回调地址；

4.粘贴您的 webhook 回调地址到您的 Github 账户中（或者 Bitbucket 账户中）；

5.当您修复一个问题时，我们会将您在 Github （或 Bitbucket ）中的修改记录同步到你修改的问题中。以 Gihub 为例：

• 在代码中做出修改；

• 在 Commit new file 中进行填写，格式 fix + ##问题编号##，例如 Fix UI ##001##；

• 点击 Commit new file 后，在 #001 问题下方可以看见刚才进行的代码编辑。

6.关联设置后，即可对该项目中的某一个问题选择相应的「代码修改记录」进行查看了；

• 除了在 Bug 管理云某一问题中可关联选择外，在各代码库中正编辑时也可选择需要关联的 Bug 管理云问题。需要注意的是，从代码库中关联需要在设置时点击「仓库 Webhook 回调地址」，并且关联时填写git commit -m ‘##问题编号##’来进行相应问题的选择。

• 在提交代码时备注内包含 ‘##问题编号##’ 也可将代码修改记录与 Bug 管理云问题进行关联 ：

例如：git commit -m 'fix bugs of login ##026##'就表示把 Bug 管理云中相应项目中 026 问题与此次代码修改相关联 。

需要注意的是，提交代码时关联 Bug 管理云的问题是需要在仓库中设置 Webhook 回调地址并且接受 Push 事件。

如何取消版本控制

如需取消关联，在「账户设置」中的「授权凭据」中进行「销毁」。

版本控制功能能方便地将您的项目进行更高效和有条理的管理，方便开发者和使用者对每一次改动都进行有效，可追踪的管理，快来bug.pgyer.com试试吧！

任意调试漏洞

说到任意调试漏洞，我们就要提到 AndroidManifest.xml ，它是每个 Android 程序中必须的文件。它位于整个项目的根目录，描述了 package 中暴露的组件（ activities, services, 等等），他们各自的实现类，各种能被处理的数据和启动位置。 除了能声明程序中的 Activities, ContentProviders, Services, 和 Intent Receivers,还能指定 permissions 和 instrumentation （安全控制和测试）。

而在 AndroidManifest.xml 文件中， debuggable 属性值被设置为 true 时（默认为 false ），该程序可被任意调试 ，这就产生了任意调试漏洞。

任意调试漏洞的危害：

可被动态调试，增加了 apk 被破解、分析的风险。 目前动态调试器的功能都很强大，如果 debuggable 属性为 true ，则可轻易被调试，通常用于重要代码逻辑分析、破解付费功能等。

下图是 IDA 的调试界面，可以下断点、单步执行，调试过程中可以看到变量内容，即使没有 java 代码，反编译后的 smali 代码也比较容易阅读，加上动态调试，对 App 的逆向分析将变得容易的多。

HTTPS 中间人劫持漏洞

中间人攻击是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容。

HTTPS 中间人攻击漏洞有以下来源：

• 没有对 SSL 证书进行校验。
• 没有对域名进行校验。
• 证书颁发机构(Certification Authority)被攻击，导致私钥泄露等。

示例：

• 实现的 X509TrustManager 接口的 Java 代码片段 [其中的 checkServerTrusted()方法实现为空，即不检查服务器是否可信] ：

• 接受任意域名的 Java 代码片段

攻击效果： 某 App 中添加收货地址，使用中间人劫持能获取到手机号、地址、姓名等敏感信息。

我们从上面的攻击效果可以看出来，利用中间人劫持漏洞，攻击者可通过中间人攻击（比如使用钓鱼 WiFi ），盗取账户密码明文、聊天内容、通讯地址、电话号码以及信用卡支付信息等敏感信息，甚至通过中间人劫持将原有信息替换成恶意链接或恶意代码程序，以达到远程控制、恶意扣费等攻击意图。

在各大漏洞平台上，有大量存在 HTTPS 证书不校验漏洞，例如国内绝大部分 Android APP 存在信任所有证书漏洞、亚马逊最新官方 Android 版存在一处信任所有证书漏洞、 Yahoo 雅虎在国内访问遭遇 SSL 中间人攻击、携程旅游网最新 Android 客户端 https 未校验证书导致 https 通信内容完全被捕获。

加密算法漏洞

以下几种行为会有产生加密算法漏洞的危险：

• 使用 AES/DES/DESede 加密算法时，如果使用 ECB 模式，容易受到攻击风险，造成信息泄露。
• 代码中生成秘钥时使用明文硬编码，易被轻易破解。
• 使用不安全的 Hash 算法(MD5/SHA-1)加密信息，易被破解。
• 生成的随机数具有确定性，存在被破解的风险。

而加密信息被破解后，产生的危害也就不言而喻了：加密信息被泄露。如果加密的是账号、密码、银行卡、身份证等信息，破解后可被不法分子用于诈骗、盗号、盗刷等。

相关案例：

• 某互联网金融 APP 加密算法被破解导致敏感信息泄露

某 P2P 应用客户端，用来加密数据的 DES 算法的密钥硬编码在 Java 代码中，而 DES 算法是对称密码算法，既加密密钥和解密密钥相同。知道了密文和加密算法以及密钥，通过解密操作，可以从文件中恢复出原始的手势密码。

• 某租车 APP 加密算法被破解导致一系列风险

某租车 APP 与服务器通信的接口采用 http 传输数据，并且有对传输的部分参数进行了加密，加密算法采用 AES ，但是密钥硬编码在 java 代码中为“ shenzhoucar123123 ”，可被逆向分析出来，导致伪造请求，结合服务器端的漏洞，引起越权访问的风险，如越权查看其它用户的订单等。 攻击者完全可以做到使用其他脚本重新实现相同的加密功能并拼接出各个接口请求，批量的刷取订单信息和用户其他信息。

那么 APP 端的常见漏洞就介绍到这里，就像蒲公英之前所说的， APP 端本身的漏洞只占到了 Android 应用目前可发现漏洞的 21%，除了 5%通信层的漏洞，剩下的都是服务器端的漏洞，这里就留到下次说明了。

今天就是美国的大选日了，在美国人民站队选择给谁投票坏处更少一点的时候，希拉里邮件门事件的阴霾还未散去， WikiLeaks 表示，要把最重磅的消息，留到大选前夕公布，给希拉里最致命的打击。表面上看是全球人民等谁当选，不如说是等谁先倒下，在这期间我们不妨回顾一下整件事情。

2009 年至 2013 年，希拉里在任国务卿期间利用私人电子邮箱和位于家中的私人服务器收发公务邮件，其中包括一些涉及国家机密的绝密邮件。这批邮件一共月 6 万封，在调查开启之前，其中 3 万多封已经被希拉里团队以涉及私人生活为由删除了，只剩下另外约 3 万封邮件可供调查。

2015 年 7 月， FBI 启动对这件事请的调查，然而，这一次的邮件门危机被希拉里糊弄了过去。在接受 FBI 调查时，她不断以“不记得”“不清楚”来回答问题。整整 39 次，当被问及如何保存政府文件、处理涉密信息等相关问题时，希拉里至少有 39 次用“忘记了”“想不起来”来应答。

第二天美国司法部长决定不会对希拉里提出指控。但是——

今年 7 月 22 日之后，就在美国司法部宣布不指控希拉里的两周之后，阿桑奇领导下的 WikiLeaks 公布了希拉里乙方民主党委员会内部约 2 万封的绝密邮件，所有邮件中主要讨论的当然是怎么把希拉里捧上总统宝座。

在这些邮件公布之后，美国人才真正发现，原来希拉里还有那么多各种暗地里的勾当!

就算是吃瓜群众，也都意识到，如果你们党内的邮件都有这么多黑料的话，那你删掉的那 3 万封绝对不能给外人看的邮件里，究竟有什么?

就在这牵一发而动全身的关键时刻，希拉里的竞选团队主席 John Podesta 点开了一封来自黑客的钓鱼邮件，泄露了自己的密码，这也就意味着， Podesta 的邮箱已经毫无秘密可言了，黑客已经把他的邮箱翻了个底朝天。对于如此重视电子邮件交流的美国，这无异于在大街上裸奔，更何况当事人是时下总统竞选人旗下的军师级人物。

随后，从今年 10 月 9 日开始， WikiLeaks 开始逐渐公布 Podesta 的邮件，邮件中一些黑暗邪恶的内容让整个美国更加人心惶惶。 10 月 29 日， FBI 也宣布重启了对希拉里的调查，虽然在当地时间 11 月 6 日 FBI 又突然决定不建议对希拉里提起诉讼，但这期间的舆论纷争无疑对希拉里团队是一个不小的打击。

那么，黑客究竟是如何通过钓鱼邮件获取这些机密信息的呢？

首先我们得先了解一下什么是钓鱼邮件，维基百科中是这么解释的：钓鱼式攻击（ Phishing ，源自 Phone + Fishing ，与英语 fishing 发音一样；又名网钓法或网络网钓，以下简称网钓）是一种企图从电子通信中，通过伪装成信誉卓著的法人媒体以获得如用户名、密码和信用卡明细等个人敏感信息的犯罪诈骗过程……网钓通常是通过 e-mail 或者即时通信进行。它常常导引用户到 URL 与接口外观与真正网站几无二致的假冒网站输入个人数据。

那么我们就可以推测出， Podesta 可能就是点开了来自黑客邮件中的某个伪装后的链接，进入了仿冒的登录页面，输入了自己的邮箱密码，从而将自己的邮箱拱手送给了黑客。只因为在错误的时间点击了一个错误的链接，就让整个美国甚至全世界的下巴惊到了地上，除了让大家感慨“你们美帝精英阶层真会玩”之外，网络安全的问题也引发了人们的密切关注。

在美国，电子邮箱对各个阶层来说都是一个使用频繁的工具，所以很多攻击可以通过电子邮箱进行，在中国来说，电子邮箱的使用频率没有美国那么高，但要知道，大家平常经常使用的手机 APP 上也是有类似的漏洞存在的。

以 Android 系统为例，由于其高度的开放性和可定制性，系统的漏洞和各种 APP 的漏洞就会给予黑客可乘之机，在一个有漏洞的 APP 中，可能是一个广告，可能是一个按钮，可能是一个弹窗，邮件钓鱼还需要你手动去输入密码等关键信息，但在 APP 中，一个简单的点击动作就有可能将你手机里的信息暴露给黑客。

很多人会说，这些政坛人物对黑客来讲本身就是非常有价值的目标，这些高端的黑客攻击跟我们平民大众可没什么关系，那蒲公英可要说，这种想法真的是大错特错了。黑客选择攻击对象时，一般会考虑两种类型，一种是如政客、明星等具有攻击价值的个人，一种就是某类具有攻击价值的群体，我们大多数人其实属于第二种类型，只是你可能还没有发现而已。那些骚扰和诈骗的电话、短信中，电话那头的人可以脱口而出你的真实姓名和工作单位，这些信息他们可不是凭空猜到的，正是从黑客那里以及其便宜的价格买过来的，一次购买的个人信息数量可以达到数万条甚至数十万条，这就是我们普通大众对于黑客的价值，我们可能就是那被拿到黑市上售卖的数十万分之一。

那么，是不是目前网络上就没有安全可言了？

其实，只要有合理的预防和保护意识，以上这些问题是完全可以规避掉的，蒲公英为大家总结了一下几点：

• 千万不要响应要求个人金融信息的邮件

• 检查你所访问地址是否正确，有没有字母 O 被替换为数字 0 等情况

• 检查地址栏中的地址。如果你访问的站点是一个安全的站点，它应当以 https:// 开头，而不是通常的 http://

• 不要点击链接，通过在浏览器地址栏键入域名或 IP 地址等方式访问需要敏感信息的站点

对于 APP 中可被黑客用来钓鱼的漏洞来讲，除了在开发过程中要考虑的事无巨细以外，开发完成后的安全性测试也是必不可少的，这里推荐蒲公英专家测试推出的安全性测试，对 APP 的客户端、通信层、服务端进行全方位的检查，让用户对 APP 更加放心。

蒲公英安全测试，您 APP 的质量守护神。

而作为 APP 开发者，需要考虑的就是在手机被 root 后，私有数据被暴露的情况下，仍然能保证数据安全，不会泄露用户重要的数据及隐私信息，而对于手机厂商修复系统漏洞速度慢的问题，开发者不能依赖系统更新，更多时候需要自己想办法避免漏洞对用户造成损失。这时作为一个 Android 开发者，了解一些安全漏洞的基础知识是十分必要的，本次蒲公英内测就从 APP 端和服务端两个方面来为各位开发者简单介绍一些那些开发过程中最常见到的漏洞。

本次首先介绍 APP 端的敏感信息泄露漏洞。

敏感信息可分为产品敏感信息和用户敏感信息两类，我们对产品敏感信息是这样界定的：

泄露后直接对企业安全造成重大损失或有助于帮助攻击者获取企业内部信息，并可能帮助攻击者尝试更多的攻击路径的信息。

以下这些信息都属于产品敏感信息：登录密码、后台登录及数据库地址、服务器部署的绝对路径、内部 IP 、地址分配规则、网络拓扑、页面注释信息（开发者姓名或工号、程序源代码）。

而用户敏感信息有两个界定原则：

1. 用户隐私保护主要考虑直接通过该数据或者结合该数据与其它的信息，可以识别出自然人的信息。
2. 一旦发生数据泄露事件，可以被恶意人员利用并获取不当利润。

由此标准参考，以下字段在数据库的存储以及传输过程中，我们建议加密处理：密码、手机号、快捷支付手机号、 Email 、身份证、银行卡、 CVV 码、有效期。

而这些敏感信息泄露的原因大多数情况下是因为信息未加密或储存位置不当造成的：

• 代码中明文使用敏感信息，比如：服务器地址、数据库信息等
• 数据库中明文保存敏感信息，比如：账号、密码、银行卡等
• SD 卡中保存敏感信息或隐私数据，比如：聊天记录、通讯录等
• 日志中打印敏感信息：比如：账号、密码
• 通信过程中明文传输敏感信息

以上这些做法都会使 APP 中的敏感信息暴露在黑客的眼皮底下，只要黑客认为该信息有价值，他就会轻而易举的获取这些敏感信息，最直接的损失可能就是用户的账号被盗、网银被盗刷等。

而黑客如果知道了登录密码、后台登录及数据库地址、服务器部署的绝对路径、内部 IP 、地址分配规则、网络拓扑等产品敏感信息，会极大节省攻击时间，获取该应用的绝对控制权，其损失不是能够用金钱来衡量的。另外，这些敏感信息泄露，也会招来其他试探性的黑客去尝试攻击，导致服务器处于危险境地。

比如以下这几个案例，都将用户名、密码等敏感信息完全明文存储，这对一款金融或涉及线上交易的应用无疑是巨大的问题：

1.某金融 App 日志中明文打印用户名、密码，如果用户手机被安装了恶意软件，恶意软件可以获取到这些信息，导致账号被盗、被转账等。

2.某金融 App Preferences 中明文存储用户名、密码、 Token(令牌)。 Preferences 通常用于把一些配置、状态信息保存在手机上。 如果手机有 root 权限，安装了恶意软件，这些信息可被轻松获取。

3.携程用于处理用户支付的安全支付服务器接口开启了调试功能，使所有向银行验证持卡所有者接口传输的数据包均直接保存在本地服务器，同时因为保存支付日志的服务器未做严格的基线安全配置，存在目录遍历漏洞。可能导致大量用户持卡人姓名、身份证、银行卡号、卡 CVV 码、等信息外泄。 来源： http://money.163.com/14/0324/01/9O2KIFE500253B0H.html

4.某 App 登录时使用 HTTP 明文传输用户名、密码

以上便是敏感信息泄露漏洞的简单了解，下次将会为大家介绍 APP 端的备份功能开启漏洞与本地拒绝服务漏洞，其危险程度丝毫不亚于敏感信息的泄露，敬请关注。

移动互联网金融大行其道，各类互联网金融 APP 挤满了手机应用商店，在 2016 年第一季度国内 APP 市场上就已新增超过 100 家相对稳定运营的互联网金融 APP ，为用户提供相关产品和服务。移动互联网改变了用户的行为习惯，同时也影响了用户对互联网金融产品和服务的获得手段。

在互联网金融蓬勃的几年中，许多曾经名噪一时的金融平台都曾曝出各种各样的问题，一个接一个地倒下，其中不乏因问题严重而出现提现困难，甚至跑路的。根据互联网专业平台网贷之家 的数据统计，自 2011 年有相关正式记录以来，至 2016 年 6 月底，出现重大问题（跑路、提现困难、经侦介入等）的互联网金融平台总数为 1347 个。

目前记录在案的所有出现重大问题的互联网金融平台中，单从互联网金融平台最为兴盛的近三年来看，2014 年为 254 个，占所有出现重大问题平台的 18.86%； 2015 年为 746 个，占总数的 55.38%； 2016 上半年共出现 268 个，占总数的 19.90%。虽然从上半年的数量上看， 2016 年似乎呈现出了重大问题平台数量一定的下降趋势，但目前仅仅是半年的统计，而互联网金融平台问题高发主要出现在金融业结算、兑付频率较高的下半年，所以这表面上看似的一点点下降趋势并非真实。

尽管这些名噪一时的互金案件将大众视野都吸引到了金融安全上，也使得很多普通用户视所有金融 APP 为洪水猛兽，提到金融 APP 必言隐私泄露，但一个更为深层次的安全问题却被公众所忽视——金融 APP 自身存在的技术问题。

目前国内大部分为客户提供移动金融服务的 APP 都缺少规范的安全监管标准和流程，许多 APP 缺乏对其和业务逻辑的充分安全性测试，其原因大多是没有专业的安全测试团队，安全测试仅仅停留在表面，而且对于很多公司来讲专门聘请一个安全团队成本会有些高。这就导致了其包含的安全漏洞会将重要的数据信息暴露给黑客，将使用该应用的客户置于风险之中。

正常情况下，一名普通用户在普通的网络环境（安全的 Wifi 网络）下载和安装了上述存在问题的 APP ，然后通过 APP 去注册了金融服务的账号，并绑定了手机、注册邮箱和银行卡等个人信息。之后，用户通过该账号发起了金融交易。整个过程均为正常的用户使用流程，然而在这个过程中，黑客存在大量可乘之机，可窃取用户的关键信息并最终完成对用户行为的操作，掌握了用户关键信息后，大多会选择交易这些用户隐私数据换取丰厚的报酬，这也从侧面说明了如今骚扰电话的数量日益增多的原因。

据统计， Android 应用目前可发现的漏洞， 21%存在于 APP 自身安全漏洞上， 5%存在于通信层面上，剩下的全部漏洞均来自服务端，而目前市面上自动化安全测试的工具也仅仅能针对 APP 的风险代码进行检测和规避，而服务端和通信层面的渗透测试是很多第三方测试机构做不到的。

术业有专攻，专业的开发者与专业的安全行业从业者相比，对于漏洞的发现和危险评估必然是有一定的差距，如果能够为 APP 开发团队配置专业的第三方安全测试团队，制定一套详细的安全规范和测试安全标准，必将有效地降低金融以及其它类 APP 安全问题发生的概率，让普通用户重拾对金融类 APP 乃至整个互联网金融行业的信任。

背景

Google Play 的开发者政策中心对“隐私和安全”有如下描述：

如果您的应用会处理用户个人数据或敏感数据（包括个人身份信息、财务和付款信息、身份验证信息、电话簿或联系人数据、麦克风和相机传感器数据，以及敏感的设备数据），则必须：

• 同时在 Play Developer Console 中的指定位置以及通过 Play 分发的应用内提供隐私权政策。
• 以安全无虞的方式处理用户数据，包括使用新型加密技术（例如通过 HTTPS ）传输数据。

随着数据量级和维度的不断增加，数据安全已经成为移动互联网行业重点关注的领域。尤其是数据传输过程，是相对比较容易被拦截和嗅探的，因此谷歌对数据传输安全提出了更高的要求，推动 Android 开发者使用 HTTPS 来提升安全能力。

但是现实中， Android 开发人员对 HTTPS 的使用却存在一些问题，包括：

1.多数 HTTPS 是基于 HttpClient 来实现，但 Android 已不再默认支持 HttpClient 开发库，需要切换；

2.为了方便，开发人员一般会默认信任所有域名，这是个较大的安全隐患；

3.也是为了方便，证书校验也采用默认的设置，没有正确校验自签名证书；

关键还是在于如何正确校验证书和域名。

介绍 Android HTTPS 的文章有很多，比如谷歌官方 Android Develop Training 中有一篇文章讲 Securitywith HTTPS and SSL ，从基本概念和一个简单的 HTTPS 案例开始，帮助大家理解使用 HTTPS 可能遇到的问题以及应对方案，知识性很强。当然，阅读之前，最好已经掌握以下基础知识：

Java Security 基础知识 HTTPS 的通信原理 Android 网络基础 证书，证书文件格式 SSL TLS 秘钥管理， JSSE 等

HTTPS 的简单例子

这里是 Google 提供的 HTTPS 例子：

 URL url = newURL("https://wikipedia.org"); URLConnection urlCOnnection=url.openConnection(); InputStream in=urlConnection.getInputStream(); copyInputStreamToOutputStream(in, System.out); 

以上代码表明，可以用 HTTPS URL 直接获取地址内容。隐含的意思是，服务器证书需要配置 CA 证书，不能是自签名证书，甚至不能是不知名的证书机构签发的证书，否则就会有异常。

关于证书，有几个概念说明：

CA 证书：证书授权中心签发的证书，在访问这类网站的时候，浏览器地址栏的左端一般都有一个绿色盾牌。 不知名机构签发的证书：不是国际公认的签发机构，比如 12306 用的证书是中铁数字证书认证中心签发的。 自签名证书： Android 应用程序开发最可能使用到，一般由服务器管理者生成。

平常大家使用自签名证书的情况比较多，因为自签名证书不仅免费，而且有效时间可以比较长。 但是使用自签名证书的时候，需要移动端开发人员自己实现校验代码，增加了开发的难度。尤其是如果开发人员没有经验，未对证书和域名做正确校验，则可能引入安全隐患。 这里重点讨论一下如何校验自签名证书和域名。

如何校验自签名证书

Google 文章中关于如何让 HttpsURLConnection 信任自签名证书有如下代码（我们补充了中文注释）：

 // Load CAs from an InputStream // (could be from a resource or ByteArrayInputStreamor ...) // X.509 是 Android 唯一支持的证书格式 CertificateFactory cf =CertificateFactory.getInstance("X.509"); // From[https://www.washington.edu/itconnect/security/ca/load-der.crt]( https://www.washington.edu/itconnect/security/ca/load-der.crt) InputStream caInput = newBufferedInputStream(new FileInputStream("load-der.crt")); // 证书的加载也可以是字符串的方式，建议使用字符串，并且对字符串做些额外的处理 // InputStream caInput=newByteArrayInputStream(cerString.getBytes()); Certificate ca; try {       ca =cf.generateCertificate(caInput); System.out.println("ca=" + ((X509Certificate) ca).getSubjectDN()); } finally { caInput.close(); } // Create a KeyStore containing our trusted CAs // KeyStore 默认类型是 BKS ，虽然 Android 的文档中的例子写了 JKS ，但是 Android 并不支持 JKS String keyStoreType =KeyStore.getDefaultType(); KeyStore keyStore = KeyStore.getInstance(keyStoreType); keyStore.load(null, null); // 加载一个默认的秘钥仓库，仓库是空的 keyStore.setCertificateEntry("ca",ca); // Create a TrustManager that trusts the CAs inour KeyStore // TrustManager 是证书校验的关键，不使用系统默认校验方式时，需要开发者自己实现接口，完成校验代码 String tmfAlgorithm = TrustManagerFactory.getDefaultAlgorithm();// 默认算法 PKIX TrustManagerFactory tmf =TrustManagerFactory.getInstance(tmfAlgorithm); tmf.init(keyStore); // Create an SSLContext that uses ourTrustManager // Android 不仅支持 TLS ，还有 TLSv1.2 等， TLSv1.2 需要 API levels 20+ // 更多选择可以参考[https://developer.android.com/re ... /ssl/SSLSocket.html]( https://developer.android.com/reference/javax/net/ssl/SSLSocket.html) SSLContext cOntext=SSLContext.getInstance("TLS"); context.init(null, tmf.getTrustManagers(),null); // Tell the URLConnection to use aSocketFactory from our SSLContext URL url = newURL("https://certs.cac.washington.edu/CAtest/"); HttpsURLConnection urlCOnnection=      (HttpsURLConnection)url.openConnection(); // 证书校验的关键，设置 SSLSocketFactory // 执行 TrustManagerImpl 中 checkServerTrusted 方法完成服务器证书校验 urlConnection.setSSLSocketFactory(context.getSocketFactory()); InputStream in =urlConnection.getInputStream(); copyInputStreamToOutputStream(in, System.out); 

以上代码，可以解决证书信任问题。但同时需要注意的是，这里是基于 Android 默认的信任检查来解决的。因为我们没有对 TrustManager 做任何修改，如果仍然遇到证书校验不通过的情况，则需要重新实现 TrustManager ，请用以下代码代替“ tmf.getTrustManagers()”：

 TrustManager tm = new X509TrustManager() { @Override public X509Certificate[] getAcceptedIssuers() {return null; } @Override public void checkServerTrusted(X509Certificate[] chain, String authType) throwsCertificateException {} @Override public void checkClientTrusted(X509Certificate[] chain, String authType) throwsCertificateException { // 方法直接返回，    将不对服务器证书做任何校验 // 确认服务器端证书颁发者和代码中的证书主体一致 if (!chain[0].getIssuerDN().equals(cert.getSubjectDN())) { } // 确认服务器端证书被代码中证书公钥签名 chain[0].verify(cert.getPublicKey()); // 确认服务器端证书没有过期 chain[0].checkValidity(); } }; context.init(null, new TrustManager[]{tm},null); 

context.init(null, new TrustManager[]{tm},null);通过重新实现 TrustManager ，一定可以搞定证书校验。最好不要信任所有证书，这样会大大降低安全能力。

如何校验域名

在 HttpsURLConnection 中校验域名是比较简单的，这里 Google 提供了为 URLConnection 替换验证过程的例子：

 // Create an HostnameVerifier that hardwiresthe expected hostname. // Note that is different than the URL'shostname: // example.com versus example.org // 这里强调的是 URL 中的域名和证书中不一致，所以默认的校验不能通过 HostnameVerifier hostnameVerifier = newHostnameVerifier() { @Override publicboolean verify(String hostname, SSLSession session) { // 这段代码中 hostname 应该是 example.org // 获取默认的 HostnameVerifier HostnameVerifier hv =                     HttpsURLConnection.getDefaultHostnameVerifier(); // 如果直接返回 true ，等于不做域名校验 return hv.verify("example.com", session); } }; // Tell the URLConnection to use ourHostnameVerifier URL url = newURL("https://example.org/"); HttpsURLConnection urlCOnnection=(HttpsURLConnection)url.openConnection(); urlConnection.setHostnameVerifier(hostnameVerifier); InputStream in =urlConnection.getInputStream(); copyInputStreamToOutputStream(in, System.out); 

正确使用域名校验很重要，直接返回 true 显然不安全。回调参数 hostname 是访问的域名， session 可以通过 getPeerCertificates 获取到证书的相关信息，如果需要自己写代码完成域名校验，需要根据实际开发情况正确校验。

总结

用 HttpsURLConnection 来校验证书和域名的方法如下（不明确指定校验方式时，系统会采用默认的方式）：

 HttpsURLConnection urlCOnnection=(HttpsURLConnection)url.openConnection(); urlConnection.setSSLSocketFactory(context.getSocketFactory()); urlConnection.setHostnameVerifier(hostnameVerifier); 

校验的顺序是先校验证书，再校验域名。为了能够更好的理解 Android HTTPS 证书校验和域名校验的默认实现，可以参考 Android 的源代码：

• 证书校验的默认实现： 类： TrustManagerImpl.java

Git 获取源码： git clonehttps://android.googlesource.com/platform/external/conscrypt

• 域名校验的默认实现： 类： OkHostnameVerifier.java

Git 获取源码： git clonehttps://android.googlesource.com/platform/external/okhttp

这些知识也不算复杂，但是确实不少移动开发者容易忽视的。希望通过以上分享，能帮助开发者给移动用户提供一个安全的服务环境。

蒲公英专家测试近日也推出了针对 App 客户端进行包括上文提到的 HTTPS 安全问题的漏洞和安全风险测试，对服务端（服务器、通信）进行深入的渗透测试。端到端的评估安全风险，并提供修复建议。

蒲公英拥有拥有众多专业、资深安全行业专家，多年安全行业渗透测试经验，为您的产品保驾护航。让您不再担忧您 App 的安全问题，详情可前往蒲公英安全性测试查看详情。

那么， Android 系统为什么就那么不安全呢？

由于 Android 系统是开源的，任何人都可以下载源码。这也就代表着，任何人都可以研究代码，也更容易发现系统漏洞，其开放的系统使得任何厂商均可以生产制造 Android 设备，而各种硬件厂商和第三方 ROM 开发者水平参差不齐，导致系统容易出现漏洞。

在安装 Android 应用时，应用会请求各种各样的权限，这也是普通使用者最容易忽略的一点，许多应用在安装时会请求和该应用使用时完全用不到的权限，这也为日后可能出现的问题埋下隐患。

Android 系统的应用可以申请读取短信、发送短信、接收短信、拨打电话、读取通讯录、修改通讯录等重要权限，无需 Root 即可替换短信、通讯录、相机、输入法等系统应用功能，可以更灵活的去开发第三方应用，但是也给了病毒和恶意软件可乘之机，易造成隐私泄露、短信被拦截（可导致账号被盗、网络支付安全问题）、被恶意扣费、自动给通讯录其他人发送病毒链接等问题。

手机厂商对安全补丁的更新缓慢同样也是一个大问题。系统漏洞被发现后， Google 会及时更新系统补丁，而等到各个厂商给用户提供更新时可能已经过了半年以上。甚至有些厂商手机发布后，不再提供更新，导致用户始终处于已知系统漏洞的风险之中。

目前国内第三方 ROM 市场缺乏监管，安全难以保障：现在很多手机厂商为了自身利益内置各类应用，但很多用户并不喜欢原生系统或内置应用，经常会 Root ，并刷第三方 ROM ，也造就了第三方 ROM 的繁荣市场。但第三方 ROM 的技术人员水平参差不齐，行业也缺乏监管，系统安全性难以保障，而且手机一旦进行了 Root ，被病毒、恶意软件利用申请到最高权限，可以执行很多操作，会造成更大的危害。

除了普通用户， Android 应用的开发者也同样要关注 Android 系统的安全问题，前面已经介绍了， Android 系统有各种原因导致会有各种安全问题出现，且用户在手机 Root 后、中病毒等情况下，都会导致普通 APP 完全没有“隐私”可言，各种私有数据充分暴露。所以，开发者需要考虑在手机被 Root 后私有数据被暴露的情况下，仍然能保证数据安全，不会泄露用户重要数据及隐私信息。由于手机厂商修复系统漏洞很慢，一旦出现漏洞，开发者不能依赖系统更新，更多时候需要自己想办法避免漏洞对用户造成损失。而且 Android 碎片化严重，各种版本的系统占有率不相上下，这种情况下，低版本手机安全风险更大，虽然谷歌在每次新系统上都会加强安全措施，但是很多情况下低版本系统仍然暴露在已知漏洞的威胁之下。

Android 应用漏洞分布现状

在第三方应用市场分别下载了 18 个行业的 Top10 应用共计 180 个，进行漏洞分析， 97%的应用都有漏洞，总漏洞量 15159 个，平均每个应用有 87 个漏洞，且 23%的 Top10 应用都有高风险漏洞。（数据来自阿里）

游戏类 Top10 Android 应用有 788 个漏洞，平均每个应用含 79 个漏洞。其中 29%是 Webview 远程代码执行高危漏洞。 约 19%是高危漏洞，游戏类应用更新迭代频率高，资金，用户下载量大，存在的漏洞风险不容忽视。

金融类 Top10 ， Android 应用有 669 个漏洞，平均每个含 67 个漏洞，其中 22%是 Webview 远程代码执行高危漏洞。 约 34%是高危漏洞，在 18 个行业中高危漏洞占比最高。

电商类 Top10 应用共有 851 个漏洞，平均每个应用含 85 个漏洞，其中约 27%是 Webview 远程代码执行高危漏洞，可导致恶意应用被植入、通讯录和短信被窃取、手机被远程控制等严重后果。 约 27%是高危漏洞。

这些漏洞到底是什么，有多危险呢？

敏感信息泄露漏洞

敏感信息可分为产品敏感信息和用户敏感信息和两个方面。

产品敏感信息为：信息泄露后直接对企业安全造成重大损失或有助于帮助攻击者获取企业内部信息，并可能帮助攻击者尝试更多的攻击路径。比如登录密码、后台登录及数据库地址、服务器部署的绝对路径、内部 IP 、地址分配规则、网络拓扑、页面注释信息包括（开发者姓名或工号、程序源代码）等。

用户敏感信息包括：用户隐私保护主要考虑直接通过该数据或者结合该数据与其它的信息，可以识别出自然人的信息。一旦发生数据泄露事件，可以被恶意人员利用获取不当利润。

由此标准参考，如下字段在数据库的存储以及传输过程中，我们建议加密处理：密码、手机号、快捷支付手机号、 Email 、身份证、银行卡、 CVV 码、有效期。

敏感信息可能泄露的方式有：代码、数据库、配置文件中明文存储敏感数据、日志中打印敏感信息、通信过程中明文传输敏感信息。

一旦产品敏感信息泄露，会导致服务器处于危险境地，可能被入侵攻击，个人敏感信息泄露也会导致账号被盗、网银盗刷等，给普通用户造成经济损失。

相关案例： 国王控卫电脑被黑遭勒索 私人敏感信息或泄露

WebView 远程代码执行漏洞

WebView 组件中的 addJavascriptInterface 方法用于实现本地 Java 和 Javascript 的交互，但是该函数并没有对方法调用进行限制，导致攻击者可以调用任何 JAVA 类，最终导致 Javascript 代码对设备进行任意攻击。该漏洞可被用来实现网页挂马，导致手机中毒等。

相关案例： 关于安卓 webview 安全漏洞远程命令执行

任意调试漏洞

AndroidManifest.xml 文件中 debuggable 属性值被设置为 true 时（默认为 false ），该程序可被任调试 。该漏洞可被动态调试，增加了 apk 被破解、分析的风险。

HTTPS 中间人劫持漏洞

中间人攻击是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容。

攻击者可通过中间人攻击，盗取账户密码明文、聊天内容、通讯地址、电话号码以及信用卡支付信息等敏感信息，甚至通过中间人劫持将原有信息替换成恶意链接或恶意代码程序，以达到远程控制、恶意扣费等攻击意图。

相关案例： 在各大漏洞平台上，有大量存在 HTTPS 证书不校验漏洞，例如国内绝大部分 Android APP 存在信任所有证书漏洞、亚马逊最新官方 Android 版存在一处信任所有证书漏洞、 Yahoo 雅虎在国内访问遭遇 SSL 中间人攻击、携程旅游网最新 Android 客户端 https 未校验证书导致 https 通信内容完全被捕获。

加密算法漏洞

使用 AES/DES/DESede 加密算法时，如果使用 ECB 模式，容易受到攻击风险，造成信息泄露。 代码中生成秘钥时使用明文硬编码，易被轻易破解。 使用不安全的 Hash 算法(MD5/SHA-1)加密信息，易被破解。 生成的随机数具有确定性，存在被破解的风险。

加密信息被破解会导致信息的泄露。 如果加密的是账号、密码、银行卡、身份证等信息，破解后可被不法分子用于诈骗、盗号、盗刷等。

除了以上客户端可能出现的这些漏洞，服务端可能出现的安全漏洞同样不能忽视。目前大量业务从传统的 PC 端扩展到移动端，在服务器上运行业务逻辑也是较为安全和低成本的实现方式。但正因为业务逻辑是在服务端处理，如果不对作为入口的客户端进行强有效的安全校验，客户端很容易被黑客作为突破口，用于挖掘服务端的业务风险漏洞。理论上， web 服务器所有安全问题也会出现在 App 的服务端。而 Web 安全已经发展了很长时间，研究人员、黑客也很多，技术成熟，更容易被黑客发现漏洞。

SQL 注入漏洞

SQL 注入攻击是黑客对数据库进行攻击的常用手段之一。原因是没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据。该漏洞可导致用户信息泄露，被不法分子用于诈骗、出售信息等。

相关案例： 贷齐乐系统多处 SQL 注入漏洞可影响大量 P2P 网贷站点

越权访问漏洞

一个正常的用户 A 通常只能够对自己的一些信息进行增删改查，但是由于程序员的一时疏忽，在进行增删改查的时候，没有判断所需要操作的信息是否属于对应的用户，可以导致用户 A 可以操作其他人的信息。该漏洞可导致黑客查看、修改他人用户信息、信息泄露等。

相关案例：

黑客可通过漏洞访问 Uber 优步司机和乘客信息

接口未限制导致撞库漏洞

撞库是黑客通过收集互联网已泄露的用户和密码信息，生成对应的字典表，尝试批量登陆其他网站后，得到一系列可以登录的用户。很多用户在不同网站使用的是相同的帐号密码，因此黑客可以通过获取用户在 A 网站的账户从而尝试登录 B 网址，这就可以理解为撞库攻击。同样容易引起账号被盗、信息泄露等严重问题。

相关案例：

12306 数据泄露原因曝光：手机 APP 漏洞导致“撞库”

XSS 漏洞

跨站脚本攻击(Cross Site Scripting)，为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故将跨站脚本攻击缩写为 XSS 。恶意攻击者往 Web 页面里插入恶意 Script 代码，当用户浏览该页之时，嵌入其中 Web 里面的 Script 代码会被执行，使得用户信息谢咯，从而达到恶意攻击用户的目的。

相关案例： APP 安全之上车一处无效 xss 可间接影响 18 万土豪车主(包括认证的特斯拉 /劳斯莱斯 /法拉利车主等)

业务逻辑漏洞

业务逻辑漏洞是指由于程序逻辑不严密或逻辑太复杂，导致一些逻辑分支不能够正常处理或处理错误。常见漏洞包括：任意密码修改（没有旧密码验证）、密码找回漏洞、业务数据篡改等。该漏洞易造成账号被盗、免费购物、刷钱、刷游戏币等严重问题。

相关案例： 有利网某业务逻辑漏洞导致可无限刷红包(红包可用于投资)

如何最大限度的避免这些漏洞的出现

在目前大多数应用的测试团队中，大都缺乏安全测试的意识和能力，且安全测试专业性强、涉及面广、人才稀缺，组建安全团队成本太高，想做安全测试也有心无力。

蒲公英专家测试同样也注意到了以上的问题，本着更好的为开发者服务的初心，新产品安全性测试也正在最后的打磨阶段，即将在不久后推出，详情可访问蒲公英专家测试咨询客服，我们也会根据您的需求在最后阶段完善我们的产品。

蒲公英主要提供了app托管分发和SDK功能（异常上报，摇一摇反馈，新版本检测），当然还有各种各样的客户端（mac、windows、iphone、android）等和公共API接口。

从最初的用网页上传app到后来用mac和windows客户端的上传app，再到后来用蒲公英的Android SDK，一路走来逐渐摸索出一条适合自己的用法。

我主要是用到了蒲公英的上传和sdk功能，此方法是针对gradle构建的工程：

1. 在主工程的build.gradle中添加如下标注的代码

2. 在module的build.gradle中添加如下标注的代码

3. 在Android Studio的终端执行./gradlew uploadPgyer

提示build successful表明上传成功，同时当前用户的邮箱会收到一封新版本发布的邮件。

demo： https://github.com/rikyou/PgyerSDKForAndroidStudio/tree/master

Rikyou Li

1、首先安装ant ，下载地址http://ant.apache.org/不会安装的可以参考http://yarin.blog.51cto.com/1130898/692569。

2、利用Ant批量打包的基本思想是，每次打包后自动替换渠道号，以及自己要替换的参数，比如本demo就要不仅要替换渠道号，一些参数，还要替换图标和启动页面。

这样带来了一个问题：Ant不支持循环，怎样循环打包？

扩展包Ant-contrib能轻松解决这个问题

可以翻墙的同学可以到http://ant-contrib.sourceforge.net/自行下载，或者去我的云空间下载http://pgyer.qiniudn.com/ant-contrib-1.0b3.jar，下载后直接把ant-contrib-1.0b3.jar放到Ant的lib文件夹即可。

3、生成并改写build.xml 执行如下命令

android update project --name testbyfrank -t 1 -p /Users/frank/Documents/workspace/testbyfrank

此命令在当前的工程目录生成build.xml， -t 表示targetid 可以通过android list targets查看 -p 指定工程目录

修改build.xml 代码见demo

4、生成ant.properties 内容如下：market_channels是用来替换的参数以:和-分割。

java.encoding=utf-8

out.absolute.dir=/Users/frank/Documents/publish_testbyfrank

gos.path=/Users/frank/Documents/publish_testbyfrank_bin

proguard.cOnfig=proguard.cfg

app_version=1.5

market_channels=\u65B0\u77E5:60-xinzhi,\u897F\u5149:18-xiguang

5、project.properties文件中打开混淆代码，去掉下面所在行的#

proguard.cOnfig=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt

6、编写proguard-project.txt，demo中有，大家自行删减

6、执行命令ant deploy就慢慢等待生成的多渠道的apk吧

7、最后在目录/Users/frank/Documents/publish_testbyfrank_bin下生成了两个apk

testbyfrank_xiguang.apk 和testbyfrank_xinzhi.apk

自己抽离出来的demo已经经过我的测试没有问题，大家可以通过http://pgyer.qiniudn.com/testbyfrank.zip下载示例代码。

注意事项及可能遇到的问题

1.工程如果引用到其它类库工程，请先生成类库的build.xml

2.如果提示invalid resource directory name: /Users/frank/Documents/workspace/appcompat_v7/bin/res/crunch等类似的错误请先手动删除bin目录，重新执行ant deploy命令

3.如果出现Can't read [/Users/frank/Documents/workspace/testbyfrank/libs/Android_Location_V1.1.0.jar] (No such file or directory)类似的错误，表明你没有用到这个类库，请在混淆文件中去掉对应的即可。

4.如果xml文件有用到自定义的控件，对应的java文件不能混淆

5.如果用的gson的库，对应的实体类不可以混淆。