安全でない API またはライブラリ
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
OWASP カテゴリ: MASVS-CODE: コード品質
概要
安全でない API やライブラリを使用すると、アプリケーションのセキュリティ対策が大幅に弱まります。これらの依存関係のいずれかでセキュリティ侵害が発生すると、攻撃者は多数のベクトルを利用して、中間者攻撃(MitM)やリモートコード実行(RCE)などの広範な攻撃を行う可能性があります。
安全でない依存関係を実装することの脅威は、デベロッパーがセキュリティ評価と脆弱性テストをソフトウェア開発ライフサイクル(SDLC)に統合しない場合や、アプリケーションの依存関係の自動更新ポリシーを実装しない場合に発生することがあります。
依存関係の悪用は、通常、脆弱なライブラリを検索するためにアプリケーション バイナリ(.apk)を分析することから始まります。この時点で、オープンソース インテリジェンス(OSINT)が実行され、以前に発見された悪用可能な脆弱性を発掘できます。その後に攻撃者は、共通脆弱性識別子(CVE)などの一般公開された脆弱性情報を利用して、さらなる攻撃を仕掛ける可能性があります。
影響
安全でない依存関係が悪用されると、リモートコード実行(RCE)、SQL インジェクション(SQLi)、クロスサイト スクリプティング(XSS)などの広範な攻撃につながる可能性があります。そのため、全体的な影響は、サードパーティ ソフトウェアに導入されて攻撃者が悪用する恐れのある脆弱性の種類と直接的に関係しています。脆弱な依存関係が悪用されると、データが侵害されてサービスが利用できなくなり、評価や売上に重大な影響が及ぶ可能性があります。
リスクの軽減
多層防御
より強力なセキュリティ対策を確保し、アプリケーションの攻撃対象領域を減らすには、以下に挙げる緩和策を組み合わせて実行する必要があります。正確なアプローチは、常に状況に応じて評価する必要があります。
依存関係の脆弱性の評価
サードパーティ コード内の脆弱性を検出するために、開発ライフサイクルの始めに依存関係の検証を実装します。このフェーズでは、社内でビルドされていないコードが本番環境にロールアウトされる前に、安全かどうかをテストします。ソフトウェア開発ライフサイクル内に静的アプリケーション セキュリティ テスト(SAST)ツールと動的アプリケーション セキュリティ テスト(DAST)ツールを実装することで検証を補完し、アプリケーションのセキュリティ対策を改善できます。
依存関係を継続的に更新する
コードに埋め込まれた依存関係を継続的に更新するよう、常に心がけてください。そのためには、サードパーティ コンポーネントが新しいセキュリティ パッチをリリースするたびに、本番環境にプッシュされる自動更新の実装をおすすめします。
定期的にペネトレーション テストを実施します。この種のテストの目的は、プロプライエタリ コードやサードパーティ依存関係に影響しかねない既知の脆弱性を発見することです。また、セキュリティ評価では、未知の脆弱性(ゼロデイ)がしばしば発見されます。ペネトレーション テストは、アプリケーションの現在のセキュリティ対策状況をデベロッパーに提供し、対処すべき悪用可能なセキュリティ問題に優先順位をつけるため、デベロッパーにとって有益です。
参考資料
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2024-02-23 UTC。
[[["わかりやすい","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-02-23 UTC。"],[],[],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)"]]