Spec Security

セキュリティ・脆弱性対策ガイド

ドキュメント

• e2e/src/tests/security/README.md - セキュリティテスト詳細
• documentation/docs/content_11_learning/06-security/ - セキュリティ学習リソース

対策済み脆弱性一覧

認証識別子切り替え攻撃（CWE-287）

攻撃シナリオ

1. 被害者のメールアドレスAで認証開始
2. チャレンジ送信後、攻撃者メールアドレスBに変更
3. Bの検証コードで認証
4. 【脆弱】: メールアドレスAとしてログイン ❌
5. 【正常】: メールアドレスBとしてログイン ✅

対策コード

EmailAuthenticationInteractor.java:257-306:

private User resolveUser(
    Tenant tenant,
    AuthenticationTransaction transaction,
    String email,
    String providerId,
    UserQueryRepository userQueryRepository) {

  // === 1st factor user identification ===

  // 1. Database search FIRST (Issue #800 fix)
  User existingUser = userQueryRepository.findByEmail(tenant, email, providerId);
  if (existingUser.exists()) {
    log.debug("User found in database. email={}, sub={}", email, existingUser.sub());
    return existingUser;
  }

  // 2. Reuse transaction user if same identity (Challenge resend scenario)
  if (transaction.hasUser()) {
    User transactionUser = transaction.user();
    if (email.equals(transactionUser.email())) {
      return transactionUser; // Same identity -> reuse
    }
    // Different identity -> create new user (identifier switching)
  }

  // 3. New user creation...
}

セキュリティテスト

e2e/src/tests/security/identifier_switching_attack.test.js

Redirect URI切り替え攻撃（CWE-601）

攻撃シナリオ

RFC 6749 準拠検証

// redirect_uri検証（RFC 6749 Section 4.1.3）
// "values MUST be identical"

// NG: 部分一致
if (registeredUri.startsWith(requestUri)) // ❌

// OK: 完全一致
if (registeredUri.equals(requestUri)) // ✅

セキュリティテスト

e2e/src/tests/security/redirect_uri_switching_attack.test.js

テストケース（21件）:

• Token Endpoint redirect_uri検証
• 未登録URI拒否
• 部分一致攻撃防止
• HTTP/HTTPS スキーム違い検証
• ポート省略/明示検証
• クエリパラメータ追加検証
• 認可コード再利用防止

Session Fixation（CWE-384）

攻撃シナリオ

1. 攻撃者がSession IDを取得
2. 被害者に固定Session IDでアクセスさせる
3. 被害者が認証完了
4. 【脆弱】: 攻撃者が同じSession IDで被害者としてアクセス ❌
5. 【正常】: 認証後にSession ID再生成 ✅

対策

認証成功後にセッションを再生成し、旧セッションIDを無効化。

セキュリティテスト

e2e/src/tests/security/session_fixation_password_auth.test.js

認可コード再利用攻撃（CWE-294）

RFC 6749 Section 10.5

"The authorization server MUST ensure that authorization codes cannot be used more than once."

対策コード

AuthorizationCodeGrantService.java:131-134, 202:

// 存在確認
if (!authorizationCodeGrant.exists()) {
  throw new TokenBadRequestException("invalid_grant", "not found authorization code.");
}

// ... トークン発行処理 ...

// 使用後は即時削除（再利用防止）
authorizationCodeGrantRepository.delete(tenant, authorizationCodeGrant);

マルチテナント分離（CWE-284）

設計原則

// ✅ 全Repository操作でTenant第一引数
public interface UserRepository {
    User find(Tenant tenant, UserId userId);
    void register(Tenant tenant, User user);
}

// ❌ Tenant指定なし（テナント間データ漏洩リスク）
public interface UserRepository {
    User find(UserId userId);  // 危険
}

Row-Level Security（PostgreSQL）

-- RLSポリシーでテナント分離を強制
CREATE POLICY tenant_isolation ON users
    USING (tenant_id = current_setting('app.current_tenant')::uuid);

セキュリティテスト

e2e/src/tests/security/multi_tenant_isolation.test.js

SSRF保護（CWE-918）

ブロック対象（16種）

PrivateIpRange.java:

対策コード

SsrfProtectionValidator.java:261-274:

private void validateIpAddress(String host, InetAddress address) {
  String ipString = address.getHostAddress();

  for (PrivateIpRange range : blockedRanges) {
    if (range.contains(address)) {
      throw new SsrfProtectionException(
          String.format(
              "Blocked: Host '%s' resolves to private/reserved IP %s (%s)",
              host, ipString, range.description()),
          host,
          ipString,
          range);
    }
  }
}

詳細は /ops-system-config スキル参照。

Null Byte Injection（CWE-626）

攻撃シナリオ

1. 攻撃者がCIBA/OAuth/管理APIのパラメータにUTF-8 0x00（null文字）を含めて送信
2. 【脆弱】: PostgreSQLが "invalid byte sequence for encoding UTF8: 0x00" で500エラー ❌
3. 【正常】: Servlet Filterで事前検出し400 Bad Requestを返却 ✅

対策コード

MaliciousRequestRejectFilter.java — Servlet Filterで全APIを一括防御:

• Query parameters / form-urlencoded body: getParameterNames() / getParameterValues() でチェック
• JSON/その他のリクエストボディ: InputStreamを先読みしてバイト列をスキャン
• リクエストボディサイズ制限: 10MB超のJSONボディを413 Payload Too Largeで拒否
• Null byte検出時: 400 Bad Request + ERRORレベルセキュリティログ出力

@Component
@Order(Ordered.HIGHEST_PRECEDENCE + 5)
public class MaliciousRequestRejectFilter extends OncePerRequestFilter {
  private static final int MAX_BODY_SIZE = 10 * 1024 * 1024; // 10MB
  // query params, form body, JSON body全てをチェック
  // Null byte検出時: {"error":"invalid_request","error_description":"Invalid parameter value"}
  // サイズ超過時: {"error":"invalid_request","error_description":"Request body too large"}
}

ボディサイズ制限の多層防御

• 本番ではAWS API Gatewayが10MBで先に弾く
• フィルターはAPI Gatewayがない環境やバイパスされた場合のdefense-in-depth
• nginxは20MBに設定し、E2Eテストでフィルターの413を直接検証可能にしている

セキュリティテスト

e2e/src/tests/spec/malicious_request_reject_filter.test.js

テストケース（5件）:

• CIBA binding_message に null byte
• CIBA scope に null byte
• CIBA login_hint に null byte
• Token grant_type に null byte
• 10MB超のJSONボディで413 Payload Too Large

ユーザーステータス検証

無効ユーザーの認可防止

e2e/src/tests/security/invalid_user_status_authorization.test.js

セキュリティテスト実行

全セキュリティテスト

cd e2e
npm test -- security/

個別実行

# 認証識別子切り替え
npm test -- security/identifier_switching_attack.test.js

# Redirect URI攻撃
npm test -- security/redirect_uri_switching_attack.test.js

# Session Fixation
npm test -- security/session_fixation_password_auth.test.js

# マルチテナント分離
npm test -- security/multi_tenant_isolation.test.js

# MaliciousRequestRejectFilter (Null Byte Injection + Payload Size)
npm test -- --testPathPattern="malicious_request_reject_filter"

セキュリティテスト作成パターン

describe("Security: [攻撃名]", () => {
  it("Should prevent [攻撃シナリオ]", async () => {
    // 1. 攻撃準備
    const victim = createVictimUser();
    const attacker = createAttackerUser();

    // 2. 攻撃実行
    const result = await executeAttack(victim, attacker);

    // 3. 脆弱性検証
    if (result.authenticatedAs === victim) {
      fail("CRITICAL: Attack succeeded - vulnerability exists");
    }

    // 4. 正常動作確認
    expect(result.authenticatedAs).toBe(attacker);
  });
});

OWASP参照

関連スキル