1. OWASP 移动应用 2024 十大安全风险

开放全球应用程序安全项目 （OWASP） 是一个非营利性基金会，致力于提高软件的安全性。自 2014、2016 年两次发布了移动应用的 10 大风险后，今年再次发布2024版。这对移动应用软件的检查工具有着重要的指导作用。

1.1. M1 - 凭据使用不当(Improper Credential Usage)

1.1.1. 攻击途径

• 可利用性: 容易

攻击者可以利用硬编码凭据和不当凭据使用中的漏洞。一旦发现这些漏洞，攻击者就可以使用硬编码的凭据来未经授权访问移动应用程序的敏感功能。他们还可能滥用凭据，例如通过未经正确验证或存储的凭据获取访问权限，从而绕过合法访问的需要。

1.1.2. 攻击场景

当移动应用使用硬编码凭据或凭据被滥用时，可能会发生不安全的凭据管理。

以下是移动应用可能容易受到攻击的一些场景：

• 硬编码凭据
  如果移动应用的源代码或任何配置文件中包含硬编码凭据，则这清楚地表明存在漏洞。

• 不安全的凭据传输
  如果凭据是在未加密的情况下传输的，或者是通过不安全的通道传输的，则可能表示存在漏洞。

• 不安全的凭据存储
  如果移动应用程序以不安全的方式将用户凭据存储在设备上，则可能表示存在漏洞。

• 弱用户身份验证
  如果用户身份验证依赖于弱协议或允许轻松绕过，则这可能是漏洞的迹象。

1.1.3. 安全漏洞

• 发生率：常见
• 可检测性：容易

凭据管理实施不当（例如使用硬编码凭据和处理不当）可能会导致严重的安全漏洞。全面的安全测试过程应旨在识别这些问题。例如，安全测试人员应尝试在移动应用程序的源代码或任何配置文件中识别硬编码的凭据。

1.2. M2 - 供应链安全不足(Inadequate Supply Chain Security)

1.2.1. 攻击途径

• 可利用性: 一般

有多种方法可以利用供应链不足漏洞，例如，内部威胁代理或攻击者可以在应用程序的开发阶段注入恶意代码，然后他们可以破坏应用程序签名密钥或证书以将恶意代码签名为受信任。

另一种方式是，威胁代理可以利用应用程序中使用的第三方库或组件中的漏洞。

1.2.2. 攻击场景

您可能容易受到供应链不足漏洞的影响，尤其是在您使用由第三方开发人员开发或依赖第三方库和组件的移动应用程序时。

该漏洞可能由多种原因引起，例如：

• 第三方组件缺乏安全性
  第三方组件（如库或框架）可能包含可被攻击者利用的漏洞。如果移动应用程序开发人员未正确审查第三方组件或对其进行更新，则应用程序可能容易受到攻击。

• 恶意内部威胁
  恶意内部人员（例如流氓开发人员或供应商）可能会故意将漏洞引入移动应用程序。如果开发人员没有对供应链流程实施足够的安全控制和监控，就会发生这种情况。

• 测试和验证不足
  如果移动应用程序开发人员没有彻底测试应用程序，它可能容易受到攻击。开发人员还可能无法验证供应链流程的安全性，从而导致应用程序中出现漏洞。

• 缺乏安全意识
  如果移动应用程序开发人员没有足够的安全意识，他们可能无法实施必要的安全控制来防止供应链攻击。

1.2.3. 安全漏洞

• 发生率：常见
• 可检测性：困难

供应链不足漏洞是由于缺乏安全的编码实践、代码审查和测试不足导致应用程序中包含漏洞而发生的。

供应链漏洞不足的其他原因包括应用程序签名和分发流程不足或不安全、第三方软件组件或库的弱点、数据、加密、存储的安全控制不足，或将敏感数据暴露在未经授权的访问中。

1.3. M3 - 不安全的身份验证/授权(Insecure Authentication/Authorization)

1.3.1. 攻击途径

• 可利用性: 容易

一旦攻击者了解身份验证或授权方案中的漏洞，他们就可以通过以下两种方式之一利用这些漏洞。他们可以通过直接向移动应用程序的后端服务器提交服务请求来伪造或绕过身份验证，从而绕过与移动应用程序的任何直接交互，或者他们可以在成功通过身份验证控制后以合法用户身份登录应用程序，然后强制浏览到易受攻击的端点以执行管理功能。这两种利用方法通常都是通过设备内的移动恶意软件或攻击者拥有的僵尸网络来实现的。

1.3.2. 攻击场景

了解身份验证和授权之间的区别对于评估移动应用程序安全性至关重要。身份验证标识个人，而授权验证标识的个人是否具有特定操作的必要权限。这两个方面密切相关，因为授权检查应立即在移动设备请求身份验证之后进行。

当组织在从移动设备执行请求的 API 端点之前未能对个人进行身份验证时，可能会发生不安全的授权，因为如果没有已建立的调用方身份，几乎不可能对传入请求进行授权检查。

以下是一些不安全授权的简单场景：

• 存在不安全的直接对象引用 （IDOR） 漏洞
  注意到 IDOR 漏洞可能表明代码未执行正确的授权检查。
• 隐藏的终结点
  开发人员可能会忽略对后端隐藏功能的授权检查，假设隐藏功能只能由具有适当角色的用户访问。
• 用户角色或权限传输
  如果移动应用将用户的角色或权限作为请求的一部分传输到后端系统，则可能表示授权不安全。

同样，移动应用程序可能会表现出各种不安全身份验证的迹象：

• 匿名后端 API 执行
  应用在不提供访问令牌的情况下执行后端 API 服务请求的能力可能指向不安全的身份验证。
• 密码或共享密钥的本地存储
  如果应用在设备上本地存储任何密码或共享密钥，则可能是身份验证不安全的迹象。
• 弱密码策略
  使用简化的密码输入过程可能意味着不安全的身份验证。
• 使用 FaceID 和 TouchID 等功能
  使用 FaceID 或 TouchID 等功能可能表明身份验证不安全。

1.3.3. 安全漏洞

• 发生率：常见
• 可检测性：一般

为了测试移动应用程序中不良的授权和身份验证方案，测试人员可以采用多种策略。对于授权，测试人员可以对移动应用程序执行二进制攻击，并尝试执行只能由具有更高权限的用户执行的特权功能，尤其是在移动应用程序处于“离线”模式时。测试人员还应尝试在对后端服务器的敏感功能的相应 POST/GET 请求中使用低特权会话令牌执行任何特权功能。

不良或缺失的授权方案可能会允许攻击者使用经过身份验证但权限较低的移动应用用户执行他们不应有权使用的功能。当授权决策是在移动设备内而不是通过远程服务器做出时，这种权限升级攻击的风险会增加，这种情况通常是由于离线可用性的移动要求而出现的。

就糟糕的身份验证方案而言，测试人员可以在移动应用程序处于“离线”模式时对其进行二进制攻击，旨在绕过离线身份验证，然后执行需要离线身份验证的功能。测试人员还应尝试通过从移动应用功能的任何 POST/GET 请求中删除任何会话令牌来匿名执行任何后端服务器功能。

不良或缺失的身份验证方案可能允许攻击者在移动应用或移动应用使用的后端服务器中匿名执行功能。由于移动设备的输入外形因素，移动应用程序身份验证中的这些弱点相当普遍，这通常鼓励使用短密码或 4 位 PIN。

移动应用程序面临着独特的身份验证要求，这些要求可能与传统的 Web 身份验证方案不同，这主要是由于它们的可用性要求不同。与传统的 Web 应用程序不同，在传统的 Web 应用程序中，用户需要在线并使用后端服务器进行实时身份验证，而移动应用程序可能需要满足正常运行时间要求，由于移动互联网连接的不可靠性或不可预测性，因此需要离线身份验证。此要求可能会显著影响开发人员在实施移动身份验证时必须考虑的因素。

1.4. M4 - 输入/输出验证不足(Insufficient Input/Output Validation)

1.4.1. 攻击途径

• 可利用性: 困难

输入/输出验证不足会使我们的应用程序暴露于严重的攻击媒介，包括 SQL 注入、XSS、命令注入和路径遍历。这些漏洞可能导致未经授权的访问、数据操纵、代码执行和整个后端系统的破坏。

1.4.2. 攻击场景

由于以下原因，应用程序可能容易受到输入/输出验证不足的影响：

• 缺少输入验证
  未能正确验证用户输入可能会使应用程序面临注入攻击，例如 SQL 注入、命令注入或 XSS。
• 输出清理不足
  输出数据清理不足可能导致 XSS 漏洞，使攻击者能够注入和执行恶意脚本。
• 特定于上下文的验证忽略
  忽略考虑基于数据上下文的特定验证要求可能会产生漏洞，例如路径遍历攻击或未经授权访问文件。
• 数据完整性检查不足
  未执行适当的数据完整性检查可能会导致数据损坏或未经授权的修改，从而损害可靠性和安全性。
• 糟糕的安全编码实践
  忽视安全编码实践，例如使用参数化查询或转义/编码数据，会导致输入/输出验证漏洞。

1.4.3. 安全漏洞

• 发生率：常见
• 可检测性：容易

当应用程序未能正确检查和审查用户输入或验证和审查输出数据时，就会发生输入/输出验证不足漏洞。可以通过以下方式利用此漏洞：

• 输入验证不足
  当用户输入未得到彻底检查时，攻击者可以通过输入意外或恶意数据来操纵它。这可能会绕过安全措施，并导致代码执行漏洞或未经授权的系统访问。

• 输出验证不足
  如果输出数据未得到正确验证和审查，攻击者可以注入由用户浏览器执行的恶意脚本。这可能导致跨站点脚本 （XSS） 攻击，从而导致数据盗窃、会话劫持或操纵显示的内容。

• 缺乏上下文验证
  不考虑特定的上下文或预期的数据格式可能会导致 SQL 注入或格式字符串漏洞等漏洞。当未经验证的用户输入直接合并到数据库查询中或在格式字符串函数中处理不当时，就会发生这种情况，从而允许攻击者操纵查询或执行任意代码。

• 无法验证数据完整性
  如果不验证数据完整性，应用程序就会容易受到数据损坏或错误处理的影响。攻击者可以篡改关键系统变量或引入格式错误的数据，从而破坏应用程序的功能。

这些漏洞通常源于应用程序逻辑中的错误、验证检查的不完整实现、缺乏安全意识或测试和代码审查实践不足。

1.5. M5 - 不安全的通信(Insecure Communication)

1.5.1. 攻击途径

• 可利用性: 容易

虽然现代应用程序确实会回复 SSL/TLS 等加密协议，但它们的实现有时可能存在缺陷，例如：

• 使用已弃用的协议和/或错误的配置设置;
• 接受错误的 ssl 证书（自签名、吊销、过期、错误的主机…或
• 不一致（仅在选定的工作流（如身份验证）上具有 SSL/TLS）。

1.5.2. 攻击场景

这种风险涵盖了从 A 点到 B 点获取数据的所有方面，但这样做并不安全。它包括移动到移动通信、应用程序到服务器通信或移动到其他通信。此风险包括移动设备可能使用的所有通信技术：TCP/IP、WiFi、蓝牙/蓝牙-LE、NFC、音频、红外线、GSM、3G、短信等。

所有TLS通信问题都在这里。所有 NFC、蓝牙和 WiFi 问题都在这里。

突出的特征包括打包某种敏感数据并将其传输到设备或传出设备。敏感数据的一些示例包括加密密钥、密码、私人用户信息、帐户详细信息、会话令牌、文档、元数据和二进制文件。敏感数据可能来自服务器，也可能来自应用程序到服务器，或者它可能在设备和其他本地设备（例如，NFC终端或NFC卡）之间传输。这种风险的定义特征是存在两个设备以及它们之间传递的一些数据。

如果数据存储在设备本身的本地，则 #Insecure 数据。如果会话详细信息是安全地通信的（例如，通过强 TLS 连接），但会话标识符本身是错误的（也许是可预测的、低熵等），那么这是一个 #Insecure 身份验证问题，而不是通信问题。

不安全通信的常见风险与数据完整性、数据机密性和源完整性有关。如果数据可以在传输过程中被更改，而更改是不可检测到的（例如，通过中间人攻击），那么这就是这种风险的一个很好的例子。如果机密数据可以通过观察通信（即窃听）或记录对话并在以后进行攻击（离线攻击）来暴露、学习或派生，这也是一个不安全的通信问题。未能正确设置和验证 TLS 连接（例如，证书检查、弱密码、其他 TLS 配置问题）都属于不安全的通信。

1.5.3. 安全漏洞

• 发生率：常见
• 可检测性：一般

虽然现代移动应用程序旨在保护网络流量，但它们的实现往往不一致。这些不一致可能会导致漏洞，使数据和会话 ID 暴露于拦截范围。仅仅因为应用使用传输安全协议并不意味着它已正确实现。要识别基本缺陷，您可以观察手机上的网络流量。但是，要检测更细微的缺陷，需要仔细研究应用程序的设计和配置。

1.6. M6 - 隐私控制不足(Inadequate Privacy Controls)

1.6.1. 攻击途径

• 可利用性: 一般

PII 的典型来源受到很好的保护，例如，应用程序的沙盒、与服务器的网络通信、应用程序的日志和备份。有些保护较少，但仍然难以访问，例如 URL 查询参数和剪贴板内容。

因此，获取 PII 需要攻击者首先在另一个层面上破坏安全性。攻击者可以使用特洛伊木马窃听网络通信、访问文件系统、剪贴板或日志，或者获取移动设备并创建备份进行分析。由于 PII 只是可以通过移动设备上可用的所有方式存储、处理和传输的数据，因此提取或操作它的可能性是多方面的。

1.6.2. 攻击场景

只有当应用程序处理某种形式的个人身份信息时，它才容易受到隐私控制不足的影响。几乎总是如此：客户端应用的 IP 地址对服务器可见、应用使用情况日志以及与崩溃报告或分析一起发送的元数据都是适用于大多数应用的 PII。通常，应用程序会从其用户那里收集和处理其他更敏感的 PII，例如帐户、支付数据、位置等。

给定使用 PII 的应用，它可能会像任何其他敏感数据一样公开它。这最显着地发生在

• 不安全的数据存储和通信（参见 M5、M9）；
• 使用不安全的身份验证和授权访问数据（参见 M3、M1）；
• 内部人员对应用程序沙盒的攻击（参见 M2、M4、M8）。

1.6.3. 安全漏洞

• 发生率：常见
• 可检测性：容易

几乎所有应用程序都会处理某种 PII。许多人甚至收集和处理超过他们实现目的所需的东西，这使得他们作为没有业务需求的目标更具吸引力。

由于开发人员对 PII 的粗心处理，侵犯隐私的风险会增加。在处理 PII 时，应始终牢记攻击者访问通信和存储介质的可能性。

因此，如果应用程序收集的某些个人数据促使攻击者通过安全性不足的存储或传输介质操纵或滥用该数据，则应用程序容易受到隐私侵犯。

1.7. M7 - 二进制保护不足(Insufficient Binary Protections)

1.7.1. 攻击途径

• 可利用性: 容易

应用二进制文件通常可以从应用商店下载或从移动设备复制，因此二进制攻击很容易设置。

应用二进制文件可能会受到两种类型的攻击：

• 逆向工程
  对应用二进制文件进行反编译并扫描有价值的信息，例如密钥、算法或漏洞。
• 代码篡改
  应用程序二进制文件纵，例如，删除许可证检查、规避付费墙或作为用户获得其他好处。或者，可以操纵该应用程序以包含恶意代码。

1.7.2. 攻击场景

所有应用程序都容易受到二进制攻击。如果应用程序具有以二进制文件硬编码的敏感数据或算法，或者如果它非常受欢迎，则二进制攻击可能会变得特别有害。如果有额外的保护措施，如混淆、在本机代码（适用于 Android）中对机密进行编码或类似措施，成功的攻击将变得更加难以实现，但绝不可能。

应用程序是否足够安全取决于不同二进制攻击可能产生的业务影响。对攻击者的激励越大，影响越大，就越应该在保护方面投入更多的精力。因此，针对二进制攻击的“漏洞”高度特定于给定的应用程序。

为了快速检查，开发人员可以使用与攻击者类似的工具检查自己的应用二进制文件。有许多免费或负担得起的工具，例如 MobSF、otool、apktool 和 Ghidra，它们也非常易于使用且有据可查。

1.7.3. 安全漏洞

• 发生率：常见
• 可检测性：容易

所有应用程序都容易受到二进制攻击，许多应用程序最终会在某个时候成为某种形式的攻击对象。那些将敏感数据或算法硬编码到其二进制文件中的应用程序特别容易受到二进制攻击。这些应用应采用对策来抵御潜在的攻击者足够长的时间，以便攻击者放弃，因为成功破坏保护的成本将比成功获得的收益更昂贵。通常，例如，在版权保护的情况下，延长破解过程就足够了，直到达到应用销售的目标收入。

一般来说，与 Android 应用中的高级字节码相比，完全编译的应用（如 iOS 应用）更不容易受到逆向工程和代码篡改的影响（请注意，这可能不适用于使用跨平台技术（如 PWA 或 Flutter）开发的应用）。

特别流行的应用程序可能会通过应用商店纵和重新分发。检测和删除这些纵的副本由专业公司提供，但也可以通过应用程序本身的某些检测和报告机制来实现。

请注意，没有完全可靠的机制来防止二进制攻击。防御它们是投资于对策的开发商和破坏这些措施的攻击者之间的军备竞赛。因此，每个应用程序要回答的问题是：应该投入多少精力来应对二进制攻击？

1.8. M8 - 安全配置错误(Security Misconfiguration)

1.8.1. 攻击途径

• 可利用性: 困难

移动应用程序中的安全配置错误可通过各种攻击媒介加以利用，包括：

• 不安全的默认设置
  移动应用通常附带默认配置，这些配置可能具有较弱的安全设置或启用了不必要的权限，使其容易受到攻击。

• 不正确的访问控制
  配置错误的访问控制可能允许未经授权的用户访问敏感数据或执行特权操作。

• 弱加密或哈希
  可利用未正确实施或弱加密和哈希算法来访问敏感信息。

• 缺乏安全通信
  不使用安全通信协议（如 SSL/TLS）可能会使敏感数据暴露于窃听和中间人攻击。

• 未受保护的存储
  以不安全的方式（如纯文本或弱加密）存储敏感数据（如密码或 API 密钥）可能会导致未经授权的访问。

• 不安全的文件权限
  使用全局可读和/或全局可写权限存储应用程序文件。

• 会话管理配置错误
  会话管理不当可能导致会话劫持，使攻击者能够冒充合法用户。

1.8.2. 攻击场景

如果移动应用未正确配置为遵循安全最佳实践，则容易受到安全错误配置的影响。易受安全错误配置影响的常见指标包括：

• 未查看默认设置
  使用默认配置，而不查看安全设置、权限和默认凭据。
• 缺乏安全通信
  使用未加密或弱加密的通信通道。
• 访问控制薄弱或缺失
  允许未经授权访问敏感功能或数据。
• 更新或修补失败
  未将必要的安全更新或修补程序应用于应用或基础组件。
• 敏感数据存储不当
  以纯文本或弱保护格式存储敏感数据。
• 不安全的文件提供程序路径设置
  用于内部应用程序使用的文件内容提供程序向其他应用或用户公开，这可能会危及敏感数据或允许未经授权访问应用程序资源。
• 导出的活动
  导出和/或可浏览供内部应用程序使用的活动，这会暴露额外的攻击面。

若要确定应用是否容易受到安全错误配置的影响，应进行全面的安全评估，包括代码审查、安全测试和配置分析。

1.8.3. 安全漏洞

• 发生率：常见
• 可检测性：容易

由于时间限制、缺乏意识或开发过程中的人为错误等因素，安全配置错误在移动应用程序中很常见。通过手动代码审查、安全测试或自动扫描工具检测安全配置错误相对容易。

安全配置错误的示例包括：

• 未能在发布版本中禁用调试功能，这可能会暴露敏感信息。
• 允许不安全的通信协议（如 HTTP），而不是通过 HTTPS 强制执行安全通信。
• 保持默认用户名和密码不变，方便攻击者访问。
• 访问控制不足，允许未经授权的用户执行特权操作。

1.9. M9 - 不安全的数据存储(Insecure Data Storage)

1.9.1. 攻击途径

• 可利用性: 容易

移动应用程序中不安全的数据存储会使漏洞暴露给威胁参与者可以利用的各种攻击媒介。攻击媒介包括通过物理或远程方式未经授权访问设备的文件系统、利用弱加密或缺乏加密、拦截数据传输以及利用设备上安装的恶意软件或恶意应用程序。此外，有根或越狱的设备为攻击者提供了绕过安全措施并直接访问敏感数据的机会。其他攻击媒介包括社会工程技术，以欺骗用户提供对其数据的访问或操纵应用程序的行为。

总体而言，移动应用程序上不安全的数据存储为从直接数据提取到拦截敏感信息的攻击开辟了途径，这凸显了移动应用程序开发中对强大加密、安全传输协议和全面安全措施的迫切需求。

1.9.2. 攻击场景

移动应用程序中不安全的数据存储和意外数据泄露可能以多种方式表现出来，从而导致潜在的隐私泄露和未经授权访问敏感信息。以下是这些问题的常见表现形式：

• 缺乏访问控制
  应用程序中的访问控制不足可能会允许未经授权的用户或攻击者访问存储在设备或应用程序数据库中的敏感数据。

• 加密不足
  如果攻击者无法正确加密敏感数据，则可能导致意外的数据泄露。无需加密，数据易于读取并可被利用。

• 无意数据泄露
  移动应用程序可能会通过应用程序日志、错误消息或调试功能无意中暴露敏感数据，从而允许未经授权的个人查看或捕获敏感信息。

• 糟糕的会话管理
  薄弱的会话管理可能导致意外的数据泄露。如果会话令牌或用户身份验证信息没有得到充分的保护或管理，它们可能会被拦截或操纵，从而允许未经授权访问敏感数据。

• 输入验证不足
  输入验证和数据清理不充分可能导致意外数据泄露。攻击者可利用此漏洞注入恶意脚本或通过操纵输入字段来检索敏感数据。

• 云存储配置错误
  如果移动应用程序使用云存储服务进行数据存储，并且配置管理不善或配置错误，则可能导致意外暴露或未经授权访问存储的数据。

• 第三方库漏洞
  移动应用程序中使用的不安全第三方库可能存在可能导致意外数据泄露的漏洞。攻击者可以利用这些漏洞在未经授权的情况下访问敏感信息。

• 意外数据共享
  应用程序中数据共享功能处理不当可能会导致意外数据泄露。如果与非预期收件人共享敏感数据，或者共享过程没有得到充分保护，则可能导致隐私泄露。

1.9.3. 安全漏洞

• 发生率：常见
• 可检测性：一般

移动应用程序中不安全的数据存储包含各种安全漏洞，这些漏洞可能会危及存储信息的机密性和完整性。这些弱点包括使用弱加密或不存在的加密，使攻击者能够轻松访问和破译敏感数据。此外，将数据存储在设备文件系统中易于访问的位置（例如纯文本文件或未受保护的数据库）会使其暴露在未经授权的提取或操作中。访问控制和用户身份验证机制不足使问题进一步复杂化，使未经授权的个人能够访问敏感数据。

此外，由于缺乏安全的数据传输协议，数据在移动应用程序与外部服务器之间的通信过程中容易受到拦截。总的来说，移动应用程序数据存储中的这些安全漏洞为数据泄露、未经授权的访问和数据篡改创造了机会，强调了对强大的加密、安全存储实践和严格的访问控制以减轻这些风险的迫切需要。

1.10. M10- 加密不足(Insufficient Cryptography)

1.10.1. 攻击途径

• 可利用性: 一般

移动应用程序中不安全加密的攻击媒介涉及利用用于保护敏感信息的加密机制中的漏洞。攻击者可能会采用各种技术（例如加密攻击、暴力攻击或侧信道攻击）来利用加密算法、密钥管理或实现缺陷中的弱点。通过针对不安全的加密技术，攻击者旨在解密加密数据、操纵加密过程或未经授权访问敏感信息。这可能导致数据泄露、未经授权访问用户帐户、机密性受损或伪造或篡改数据的能力。

1.10.2. 攻击场景

不安全的加密和不安全的哈希函数可以通过多种方式在移动应用程序中表现出来：

• 弱加密算法
  移动应用程序可能使用已知弱或易受攻击的加密算法。这些算法可能存在已知的弱点、过时或缺乏有效保护敏感数据所需的安全级别。

• 密钥长度不足
  密钥长度不足会削弱加密强度。如果移动应用程序使用简短或易于猜测的加密密钥，则攻击者更容易通过暴力或其他加密攻击解密加密数据。

• 密钥管理不当
  不良的密钥管理做法（例如不安全地存储加密密钥或以纯文本形式传输加密密钥）可能会使密钥暴露在未经授权的访问中。获得密钥访问权限的攻击者可以毫无困难地解密数据。

• 有缺陷的加密实现
  加密/解密过程本身可能未正确实现或包含编程缺陷。这些实现错误可能会引入漏洞，攻击者可以利用这些漏洞来绕过或削弱加密保护。

• 数据/加密密钥的不安全存储
  如果加密密钥以不安全的方式存储在移动设备上，例如以纯文本形式或易于访问的位置，则对设备具有物理或未经授权访问权限的攻击者可以检索密钥并解密受保护的数据。移动应用程序使用弱加密算法或错误地使用加密，例如使用弱密钥或未能正确加密所有敏感数据。如果攻击者很容易绕过或解密加密，这可能会导致数据泄露。

• 缺乏安全传输层
  通过网络传输加密数据时，使用 HTTPS 等安全传输层协议至关重要。如果手机应用程式未能实施安全传输协议，加密数据在传输过程中可能容易被截取或篡改。

• 验证和身份验证不足
  对加密过程中涉及的各方进行不充分的验证和身份验证可能会削弱整体安全性。如果没有适当的验证，攻击者可以冒充合法实体，拦截加密数据，并在不被发现的情况下对其进行操作。

• 缺乏加盐
  加盐是在哈希之前将随机数据添加到输入中的过程，对于增强密码的安全性至关重要。不安全的哈希函数可能不支持加盐，或者可能使用弱加盐方法，使密码哈希容易受到预先计算的表或暴力攻击等攻击。

1.10.3. 安全漏洞

• 发生率：常见
• 可检测性：一般

移动应用程序中的不安全加密会引入安全漏洞，这些漏洞可能会破坏加密措施的有效性并损害敏感数据的机密性和完整性。这些弱点可能包括使用弱加密算法或密钥长度不足、密钥管理实践不佳、加密密钥处理不当、随机数生成不安全、加密协议实现有缺陷或加密库或框架中的漏洞。攻击者可以利用这些弱点绕过加密、执行加密攻击、操纵数据或未经授权访问加密信息。不安全的哈希函数和加密算法在移动应用程序中构成了严重的安全漏洞。这些漏洞可能导致严重的数据泄露和对敏感信息的未经授权的访问。当使用过时或弱哈希函数时，攻击者可以利用这些漏洞对哈希数据进行逆向工程，从而泄露原始内容。为了保护移动应用程序免受这些安全风险的影响，必须采用强大而现代的哈希函数和加密算法，并遵循加密和密钥管理的最佳实践，以确保数据的完整性和机密性。定期的安全审核和更新对于保持针对潜在威胁的最高级别的保护也至关重要。

2. OWASP 移动应用 2024 十大安全风险 和 2016 相比

3. Fortify 在 OWASP 移动应用 2024 十大安全风险的规则覆盖

在今年 OWASP 移动应用 2024 十大安全风险公布后，头部的静态检查工具，在上半年的两个版本发布中，很快适配了这个十大风险，给出了各自规则的对应这十大风险的检查规则。但由于其中的第二点需要用软件成分分析工具（SCA）来检测，所以通常不包含在静态分析工具中。

下表给出了Fortify 最新的版本的Java 规则对OWASP 移动应用 2024 十大安全风险的规则覆盖情况表。

4. 结论

• OWASP 移动应用 2024 十大安全风险，对静态分析工具有着重要的指导作用；
• OWASP 移动应用 2024 十大安全风险，没有像OWASP TOP 10 2021那样给出相应的 CWE，在问题的覆盖上容易产生歧义，建议提供相应的CWE列表，提高问题的覆盖的可度量性；
• 移动应用除了苹果、安卓以外，很快会迎来另一个重要的移动操作系统鸿蒙。这些安全问题同样会在鸿蒙的移动应用中存在。我们可以借鉴这些问题，提供针对鸿蒙系统的静态检查工具，以保障鸿蒙移动应用系统的安全性，建立鸿蒙的安全检查生态。

5. 参考

• OWASP Mobile Top 10 2024
• OWASP Top 10 2021
• CWE 4.6 和 OWASP TOP10(2021)
• Fortify 规则