【実務・中級編】安全でない直接オブジェクト参照(IDOR)による権限昇格 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

IDORの悪夢：URLパラメータ一つで崩壊する権限の境界線

「管理者画面のURLを推測して叩いたら、全ユーザーの顧客リストがCSVで降ってきた」。
これは都市伝説ではなく、私がレッドチームとして企業診断に入る際、いまだにトップ3に入る頻度で見つける脆弱性です。

IDOR（Insecure Direct Object Reference：安全でない直接オブジェクト参照）は、サイバー攻撃者にとって「宝探し」のようなものです。認証機能がしっかりしていても、認可（Authorization）のロジックが「IDを知っている＝本人である」という甘い前提に立っている限り、そのシステムはザルと同じです。

今日は、開発現場でなぜIDORが生まれるのか、そしてどうやってそれを根絶するのか、現場目線で深掘りします。

—

1. IDORが「成功」してしまうメカニズム

開発者がやりがちなのは、データベースの主キー（user_id や order_id）をそのままURLパラメータとして露出させる設計です。

例えば、https://example.com/api/invoice?id=1024 というAPIがあったとします。攻撃者はこれを見て、即座に id=1025、1026 とインクリメントしてリクエストを投げます。もしサーバー側で「ログイン中のユーザーが id=1025 の所有者か？」というチェックが漏れていれば、攻撃者は他人のインボイスを閲覧し放題です。

攻撃者の視点：
1. 連番ID（1, 2, 3…）であれば、スクリプトを一回回すだけで全データを吸い出せる。
2. UUID（550e8400-e29b...）であっても、推測不可能というだけであり、どこかでURLがリーク（ログやRefererヘッダ）すればIDORは成立する。

—

2. 現場で使える「セキュアな実装」の正解

「IDを隠せばいい」という考えは対症療法に過ぎません。根本的な解決策は、「リソースへのアクセス権を、データ取得のタイミングで毎回強制的に検証すること」です。

PHP (Laravel) での正しい認可実装

コントローラーで「IDが正しいか」をチェックするのではなく、Laravelの「ポリシー（Policy）」機能を使って、モデル取得時に強制的にフィルタリングするのが定石です。

// app/Policies/InvoicePolicy.php
public function view(User $user, Invoice $invoice)
{
    // リクエストされたインボイスの所有者IDと、ログインユーザーのIDが一致するか厳密に比較
    return $user->id === $invoice->user_id;
}

// 呼び出し側のコントローラー
public function show($id)
{
    // findOrFailで取得し、その後authorizeで認可チェックを通す
    $invoice = Invoice::findOrFail($id);
    $this->authorize('view', $invoice);
    
    return response()->json($invoice);
}

Python (FastAPI) での実装例

FastAPIのようなフレームワークでは、依存関係注入（Dependency Injection）を利用して、認可ロジックを共通化します。

# dependencies.py
async def verify_ownership(invoice_id: int, current_user: User = Depends(get_current_user)):
    invoice = db.query(Invoice).filter(Invoice.id == invoice_id).first()
    # 存在しない場合や権限がない場合は403/404を返す
    if not invoice or invoice.user_id != current_user.id:
        raise HTTPException(status_code=403, detail="このリソースへのアクセス権がありません")
    return invoice

# routes.py
@app.get("/invoice/{invoice_id}")
async def read_invoice(invoice: Invoice = Depends(verify_ownership)):
    return invoice

—

3. 「やらかさない」ためのインフラ・設計のTips

コードレベルの修正に加え、以下の防御レイヤーを検討してください。

予測不可能な識別子（UUID v4 / ULID）の使用:

連番IDは論理的な脆弱性を露呈させます。主キーとは別に、公開用のUUIDを発行し、内部DB検索にはそちらを使うようにしましょう。

WAFでのIDOR検知:

AWS WAFなどの設定で、特定のパスパターンに対するパラメータの急激な変化（大量のIDアクセス）を検知し、レートリミットをかける設定は非常に有効です。

ログの可視化:

「403 Forbidden」が特定ユーザーから大量に発生していないか、SIEM（SplunkやDatadog等）で監視してください。それは攻撃者があなたのID体系をスキャンしているサインです。

—

最後に：エンジニアへ送る言葉

IDORを防ぐのは、難しいアルゴリズムを実装することではありません。「自分の書いたこのAPIは、他人のIDを投げられた時にどう反応するか？」という、疑心暗鬼な視点を持つことです。

「ユーザーは正しいリクエストを送ってくる」という性善説に基づいたコードは、レッドチームの格好の餌食になります。常に「悪意ある第三者が、URLを書き換えてリクエストを送ってきたらどうなるか？」を想像し、実装してください。

皆さんのシステムが、今日も安全に運用されることを願っています。もし設計に不安があれば、いつでもコードを見直す勇気を持ってください。それが、プロフェッショナルの仕事です。