【実務・中級編】 API認証におけるOAuth 2.0/OIDCの不適切な実装 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

おい、最近のOAuth 2.0 / OIDCの実装、適当にライブラリを組み込んで「動いたからヨシ！」にしていないか？

セキュリティチーフの俺がインシデントレスポンスの現場で何度も目にしてきたのは、まさにそういう「仕様書の斜め読み」と「手抜き実装」が生んだ悲劇だ。認証・認可周りの実装ミスは、一発でユーザーアカウントの完全な乗っ取り（Account Takeover）に直結する。特に、認可コードフローにおける state パラメータの省略や、リダイレクトURIのガバガバなバリデーション、そしてリフレッシュトークンの取り扱いミスは、攻撃者にとって「どうぞ侵入してください」と言っているようなものだ。

今回は、現場で実際に使われているリアルな攻撃手法（PoC）のリスクを叩き込んだ上で、明日からプロダクション環境に投入できる「セキュアな実装サンプル」を徹底的に解説していく。しっかりついてこい。

—

1. 現場を崩壊させる「2大脆弱性」のメカニズム

まずは、攻撃者がどこを狙い、どうやってシステムをハッキングするのか、その現実を知る必要がある。

① state パラメータの欠如が生むCSRF（クロスサイト・リクエスト・フォージェリ）

OAuth 2.0の認可コードフローにおいて、state パラメータは「攻撃者が別のユーザーのセッションを強引に紐付けること（CSRF）」を防ぐための防波堤だ。

【攻撃シナリオ】
1. 攻撃者が自身のSNSアカウントなどで正規の認可リクエストを発生させ、認可サーバーから発行された code（認可コード）を手に入れる。
2. 攻撃者は、その code を含んだURLを被害者に踏ませる（「このリンクをクリックして特典をゲット！」など）。
3. 被害者のブラウザがそのURLを踏むと、被害者のセッションでアプリのバックエンドに認可コードが送信され、被害者のアカウントが攻撃者のSNSアカウントと紐付けられてしまう。
4. 結果、攻撃者は「自分のSNSでログインすれば、被害者のアカウントにログインできる」状態を作り出し、完全にアカウントを乗っ取る。

state パラメータを実装していれば、リクエスト時に生成したランダムな値をセッションに保持し、コールバック時にそれが一致するか検証できるため、この手の攻撃を完全に無力化できる。

② リダイレクトURIの検証不備（オープンリダイレクト・トークン詐取）

認可サーバー側、あるいはクライアントアプリ側で redirect_uri の前方一致や正規表現のバリデーションがガバガバだと、大惨事になる。

【攻撃シナリオ】
攻撃者が https://your-app.com/callback?evil=1 のような不正なURIを認可リクエストに含めた際、サーバー側が https://your-app.com から始まっているという理由だけでこれを許可してしまうと、認可コードやアクセストークンが攻撃者の制御する外部サーバーへ直接送信されてしまう。これが漏洩すれば、APIへの不正アクセスはやりたい放題だ。

—

2. 【ハンズオン】コピペで動くセキュアな実装サンプル

では、実務でどう書くべきか。ここでは、PHP（バックエンド）とJavaScript（フロントエンド）を想定した、セキュアな認可コードフローの実装例を示す。

① 認可リクエストの送信側（PHP）

まずは、セキュアな state と code_verifier（PKCEを使用する場合の例）を生成し、認可サーバーへリダイレクトする処理だ。

<?php
// セッションの開始（セキュアなフラグ設定は前提とする）
session_start();

// 1. CSRF対策用のランダムな state を生成し、セッションに保存
$state = bin2hex(random_bytes(32));
$_SESSION['oauth2_state'] = $state;

// 2. PKCE (Proof Key for Code Exchange) 用のverifierとchallengeを生成（パブリッククライアントやSPAでは必須級）
$code_verifier = rtrim(strtr(base64_encode(random_bytes(32)), '+/', '-_'), '=');
$_SESSION['code_verifier'] = $code_verifier;
$code_challenge = rtrim(strtr(base64_encode(hash('sha256', $code_verifier, true)), '+/', '-_'), '=');

// 3. 認可エンドポイントへのパラメータ構築
$params = [
    'response_type' => 'code',
    'client_id'     => 'YOUR_CLIENT_ID',
    'redirect_uri'  => 'https://your-app.com/callback.php',
    'scope'         => 'openid profile email',
    'state'         => $state,
    'code_challenge' => $code_challenge,
    'code_challenge_method' => 'S256',
];

$auth_url = 'https://auth.example.com/oauth/authorize?' . http_build_query($params);

// 4. 認可サーバーへ安全にリダイレクト
header('Location: ' . $auth_url);
exit;

② コールバック処理と厳格な検証（PHP）

次に、認可サーバーからリダイレクトされてきたコードを受け取り、検証してトークンを取得する処理だ。

<?php
session_start();

// 1. パラメータの存在確認
if (!isset($_GET['code']) || !isset($_GET['state'])) {
    http_response_code(400);
    die('エラー: 必要なパラメータが不足しています。');
}

$incoming_code = $_GET['code'];
$incoming_state = $_GET['state'];

// 2. state の厳格な検証（タイミング攻撃を防ぐため hash_equals を使用）
if (!isset($_SESSION['oauth2_state']) || !hash_equals($_SESSION['oauth2_state'], $incoming_state)) {
    http_response_code(403);
    die('セキュリティエラー: stateパラメータが一致しません（CSRFの可能性）。');
}

// 使用済みの state は即座に破棄
unset($_SESSION['oauth2_state']);

// 3. トークンエンドポイントへ認可コードをPOSTし、アクセストークンと交換
$token_url = 'https://auth.example.com/oauth/token';
$post_data = [
    'grant_type'    => 'authorization_code',
    'client_id'     => 'YOUR_CLIENT_ID',
    'client_secret' => 'YOUR_CLIENT_SECRET', // ※SPAの場合はバックエンド経由で行うこと
    'redirect_uri'  => 'https://your-app.com/callback.php',
    'code'          => $incoming_code,
    'code_verifier' => $_SESSION['code_verifier'] ?? '',
];

$ch = curl_init($token_url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($post_data));
curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type: application/x-www-form-urlencoded']);

$response = curl_exec($ch);
$http_code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);

if ($http_code !== 200) {
    http_response_code(500);
    die('トークンの取得に失敗しました。');
}

$token_data = json_decode($response, true);

// 4. トークンの安全な保存
// アクセストークンはメモリ上（JS変数など）に保持し、リフレッシュトークンはHttpOnlyかつSecure属性付きのCookieに保存するのが鉄則
setcookie('refresh_token', $token_data['refresh_token'], [
    'expires' => time() + (86400 * 30), // 30日
    'path' => '/',
    'domain' => 'your-app.com',
    'secure' => true,    // HTTPS必須
    'httponly' => true,  // JavaScriptからのアクセスを禁止（XSS対策）
    'samesite' => 'Strict'
]);

// ログイン成功後のリダイレクト
header('Location: /dashboard.php');
exit;

—

3. トークンの有効期限とリフレッシュトークンの安全な取り扱い

現場でよくあるミスが、「アクセストークンの有効期限を数ヶ月という長さに設定する」ことや、「リフレッシュトークンを localStorage に保存する」という愚行だ。

  • アクセストークンは短命にせよ:

有効期限は原則として5分〜15分程度に絞れ。万が一、API通信中にパケットスニッフィングやログからアクセストークンが漏洩しても、すぐに無効化されるため被害を最小限に抑えられる。

  • リフレッシュトークンのローテーション（Refresh Token Rotation）を実装せよ:

リフレッシュトークンを使って新しいアクセストークンを発行する際、古いリフレッシュトークンを即座に無効化し、新しいリフレッシュトークンを再発行する仕組みを入れろ。もし万が一、古いリフレッシュトークンが攻撃者に盗まれて再利用された場合、「トークンの盗難・不正利用」と検知して、そのセッションツリー全体を強制ログアウト＆管理者アラートを飛ばす実装が、最高峰のセキュリティ設計だ。

  • 保存場所のタブー:

フロントエンドの localStorage や sessionStorage にトークンを保存してはならない。XSS（クロスサイトスクリプティング）の脆弱性が一箇所でもあれば、数行の悪意あるスクリプト (<script>) を仕込まれてすべてのトークンが外部へ送信されてしまう。前述のサンプルコードの通り、リフレッシュトークンは必ず HttpOnly 属性付きの Cookie で保護しろ。

—

4. チーフからの総括

OAuth 2.0 / OIDCは、仕様が複雑ゆえに実装者の思い込みや「動けばいいや」という妥協が入り込みやすい領域だ。今回解説した state によるCSRF防御、厳格な redirect_uri のバリデーション、そしてPKCEやリフレッシュトークンのローテーションは、どれ一つ欠けてもセキュアなシステムとは言えない。

君たちの書いたコードやアーキテクチャが、明日、レッドチームからの容赦ないペネトレーションテストに耐えられるか、あるいは実際の攻撃者に狙われたときにビクともしないか。もう一度、自分たちの実装をコードレビューし直してほしい。セキュリティは「後付けの機能」ではなく、設計そのものなのだから。

スポンサーリンク

コメント

タイトルとURLをコピーしました