OWASP Top 10の脆弱性
2020年10月15日
0 分で読めます多くのサードパーティ製ライブラリやサービスから成る分散アーキテクチャを備えたクラウドネイティブアプリケーションは、ハッカーにとって魅力的な標的です。脆弱性の82%がアプリケーションコードで見つかるという事実を攻撃者は見逃しません。攻撃者はこの経路を利用して、アプリケーションがデプロイされているネットワークへの侵入を試みます。そのため、Webアプリケーションのセキュリティ確保は、ビジネスに不可欠な要件となっています。
OWASPとは？
Open Web Application Security Project（OWASP）は、Web全体でアプリケーションセキュリティの促進に取り組む、非営利のグローバルコミュニティです。OWASPの基本理念の一つは、知識ベースをWebサイトで誰もが無料かつ簡単に利用できるようにすることです。数万人のメンバーと数百の支部を擁するOWASPは高い信頼を得ており、開発者は不可欠なWebアプリケーションセキュリティとAPIセキュリティのガイダンスを得るために活用しています。
経験の有無にかかわらず、すべてのアプリケーション開発者は、厄介で多くのコストがかかるアプリケーションセキュリティの失敗を避けるため、コードのセキュリティ脆弱性を理解するよう努める必要があります。OWASP Top 10とは？
OWASPは数年ごとに、Webアプリケーションの脆弱性トップ10を改訂して公開しています。このリストにはOWASP Top 10の脅威だけでなく、各脆弱性がもたらす潜在的な影響と、その回避方法も記載されています。セキュリティコンサルタント、セキュリティベンダー、規模を問わずさまざまな企業や組織のセキュリティチームなど、多様な専門家の知見をもとに作成された包括的なリストです。Webアプリケーションセキュリティのベストプラクティスを知るための重要なガイドとして認められています。
OWASPは最近、2021年版OWASP Top 10を公開しました。新たに3つのカテゴリが追加され、4つのカテゴリで名称や対象範囲が変更され、Top 10内でいくつかの統合が行われています。
OWASP Top 10は、主にセキュリティ意識の向上を目的としています。しかし、2003年の初公開以来、企業はこれを事実上の業界標準であるAppSec標準として活用してきました。文書を詳しく見ると、関連付けられているCWE（共通脆弱性タイプ一覧）の数が明記されています。
Snykでゼロデイ脆弱性に備える
Snykを活用して開発者がゼロデイ脆弱性をより迅速に修正し、リスクと攻撃にさらされる範囲を低減する方法をご覧ください。
OWASP Top 10の最新の脆弱性とWebアプリケーションセキュリティリスク一覧
最新のOWASP Top 10は、OWASP設立20周年にあたる2021年9月24日に公開されました。2020年版をご存じの方は、2021年版OWASP Top 10で大幅な順位の入れ替えがあったことに気付くでしょう。SQLインジェクションに代わって、アクセス制御の不備が最上位になりました。
OWASP Top 10の脆弱性
このセクションでは、OWASP Top 10の各脆弱性について、その影響と回避方法を詳しく解説します。
1. アクセス制御の不備
Webサイトのアクセス制御では、ユーザーの種類に応じて必要なページやセクションだけに訪問者のアクセスを制限する必要があります。たとえば、ECサイトの管理者は新しいリンクやプロモーションを追加できる必要がありますが、ほかの訪問者にはこれらの機能を利用させてはいけません。
開発者には「セキュリティファースト」の姿勢を身に付けてもらい、コンテンツ管理システム（CMS）が初期設定であらゆるアクセス権（管理者レベルを含む）を付与するといった落とし穴を避ける必要があります。アクセス制御の不備により、Webサイトの訪問者が管理パネル、サーバー、データベース、その他のビジネスに不可欠なアプリケーションにアクセスできるおそれがあります。実際、このOWASP Top 10の脅威を悪用すると、ブラウザーを標的の別のURLにリダイレクトさせることも可能です。
アクセス制御の不備への対策
アクセス制御の不備による脆弱性には、次のような方法で対処できます。
最小権限の原則を採用し、各ロールにタスクの実行に必要な最低限のアクセス権のみを付与します。
不要になったアカウントや利用されていないアカウントを削除します。
サーバーやWebサイト上の活動を監査し、誰が何をいつ行っているかを把握します。
複数のアクセスポイントがある場合、その時点で不要なものを無効にします。
不要なサービスを停止し、サーバーを必要最小限の構成に保ちます。
2. 暗号化の失敗
パスワード、クレジットカード番号、医療記録、個人情報、企業秘密など、転送中や保存中のデータは、暗号化の失敗（機密データの漏えい）によるリスクがあるため、特別な保護が必要です。データがGDPRやCCPAなどのプライバシー法の対象となる場合は、特に注意が必要です。データが平文で送信されていませんか？初期設定や古いコードで、古い、または安全でない暗号化アルゴリズムやプロトコルが使われていませんか？初期設定の暗号鍵が使われていたり、弱い暗号鍵が生成・再利用されていたり、適切な鍵管理やローテーションが見落とされたりしていませんか？暗号鍵をソースコードリポジトリに登録できてしまう状態ではありませんか？暗号化が強制されておらず、受信データが暗号化されていないということはありませんか？
暗号化の失敗への対策
データを収集するフォームでは、自動入力を無効にします。
データの攻撃対象領域を縮小・最小化します。
転送中および保存中のデータを暗号化します。
最新の暗号化手法を使用します。
データを収集するフォームでは、キャッシュを無効にします。
パスワードの保存には、強力でソルト付きの適応型ハッシュ関数を使用します。
3. インジェクション
SQL、OS、NoSQL、LDAPインジェクションなどによって、信頼できないデータをクエリやコマンドを通じてインタープリターに渡すと、インジェクションの脆弱性が発生することがあります。攻撃者はこの経路から悪意のあるデータを送り込み、インタープリターをだまして、意図しないコマンドを生成したり、適切な認証なしにデータへアクセスしたりするなど、想定外の処理をアプリケーションに実行させます。
入力パラメーターを受け付けるアプリケーションは、どれもインジェクション攻撃の影響を受ける可能性があります。脅威の度合いは、アプリケーションの入力検証がどれだけ徹底されているかと強く相関します。
インジェクションへの対策
次の方法を組み合わせることで、インジェクション攻撃を防げます。
データが置き換えられ、意図しないコマンドが実行される攻撃を防ぐため、コマンドとデータを分離します。
ユーザー入力の内容だけからコマンドを組み立てるのではなく、パラメーターを使ってSQLクエリを記述します。これは、パラメーター化クエリまたはプリペアドステートメントと呼ばれます。
安全なAPIを使用して、インタープリター自体を使わないようにします。
サーバー側で適切な入力検証を実装するとともに、不審なクライアント側の挙動を検出する侵入検知システムを導入します。
4. 安全でない設計
安全でない設計とは、さまざまな欠陥を含む広範な概念であり、「制御の設計が欠けている、または不十分であること」と定義されます。脅威モデリング、安全な設計パターン、リファレンスアーキテクチャは、2021年に加わったカテゴリです。脅威モデリング、安全な設計パターン、リファレンスアーキテクチャの活用をさらに進めることが求められています。コミュニティとして、「シフトレフト」のコーディングにとどまらず、セキュア・バイ・デザインの原則に不可欠なコーディング前の作業にも取り組む必要があります。
安全でない設計への対策
セキュリティとプライバシーに関する対策を分析・構築するため、AppSecの専門家とともに安全な開発ライフサイクルを確立し、活用します。
すぐに利用できる安全な設計パターンやコンポーネントのライブラリを作成し、活用します。
重要な認証、アクセス制御、ビジネスロジック、主要な処理フローに脅威モデリングを適用します。
ユーザーストーリーに、セキュリティに関する要件や制御を含めます。
フロントエンドからバックエンドまで、各レイヤーに妥当性チェックを組み込みます。
重要な処理フローがすべて脅威モデルで想定される脅威に耐えられるよう、ユニットテストと統合テストを作成します。アプリケーションの各層について、ユースケースと悪用ケースを一覧にします。
エクスポージャーと保護要件に応じて、システムとネットワークの各レイヤーを分割します。
ユーザーとサービスによるリソース消費を制限します。
5. セキュリティ設定の不備
Gartnerの推定によると、クラウド侵害の最大95%は人為的ミスが原因です。セキュリティ設定の誤りは、この統計の主な要因の一つです。OWASPによると、Top 10の中でこの脆弱性は最も一般的です。企業をサイバーセキュリティリスクにさらす設定ミスには、次のようなものがあります。
安全でない初期設定をそのまま使用する
クラウドストレージリソースへのアクセスを過剰に許可する
設定が不完全である
HTTPヘッダーの設定を誤る
機密情報を含む詳細すぎるエラーメッセージを表示する
セキュリティ設定の不備への対策
セキュリティ設定の不備は、ネットワーク接続デバイス、データベース、Webサーバー、アプリケーションサーバー、コンテナなど、環境内のあらゆる場所で発生する可能性があります。適切に設定された環境を維持するには、次の方法が役立ちます。
組織のセキュリティポリシーに準拠するよう事前設定されたテンプレートを使い、開発、テスト、本番環境をデプロイします。
安全でない設定の要素によるリスクを最小限に抑える、分割されたアプリケーションアーキテクチャを活用します。適切に設定されたコンテナイメージのライブラリを維持します。
最小構成のプラットフォームをデプロイし、使用していない機能やサービスを削除します。
クラウドリソース、アプリケーション、サーバーを継続的に監視し、セキュリティ設定の不備を検出したら、可能な限り自動化されたワークフローを使ってリアルタイムに修正します。
6. 脆弱で古いコンポーネント
最新の分散型Webアプリケーションには、ライブラリやフレームワークなどのオープンソースコンポーネントが組み込まれていることがよくあります。既知の脆弱性を持つコンポーネントは、アプリケーション全体のセキュリティに影響を及ぼす弱点になり得ます。
既知の脆弱性を持つオープンソースコンポーネントの使用は、セキュリティ問題の深刻度では低い順位にあります。しかし、脆弱性が実際のデータ侵害の根本原因となった頻度でOWASP Top 10を順位付けすると、1位です。
脆弱で古いコンポーネントへの対策
最も効果的な防御策は、すべてのコードコンポーネントを継続的にスキャンして既知の脆弱性を検出し、脆弱性が見つかったら、できるだけ速やかにパッチなどで修正することです。この防御策の効果を高めるベストプラクティスは次のとおりです。
企業のフレームワークに組み込まれたすべてのコンポーネントを構成管理の対象にします。
スキャナーは、監視対象となるすべてのコンポーネントを自動的に検出できる必要があります。
スキャンには、脆弱性データベースを使用し、脅威インテリジェンスデータで情報を補強します。
パッチ適用に伴う運用リスクを最小限に抑えるため、適切なパッチの特定、テスト、デプロイを行うパッチ管理ワークフローを可能な限り自動化します。
7. 識別と認証の失敗
アプリケーションがセッション管理やユーザー認証に関する機能を誤って実行すると、侵入者がパスワード、セキュリティキー、セッショントークンを侵害し、ほかのユーザーのIDや権限を一時的または恒久的に乗っ取るおそれがあります。この脆弱性は、アプリケーションとそのアクセス先のリソースに深刻な脅威をもたらし、同じネットワークに接続されたほかの資産も大きく危険にさらす可能性があります。
認証への対策
認証の不備による脆弱性を軽減するために、OWASPが推奨する主なベストプラクティスは次のとおりです。
多要素認証を導入します。
特に管理者権限を持つユーザーについて、初期設定の認証情報を使ったままデプロイしないでください。
強力なパスワードを必須にします。
ログインの失敗を注意深く監視します。
ランダムで有効期限のあるセッションIDを生成する、安全なセッション管理機能を使用します。セッションIDをURLに含めてはいけません。
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のリストは定義上、重要なセキュリティ課題の一部にすぎず、組織はその他のセキュリティリスクにも注意を払うべきだと明確に述べています。
新たに発見されるゼロデイ脆弱性を常に把握し、発生時に対処するための対応計画を維持しましょう。
開発者に愛され、セキュリティチームから信頼される。
Snykの開発者ファーストのツールは、ガバナンスやコンプライアンスのニーズに応える、統合された自動化セキュリティを提供します。
OWASPの脆弱性：よくある質問
OWASPの脆弱性とは何ですか？
OWASPの脆弱性とは、Open Web Application Security Projectが公開しているセキュリティ上の弱点や問題です。企業、組織、セキュリティの専門家から寄せられた問題は、Webアプリケーションに対するセキュリティリスクの深刻度に応じてランク付けされます。
OWASPのトップ10脆弱性とは？
OWASPトップ10リストは3〜4年ごとに編纂・公開され、最も重大なセキュリティ脆弱性を取り上げています。また、脆弱性の例や攻撃者による悪用方法、アプリケーションのリスクを低減または排除するための推奨策も紹介しています。
OWASPが報告するアプリケーションセキュリティ上の最大のリスクは何ですか？
OWASPが報告する脆弱性の第1位はインジェクションです。インジェクションでは、信頼できないデータがSQLなどの経路（LDAPなど）を通じて送信され、インタープリターが許可されていないデータにアクセスしたり、アプリケーションが意図しないコマンドを実行したりする可能性があります。
OWASP Top 10の脆弱性はどのようにテストできますか？
OWASPは、さまざまなテストシナリオに対応するテストケースを掲載した詳細なテストガイドを提供しています。多くの開発チームは、ソフトウェアを活用してコードをスキャンし、脆弱性を自動的に検出して警告を出すとともに、ベストプラクティスを一貫して適用する、より自動化されたソリューションを導入しています。
OWASP Top 10はどのように活用すべきですか？
OWASP Top 10は、開発者やセキュリティチームが開発プラクティスを評価し、Webアプリケーションのセキュリティについて考えるための指針です。Webアプリケーションの脆弱性をすべて網羅しているわけではありませんが、セキュリティ上の考慮事項を可視化するための基準となります。