2013至2015年iOS平台网银应用安全性对比
针对分布在不同地理位置上的一些重要银行的iOS平台网银应用，本文主要从传输安全、编译器保护、UIWebView、数据存储、日志文件、二进制文件等方面研究了它们的安全性；此外，本文还将这次的研究结果与2013年进行的针对相同银行的APP安全性结果进行对比，并分析这两年之前iOS平台网银应用安全性的整体发展。
前言
2013年，为了了解一些重要银行移动网银应用的安全性整体情况，我决定开展一项 研究 。
在这篇博文里，我将展示最新的研究结果，以显示与2013年相同的移动网银应用安全性的发展情况。
研究范围
我的研究包括40个移动网银应用，其中它们在全球地理位置分布如下图：
这次研究中，我所采用的指标与2013年的研究中相同：
1.局限于iOS平台 2.黑盒测试方法 3.所有的测试只在APP上执行（客户端），不包含任何服务器端的测试 4.研究中不对所发现的漏洞进行描述，同时也不介绍如何利用这些漏洞 5.已经联系了受影响的银行，并向其报告了相关漏洞
测试
针对每一个APP，进行了下面的测试：
1、传输安全
（1）明文传输 （2）会话处理不当 （3）正确验证SSL证书
2、编译器保护
（1）反越狱防护 （2）以PIE进行编译 （3）以栈cookies进行编译 （4）自动引用计数
3、UIWebView
（1）数据验证（输入、输出） （2）UIWebView实现
4、不安全的数据存储
（1）SQLite数据库 （2）文件缓存 （3）属性列表文件 （4）日志文件
5、日志记录
（1）自定义日志 （2）NSLog语句 （3）崩溃报告文件
6、二进制分析
（1）反汇编应用程序 （2）检测汇编代码的混淆保护 （3）探测反篡改保护 （4）检测反调试保护 （5）协议处理程序 （6）客户端注入 （7）第三方库
下面，我将从两方面展示这次的研究结果：
1.网络和日志分析 2.二进制和文件系统分析
网络和日志分析
在所有审计的APP之中，12.5%没有验证所用SSL证书的真实性，这使它们很容易受到中间人（MITM）攻击。35%的APP在整个程序中包含非SSL的链接，这使得攻击者能够拦截流量；并且，在攻击者试图创建一个伪造的登录提示窗或类似的诈骗活动中，他们能够注入任意JavaScript或HTML代码。
30%的应用程序没有验证传入的数据，这使得攻击者通过不安全的UIWebView实现就能进行JavaScript注入，从而发起客户端攻击。42.5%的应用程序提供了替代的身份验证方案，以此来减小泄漏用户凭证和个人攻击的风险。
通过系统日志或自定义日志暴露的与客户端相关的信息中，40%的APP仍旧泄露用户活动或者客户端服务器交互信息，例如来自服务器端的请求和响应。
2013年到2015年之间的进化：
二进制和文件系统分析
在查看了每个应用程序的文件系统和二进制文件后发现，7.5%的APP仍旧没有采取一些编译器的保护措施，例如启用PIE和栈粉碎（Stack Smashing）保护。此外，只有15%的应用程序有越狱保护措施，以此来检测并通知最终用户越狱设备的风险。
15%的应用程序通过SQLite数据库或其他明文文件，将未加密的敏感信息存储在文件系统中，比如客户银行账户和交易历史的详细信息。最后，17.5%的应用程序开发时在它们的二进制文件中采用了硬编码。
2013年到2015年之间的进化：
漏洞地理位置分布
结论
1、通过正确验证SSL证书或删除明文流量，大部分应用都提高了数据传输的安全性，这有助于减小用户遭受MITM攻击的风险。
2、虽然总体数量在减少，但仍有大量的应用程序在它们的文件系统中存储不安全的数据，所以他们中的很多人仍然容易遭受客户端攻击。
3、很少有应用程序提供替代的身份验证解决方案，而仅仅依靠用户名和密码进行身份验证。
4、在这2年的时间内，虽然总体上安全性有所提高，但这还不够，很多应用程序仍然很脆弱，很容易受到黑客攻击。
*参考来源： ioactive ，FB小编JackFree编译，转载请注明来自FreeBuf黑客与极客（FreeBuf.com）
正文到此结束
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
