OWASP Top 10を実例で解説
Web開発者なら、OWASP Top 10—最も重大なWebアプリケーションセキュリティリスクのリスト—を聞いたことがあるでしょう。しかし、これらのリスクが実際のコードでどのように現れるかご存知ですか？この記事では、OWASP Top 10（2021年版）の各項目を実践的な例と具体的な防御策とともに見ていきます。読み終える頃には、自分のプロジェクトでこれらの脆弱性を発見し修正できるようになるでしょう。
1. アクセス制御の不備
アクセス制御の不備は、ユーザーが意図された権限を超えて行動できる場合に発生します。例えば、ユーザーがURLパラメータを変更することで他のユーザーのデータにアクセスできることがあります。
例： Webアプリが/api/users/123経由でユーザーデータを取得します。ログインしているユーザーが123であることを確認するチェックがない場合、攻撃者は単にIDを変更して他のユーザーのデータにアクセスできます。
防御策： すべてのリクエストに適切な認可チェックを実装します。ロールベースのアクセス制御（RBAC）を使用し、サーバー側で権限を検証します。
2. 暗号化の失敗
このカテゴリ（以前は「機密データの露出」）は、平文でのデータ送信や弱いアルゴリズムの使用など、暗号化に関連する失敗を対象としています。
例： ソルトなしでMD5やSHA-1でパスワードを保存する。攻撃者はこれらのハッシュを簡単にクラックできます。
防御策： bcrypt、scrypt、Argon2などの強力で適応型のハッシュアルゴリズムを使用します。常にHTTPSを強制します。
3. インジェクション
SQL、NoSQL、OS、LDAPインジェクションなどのインジェクション脆弱性は、信頼できないデータがコマンドやクエリの一部としてインタプリタに送信される場合に発生します。
例： ユーザー入力をSQLクエリに連結するログインフォーム：
SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'攻撃者は' OR '1'='1を入力して認証をバイパスできます。
防御策： パラメータ化クエリまたはプリペアドステートメントを使用します。ユーザー入力をクエリに連結しないでください。
4. 安全でない設計
安全でない設計とは、実装のバグだけでなく、アプリケーションのアーキテクチャと設計の欠陥を指します。
例： 推測しやすい答えの秘密の質問を使用するパスワードリセット機能、またはレート制限がない。
防御策： 設計時の脅威モデリング、安全な設計パターンの使用、レート制限とアカウントロックアウトの実装。
5. セキュリティ設定ミス
これには、デフォルトアカウント、未使用ページ、未パッチの欠陥、保護されていないファイルやディレクトリなどが含まれます。
例： Nginxサーバーでディレクトリリスティングを有効にしたままにし、機密ファイルを公開する。
防御策： 設定を強化します：ディレクトリリスティングを無効にし、デフォルトアカウントを削除し、ソフトウェアを最新に保ち、セキュリティヘッダーを使用します。
6. 脆弱で古いコンポーネント
既知の脆弱性を持つコンポーネントを使用すると、アプリケーション全体が危険にさらされる可能性があります。
例： 既知のプロトタイプ汚染脆弱性を持つ古いバージョンのlodashなどのJavaScriptライブラリを使用する。
防御策： 依存関係を定期的にスキャンし（例：npm audit、OWASP Dependency-Check）、更新します。
7. 識別と認証の失敗
これらの失敗により、攻撃者はパスワード、キー、セッショントークンを侵害したり、他の実装上の欠陥を悪用して他のユーザーの身元を偽装したりできます。
例： 「123456」のような弱いパスワードを許可する、または多要素認証（MFA）を実装していない。
防御策： 強力なパスワードポリシーを強制し、MFAを実装し、安全なセッション管理を使用します。
8. ソフトウェアとデータの完全性の失敗
このカテゴリは、完全性を検証せずにソフトウェア更新、重要なデータ、CI/CDパイプラインについて仮定を行うことに焦点を当てています。
例： 署名を確認せずに信頼できないソースからバイナリをダウンロードして実行する。
防御策： デジタル署名を使用し、チェックサムを検証し、CI/CDパイプラインを保護します。
9. セキュリティログと監視の失敗
不十分なログと監視により、攻撃者は持続、ピボット、アクセスを維持できます。
例： 失敗したログイン試行をログに記録しないため、ブルートフォース攻撃が検出できない。
防御策： セキュリティ関連イベントをログに記録し、疑わしい活動に対するアラートを設定し、定期的にログをレビューします。
10. サーバーサイドリクエストフォージェリ（SSRF）
SSRF脆弱性は、Webアプリケーションがユーザー提供のURLを検証せずにリモートリソースを取得する場合に発生します。
例： ユーザーが提供したURLを取得するWebhook機能。攻撃者はサーバーにAWS上のhttp://169.254.169.254/latest/meta-data/などの内部リソースをリクエストさせることができます。
防御策： URLを検証およびサニタイズし、許可リストを使用し、アウトバウンドトラフィックを制限します。
OWASP Top 10を軽減するための実践的なステップ
- アクセス制御を実装する： すべてのリクエストにサーバー側で認可チェックを強制します。
- 安全な暗号化を使用する： bcrypt/Argon2でパスワードをハッシュ化し、HTTPSを強制します。
- インジェクションを防ぐ： パラメータ化クエリを使用し、出力をエスケープします。
- 安全に設計する： 脅威モデリング、安全なパターンの使用、レート制限。
- 設定を強化する： 未使用機能を無効にし、ソフトウェアを最新に保ち、セキュリティヘッダーを設定します。
- 依存関係を管理する： コンポーネントを定期的にスキャンして更新します。
- 認証を強化する： 強力なパスワードを強制し、MFAを実装します。
- 完全性を検証する： 署名と安全なCI/CDを使用します。
- ログと監視： セキュリティイベントをログに記録し、アラートを設定します。
- SSRFを防ぐ： URLを検証し、許可リストを使用し、アウトバウンドトラフィックを制限します。
FAQ
OWASP Top 10とは何ですか？
OWASP Top 10は、Open Web Application Security Project（OWASP）によって公開された、最も重大なWebアプリケーションセキュリティリスクの定期的に更新されるリストです。開発者がアプリケーションを保護するためのベースラインとして機能します。
OWASP Top 10はどのくらいの頻度で更新されますか？
約3〜4年ごとに更新されます。最新版は2021年版で、前回は2017年版です。
セキュリティのためにOWASP Top 10だけに頼ることはできますか？
いいえ、それは出発点です。OWASP Application Security Verification Standard（ASVS）などの他のリソースも考慮し、定期的なセキュリティテストを実施する必要があります。
Nginxログで疑わしい活動を迅速に分析したいですか？ Nginx Log Analyzerを試して、潜在的な攻撃を特定し、Webサーバーのセキュリティを監視しましょう。