OWASP Top 10を実例で解説
毎年、何千ものWebアプリケーションが同じ繰り返し発生するセキュリティ上の欠陥によって侵害されています。OWASP Top 10は、Webアプリケーションにとって最も重大なセキュリティリスクをリストアップした標準的な啓発文書です。この記事では、各リスクを順に取り上げ、実例を示し、その緩和策を説明します。開発者、DevOpsエンジニア、セキュリティ愛好家のいずれであっても、これらのリスクを理解することは安全なシステムを構築するために不可欠です。
1. アクセス制御の不備
アクセス制御の不備は、ユーザーが意図された権限を超えて行動できる場合に発生します。例えば、ユーザーがURLパラメータを変更することで他のユーザーのデータにアクセスできることがあります。
例： アプリケーションがユーザーデータを取得するために/api/user/123を使用しているとします。ログインしているユーザーが実際にユーザー123であることを確認するチェックがない場合、攻撃者はIDを/api/user/124に変更して他人のプロフィールを閲覧できます。
緩和策： サーバー側でアクセス制御チェックを実装します。デフォルトで拒否します。ロールベースのアクセス制御（RBAC）を使用し、すべてのリクエストで権限を検証します。
2. 暗号化の失敗
以前は「機密データの露出」として知られていたこのリスクは、転送中または保存中の機密データを保護できないことを指します。
例： パスワードを平文で保存したり、MD5のような弱いハッシュアルゴリズムを使用したりすること。
緩和策： 保存データには強力な暗号化（例：AES-256）、転送データにはTLS 1.2以上、強力なパスワードハッシュ（bcrypt、Argon2）を使用します。
3. インジェクション
SQL、NoSQL、OS、LDAPインジェクションなどのインジェクションの欠陥は、信頼できないデータがコマンドやクエリの一部としてインタプリタに送信される場合に発生します。
例： 次のようなSQLクエリを構築するログインフォーム：
SELECT * FROM users WHERE username = '$username' AND password = '$password';攻撃者がユーザー名として' OR '1'='1を入力すると、認証をバイパスできます。
緩和策： パラメータ化クエリまたはプリペアドステートメントを使用します。特殊文字をエスケープし、入力を検証します。
4. 安全でない設計
安全でない設計とは、実装のバグだけでなく、アプリケーションのアーキテクチャと設計の欠陥を指します。
例： 推測しやすい答えの秘密の質問を使用するパスワードリセット機能。
緩和策： 設計時の脅威モデリング、安全な設計パターン、参照アーキテクチャ。
5. セキュリティ設定ミス
これには、デフォルトアカウント、未使用ページ、未パッチの欠陥、保護されていないファイルやディレクトリが含まれます。
例： CMSにデフォルトの管理者資格情報を残す、またはディレクトリリスティングを公開する。
緩和策： 設定を強化し、未使用の機能を削除し、設定チェックを自動化します。
6. 脆弱で古くなったコンポーネント
既知の脆弱性があるライブラリ、フレームワーク、ソフトウェアを使用すること。
例： 既知のXSS脆弱性がある古いバージョンのJavaScriptライブラリを実行する。
緩和策： 依存関係を定期的に更新し、npm auditやOWASP Dependency-Checkなどのツールを使用し、未使用の依存関係を削除します。
7. 識別と認証の失敗
認証とセッション管理の弱点。
例： 弱いパスワードを許可する、ログイン試行にレート制限がない、URLにセッションIDを露出する。
緩和策： 多要素認証を実装し、強力なパスワードポリシーを適用し、安全なセッション管理を使用します。
8. ソフトウェアとデータの整合性の失敗
整合性違反から保護しないコードとインフラストラクチャ。
例： Subresource Integrity（SRI）なしで信頼できないCDNをスクリプトに使用する。
緩和策： SRIを使用し、署名を検証し、CI/CDパイプラインが安全であることを確認します。
9. セキュリティログと監視の失敗
不十分なログと監視により、攻撃者が検出されずに持続することが可能になります。
例： 失敗したログイン試行をログに記録しないため、ブルートフォース攻撃が見逃される。
緩和策： セキュリティ関連のイベントをログに記録し、ログを監視し、疑わしい活動に対するアラートを設定します。
10. サーバーサイドリクエストフォージェリ（SSRF）
SSRFは、攻撃者がサーバーに内部リソースへのリクエストを実行させることができる場合に発生します。
例： ユーザーが提供したURLを取得するWebhook機能。攻撃者はhttp://169.254.169.254/latest/meta-data/を提供してクラウドメタデータにアクセスできます。
緩和策： URLを検証およびサニタイズし、許可リストを使用し、送信トラフィックを制限します。
比較表
| リスク | 例 | 緩和策 |
|---|---|---|
| アクセス制御の不備 | IDORによる他ユーザーデータへのアクセス | サーバー側の権限チェック |
| 暗号化の失敗 | パスワードの平文保存 | 強力なハッシュとTLSの使用 |
| インジェクション | ログインフォーム経由のSQLインジェクション | パラメータ化クエリ |
| 安全でない設計 | 弱いパスワードリセットの質問 | 脅威モデリング |
| セキュリティ設定ミス | デフォルトの管理者資格情報 | 設定の強化 |
| 脆弱なコンポーネント | XSS欠陥のある古いライブラリ | 定期的な更新 |
| 認証の失敗 | ログインにレート制限がない | MFAとレート制限 |
| 整合性の失敗 | 信頼できないCDNスクリプト | Subresource Integrity |
| ログの失敗 | 失敗したログインのログがない | 集中ログとアラート |
| SSRF | 内部メタデータの取得 | URL許可リスト |
はじめに
- 評価： OWASP Top 10に対して自動スキャナーと手動レビューを実行します。
- 優先順位付け： 最も重大な問題（例：インジェクション、アクセス制御の不備）を最初に修正します。
- トレーニング： 開発者に安全なコーディング手法を教育します。
- 監視： セキュリティイベントのログとアラートを実装します。
- 反復： 依存関係を定期的に更新し、再テストします。
FAQ
OWASP Top 10とは何ですか？
OWASP Top 10は、Open Web Application Security Project（OWASP）によって発行された、Webアプリケーションに対する最も重大なセキュリティリスクの定期的に更新されるリストです。
OWASP Top 10はどのくらいの頻度で更新されますか？
約3〜4年ごとに更新され、最新版は2021年にリリースされました。ただし、OWASPは継続的なガイダンスと更新を提供しています。
セキュリティのためにOWASP Top 10だけに頼ることはできますか？
いいえ、それは出発点です。Application Security Verification Standard（ASVS）のような他のOWASPプロジェクトにも従い、定期的なセキュリティテストを実施する必要があります。
SQLインジェクションやXSSなどの攻撃の兆候がないかNginxログを迅速に分析するには、Nginx Log Analyzerをお試しください。疑わしいパターンを発見し、Webサーバーを保護するのに役立ちます。