OWASP Top 10 の脆弱性

クラウドネイティブアプリケーションは、多くのサードパーティライブラリやサービスから構成される分散型アーキテクチャで、ハッカーにとって魅力的なターゲットとなる可能性があります。すべての脆弱性のうち 82% がアプリケーションコードで発見されている事実をハッカーが見逃すはずはなく、この攻撃ベクトルでアプリケーションが実装されたネットワークを侵害しようとします。したがって、Web アプリケーションを保護することは、ビジネスに不可欠な要件となっています。

OWASP とは

オープン Web アプリケーションセキュリティプロジェクト (OWASP) は、Web 上のアプリケーションセキュリティの推進に取り組む非営利のグローバルコミュニティです。OWASP の中核的な原則は、Web サイトのナレッジベースに自由かつ簡単にアクセスできるというものです。OWASP は、数万人の会員と数百の支部からなる信頼性の高い団体であり、開発者たちは Web アプリケーションセキュリティや API のセキュリティに関する重要なガイダンスとして OWASP を頼りにしてきました。

アプリケーション開発者は、経験レベルに関係なく、コードのセキュリティの脆弱性を理解する努力を払い、手間と多額の費用がかかるアプリケーションのセキュリティの不具合を回避する必要があります。

OWASP Top 10 とは

OWASP は、数年ごとに Web アプリケーションの脆弱性 Top 10 を改訂して発表しています。このリストには、OWASP Top 10 の脅威だけでなく、脆弱性がもたらす潜在的な影響と脆弱性を回避する方法も含まれています。この包括的なリストは、セキュリティコンサルタント、セキュリティベンダー、あらゆる規模の企業や組織のセキュリティチームなど、情報源となる各分野の専門家が編集したものです。これは、Web アプリケーションセキュリティのベストプラクティスに不可欠なガイドとして認識されています。

OWASP は最近、2021 年の OWASP Top 10 を 発表しましたが、そこには 3 種類の新しいカテゴリ、ネーミングとスコープを変更した 4 種類のカテゴリ、そして Top 10 の中でいくつかの統合が含まれています。

OWASP Top 10 の主な目的は、認知度を高めることですが、2003 年の第 1 回目以来、事実上、業界のアプリケーションセキュリティ標準とみなされてきました。ドキュメントをよく見ると、添付されている CWE (Common Weakness Enumeration) の数が明確に示されています。

OWASP Top 10 脆弱性および Web アプリケーションセキュリティリスクの最新リスト

2021 年 9 月 24 日に、OWASP の 20 周年記念で最新の OWASP Top 10 リストが発表されました。2020 年のリストをご存知の方は、2021 年の OWASP Top 10 が大きく入れ替わり、アクセス制御の不具合に代わって SQL インジェクションが第 1 位になっていることにお気づきでしょう。

1. アクセス制御の不具合

2. 暗号化の失敗

3. インジェクション

4. 安全でない設計

5. セキュリティの構成エラー

6. 脆弱性のある旧式のコンポーネント

7. 本人確認と認証の失敗

8. ソフトウェアとデータ整合性の不具合

9. セキュリティログとモニタリングの不具合

10. サーバーサイドリクエストフォージェリ

OWASP Top 10 の脆弱性

このセクションでは、OWASP Top 10 の各脆弱性について検討し、影響と回避方法についての理解を深めます。

1.アクセス制御の不具合

Web サイトのセキュリティアクセス制御では、訪問者のアクセスを、そのタイプのユーザーが必要とするページまたはセクションのみに制限します。たとえば、ネット通販サイトの管理者は、新しいリンクの追加や、プロモーションの追加ができなければなりません。他のタイプの訪問者はこれら機能にアクセスできないようにします。

開発者に「セキュリティファースト」の規律を浸透させることで、デフォルトでコンテンツ管理システム (CMS) のすべてのアクセス権限 (管理者レベルのアクセスも含む) を付与してしまうなどのミスを避けることが求められます。アクセス制御の不具合により、Web サイトの訪問者は管理パネル、サーバー、データベース、およびその他のビジネスクリティカルなアプリケーションにアクセスできてしまうことがあります。実際、この OWASP Top 10 の脅威は、ブラウザを他の標的 URL にリダイレクトするために使用される可能性さえあります。

アクセス制御の不具合の対策

アクセス制御の不具合による脆弱性は、さまざまな方法で対処できます。

• 各ロールにはタスクを実行するために必要な最低レベルのアクセス権が与えられるように最小特権のアプローチを採用します。

• 不要またはアクティブでなくなったアカウントを削除します。

• サーバーや Web サイトのアクティビティを監査し、誰がいつ何をしているかを把握します。

• アクセスポイントが複数ある場合は、現時点で不要なアクセスポイントを無効にします。

• サーバーの不要なサービスを停止します。

2.暗号化の失敗

パスワード、クレジットカード番号、健康記録、個人情報、企業秘密など、転送中および保管中のデータは、暗号化の失敗 (機密データの漏洩) の可能性があるため、特別な保護が必要です。これは、データが GDPR、CCPA などのプライバシー法に該当する場合に特に当てはまります。データがプレーンテキストで送信されていますか。デフォルトまたは古いコードで使用されている旧式または安全でない暗号化アルゴリズムまたはプロトコルはありますか。デフォルトの暗号鍵を利用している、弱い暗号鍵を生成して再利用している、適切な鍵の管理やローテーションが見落とされている、などの可能性はないでしょうか。暗号鍵をソースコードリポジトリーにチェックインすることは可能ですか。暗号化が強制されておらず、受信データは暗号化されていますか。

暗号化失敗の対策

• データ収集フォームでは、オートコンプリートをオフにします。

• データサーフェス領域のサイズを縮小するか最小化します。

• 転送中および保管中のデータを暗号化します。

• 最新の暗号化技術を使用します。

• データ収集フォームのキャッシュを無効にします。

• パスワードの保存の際は、強力なアダプティブとソルト付きハッシュ化関数を使用します。

3.インジェクション

インジェクションの脆弱性は、クエリやコマンドを使用して、SQL、OS、NoSQL、LDAP インジェクションにより信頼できないデータをインタプリターに挿入した際に発生する場合があります。この攻撃ベクトルで注入された悪意のあるデータは、意図しないコマンドを生成したり、適切な認証なしでデータにアクセスしたりするなど、アプリケーションが設計されていないことを実行させるようにインタープリターを騙します。

パラメーターを入力として受け取るアプリケーションは、インジェクション攻撃の影響を受ける可能性があります。脅威のレベルは、アプリケーションの入力検証対策の徹底度と高い相関関係にあります。

インジェクション対策

インジェクション攻撃は、以下のアプローチを組み合わせることで防ぐことができます。

• コマンドをデータから分離して、意図しないコマンド実行でデータを置き換える攻撃への暴露を防ぎます。

• ユーザー入力内容のみからコマンドを構成するのではなく、パラメーターを指定して SQL クエリをコーディングします。これらは、パラメーター化されたクエリまたはプリペアドステートメントと呼ばれます。

• 安全な API を使用して、インタープリターを完全に排除します。

• サーバー側で積極的な検証を行うとともに、クライアント側の不審な動作を検知する侵入検知システムを導入します。

4.安全でない設計

安全でない設計は、さまざまな欠陥を含む広義の用語であり、「制御設計の欠落または不良」と定義されます。  脅威モデリング、安全な設計パターン、リファレンスアーキテクチャは、2021 年に加わった新しいカテゴリの一部で、脅威モデリング、安全な設計パターン、参照アーキテクチャの使用を増やすことを求めています。コミュニティとして、私たちは「シフトレフト」コーディングを超えたセキュア・バイ・デザインの原則に基づき、重要なタスクを事前にコーディングする必要があります。

安全でない設計の対策

• セキュリティやプライバシー関連の対策を分析して構築するため、アプリケーションセキュリティの専門家とともに安全な開発ライフサイクルを確立して活用する。

• 安全な設計パターンやコンポーネントのライブラリを作成し、すぐに使えるようにする。

• 重要な認証、アクセス制御、ビジネスロジック、キーフローに脅威モデリングを使用する。

• ユーザーストーリーには、セキュリティに関する文言や制御を含める。

• アプリケーションの各レベル (フロントエンドからバックエンドまで) で、妥当性チェックを組み込む。

• すべての重要なフローが脅威モデルに対して耐性があることを確認するために、ユニットテストと統合テストを記述する。アプリの各層でユースケースと誤用ケースのリストを作成する。

• 露出度や保護要件に応じて、システム層とネットワーク層でティアを分ける。

• ユーザーとサービスのリソース消費を制限する。

5.セキュリティの構成エラー

ガートナーは、クラウドにおける脆弱性に起因するインシデントの最大 95% がヒューマンエラーの結果であると推定しています。セキュリティの構成エラーは、この統計の主な要因の一つです。OWASP は、Top 10 のうち、この脆弱性が最もよく見られると指摘しています。企業をサイバーセキュリティリスクにさらす構成エラーには、以下のようなさまざまなものがあります。

• 安全でないデフォルト設定の受け入れ

• アクセス過多のクラウドストレージリソース

• 不完全な構成

• HTTP ヘッダーの構成ミス

• 機密情報など情報が多すぎるエラーメッセージ

セキュリティ構成エラーの対策

セキュリティの構成エラーは、ネットワーク接続デバイス、データベース、Web サーバー、アプリケーションサーバー、コンテナなど、環境のほぼすべての場所で発生する可能性があります。以下のプラクティスは、適切に構成された環境を維持するために役立ちます。

• テンプレートを使用することで、組織のセキュリティポリシーに適合するようにあらかじめ構成した開発環境、テスト環境、本番環境を展開できます。

• セグメント化されたアプリケーションアーキテクチャを活用して、安全に構成されていない要素によるリスクを最小化し、適切に構成されたコンテナイメージのライブラリを維持します。

• 最小限のプラットフォームを導入し、使用しない機能やサービスを削除します。

• できる限り自動化されたワークフローを使用して、クラウドリソース、アプリケーション、およびサーバーのセキュリティの構成エラーを継続的にモニタリングし、検出された問題をリアルタイムで修正します。

6.脆弱性のある旧式のコンポーネント

最近の分散型 Web アプリケーションでは、ライブラリやフレームワークなどのオープンソースコンポーネントを組み込むことが多くなっています。既知の脆弱性を持つコンポーネントは、アプリケーション全体のセキュリティに影響を与える可能性のある脆弱なリンクになります。

既知の脆弱性を持つオープンソースコンポーネントの使用は、セキュリティ問題の重大度のランキングでは低いものの、OWASP Top 10 の脆弱性に起因するインシデントの根本原因になった頻度のランキングでは 1 位になっています。

脆弱性のある旧式のコンポーネントの対策

最も効果的な防衛策は、継続的にすべてのコードコンポーネントをスキャンして既知の脆弱性を探し、脆弱性が検出されたときにできるだけ早くパッチを導入するか他の対策を実行することです。この防衛ラインの有効性を高めるためのベストプラクティスがいくつかあります。

• 企業のフレームワークに統合されたすべてのコンポーネントは、構成の管理下にします。

• スキャナーはモニタリング対象のすべてのコンポーネントを自動検出できる必要があります。

• スキャンは、脅威インテリジェンスデータで強化された包括的な脆弱性データベースに対して実行する必要があります。

• 適切なパッチを特定し、テストし、導入するパッチ管理ワークフローは、パッチ適用に伴う運用リスクを最小限に抑えるために、可能な限り自動化します。

7.本人確認と認証の失敗

アプリケーションがセッション管理やユーザー認証に関連する機能を不正に実行すると、ハッカーはパスワード、セキュリティキー、セッショントークンに不正にアクセスし、他のユーザー ID や権限を永続的または一時的に利用できるようになる可能性があります。この脆弱性は、アプリケーションとそれがアクセスするリソースのセキュリティに深刻な脅威をもたらし、同じネットワークに接続されている他のアセットを不正アクセスの重大な危険にさらす可能性があります。

認証の対策

認証不具合の脆弱性を緩和する OWASP のベストプラクティスの主な推奨事項は以下のとおりです。

• 多要素認証を実装する。

• 特に管理者権限を持つユーザーは、デフォルトの認証情報を使用してデプロイしないでください。

• 強力なパスワードを強制する。

• 失敗したログイン試行を注意深くモニタリングする。

• ランダムで時間制限のあるセッション ID を生成するセキュアセッションマネージャーを使用する。URL にはセッション ID を含めないでください。

8.ソフトウェアとデータ整合性の不具合

整合性の違反を防止できないコードやインフラは、ソフトウェアやデータの整合性の不具合と呼ばれます。信頼できないソース、リポジトリ、コンテンツデリバリーネットワーク (CDN) からのプラグイン、ライブラリ、モジュールを使用するプログラムは、その一例です。不正アクセス、悪意のあるコード、またはシステムの侵害はすべて、セキュリティで保護されていない CI/CD パイプラインのリスクになる可能性があります。最後に、多くのプログラムは自動更新機能を備えているため、必要な整合性チェックを行わずに更新を取得して、信頼済みのアプリケーションに適用できます。ハッカーは、この機能を使用してすべてのシステムに独自の更新を配布して実行する可能性があります。

ソフトウェアとデータ整合性の不具合の対策

• プログラムまたはデータが本物であり、改ざんされていないことを確認するために、デジタル署名またはそれに類する手段を使用します。

• 開発パイプラインに有害なコードや構成が入り込むリスクを軽減するため、コードと構成の変更について、レビュー手順が整っていることを確認してください。

• npm や Maven などのライブラリと依存関係が信頼できるリポジトリを使用していることを確認します。リスクプロファイルが高い場合は、承認済みの既知の正常なリポジトリを内部でホスティングすることを検討してください。

• ビルドおよびデプロイプロセスを通過するコードの完全性を保護するには、CI/CD パイプラインに適切な分離、構成、およびアクセス制御が含まれていることを確認してください。

• 署名されていない、あるいは暗号化されていないシリアライズデータは、改ざんやリプレイを検出するための何らかの完全性チェックやデジタル署名なしに、信頼できないクライアントに配信されないようにします。

9.セキュリティログとモニタリングの不具合

調査によると、攻撃から発見までの時間は最大で 200 日で、多くの場合それ以上かかると言われています。この期間により、サイバー犯罪者がサーバーを改ざんしたり、データベースを破壊したり、機密情報を盗んだり、悪意のあるコードを仕掛けたりするのに十分な時間を与えてしまいます。

対策

すぐに利用できるロギングおよび監査ソフトウェアを実装して、不審なアクティビティや不正アクセスの試みをすばやく検出します。検出された攻撃が失敗した場合も、ロギングとモニタリングにより、攻撃のソースとベクトルを分析し、侵入を防ぐためにセキュリティポリシーとコントロールを強化する方法を学習する貴重なツールが提供されます。

10.サーバーサイドリクエストフォージェリ (SSRF)

サーバーサイドリクエストフォージェリ (SSRFとも呼ばれる) は、ハッカーがサーバー側のアプリケーションに対して、ハッカーが選択した任意のドメインに HTTP リクエストを送信させることができる Web セキュリティ上の欠陥です。

Web アプリケーションが、ユーザーが入力した URL を検証せずにリモートリソースを取得した場合、SSRF 障害が発生します。プログラムがファイアウォール、VPN、または別の種類のネットワークアクセス制御リストによって保護されている場合でも、ハッカーはリクエストを偽造して予期しない場所に送信するよう強制できます。

対策

• 入力の検証を実装する。

• 正規表現 (RegEx) を使用する。

• 意図した IP アドレスの形式 (IPv4 または IPv6) のみ受け入れる。

• メソッド/出力ライブラリの値を IP アドレスとして使用して許可リストと比較する。

• 受信ドメイン名を検証する。

• OWASP チートシートシリーズを確認する

OWASP 以外のその他の脆弱性について

OWASP はその方法論で、Top 10 リストは定義上、重要なセキュリティ問題の一部にすぎず、組織はその他のセキュリティリスクについて認識しておくべきであると非常に明確に指摘しています。

2021 年 12 月に公開された Log4Shell 脆弱性など、新たに発見された脆弱性にもご注意ください。

その他の非 OWASP Vuln チャート

OWASP 脆弱性: よくある質問