現場のエンジニア諸君、今日も泥臭いデバッグとログの海にお疲れ様。
セキュリティの世界で「完璧な防御」などという幻想を抱いている奴は、最初のインシデントで心が折れる。我々が対峙しているのは、機械的な攻撃ツールだけじゃない。URLのパラメータを書き換えて、他人の個人情報を覗こうとする「悪意を持った人間」だ。
今日は、OWASP Top 10の常連である「認証・認可の不備」の中でも、特に見逃されがちな権限昇格（Privilege Escalation）の検知と、その撲滅について話そう。
—
1. なぜ「IDの改ざん」は検知しにくいのか
攻撃者は、ブラウザのデベロッパーツールやBurp Suiteを使って、GET /api/user/101/profile の 101 を 102 に書き換える。これが「水平的権限昇格」だ。
開発者が陥る最大の罠は、「認証（ログインしているか）」と「認可（そのデータにアクセスする権利があるか）」を混同することだ。ログインセッションがあるからといって、そのユーザーが要求したリソースの所有者である保証はどこにもない。
攻撃者の思考プロセス（PoCの視点）
1. 列挙（Enumeration）: IDが連番であることを突き止める。
2. 改ざん（Tampering）: 自分のID（例: 101）を他者のID（例: 102）に書き換えてリクエストを送る。
3. 検証（Verification）: ステータスコード 200 OK が返ってきた瞬間に「当たり」を確信する。
これをログだけで検知しようとすると、往々にして「大量のアクセスがあるな」というノイズに埋もれる。我々が守るべきは、そのノイズの中から「不自然なリソースへのアクセス」を抽出するロジックだ。
—
2. 垂直・水平権限昇格を防ぐ実装：セキュアな設計の鉄則
コードレベルで最も重要なのは、「リソースを特定する際は、セッション内のユーザーIDを絶対基準とする」ことだ。
不適切な実装（よくあるアンチパターン）
// IDをURLからそのまま取ってくる（危険！）
$targetUserId = $_GET[‘id’];
$data = $db->query(“SELECT FROM profiles WHERE user_id = $targetUserId”);
セキュアな実装（PHP/Laravel風）
URLのIDは「補助的なヒント」として扱い、認可判定は「現在ログインしているユーザー（Auth::id()）」を起点にする。
/
- セキュアなリソース取得処理
/
public function getProfile(Request $request, $targetUserId) {
// 1. 本人確認（水平権限の保護）
// ログイン中のユーザーIDとリクエストされたIDが一致しなければエラー
if (Auth::id() != $targetUserId) {
Log::warning(‘権限違反の検知’, [‘user_id’ => Auth::id(), ‘accessed_id’ => $targetUserId]);
abort(403, ‘Unauthorized Access Attempt’);
}
// 2. 垂直権限の確認（管理者権限が必要な場合）
if (!Auth::user()->is_admin) {
abort(403, ‘Admin privilege required’);
}
return Profile::where(‘user_id’, $targetUserId)->first();
}
—
3. ログ監視と異常検知：SIEMへの流し込み方
コードで防ぐのは大前提だが、網をすり抜けてくる奴もいる。そこで「ログ」の出番だ。重要なのは、「アクセスしたID」と「セッションID」の不一致を相関分析すること。
Nginxでのログ出力設定
まずは、認証情報をログに出すための設定を nginx.conf に仕込む。
ログフォーマットにユーザーIDを含める（カスタムログ）
log_format secure_log ‘$remote_addr – $remote_user [$time_local] ‘
‘”$request” $status $body_bytes_sent ‘
‘”$http_referer” “$http_user_agent” ‘
‘UID:$sent_http_x_user_id’; # アプリ側でユーザーIDをヘッダーにセットさせる
異常検知ルール（Elasticsearch/Splunkの考え方）
以下のクエリで異常を弾き出す。
- ルール:
同じセッションID（またはIP）が、短時間に異なるユーザーIDのリソースへアクセスを試行している件数がしきい値を超えた場合
— 擬似クエリ：連続するアクセスで異なるuser_idが頻出しているケース
SELECT session_id, COUNT(DISTINCT target_user_id) as target_count
FROM access_logs
WHERE status = 403
GROUP BY session_id
HAVING target_count > 3; — 3回以上別のIDを叩いたら即座にアラート
—
4. 最後に：現場の君たちへ
セキュリティは「設定して終わり」のタスクじゃない。プロダクトが成長すれば攻撃手法も進化する。
もし君たちが明日、403 Forbidden のログが大量に吐かれていることに気づいたら、それは「システムが攻撃に耐えている」証拠だが、同時に「攻撃者が弱点を探っている」という警告でもある。
- APIならUUIDを使う: 連番（1, 2, 3…）ではなく、推測困難なUUIDを利用するだけで、水平的権限昇格の難易度は跳ね上がる。
- WAFの活用: AWS WAFなどを使っているなら、URLパスのパラメータパターンを正規表現で監視し、異常なIDフォーマットをブロックするルールを即座に追加してくれ。
泥臭いログ解析こそが、最高の防御になる。コードの裏側にある「攻撃者の意図」を想像できるようになれば、君たちも一人前のセキュリティエンジニアだ。
次は、認証トークンのハイジャック対策について語ろうか。準備はいいか？
コメント