不安全的 API 或程式庫
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
OWASP 類別：MASVS-CODE：程式碼品質
總覽
使用不安全的 API 或程式庫，會大幅削弱應用程式的安全防護機制。這些依附元件萬一出現安全漏洞，可能會讓攻擊者利用各種向量進行大範圍攻擊，例如中間人 (MitM) 和遠端程式碼執行 (RCE) 攻擊。
假如開發人員未在軟體開發生命週期內併入安全性評估和安全漏洞測試 (SDLC)，或在某些情況下未針對應用程式依附元件導入自動更新政策，就會帶來實作不安全依附元件的威脅。
依附元件漏洞攻擊通常會從分析應用程式二進位檔 (.apk) 開始，目的是搜尋有安全漏洞的程式庫。此時，系統會執行開放原始碼情報 (OSINT)，找出先前發現的潛在可利用漏洞。這麼一來，攻擊者就能運用公開揭露的安全漏洞資訊，例如常見安全漏洞與弱點 (CVE)，展開後續攻擊。
影響
如果攻擊者成功利用了不安全的依附元件，可能會導致大規模攻擊，例如遠端程式碼執行 (RCE)、SQL 插入 (SQLi) 或跨網站指令碼攻擊 (XSS)。因此，整體影響會與第三方軟體引入和攻擊者能利用的安全漏洞類型直接相關。一旦有安全漏洞的依附元件遭人成功利用，可能就會發生資料侵害或服務不可用的情況，進而在信譽和經濟方面造成重大影響。
因應措施
縱深防禦
請注意，您必須同時採行下列因應措施，才能確立更完善的安全防護機制，並減少應用程式的攻擊途徑。確切方式一律應視個案情況評估。
依附元件安全漏洞評估
在開發生命週期開始時導入依附元件驗證機制，有助於偵測第三方程式碼中的安全漏洞。這個階段會測試非內部建構的程式碼是否安全無虞，再於正式環境中推出。如要補強驗證程序，您可以在軟體開發生命週期中實作靜態與動態應用程式安全防護測試 (SAST 與 DAST) 工具，強化應用程式的安全防護機制。
持續更新依附元件
請務必持續更新程式碼中內嵌的所有依附元件。為此，建議您導入自動更新機制，這樣每當第三方元件發布新的安全性修補程式時，更新就會推送至正式版測試群組。
請定期執行滲透測試。這類測試旨在找出任何可能影響專屬程式碼/第三方依附元件的已知安全漏洞。此外，安全性評估往往也可找出未知的安全漏洞 (0-day)。滲透測試對開發人員來說非常實用，因為他們可以藉此獲得應用程式現行安全防護機制的數據匯報，有助於安排要優先處理的安全漏洞問題。
資源
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間：2024-01-05 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2024-01-05 (世界標準時間)。"],[],[],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)"]]
