Android 应用安全 - Mobile安全漏洞Top10（OWASP）

版权归作者所有，转发请注明出处：https://www.jianshu.com/p/54a1e3e624fa

Android 应用安全 - 应用安全概览
Android 应用安全 - 移动应用安全
Android 应用安全 - Mobile安全漏洞Top10（OWASP）
Android 应用安全 - 案例
Android 应用安全 - 检测设备是否Root
Android 应用安全 - 加密算法

前言

提高应用的安全性有助于维护用户信任和设备完整性

M1. 平台代码使用不当

此异常主要由于未正确使用平台SDK，包含Android Intent,权限控制，Key chain,可能会对受影响的app造成严重影响

• 使用Android Intent造成数据泄漏
  使用Intent可以进行打开应用，打开后台服务访问存储在移动设备的数据，所以Intent的数据传递使用不当是会造成数据泄漏
  尽量避免将应用的Activity,Service等做导出操作
  如果有导出操作,尽量设置白名单过滤，而不是信任所有来源

• Android意图嗅探
  这些应用程序在其他合法应用程序与其他应用进行数据传递时研究所传递的信息进行分析
  可以通过定义显示意图来放置意图嗅探操作,显示意图相对隐式意图更安全因为有确定的目的地

• IOS钥匙串风险
  如果用户不选择钥匙串选项，则他们可以直观的选择易于记忆的密码，这些密码可能会被黑客利用
  不允许通过服务器路由进行钥匙串加密，而只能将加密的密钥保留在一台设备中，以使其不能在其他设备或服务器中被利用。
  使用钥匙串存储应用程序的机密，以保护应用程序的安全，该机密应具有专用的访问控制列表。访问控制列表的用户身份验证策略可以由OS强制执行
• IOS TouchID风险
  IOS允许开发人员使用TouchID来验证其应用程序，绕过TouchID选项会使身份验证过程容易受到黑客攻击

M2. 不安全的数据存储

攻击者可以物理访问设备，将设备连接到计算机后访问文件系统，也可以使用许多第三方软件来访问第三方应用程序目录以及其中的用户敏感数据

• 文件系统遭破坏
  攻击者会在受感染设备中的多个位置查看不安全数据，它们主要通过操作系统，框架，编译器环境，新硬件中存在或发生的漏洞进行以及Root/越狱的设备
• 利用不安全的数据
  由于开发人员对设备如何存储缓存数据，图像，按键和缓冲区的了解不足，因此可以利用不安全的数据。分析人士观察到，在操作系统和开发框架级别缺少有关这些过程的适当技术文档，使开发人员可以忽略这些安全过程，从而使黑客可以操纵设备中的数据或过程。

M3. 数据通信安全

与移动应用程序之间的数据传输通常通过电信运营商和/或互联网进行。黑客通过受威胁的Wi-Fi网络拦截作为数据攻击者坐在用户局域网中的数据，通过路由器，蜂窝塔，代理服务器进入网络或通过恶意软件利用受感染的应用程序。

• 信息安全
  黑客通过拦截网路请求拦截去获取到用户的数据信息,开发人员应该监控到所有应用进出的流量
• 中间人攻击
  尽管移动开发人员通常都知道使用SSL / TLS进行身份验证，但他们并未正确验证这些证书，从而使网络攻击者有机会发起中间人（MITM）攻击
• 管理员帐户受损
  MITM攻击的真正危险不是当对手窃取用户数据时，而是当通信不安全而导致管理员帐户的数据被盗时。这可能会导致整个网站及其所有敏感数据遭到黑客攻击。这种攻击还可能影响或窃取加密密钥，密码，私人用户信息，帐户详细信息，会话令牌，文档，元数据和二进制文件。

1.在开发时默认网络不安全并且容易被窃听
2.使用SSL/TLS处理所有网络数据,包括web数据传输也要考虑使用SSL/TLS进行处理,确保数据的安全
3.使用强大的加密算法以及使用适当的密钥
4.使用信任的CA签名的证书
5.仅在使用密钥链中的受信任证书验证端点服务器的身份之后，才建立安全连接
6.如果移动应用检测到无效证书，则通过UI提醒用户
7.如果可能，在将任何敏感数据提供给SSL通道之前，对其应用单独的加密层。如果在SSL实施中发现了将来的漏洞，则加密的数据将提供第二道防御机密性的措施

M4. 不安全的身份验证

• 输入格式
  使用易于记忆的四位或者六位密码校验相对薄弱,移动设备上不可靠的Internet访问还迫使开发人员采用离线在线方法对会话进行身份验证
• 用户凭证不安全
  不安全身份验证的技术影响是，当应用无法正确确定用户凭据时，它也无法正确记录用户活动。如果此类用户利用设备的数据或代码或从设备传输数据或代码，则安全团队将无法正确确定攻击的来源和性质。此外，不安全的身份验证还会对设备中的用户权限造成严重破坏，因为操作系统将无法确切知道要分配给未正确身份验证的用户的角色。

1.Web应用程序的安全协议在复杂性和身份验证方法方面应与移动应用程序的安全协议匹配；
2.就像在网络浏览器中一样，使用在线身份验证方法。如果在移动设备中访问的便利性优先，请尝试防范二进制攻击，这在M10风险中有详细介绍；
3.除非服务器已验证用户会话，否则不允许加载应用程序数据。
4.将应用程序数据存储在本地可以加快加载速度，但会危及用户安全。
5.如果需要在本地存储数据，请确保使用从用户的登录凭据派生的加密密钥对数据进行加密，从而强制应用程序至少对应用程序数据进行一次身份验证；
6.永久身份验证请求应存储在服务器上，而不是本地。当用户选择使用“记住我”选项时，请务必记住要提醒用户，记住密码功能使用服务端公私钥加密相对安全
7.安全团队需要小心在应用程序中使用以设备为中心的授权令牌，因为被盗的设备应用程序容易受到攻击。

M5. 加密不足

由于弱的加密/解密过程或触发加密/解密过程的算法中的缺陷，移动应用程序中的数据变得容易受到攻击。黑客可以获取对移动设备的物理访问权，监视网络流量或使用设备中的恶意应用程序访问加密数据。利用加密过程中的缺陷，其目的是将数据解密为原始形式，以便通过对抗性过程来窃取或加密数据，从而使合法用户无法使用它。

• 窃取应用程序和用户数据
  Android和iOS都使用受信任源颁发的证书来强制对应用程序代码进行加密，当用户调用应用程序时，它们会在验证加密签名后在设备内存中解密。但是，许多常用工具允许绕过此方法。这些工具可用于在越狱设备中下载应用程序，在该设备中解密，并在用户执行该应用程序之前将解密的应用程序快照恢复到原始设备的内存中。一旦应用程序在此受损状态下执行，黑客就可以进一步分析该应用程序以进行二进制攻击或窃取用户和应用程序数据。任何依赖于操作系统提供的默认加密过程的开发人员都将面临代码操纵的风险。
• 访问加密文件
  许多开发人员对加密密钥的处理不当，即使使用最佳算法对已加密文件进行保护，攻击者也可以控制这些文件。开发人员还倾向于将加密密钥与加密数据放在同一目录中。这使黑客更容易访问密钥并将其用于解密。

1.选择现代的加密算法来加密应用程序。选择算法在很大程度上可以解决此漏洞，因为安全社区通常会测试来自受信任来源的加密算法。美国政府的国家标准技术研究院不定期发布加密标准，并建议加密算法。开发人员应注意此文档，以防出现新的威胁。
2.使用多层级校验避免二进制攻击,比如同时检测设备是否Root/越狱,检查签名文件,使用应用加固技术,合理使用混淆技术，及时更新操作系统补丁

M6. 不安全授权

不安全的授权涉及攻击者利用授权过程中的漏洞以合法用户身份登录，这与不安全的身份验证不同，在不安全的身份验证中，对手试图通过以匿名用户身份登录来绕过身份验证过程。

• 对管理端点的不受管制的访问
  一旦攻击者以合法用户身份访问应用程序，他们的下一个任务是通过强制浏览到可以执行管理命令的端点来获得管理访问权限。攻击者通常使用僵尸网络或移动设备中的恶意程序来利用授权漏洞。这种安全问题的结果是，攻击者可以在脱机模式下在设备上进行二进制攻击。
• IDOR访问：在某些情况下，授权方案使对手运行不安全的直接对象引用（通常以其首字母缩写IDOR知道），在此情况下，它可以简单地通过提供用户提供的输入来获取对对象（如数据库或文件）的访问权限。这样的泄漏会破坏整个操作系统的稳定性或导致数据和信誉的损失。

M7. 代码质量差

不良或不一致的编码实践，开发团队的每个成员都遵循不同的编码实践，并在最终代码中造成不一致，或者没有创建足够的文档供他人遵循,

• 安全web代码在手机中受到威胁
  每当在移动设备中调用代码子集时，威胁代码就可以让威胁代理推送不受信任的输入，从而使移动代码可能损害本来可以在Web浏览器中正常运行的安全应用程序。实际上，这样的移动代码可能不是恶意的，但是通过允许在设备中执行不受信任的代码，它可能会严重危害用户信息。此类别中的典型漏洞包括内存泄漏和缓冲区溢出。
• 第三方库中的漏洞
  开发人员在将流行的库集成到他们的应用程序时应谨慎。即使是老牌玩家也无意中提供了遭到破坏的库，这为应用程序所有者带来了安全问题。通常，开发人员不会跟踪第三方库的较新版本，在这些版本中，库开发人员可能已纠正了较早版本的错误代码，从而使对手可以利用可以轻松保护的应用程序。
• 客户端的不安全输入
  在为特定客户端创建的应用中，开发人员编写代码以接受所有输入为安全。由于内容提供者调用可能包含敏感信息，因此这种做法可能导致内容提供者攻击。攻击者还可以致电内容提供商并获得对不安全信息的访问。

1.解决此问题的最简单方法是在移动设备中重写代码，而不是在服务器端解决问题。开发人员应记住，服务器级别的编码与客户端的编码不同。服务器端的代码问题也将反映在应用程序的Web视图中，但是移动端的错误编码只会影响移动用户。
2.开发人员应始终使用第三方工具进行静态分析，以识别内存泄漏和缓冲区溢出。开发团队应尝试消除传入缓冲区数据的长度与目标缓冲区之间的不匹配。
3.开发人员应避免在代码中使用简单的逻辑
4.开发团队应创建该应用程序中使用的所有第三方库的列表，并定期检查其较新版本，即使仅使用来自受信任来源的库也是如此。
5.开发人员应将所有客户端输入视为不受信任，并对其进行验证，无论它来自应用程序还是来自用户。他们应该在内容提供商的输入上仔细设置权限标志，以阻止所有未经授权的访问。

M8.代码篡改

相比于其他形式的操纵，黑客更喜欢篡改应用程序的代码，因为这使他们能够不受限制地访问应用程序，用户行为甚至整个移动设备。他们倾向于促使用户通过网络钓鱼攻击和误导性广告，从第三方应用商店中下载流行应用的篡改版本。

• 恶意软件注入
  一旦成功提示用户下载被篡改的应用程序，他们将下载并安装其核心二进制文件已更改或资源包已更改的应用程序。受到篡改的应用程序使黑客可以更改系统API，以允许在移动设备中执行恶意外来代码。然后，黑客倾向于沉迷于二进制修补程序，修改设备中的常驻代码，修改内存以及盗窃数据等。
• 数据盗窃
  一般来讲修改过的应用程序可以提供比原始应用程序更多的功能,这是用户采用他们的诱因，黑客还可以更改原始应用程序中的源代码，在游戏应用程序中，篡改功能使用户可以绕过免费增值选项，而跳到下一个阶段，否则他们将不得不为此付费。通过为用户提供这种有利可图的报价，黑客可以轻松地将间谍软件插入其设备并窃取其用户信息。

1.运行时检测: 开发人员应确保该应用程序可以在运行时检测到代码更改。如果被篡改的应用程序希望在有根或越狱的设备中运行，而开发人员不希望允许这种执行，则最好在运行时自行向服务器报告这种危害。 应用加壳运行时多层检测防护是开发人员可以用来实时检测和阻止攻击媒介的一种技术。
2.校验和更改:开发人员应使用校验和并评估数字签名，以查看是否发生了文件篡改。由于代码和文件篡改几乎总是会更改校验和值，因此这是确定对抗措施的最简单方法。
3.资料清除:一旦检测到篡改，请确保擦除应用代码，密钥和数据。这样的规定将破坏篡改的理由，并阻止黑客再次针对同一应用。

M9.逆向工程

移动代码的逆向工程是普遍可利用的情况。黑客倾向于使用外部的，普遍可用的二进制检查工具，例如IDA Pro，Hopper，otool等，来研究原始应用程序的代码模式及其与服务器进程的链接。

• 运行时动态检查
  某些语言（例如Java，.NET，Objective C，Swift）比其他语言更易于进行逆向工程，因为它们允许在运行时进行动态检查。除其他损害外，反向工程代码还会影响服务器的安全性，移动设备中包含的数据以及服务器检测越狱或生根设备的能力。
• 偷代码
  应用程序竞争对手可以使用逆向工程来查看应用程序的功能，甚至可以偷偷复制某些功能。这样，减少了开发新代码的成本。
• 高级功能
  黑客可以通过绕过身份验证过程来使用此技术来访问应用程序的高级功能。通过这种方法，游戏作弊可能会在竞争中获得不公平的优势。

1.使用类似的工具保护应用程序免受逆向工程保护的最佳方法是使用黑客用来进行逆向工程的相同工具。如果这些工具可以轻松分析应用程序的字符串表，控制流路径，与服务器的交互，密码常量和密码，元数据等，那么代码就毫无用处。开发人员还可以使用AppSealing之类的工具实时检测逆向工程的尝试。
2.混淆过程应针对最小影响代码性能的源代码，字符串表和方法的特定段。开发人员应确保使用迷惑工具（如IDA Pro和Hopper）不容易逆转他们采用的迷惑程度。
3.考虑使用C和C ++，可以在很大程度上帮助运行时操作。这两种语言的许多库都可以轻松地与Objective C集成。对于Android应用程序，类似的方法是使用其Java本机接口。使用C和C ++库的目的是为了保护运行时或反向工程工具，例如class-dump，class-dump-z，Cycript或Frida。

M10：多余的功能

在应用准备好投入生产之前，开发团队通常会将代码保存在其中，以方便访问后端服务器，创建日志以分析错误或携带暂存信息和测试详细信息。此代码与应用程序的功能无关，即，一旦应用程序投入生产，它就不会对目标用户有用，并且仅在开发周期内才需要。

• 外部功能风险
  在大多数情况下，良性代码不会为获得访问权限的对手提供任何额外的优势。但是，在某些情况下，此代码可以包含与数据库，用户详细信息，用户权限，API端点等有关的信息，或者禁用诸如两因素身份验证之类的功能。

1.开发人员应该知道，自动化工具不能总是检测出M10风险的存在。通常，在将应用程序推送到应用程序商店之前，它需要人工干预。开发人员应在发布应用程序之前采取以下步骤：
2.确保最终版本中没有测试代码；
3.确保配置设置中没有隐藏的开关；
4.日志不应包含任何有关后端服务器进程，管理特权等的描述；
5.通常，日志根本不应该是描述性的；
6.确保OEM不会向应用程序公开完整的系统日志；
7.使用ProGuard或DexGuard停止方法调用和日志类之间的交互；
8.确保对手无法将应用的调试标志设置为true；和
9.应用程序访问的API端点应有详细记录。

欢迎关注Mike的

Android 知识整理