メインコンテンツまでスキップ

OWASP Top 10 - ID/認証システムの観点から

このドキュメントの目的​

OWASP Top 10の脆弱性をID・認証システムの観点から理解し、適切な対策方法を学びます。

OWASPとは​

OWASP = Open Worldwide Application Security Project

Webアプリケーションセキュリティの向上を目指す
非営利のオープンコミュニティ。

提供しているもの:
- OWASP Top 10: 最も重大なWebセキュリティリスクのランキング
- チートシート: 各分野のセキュリティ対策ガイド
- ツール: ZAP（脆弱性スキャナー）等

なぜ学ぶべきか:
- 業界標準のセキュリティ基準として広く認知
- 開発者が知るべき最低限のセキュリティ知識
- セキュリティ監査で必ず参照される

OWASP Top 10（2021年版）概要​

#脆弱性カテゴリ何が起こるかID/認証との関連度
A01Broken Access Control他人のデータを閲覧・操作できる◎ 非常に高い
A02Cryptographic Failuresパスワードが解読・漏洩する◎ 非常に高い
A03Injection悪意あるコードが実行される○ 高い
A04Insecure Design根本的に守れない構造◎ 非常に高い
A05Security Misconfiguration不要な機能が有効なまま○ 高い
A06Vulnerable Components既知の脆弱性を突かれる△ 中程度
A07Auth Failures総当たりで突破される◎ 直接該当
A08Integrity Failures改ざんされたコードが動く○ 高い
A09Logging Failures侵入されても検知できない○ 高い
A10SSRF内部システムに不正アクセス△ 中程度

A01: Broken Access Control（アクセス制御の不備）​

概要​

認可されていないリソースへのアクセスを許してしまう脆弱性。

ID/認証システムでの具体例​

1. 他のユーザーのプロファイルを閲覧できる
   GET /users/12345 → 自分以外のユーザー情報が取得できる

2. 管理者APIに一般ユーザーがアクセスできる
   POST /admin/users → 権限チェックがない

3. テナント間のデータが見える（マルチテナント）
   Tenant AのユーザーがTenant Bのデータを取得

対策パターン​

1. デフォルト拒否（Deny by Default）

// 悪い例：許可リストで判定
if (user.hasRole("admin")) {
    // 許可
}
// else は何もしない → 暗黙的に許可される可能性

// 良い例：明示的に拒否
if (!user.hasRole("admin")) {
    throw new ForbiddenException("Admin role required");
}

2. リソースオーナーシップ検証

// リソース取得時に所有者を確認
User user = userRepository.findById(userId);
if (!user.getTenantId().equals(currentTenant.getId())) {
    throw new ForbiddenException("Access denied");
}

3. 主な対策

  • 全Repository操作でTenantを必須化
  • スコープベース認可：Access Tokenのscopeでアクセス範囲を制限
  • RBAC：ロールベースのアクセス制御

A02: Cryptographic Failures（暗号化の失敗）​

概要​

機密データの暗号化不備、弱い暗号アルゴリズムの使用。

ID/認証システムでの具体例​

1. パスワードの平文保存
2. MD5/SHA1でのパスワードハッシュ（弱い）
3. 秘密鍵のハードコード
4. HTTPでの認証情報送信
5. JWTの署名なし（alg: none）

対策パターン​

1. パスワードハッシュ

推奨アルゴリズム:
- bcrypt（コスト係数12以上）
- Argon2id（メモリハード）
- scrypt

2. JWT署名アルゴリズム

推奨:
- RS256（RSA + SHA-256）: 公開鍵検証が必要な場合
- ES256（ECDSA + SHA-256）: より短い鍵長で同等のセキュリティ
- PS256（RSA-PSS）: より安全なパディング

非推奨:
- HS256（共有秘密鍵）: 鍵管理が難しい
- none: 絶対に禁止

3. 鍵管理

# 悪い例：設定ファイルに直接記載
jwt:
  secret: "my-super-secret-key"

# 良い例：環境変数または外部シークレット管理
jwt:
  secret: ${JWT_SECRET}  # 環境変数から取得

A03: Injection（インジェクション）​

概要​

ユーザー入力がコード/クエリとして実行される脆弱性。

ID/認証システムでの具体例​

SQLインジェクション

-- 脆弱なコード
SELECT * FROM users WHERE username = '${username}'

-- 攻撃例
username = "admin' OR '1'='1"
→ SELECT * FROM users WHERE username = 'admin' OR '1'='1'
→ 全ユーザーが返される

LDAPインジェクション

-- 脆弱なコード
(&(uid=${username})(userPassword=${password}))

-- 攻撃例
username = "*)(uid=*))(|(uid=*"
→ 認証バイパス

対策パターン​

1. パラメータ化クエリ

// 悪い例
String query = "SELECT * FROM users WHERE username = '" + username + "'";

// 良い例
PreparedStatement stmt = conn.prepareStatement(
    "SELECT * FROM users WHERE username = ?"
);
stmt.setString(1, username);

2. 主な対策

  • ORMを使用（パラメータバインディング自動適用）
  • 入力バリデーション（許可文字のホワイトリスト）

A04: Insecure Design（安全でない設計）​

概要​

設計段階でのセキュリティ考慮不足。

ID/認証システムでの具体例​

1. パスワードリセットで秘密の質問を使用（推測可能）
2. 認証試行回数に制限がない（ブルートフォース可能）
3. セッションタイムアウトがない（盗まれたセッションが永続化）
4. 多要素認証のバイパス経路がある

対策パターン​

1. 脅威モデリング

STRIDE分析:
- Spoofing（なりすまし）→ 強力な認証
- Tampering（改ざん）→ 署名・MAC
- Repudiation（否認）→ 監査ログ
- Information Disclosure（情報漏洩）→ 暗号化
- Denial of Service（サービス拒否）→ レート制限
- Elevation of Privilege（権限昇格）→ 最小権限

2. セキュアなデフォルト

# セキュアデフォルト例
authorization_server:
  access_token_duration: 3600      # 1時間（短め）
  refresh_token_duration: 2592000  # 30日
  authorization_code_duration: 600 # 10分
  require_pkce: true               # PKCE必須

A05: Security Misconfiguration（セキュリティ設定ミス）​

概要​

デフォルト設定のまま運用、不要な機能の有効化、不適切なエラーメッセージなど、設定に起因する脆弱性。

ID/認証システムでの具体例​

1. デフォルト認証情報
   - 管理者アカウント: admin/admin のまま
   - APIキー: 公開サンプルのまま使用

2. 不要な機能の有効化
   - デバッグエンドポイントが本番で有効
   - 未使用のOAuth grant_typeが有効
   - トークンイントロスペクションが認証なしで公開

3. 過剰な情報露出
   - エラーメッセージにスタックトレース
   - /.well-known/openid-configuration に内部情報
   - HTTPヘッダーにサーバーバージョン

4. セキュリティヘッダー未設定
   - HSTS未設定でHTTPダウングレード可能
   - CSP未設定でXSSリスク増大

対策パターン​

1. 本番環境チェックリスト

設定確認:
- [ ] デフォルト認証情報を変更済み
- [ ] デバッグモード無効化
- [ ] 不要なエンドポイント無効化
- [ ] エラーメッセージは最小限
- [ ] セキュリティヘッダー設定済み

2. 最小機能の原則

# 必要なgrant_typeのみ有効化
oauth:
  grant_types:
    - authorization_code  # 必要
    - refresh_token       # 必要
    # - implicit          # 不要なら無効化
    # - password          # 不要なら無効化

3. 環境別設定の分離

本番環境:
- debug: false
- detailed_errors: false
- admin_endpoints: 内部ネットワークのみ

開発環境:
- debug: true
- detailed_errors: true

A06: Vulnerable and Outdated Components（脆弱なコンポーネント）​

概要​

既知の脆弱性を持つライブラリやフレームワークを使用することで、攻撃を受けるリスク。

ID/認証システムでの具体例​

1. JWT/JOSEライブラリの脆弱性
   - CVE-2022-21449: Java 15-18のECDSA署名検証バイパス
   - alg: none攻撃に脆弱な古いライブラリ

2. 暗号ライブラリの脆弱性
   - OpenSSL Heartbleed (CVE-2014-0160)
   - 古いbcryptライブラリのタイミング攻撃

3. フレームワークの脆弱性
   - Spring4Shell (CVE-2022-22965)
   - Log4Shell (CVE-2021-44228)

4. 認証ライブラリの脆弱性
   - passport.jsの認証バイパス
   - OAuthライブラリのオープンリダイレクト

対策パターン​

1. 依存関係の監視

# 脆弱性スキャン
npm audit                    # Node.js
./gradlew dependencyCheckAnalyze  # Java (OWASP Dependency Check)
trivy fs .                   # コンテナ/ファイルシステム

2. 定期的な更新

推奨プラクティス:
- セキュリティパッチは即座に適用
- メジャーバージョンは四半期ごとに評価
- EOL（サポート終了）ライブラリの排除計画

3. 脆弱性情報の収集

情報源:
- CVE/NVD（National Vulnerability Database）
- GitHub Security Advisories
- 利用ライブラリのセキュリティML/RSS
- JPCERT/CC（日本）

4. SBOM（ソフトウェア部品表）の管理

目的:
- 使用コンポーネントの一覧化
- 脆弱性発見時の影響範囲特定
- ライセンスコンプライアンス

A07: Identification and Authentication Failures​

概要​

認証・識別の実装不備。OWASP Top 10で最もID/認証に直接関連するカテゴリ。

具体的な脆弱性​

脆弱性影響対策
弱いパスワード許可アカウント乗っ取りパスワードポリシー強制
ブルートフォース可能アカウント乗っ取りレート制限、アカウントロック
クレデンシャルスタッフィング大量アカウント侵害漏洩パスワードチェック
セッション固定攻撃セッションハイジャック認証後セッションID再生成
平文パスワード送信盗聴HTTPS必須
多要素認証なし単一障害点MFA推奨/必須

対策​

1. パスワードポリシー

password_policy:
  min_length: 12
  require_uppercase: true
  require_lowercase: true
  require_number: true
  require_special: true
  max_consecutive_chars: 3

2. 認証試行制限

authentication_policy:
  max_attempts: 5
  lockout_duration: 900  # 15分
  progressive_delay: true

3. 多要素認証

authentication_policy:
  mfa:
    required: true
    methods:
      - webauthn
      - totp

A08: Software and Data Integrity Failures​

概要​

ソフトウェアやデータの整合性検証不備。

ID/認証システムでの具体例​

1. JWTの署名検証をスキップ
2. 外部IdPからのSAMLレスポンスを未検証で信頼
3. ソフトウェア更新時の署名検証なし

対策パターン​

1. JWT検証の徹底

必須の検証項目:
- 署名検証（alg: noneを拒否）
- 発行者（iss）検証
- 有効期限（exp）検証
- 対象者（aud）検証

2. Federation時の検証

OIDC Federationでの検証項目:
1. ID Tokenの署名検証（外部IdPの公開鍵で）
2. issクレームが期待するIdPか
3. audクレームが自分のclient_idか
4. nonceが送信したものと一致するか
5. expが有効期限内か

A09: Security Logging and Monitoring Failures​

概要​

セキュリティイベントのログ記録・監視不備。

ID/認証システムで記録すべきイベント​

必須ログ:
- 認証成功/失敗（ユーザーID、IP、タイムスタンプ）
- 権限変更（ロール付与/剥奪）
- パスワード変更
- MFA設定変更
- セッション作成/破棄
- 管理操作（ユーザー作成/削除）

推奨ログ:
- 認可判定（許可/拒否）
- トークン発行/失効
- 設定変更

A10: Server-Side Request Forgery (SSRF)​

概要​

サーバーに外部URLを取得させる機能を悪用し、内部システムへ不正アクセスする攻撃。

ID/認証システムでの具体例​

1. redirect_uriの検証不備
   攻撃者: redirect_uri=http://169.254.169.254/latest/meta-data/
   → サーバーがクラウドメタデータにアクセスし、認証情報が漏洩

2. ユーザー情報取得時の外部URL指定
   攻撃者: picture=http://internal-service/admin
   → サーバーが内部サービスにアクセス

3. WebFinger/OpenID Connect Discovery
   攻撃者: issuer=http://internal-server/.well-known/openid-configuration
   → 内部サーバーへのアクセスを誘発

攻撃の流れ​

┌──────────┐    ┌──────────────┐    ┌──────────────┐
│  攻撃者   │    │   IdPサーバー │    │  内部システム  │
└────┬─────┘    └──────┬───────┘    └──────┬───────┘
     │                 │                   │
     │ redirect_uri=   │                   │
     │ http://169.254. │                   │
     │ 169.254/...     │                   │
     │────────────────>│                   │
     │                 │                   │
     │                 │ GET /latest/      │
     │                 │ meta-data/        │
     │                 │──────────────────>│
     │                 │                   │
     │                 │ IAMクレデンシャル  │
     │                 │<──────────────────│
     │                 │                   │
     │ 認証情報が漏洩   │                   │
     │<────────────────│                   │

対策パターン​

1. redirect_uriの厳格な検証

対策:
- 事前登録されたURIとの完全一致
- ワイルドカード禁止
- localhostやプライベートIPの禁止
- URLスキームはhttpsのみ許可

2. 外部リソース取得の制限

対策:
- 許可リスト方式（取得可能なドメインを限定）
- プライベートIPレンジへのアクセス禁止
  - 10.0.0.0/8
  - 172.16.0.0/12
  - 192.168.0.0/16
  - 169.254.0.0/16（クラウドメタデータ）
- DNSリバインディング対策（解決後のIPも検証）

DNSリバインディング攻撃とは

DNSリバインディングは、DNS応答を操作してSSRF保護をバイパスする攻撃手法です。

攻撃の流れ:
1. 攻撃者は自身のドメイン（evil.com）のDNS TTLを極端に短く設定（例: 1秒）
2. 被害者アプリがevil.comを検証 → 最初のDNS解決で外部IP（203.0.113.1）を返す
3. アプリは「外部IPなので安全」と判断して許可
4. 実際の接続時にDNSを再解決 → 今度は内部IP（169.254.169.254）を返す
5. アプリは内部リソース（クラウドメタデータ等）にアクセスしてしまう

対策:
- DNS解決は1回のみ行い、解決したIPアドレスを保持して再利用
- 接続前にIPアドレスを再検証（解決後のIPがプライベートIPでないか確認）
- DNSキャッシュのTTLに最小値を設定（攻撃者の短いTTLを無効化）

3. ネットワークレベルの防御

対策:
- IdPサーバーから内部ネットワークへのアクセスを制限
- メタデータサービスへのアクセスをIMDSv2必須に
- アウトバウンド通信のファイアウォール設定

まとめ：ID/認証システムのセキュリティチェックリスト​

設計フェーズ​

  • 脅威モデリングを実施した
  • 認証フローを文書化した
  • データフロー図でセキュリティ境界を明確化した

実装フェーズ​

  • パスワードはbcrypt/Argon2idでハッシュ化
  • SQLはパラメータ化クエリを使用
  • JWTは署名検証を必ず実施
  • HTTPS必須化
  • セッションIDは認証後に再生成

運用フェーズ​

  • 認証イベントをログ記録
  • 異常検知アラートを設定
  • 定期的なセキュリティレビュー
  • 依存ライブラリの脆弱性スキャン

参考資料​

最終更新: 2025-12-25 対象: IDサービス開発者