【DNS攻撃編】名前解決とサブドメイン管理の落とし穴｜CTF思考フレームワーク #22
安全に生きたい編集部
安全に生きたい
【API認証・認可編】APIキー・OAuth・JWTの役割と守り方｜CTF思考フレームワーク #35
安全に生きたい編集部
APIキー、OAuth、JWTって、全部ログイン方法の名前なの？
役割が違うよ。APIキーは資格情報の一種、OAuthは権限を渡す枠組み、JWTは情報を載せるトークン形式なんだ。
APIの安全性では、「本人かどうかを確かめる認証」と「そのデータを操作してよいかを確かめる認可」を分けて考える必要があります。
トークンが正しくても、別の利用者のIDを指定してデータが見えてしまえば認可の問題です。OWASP API Security Top 10でも、オブジェクト単位の認可不備（BOLA）は重要なリスクとして扱われています。
📚 CTF思考フレームワーク シリーズ
#35 【API認証・認可編】APIキー・OAuth・JWTの役割と守り方 ／ 全86記事。全シリーズ記事はこちら。
この記事の難易度
難易度：中級 ／ 読了目安：10分 ／ 学習順：#35
この記事で分かること
- APIキー・OAuth・JWTの役割の違いを整理する
- 認証済みでも認可不備が起こる理由を理解する
- トークン管理とオブジェクト認可の基本を知る
この記事で出てくる言葉
- 認証：利用者やアプリが誰かを確認することです。
- 認可：確認された主体が、その操作をしてよいか判断することです。
- JWT：署名付きで情報を持たせられるトークン形式で、単独で権限設計を保証するものではありません。
Contents
🔍 観察フェーズ：まず何を見る？
最初から攻撃方法を探すのではなく、どの機能や設定が外から見えているかを整理するところから始めるよ。
いきなり試すんじゃなくて、まず「どこが入口になり得るか」を整理するんだね。
💡 仮説フェーズ：なぜ危険になり得る？
観察した内容から、被害につながる条件を仮説として並べるよ。
仮説1
ログイン済みでも、IDを変えるだけで他人の情報へ到達できれば被害が起きます。
仮説2
長期間有効で権限の広いトークンが漏れると、影響範囲が大きくなります。
仮説3
JWTの署名検証が正しくても、認可ロジックがなければ他人のデータ操作は防げません。
🔬 検証フェーズ：安全に確かめる
検証の目的は、実在サービスを攻撃することではなく、自分のラボで仕組みと防御の効き方を理解することだよ。
自作APIや許可されたCTFで、同じログイン状態でも自分のオブジェクトと他利用者のオブジェクトで認可判定が変わる設計を確認します。実サービスのID変更試行は行いません。
許可された環境で、結果だけじゃなく「なぜそうなったか」まで確認するんだね。
⚔️ 攻撃フェーズ：成立すると何が起きる？
ここでは実サービスへの手順ではなく、成立した場合の影響を押さえよう。
影響1
攻撃者にとって利用価値のある入口や情報が増え、次の侵害につながる可能性があります。
影響2
設定や権限の範囲によっては、情報漏えい・改ざん・業務停止などへ影響が広がります。
影響3
検知や記録が不足していると、侵害の発見や原因調査が遅れます。
🛡️ 防御フェーズ：守る側はどうするか
守りは「気をつける」では終わらせず、設定・実装・監視に落とし込もう。
対策1
すべてのオブジェクト参照で、要求者がアクセス可能かをサーバー側で検証する
対策2
トークンは短命・最小権限にし、安全な保存と失効手段を用意する
対策3
APIキー、OAuth、JWTを役割に応じて使い分け、ログと異常アクセスを監視する
🤝 大事なお約束
必ず守ってね
この記事で扱う確認・検証は、自分の環境、CTF、または明示的に許可された演習環境だけで行ってください。他人のサービスや端末に無断で試す行為は、不正アクセス等に該当するおそれがあります。学んだ知識は守る側で活用しましょう。
📝 まとめ
APIの守りは「トークンを付ければ終わり」ではありません。誰が、どのデータに、何をしてよいかを毎回確認する認可が中心です。
