OWASP Top 10を実例で解説
Webアプリケーションを構築したものの、セキュリティが心配になってきたあなた。OWASP Top 10は、Webアプリケーションの重大なセキュリティリスクをまとめた定番のリストです。しかし、リストを読むことと、これらのリスクが実際のコードでどのように現れるかを理解することは別物です。この記事では、OWASP Top 10の各カテゴリを実例と具体的な緩和策とともに解説します。
1. アクセス制御の不備
アクセス制御の不備は、ユーザーが本来の権限を超えた操作を行える場合に発生します。たとえば、ユーザーがURLパラメータを変更するだけで他のユーザーのアカウントにアクセスできてしまうケースです。
// 脆弱: リクエストされたユーザーIDが認証済みユーザーのものかチェックしていない
app.get('/api/user/:id', (req, res) => {
const user = getUserById(req.params.id);
res.json(user);
});
緩和策: サーバー側でアクセス制御チェックを強制します。ロールベースまたは属性ベースのアクセス制御を使用し、デフォルトで拒否するようにします。
2. 暗号化の失敗
パスワードやクレジットカード番号などの機密データは、転送中も保存中も暗号化する必要があります。弱いアルゴリズムを使用したり、シークレットをハードコードしたりするのがよくある落とし穴です。
# 脆弱: パスワードハッシュにMD5を使用
import hashlib
hash = hashlib.md5(password.encode()).hexdigest()
緩和策: bcryptやArgon2などの強力なソルト付きハッシュアルゴリズムを使用します。転送中のデータには常にHTTPS(TLS)を使用します。
3. インジェクション
SQLインジェクションなどのインジェクションの欠陥は、信頼できないデータがコマンドやクエリの一部としてインタプリタに送信される場合に発生します。
// 脆弱: SQLクエリでの文字列連結
$sql = "SELECT * FROM users WHERE username = '" . $_GET['username'] . "'";
緩和策: パラメータ化クエリまたはプリペアドステートメントを使用します。ユーザー入力をクエリに直接連結しないでください。
4. 安全でない設計
安全でない設計とは、制御設計の欠如または不十分な設計を指します。たとえば、メールアドレスが存在するかどうかを明らかにするパスワード回復システムは、攻撃者を助ける可能性があります。
緩和策: 設計段階での脅威モデリング、安全な設計パターンの使用、レート制限やその他の制御の実装を行います。
5. セキュリティ設定ミス
これには、デフォルトアカウントを有効にしたままにする、スタックトレースをユーザーに表示する、クラウドストレージの権限を誤設定するなどが含まれます。
# 脆弱: 本番環境でデバッグモードが有効
DEBUG = True
緩和策: 設定を堅牢化し、未使用の機能を削除し、設定チェックを自動化します。
6. 脆弱で古いコンポーネント
既知の脆弱性があるライブラリを使用することは、ドアを開けっぱなしにするようなものです。たとえば、人気ライブラリの古いバージョンにリモートコード実行の欠陥があるかもしれません。
緩和策: 依存関係を定期的に更新し、OWASP Dependency-Checkなどのツールを使用し、CVEを監視します。
7. 識別と認証の失敗
弱い認証により、攻撃者はパスワードを推測したり、セッションをハイジャックしたりできます。
// 脆弱: 失敗試行後のアカウントロックなし
if (passwordMatches) {
loginUser();
} else {
// エラーを表示するだけ、レート制限なし
}
緩和策: 多要素認証を実装し、強力なパスワードポリシーを強制し、安全なセッション管理を使用します。
8. ソフトウェアとデータの整合性の失敗
このカテゴリには、ソフトウェア更新に信頼できないソースを使用したり、信頼できないデータをデシリアライズしたりすることが含まれます。
// 脆弱: 信頼できないデータのデシリアライズ
$data = unserialize($_POST['data']);
緩和策: デジタル署名を検証し、整合性チェックを使用し、信頼できないデータのデシリアライズを避けます。
9. セキュリティログと監視の失敗
適切なログがないと、侵害が検出されません。たとえば、ログイン失敗のログ記録を怠るケースです。
緩和策: セキュリティ関連イベントをログに記録し、アラートを設定し、インシデント対応計画を用意します。
10. サーバーサイドリクエストフォージェリ(SSRF)
SSRFは、攻撃者がサーバーに意図しない場所へのリクエストを送信させることができる場合に発生します。
// 脆弱: 検証なしでユーザー入力からURLを取得
fetch(req.query.url).then(...)
緩和策: URLを検証およびサニタイズし、許可リストを使用し、サーバーの権限を制限します。
比較表
| リスク | 例 | 緩和策 |
|---|---|---|
| アクセス制御の不備 | URL操作による他ユーザーのデータへのアクセス | サーバー側のアクセスチェックを強制 |
| 暗号化の失敗 | パスワードを平文で保存 | 強力なハッシュとTLSを使用 |
| インジェクション | 未サニタイズ入力によるSQLインジェクション | パラメータ化クエリ |
| 安全でない設計 | パスワード回復がメールの存在を明かす | 脅威モデリングと安全なパターン |
| セキュリティ設定ミス | 本番環境でデバッグモードがオン | 設定を堅牢化 |
| 脆弱なコンポーネント | 既知のCVEがある古いライブラリ | 定期的な更新と依存関係チェック |
| 認証の失敗 | ログインにレート制限なし | MFAと強力なポリシー |
| 整合性の失敗 | 信頼できないデータのデシリアライズ | 署名を検証し、安全でないデシリアライズを避ける |
| ログの失敗 | ログイン失敗のログなし | ログと監視を実装 |
| SSRF | ユーザー提供のURLを取得 | URLを検証し許可リストに登録 |
FAQ
OWASP Top 10とは何ですか?
OWASP Top 10は、Open Web Application Security Project(OWASP)が公開している、最も重大なWebアプリケーションセキュリティリスクの定期的に更新されるリストです。
OWASP Top 10はどのくらいの頻度で更新されますか?
新たな脅威やテクノロジーの変化を反映するために定期的に更新されます。最後の大きな更新は2021年でした。
OWASP Top 10だけでセキュリティは十分ですか?
いいえ、それは出発点にすぎません。包括的なセキュリティプログラムには、安全なコーディングプラクティス、定期的なテスト、継続的な監視が含まれます。
アプリケーションをさらに安全にするには、Nginx Log Analyzerなどのツールを使用してサーバーログ内の疑わしいアクティビティを監視・検出することを検討してください。