Hello there, ('ω')ノ
🎯 1. OAuthとは?
OAuth 2.0は、アプリケーション(クライアント)が、ユーザの資格情報(ID/パスワード)を保持せずに、他サービスへのアクセスを委譲できる仕組みです。
例: WebサービスAで「Googleアカウントでログイン」を実現する
🧭 2. OAuthの登場人物
役割 | 説明 |
---|---|
リソースオーナー(ユーザ) | 自分の情報にアクセスする権利を持つ人 |
クライアント | Webサービスなど、ユーザの代理でアクセスを行う |
認可サーバ(Authorization Server) | アクセスの許可・トークンの発行を行う |
リソースサーバ | 実際にユーザ情報を保持しているAPIなど |
🔐 3. よくある脆弱性と診断ポイント
種類 | 内容 | 危険性 |
---|---|---|
❌ リダイレクトURIの検証不足 | 攻撃者のサイトにトークンが漏れる | 高 |
❌ 認証と認可の混同 | トークンが「本人確認」代わりに使われる | 高 |
❌ トークンの長期有効・使い回し | セッション乗っ取り | 中 |
❌ スコープ制御不備 | 想定外の操作ができてしまう | 中 |
❌ ログにコード/トークン出力 | 情報漏洩 | 高 |
🛠️ 4. 診断手順:基本フローの観察
標準OAuth 2.0認可コードフロー(例)
- ユーザが以下のような認可URLにアクセス
https://auth.example.com/oauth/authorize?
response_type=code&
client_id=1234&
redirect_uri=https://client.com/callback&
scope=openid email profile
- ユーザがログイン&同意 → 認可コードが
redirect_uri
に付与されてリダイレクト
https://client.com/callback?code=abc123
- クライアントが
code
を使ってアクセストークンを取得
🔍 5. 主な診断ポイント
✅ リダイレクトURIの検証
- クエリパラメータを改ざんして攻撃者のサイトにリダイレクトできるか?
例:
redirect_uri=https://evil.com/callback
→ 正常にトークンが付与されたら ❌ オープンリダイレクト脆弱性あり
✅ 認可コードの再利用・使い回し
- 同じ
code
を使って複数回トークン取得できるか?
✅ access_token の漏洩確認
- 認可コードやトークンが URL・ログ・Refererヘッダなどに残っていないか?
- ブラウザの「開発者ツール」→「Network」タブでレスポンス・リクエストを観察
✅ IDトークンの検証(OIDCの場合)
id_token
をそのまま信用してログイン処理を行っていないか?- 署名の検証をしていないと、偽のトークンでログインされてしまう
🧪 6. テスト項目例
テスト内容 | ペイロード / 方法 |
---|---|
不正リダイレクトURI | redirect_uri=https://attacker.com/callback |
スコープ変更 | scope=admin など権限昇格 |
認証バイパス | 自作の id_token を用意してログイン試行 |
トークン再利用 | 同じ code を使って何度もトークン取得 |
🧰 7. 補助ツール
- Burp Suite(Repeater):OAuthの通信操作に便利
- OAuth 2.0 Playground(Google提供):フローの体験とテストが可能
- Postman:トークン発行・検証・スコープの確認
- jwt.io:
id_token
(JWT形式)のデコード・検証
✅ 8. 安全なOAuth設計のチェックリスト
項目 | OK | NG(要注意) |
---|---|---|
redirect_uri を事前登録している |
✅ | ❌ 任意指定可能 |
認可コードは一度しか使えない | ✅ | ❌ 再利用可 |
トークンがログなどに出力されない | ✅ | ❌ ログ漏洩あり |
トークン有効期限が適切 | ✅ | ❌ 長すぎる/無期限 |
IDトークンの署名検証がある | ✅ | ❌ 何でも受け入れる |
📌 見つけやすいヒント
- URLに
client_id=
,redirect_uri=
,response_type=
,scope=
が含まれる id_token
,access_token
,code
などのパラメータがやり取りされている- JavaScriptやローカルストレージにトークンが保存されていないか確認
Best regards, (^^ゞ