mcpField
H
hunt-captcha-bypass

hunt-captcha-bypass

github.com/elementalsoulsセキュリティ5.3k211 回インストール今日更新
リポジトリ

hunt-captcha-bypass について

CAPTCHAの回避を調べるセキュリティテスト用スキルです。フィールドの省略や空値、トークンの再利用、関連エンドポイントを検査し、成功した操作と影響を評価する方法を示します。

主な機能

  1. 01CAPTCHAフィールド省略の検査
  2. 02空値とトークン再利用の確認
  3. 03類似エンドポイントの検証漏れ調査
  4. 04同時リクエストのカウント検査
  5. 05状態変更と影響チェーンの確認

活用シーン

  1. 01ログインAPIのサーバー側検証漏れの確認
  2. 02登録やパスワードリセットのCAPTCHA検査
  3. 03CAPTCHAトークンの再利用可否の確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/elementalsouls/claude-bughunter --skill hunt-captcha-bypass

インストール後、Claude Code で/hunt-captcha-bypassを入力して読み込まれたか確認します。

詳細

自動テストの優先順位

最速のテスト：CAPTCHA フィールドを完全に省略します。ほとんどの CAPTCHA バイパスのバグは、クライアント側のみの検証が原因です。

パターン 1 — CAPTCHA フィールドを省略する（最も一般的で、自動化しやすい方法）：

  1. CAPTCHA が表示されるフォームまたはエンドポイントに GET リクエストを送り、フィールド名を確認します（通常は g-recaptcha-response、captcha、captcha_token、captcha_answer、h-captcha-response です）。
  2. CAPTCHA フィールドを除くすべてのフィールドを指定してフォームに POST リクエストを送ります。
  3. 操作が成功する（200、リダイレクト、または「成功」メッセージが返る）場合 → サーバー側で CAPTCHA が検証されていません。
  4. 証拠：有効な CAPTCHA フィールドがなくても状態を変更する操作が完了します（このリクエストを CAPTCHA フィールドを含むベースラインリクエストと比較してください）。

パターン 2 — CAPTCHA の値を空または null にする： フィールドを完全に省略する代わりに、空文字列、null、0、または undefined を指定します：

captcha=&[email protected]&password=test123

フィールドの存在は検証しても、内容は検証しないアプリもあります。

パターン 3 — 以前解いた CAPTCHA トークンを再送する：

  1. 正規の CAPTCHA チャレンジを 1 回完了し、g-recaptcha-response トークンを取得します。
  2. 同じトークン値を使って、2 回目のリクエストをすぐに送信します。
  3. 2 回目の送信も成功する場合 → トークンは一度しか使えないようになっていません（リプレイ攻撃）。
  4. 再送したトークンは、自動化された複数のリクエストで共有できます。

パターン 4 — 類似のエンドポイントで CAPTCHA なしのリクエストを試す： 登録フォームには CAPTCHA を追加していても、パスワードリセット、API エンドポイント、モバイル API のパス（/api/register と /register など）を忘れているアプリもあります。CAPTCHA フィールドを指定せず、API パス経由で同じ操作を試します。

パターン 5 — レート／スループットを基準とする「自動化されていることを証明する」チャレンジ： アプリによっては、CAPTCHA の「バイパス」を、人間が現実的に維持できる速度を超えることとして定義します。 たとえば「T 秒以内に N 件送信する」といった条件を、成功したリクエスト数ではなく、ルートに到達したリクエスト数を数えるミドルウェアで確認します。この場合、カウンターはリクエスト自体の検証に成功したかどうかに関係なく増えるため、無効な値やプレースホルダーのペイロードでも、有効な値と同じように条件を満たします。

タイミングに関する注意（スライディングウィンドウカウンター）：このテストは、1 件ずつ解決しないでください。リクエストを逐次的に送信する（各リクエストの間に数秒空ける）方法では、短いスライディングウィンドウ内に N 件を収めることは構造上できず、リクエストを逐次的に増やしても解決しません。よくある失敗例は、約 250 秒にわたって 12 件のリクエストを送信するケースです。条件は、20 秒以内に約 10 件のリクエストを必要とします。代わりにリクエストを並行して送信します（1 回のリクエスト呼び出しで "concurrency": N を指定するか、利用するツールが提供する並列リクエスト機能を使い、N を必要件数以上にします）。これによりリクエストが同時に到着し、スライディングウィンドウの条件を簡単に満たせます。まずエンドポイント固有の必須フィールド検証（たとえば null にできない rating フィールド）を確認し、CAPTCHA の回答など、ほかのフィールドが誤っていたり再利用されていたりしても、並行して送るペイロードがカウント用ミドルウェアに到達できる程度に正しい形式になっていることを確認します。

**自動テストで省略する項目：**実際の reCAPTCHA／hCaptcha をプログラムで解くには、OCR や音声バイパスのための外部サービスが必要です。パターン 1〜4 が失敗し、テスト予算に余裕がある場合に限り試してください。

**証拠：**有効な CAPTCHA トークンなしで完了した、状態を変更する操作（アカウントの作成、ログインの成功、フォームの送信）があれば、バイパスが確認できます。

このスキルにおける脆弱性の種類

1. クライアント側のみの CAPTCHA 検証

JavaScript が CAPTCHA を解くまで送信ボタンを非表示または無効にしますが、サーバーは CAPTCHA トークンを検証しません。直接 API を呼び出せば、UI の制限を完全に回避できます。

2. CAPTCHA がセッションまたは操作に紐付けられていない

ログイン用に解いたトークンが、登録エンドポイント（またはほかの任意のエンドポイント）で受け入れられます。サーバーは「本物の CAPTCHA の回答か」を検証しても、「この操作に対する正しい回答か」は検証しません。

3. 一度限りの使用が強制されていない

CAPTCHA トークン（特に reCAPTCHA v2）は、一度使用したら消費済みにする必要があります。検証後にサーバーがトークンを無効化しない場合、1 回人間が解いたトークンを何度ものリクエストで再利用できます。

4. CAPTCHA がリアクティブに追加される（N 回失敗した後のみ）

アプリによっては、ログインに 3～5 回失敗した後にのみ CAPTCHA が表示されます。そのしきい値に達するまでは CAPTCHA は必要ないため、攻撃者は試行のたびに状態をリセットすることで、アカウントごとに N-1 回の試行を無期限に行えます。

5. 静的または予測可能な CAPTCHA

数学 CAPTCHA（3 + 4 = ?）、単純な画像 CAPTCHA、または回答候補が限られたテキスト CAPTCHA は自動化できます。これらは Google/hCaptcha ではなく、独自の CAPTCHA 実装です。

影響の連鎖

CAPTCHA のバイパスのみ：中（レート制限された操作の自動化が可能になります）

CAPTCHA のバイパス + ログインエンドポイント = ブルートフォース攻撃のゲートが解除される → hunt-brute-force と連鎖 → 高／重大

CAPTCHA のバイパス + 登録エンドポイント = アカウントの大量作成 → 不正利用、スパム、リソースの枯渇

CAPTCHA のバイパス + パスワードリセット = トークンの大量発行 → hunt-forgot-password と連鎖

関連スキル

  • hunt-brute-force — CAPTCHA はレート制限の唯一のゲートであることが多く、バイパスするとブルートフォース攻撃が可能になります
  • hunt-forgot-password — リセットエンドポイントが CAPTCHA のみで保護されている場合があります
  • hunt-race-condition — CAPTCHA の検証ウィンドウを競合させます（トークンが無効化される前に送信します）

コメント

Markdown 対応