不安全的 API 或库
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
OWASP 类别：MASVS-CODE：代码质量
概览
使用不安全的 API 或库会显著降低应用的安全状况。如果其中任何依赖项出现安全事故，攻击者就能利用多种途径来实施大量攻击，例如中间人 (MitM) 和远程代码执行 (RCE) 攻击。
如果开发者未将安全评估和漏洞测试集成到软件开发生命周期 (SDLC)，或者在某些情况下未对应用依赖项实施自动更新政策，就会出现实现不安全依赖项的威胁。
利用依赖项攻击通常会先分析应用二进制文件 (.apk) 以搜索存在漏洞的库。此时，系统会执行开源情报 (OSINT)，以找出之前发现的可利用漏洞。之后，攻击者便可利用公开披露的漏洞信息（例如常见漏洞和风险 [CVE]）执行进一步攻击。
影响
成功利用不安全的依赖项可能会导致各种攻击，例如远程代码执行 (RCE)、SQL 注入 (SQLi) 或跨站脚本攻击 (XSS)。因此，总体影响与第三方软件引入的漏洞类型以及攻击者可利用的漏洞类型直接相关。成功利用存在漏洞的依赖项可能造成数据泄露或服务不可用等后果，这可能会对声誉和经济收入产生重大影响。
缓解措施
纵深防御
请注意，下列缓解措施必须结合起来实施，以确保强化安全状况，并缩小应用的攻击面。始终应根据具体情况评估确切的方法。
依赖项漏洞评估
在开发生命周期之初实施依赖项验证，以检测第三方代码中的漏洞。此阶段会在将非内部构建的代码发布到生产环境之前先测试这些代码是否安全。除了验证之外，还可以在软件开发生命周期内辅以实现静态应用安全保障测试 (SAST) 和动态应用安全保障测试 (DAST) 工具，以改善应用的安全状况。
持续更新依赖项
始终要注意持续更新代码中嵌入的任何依赖项。为此，我们建议，只要第三方组件发布新的安全补丁，便实现推送到生产环境的自动更新。
执行常规渗透测试。此类测试旨在发现任何可能影响专有代码和/或第三方依赖项的已知漏洞。此外，安全评估还会经常发现未知漏洞 (0-day)。渗透测试对开发者来说很实用，因为这些测试能为他们提供应用当前安全状况的概况信息，并帮助他们确定必须解决的可能被利用的安全问题的优先级。
资源
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2023-12-13。
[null,null,["最后更新时间 (UTC)：2023-12-13。"],[],[],null,["# Insecure API or Library\n\n\u003cbr /\u003e\n\n**OWASP category:** [MASVS-CODE: Code Quality](https://mas.owasp.org/MASVS/10-MASVS-CODE)\n\nOverview\n--------\n\nUsing insecure APIs or libraries significantly reduces an application's security\nposture. A security breach in any of these dependencies would allow an attacker\nto leverage a number of vectors to conduct a broad set of attacks such as man-\nin-the-middle (MitM) and remote code execution (RCE).\n\nThe threat of implementing insecure dependencies arises when developers don't\nintegrate security assessments and vulnerability testing into the Software\nDevelopment Lifecycle (SDLC) or, in some cases, don't implement an automated\nupdate policy for application dependencies.\n\nDependency exploitation usually starts by analyzing application binary (.apk) to\nsearch for vulnerable libraries. At this point, Open Source Intelligence (OSINT)\nis performed to unearth previously discovered potentially exploitable\nvulnerabilities. Attackers can then leverage publicly disclosed vulnerability\ninformation such as common vulnerabilities and exposures (CVEs) to perform\nfurther attacks.\n\nImpact\n------\n\nThe successful exploitation of insecure dependencies can lead to a broad set of\nattacks such as remote code execution (RCE), SQL injections (SQLi), or cross-\nsite scripting (XSS).\nTherefore, the overall impact is directly related to the type of vulnerability\nthat third-party software introduces and that attackers can exploit.\nPossible consequences of a successful exploitation of vulnerable dependencies\nare data breaches or service unavailability, which may lead to a significant\nimpact on reputation and economic turnover.\n\nMitigations\n-----------\n\n### Defense in depth\n\nNote that the mitigations listed below have to be implemented in combination to\nensure a stronger security posture, and reduce the application's attack surface.\nThe exact approach should always be evaluated on a case-by-case basis.\n\n### Dependency vulnerability assessments\n\nImplement dependency verification at the beginning of the development lifecycle\nto detect vulnerabilities within third-party code. This phase tests whether the\ncode that is not built in-house is secure before being rolled out in production\nenvironments.\nVerification could be complemented by implementing static application security\ntesting (SAST) and dynamic application security testing (DAST) tools within the\nsoftware development lifecycle to improve the security posture of the\napplication.\n\n### Continuously update dependencies\n\nAlways be careful to continuously update any dependency embedded within the\ncode. For this purpose, it is recommended to implement automatic updates that\nare pushed to production whenever a third-party component releases a new\nsecurity patch.\n\n### Perform application penetration testing\n\nConduct regular penetration tests. These kinds of tests aim to uncover any well-\nknown vulnerability that could affect proprietary code and, or third-party\ndependencies.\nAdditionally, security assessments frequently uncover unknown vulnerabilities\n(0-days).\nPenetration tests are helpful for developers, as they provide them with a\nsnapshot of the application's current security posture and help them prioritize\nexploitable security issues that have to be addressed.\n\nResources\n---------\n\n- [How to recognise and manage insecure dependencies](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html)\n\n- [GitHub security features](https://docs.github.com/en/code-security/getting-started/github-security-features)\n\n- [How to secure dependencies](https://www.hacksplaining.com/prevention/toxic-dependencies)\n\n- [CWE-1395: Dependency on Vulnerable Third-Party Component](https://cwe.mitre.org/data/definitions/1395.html)\n\n- [SDK implementation best-practices for Android.](/guide/practices/sdk-best-practices)"]]
