mcpField
C
caido-mode

caido-mode

github.com/caidoセキュリティ2852.7k 回インストール11 週間前に更新
リポジトリ

caido-mode について

Caido API を利用するコマンドラインスキルで、HTTP 履歴に基づくセキュリティテストとリクエストの引き継ぎを支援します。プロキシ経由の curl 検証、認証情報のスナップショット、名前付き Replay セッションを扱います。

主な機能

  1. 01HTTP 履歴の検索と確認
  2. 02認証情報付き curl 設定の出力
  3. 03Caido プロキシ経由の検証
  4. 04名前付き Replay セッションの作成
  5. 05複数インスタンスの認証情報管理

活用シーン

  1. 01履歴の認証済みリクエストでエンドポイントを検証
  2. 02テスト通信を Caido の履歴に記録
  3. 03Replay でリクエストを担当者に引き継ぐ
  4. 04設定済み Caido インスタンスを切り替える

インストール

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

$npx skills add https://github.com/caido/skills --skill caido-mode

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

.gitignore
caido-client.ts
package-lock.json
package.json
README.md
lib/
client.ts
graphql.ts
output.ts
types.ts
lib/commands/
findings.ts
info.ts
intercept.ts
management.ts
matchreplace.ts
replay.ts
requests.ts
test/
exportcurl.test.ts
matchreplace.test.ts
rawedit.test.ts

詳細

Caido Mode スキル

HTTP 履歴を活用したテスト向けの Caido API 用 CLI(公式の @caido/sdk-client 上に構築されています)です。ツールは ~/.claude/skills/caido-mode/caido-client.ts にあります。各コマンドは npx tsx caido-client.ts <command> で実行し、特に記載がない限り JSON を出力します。

操作方法(最初にお読みください)

2 つの異なるモードがあります。

  1. テスト → 必ず Caido 経由でプロキシされた curl を使用します。 履歴から認証済みの実際のリクエストを見つけ、認証情報を再利用可能な curl 設定ファイル(ヘッダーと Cookie を忠実に静的スナップショットとして保存したもの)にキャッシュしてから、curl -K auth.cfg "$BASE/path" でプローブします。すべてのトラフィックを Caido 経由にする必要があります(設定ファイルにプロキシが含まれているため)。これにより、すべてのリクエストが HTTP 履歴に記録されます。
  2. 引き継ぎ → リプレイセッションとコレクションを使用します。 リクエスト(または複数のリクエスト)をユーザーに引き継ぐ場合に限り、名前付きコレクション内に名前付きリプレイセッションとして作成します。

厳守するルール:

  • 大量のブルートフォース/ファジングを除き、すべて Caido 経由で実行します。 単一の対象リクエストを直接 curl してはいけません。必ず Caido プロキシ経由にします(生成された設定ファイルを使用するか、そうでない場合は -x <proxy> を追加します)。唯一の例外: ブルートフォース/ファジングツール(ffuf など)や、一度に100 件以上のリクエストを送る場合は Caido 経由でプロキシしないでください。HTTP 履歴が膨れ上がります。これらは直接実行し(-x を付けずに)、調査や引き継ぎのために、興味深い結果があれば Caido に取り込みます(プロキシ経由で再送信する/リプレイに昇格させる)。
  • テストには curl を使用します。 プローブのためにリプレイセッションを作成してはいけません。リプレイセッションは引き継ぎ専用です。
  • オペレーターにリクエストを見せるには、リプレイに送信します。 オペレーターに特定のリクエストを見せたい場合は、必ずそのリクエスト用の名前付きリプレイセッションを(複数ある場合は名前付きコレクション内に)作成します。これにより、オペレーターは Caido でリクエストを確認し、再実行できます。curl でテストしたリクエストは、リプレイに昇格させて初めてオペレーターが扱えるようになります(create-session <id> --name …、または作成したリクエストの場合は send-raw … --name …)。
  • 認証情報はファイルにキャッシュし、貼り直さないでください。 対象ごとに export-curl --config を一度だけ使用し、以降はその設定ファイルを参照します。すべてのコマンドに Cookie/JWT を出力したり、コンテキストに繰り返し貼り付けたりしないでください。
  • オペレーターに実行可能なコマンドを渡す場合は、完全に自己完結した curl コマンドにします(すべてのヘッダーをインラインで指定し、export-curl を使用します)。PoC や Caido の外部で実行するコマンドがこれに該当します。-K 設定ファイルは内部テスト専用です。curl -K /tmp/… の行をオペレーターに渡してはいけません。
  • リプレイセッション名は必須であり、セッションを編集するときは明示的に名前を指定する必要があります。
  • 複数リクエストを引き継ぐときはコレクションを使用し、セッション/コレクションは ID ではなく名前で参照します。

基本のワークフロー(デフォルトではこの手順を使用)

# 1. Find a base request that already has the auth/cookies you need.
npx tsx caido-client.ts search 'req.host.cont:"target.com" AND req.path.cont:"/api/user"' --compact
#    → 8431  200  GET target.com/api/user/me

# 2. ONCE per target: cache its auth into a reusable curl config.
npx tsx caido-client.ts export-curl 8431 --config
#    → writes /tmp/caido/target.com/auth.cfg — a FAITHFUL STATIC snapshot:
#      proxy + insecure + compressed + ALL the request's auth/identity headers
#      (cookies, Authorization, Origin/Referer, X-*, Sec-*, app-specific headers)
#      and prints BASE + the captured header list

# 3. Test with curl. -K carries the proxy + auth, so it goes through Caido into history.
BASE=https://target.com
curl -K /tmp/caido/target.com/auth.cfg "$BASE/api/user/999"                 # IDOR
curl -K /tmp/caido/target.com/auth.cfg -X POST "$BASE/api/profile" \
     -H 'Content-Type: application/json' --data-binary @/tmp/caido/target.com/body.json

手順 3 は自由に繰り返してください。コストが低く、すべて Caido 内で完結し、認証情報の大きなデータはファイル内に保持されます。 search 'req.host.cont:"target.com"' --compact でプローブが Caido に記録されたことを確認します。

パスを記載どおりに送信する

パストラバーサル/パス正規化(../、/..、/./、エンコードされたバリエーション)をテストする場合は、 curl --path-as-is を渡します。そうしないと、送信前に curl がクライアント側で ../ と /./ を折りたたむため、サーバーにペイロードが届かず、テストが気付かないまま成功してしまいます。パスはそのまま保持してください。

curl --path-as-is -K /tmp/caido/target.com/auth.cfg "$BASE/api/../../../etc/passwd"

(同様に、URL に curl に解釈させたくない [ ] { } が含まれている場合は、-g/--globoff を追加します。)

設定は忠実な静的スナップショットです(重要)

export-curl --config は、ベースリクエストの認証/ID ヘッダーをすべて取得し(厳選した一部ではありません)、Cookie を静的にインライン化します。どちらも、苦い経験から学んだうえで意図的に選択したものです。

  • 許可リストではなく、すべてのヘッダー。 最近のアプリは、予測できないアプリ固有のヘッダー(x-goog-ext-*、X-Browser-Validation、X-Client-Data、Origin、Referer、X-Same-Domain、Sec-*、…)に基づいて認可を制御しています。許可リストを絞ると、こうしたヘッダーが気付かないうちに除外され、不明瞭な 403/PERMISSION_DENIED が発生します。設定には、実際にリクエストを認可した内容が反映されます。除外するのは、真にリクエストごとに変わる、または揮発性のヘッダーだけです:Host、Content-Length、Content-Type、Connection、Accept-Encoding(これらは curl がリクエストごとに管理します)。
    • ⚠ Content-Type は除外されるため、すべての POST/PUT/PATCH で必ず自分で指定してください: curl -K auth.cfg -X POST "$BASE/path" -H 'Content-Type: application/json' --data-binary @body。エンドポイントが要求する正確な Content-Type を使ってください(例:Google の batchexecute では application/x-www-form-urlencoded;charset=UTF-8 が必要です)。誤った値や指定漏れは、400/403 のよくある原因です。curl が Content-Length を自動設定するため、追加しないでください。
  • 静的 Cookie。Cookie jar は使いません。 デフォルトでは cookie-jar を使わないため、curl がレスポンスでローテーションされた Set-Cookie を、取得済みの正常な Cookie に上書きすることはありません(Google のようなサーバーは、エラーレスポンスを含むすべてのレスポンスで Cookie をローテーションします。書き戻しを行う Cookie jar を使うと、セッションの状態が徐々に悪化して失敗します)。ローテーションに追従する必要がある場合は、export-curl <id> --config --cookie-jar で有効にします。

特定のヘッダーを除外するには、--exclude <name> を指定します(複数回指定可能)。Cookie を完全に省略するには(たとえば、Match & Replace ルールで認証情報を挿入する場合)、--exclude cookie を指定します。

その他の規約
  • ターゲットごとのスクラッチディレクトリ: /tmp/caido/<host>/ に auth.cfg、本文ファイル、メモを格納します。
  • $BASE: BASE=https://<host> を一度設定し、リクエストには "$BASE/path" を使います。
  • 本文はファイルに保存: 大きい本文や複雑な本文は一度保存し、--data-binary @body.json で送信します(--data-binary の正しい使い方は、バイト単位で正確な本文を送信することです)。設定には Content-Type が含まれないため、リクエストごとに -H 'Content-Type: …' を追加します。
  • 必要に応じた更新: スナップショットは静的です。そのため、リクエストが 401/403 を返すようになったら(トークンの期限切れ/Cookie の期限切れ)、export-curl <fresh-id> --config を再実行してスナップショットを更新してから、再試行します。
  • CSRF: 対応する X-CSRF*/ダブルサブミットヘッダーは自動的に取得されます。操作ごとにローテーションされるトークンの場合は、新しいものを取得します:T=$(curl -sK auth.cfg "$BASE/csrf" | jq -r .token)。
  • プロキシで認証情報を挿入する方法(代替案): 設定を使う代わりに、Match & Replace ルールでプロキシ経由のすべてのトラフィックに Authorization/Cookie を挿入できます。その場合、curl -x <proxy> -k "$BASE/path" にヘッダーは不要です。Match & Replace を参照してください。
ユーザーにコマンドを渡す

Caido 内でオペレーターにリクエストを提示するには、Replay に送信します(下記の「Replay セッション」を参照)。これがデフォルトです。このセクションでは別のケース、つまり実行可能なコマンド(PoC、または Caido の外で実行するもの)を渡す場合について説明します。その場合は、必ず完全に自己完結した curl コマンドを作成してください。すべてのヘッダーをインラインで指定し、-K は使いません:

npx tsx caido-client.ts export-curl 8431      # full curl, all headers inline (portable PoC)

ユーザーがどこでも実行できるポータブルな PoC にする場合は -x/-k を外し、ユーザー自身の Caido 経由で実行する想定の場合に限り残します。curl -K /tmp/... の行をユーザーに渡してはいけません。そのファイルはあなたのものです。


プロキシ

curl でのテストはすべて Caido のプロキシ経由で行う必要があります。アドレスのデフォルトは Caido の URLです(プロキシと API は同じアドレスを共有します)。必要に応じて、いつでも確認してください。

npx tsx caido-client.ts auth-status     # prints "proxy": "http://localhost:8080"

export-curl --config はプロキシを設定に埋め込みます(proxy = "…")。その場で curl を実行する場合は、-x <proxy> -k を自分で追加してください。プロキシのリスナーが API URL と異なる場合に限り、setup --proxy <addr> または export CAIDO_PROXY=<addr> でプロキシを上書きしてください。

プロキシは auth-status の proxy/activeUrl フィールドから取得してください。**secrets.json を直接解析しないでください。**認証情報は現在 URL をキーとしており、アドレスは .caido.url ではなく .caido.default/.caido.instances に保存されています。


認証の設定

# One-time: create a PAT in Caido (Dashboard → Developer → Personal Access Tokens), then:
npx tsx caido-client.ts setup <your-pat>
npx tsx caido-client.ts setup <pat> http://192.168.1.100:8080            # non-default instance
npx tsx caido-client.ts setup <pat> http://localhost:8080 --proxy http://localhost:8080

# Or env vars
export CAIDO_PAT=caido_xxxxx
export CAIDO_URL=http://localhost:8080
export CAIDO_PROXY=http://localhost:8080   # only if the proxy differs from the URL

npx tsx caido-client.ts auth-status        # check (also prints the proxy)
npx tsx caido-client.ts health             # verify instance is up

setup は SDK のデバイスコードフローを介して PAT を検証し(PAT によって自動承認されます)、PAT とアクセストークン(およびプロキシ)を ~/.claude/config/secrets.json にキャッシュします。次回以降の実行ではキャッシュされたトークンが使われます。有効なキャッシュ済みトークンがあれば、PAT がなくても動作します。

複数の Caido インスタンス

認証情報はインスタンス URL をキーとして保存されるため、1 台のマシン上の 2 つのインスタンスが互いの情報を上書きすることはありません。setup <pat> <url> は、そのインスタンスを URL の下に保存し、アクティブなデフォルトに設定します。2 つ目の URL を設定すると、最初のエントリを上書きせずに、2 つ目のエントリが追加されます。

npx tsx caido-client.ts setup <pat-a> http://localhost:8080
npx tsx caido-client.ts setup <pat-b> http://localhost:8081     # added, not overwritten
npx tsx caido-client.ts auth-status                              # lists configuredInstances + activeUrl

アクティブなインスタンスは、CAIDO_URL 環境変数 → 保存済みのデフォルト → http://localhost:8080 の順で決まります。CAIDO_URL を使ってシェル/エージェントごとに選択してください(共有の「現在のインスタンス」を奪い合わないため、並行実行にも安全です)。例:CAIDO_URL=http://localhost:8081 npx tsx caido-client.ts recent。CAIDO_PAT/CAIDO_PROXY 環境変数は、アクティブなインスタンスの保存済みの値を上書きします。


HTTP 履歴の検索(HTTPQL)

npx tsx caido-client.ts search 'req.method.eq:"POST" AND resp.code.eq:200' --compact
npx tsx caido-client.ts search 'req.host.cont:"api"' --limit 50
npx tsx caido-client.ts search 'req.host.cont:"api"' --asc --limit 50   # oldest first (rarely wanted)
npx tsx caido-client.ts recent --compact            # newest requests, one line each
npx tsx caido-client.ts get 8431 --compact          # full details (JSON) when you need them
npx tsx caido-client.ts get-response 8431 --compact
npx tsx caido-client.ts raw 8431 --out /tmp/caido/target.com/body.json   # dump bytes (e.g. a body)
  • search はデフォルトで新しい順です(リクエスト ID の降順)。そのため、--limit N は一致した結果のうち最新の N 件を返します。古い順が必要な場合に限り、--asc(エイリアスは --oldest)を指定してください。
  • **「条件に一致する最新の X」を取得するには、search '<filter>' --limit N を実行するだけで十分です。**大きな --limit で取得してから、クライアント側で並べ替える方法(例:jq 'sort_by(.createdAt) | reverse')は使わないでください。取得した範囲内でしか並べ替えられないため、N 件目より新しいリクエストが見えないままになり、古いトラフィックを最新と誤認することになります。並べ替えは Caido に任せてください。
  • recent は常に新しい順ですが、フィルターは指定できません。フィルターに一致する最新の結果を取得するには、search --limit N を使ってください。
  • --compact → リクエスト 1 件につき簡潔な 1 行を表示します(id status METHOD host/path)。
  • 閲覧には search/recent --compact を使い、対象を選んだら get/export-curl を使ってください。

クエリ言語の全容については、以下のHTTPQL リファレンスを参照してください。


リプレイセッション — 引き継ぎ専用

リクエストをユーザーに渡す場合に使います。通常のテストではセッションではなく、(上記の)curl を使ってください。生のリクエストから作成したセッションでは、ヘッダーの行末が自動的に CRLF に正規化されます。引き継ぎ用セッションが単独の LF(\n)で作成されることはありません。

# Create a NAMED session from a history request (name is REQUIRED).
npx tsx caido-client.ts create-session 8431 --name "IDOR /api/user/:id"
npx tsx caido-client.ts sessions                                   # list (alias: replay-sessions)
npx tsx caido-client.ts rename-session "IDOR /api/user/:id" "IDOR - confirmed"
npx tsx caido-client.ts move-session "IDOR - confirmed" "Vuln chain - IDOR to ATO"

# Build a handoff session from a raw request file (CRLF auto-normalized):
npx tsx caido-client.ts send-raw --host target.com --raw @/tmp/req.txt --name "crafted repro"
セッションの編集時は名前の扱いを指定する必要があります

ユーザーから Replay 内でテストするよう依頼された場合は、edit/edit-session を使ってください。編集によってセッションの内容が変わるため、名前をどうするかを指定してください。次のいずれか一方を必ず渡します:--no-name-change(--nonach)または --new-name "<name>"。

npx tsx caido-client.ts edit 8431 --path /api/user/999 --name "IDOR victim 999"        # new session
npx tsx caido-client.ts edit-session "IDOR victim 999" --body '{"role":"admin"}' --nonach --compact
npx tsx caido-client.ts edit 8431 --path /api/admin --session "IDOR victim 999" --new-name "priv-esc"

edit は元のリクエストの Cookie/認証情報を保持します。--method、--path、--set-header、--remove-header、--body(Content-Length を自動設定)、--replace <from>:::<to>、接続の上書き設定(--sni、--connect-host、…)に対応しています。

既存のリプレイタブを確認する

Caido ですでにリプレイタブが開いており、その現在の状態をもとに作業したい場合は、再作成する必要はありません。名前または ID で検索してください。

npx tsx caido-client.ts get-session "IDOR victim 999" --compact      # session + its active entry
npx tsx caido-client.ts replay-entries "IDOR victim 999" --limit 20  # request/response history in the tab
npx tsx caido-client.ts replay-entries "IDOR victim 999" --raw --compact   # include raw bytes

session-entries は replay-entries のエイリアスです。タブの内容を読み取るにはこれらを使い、タブに変更したリクエストを送るには上記の edit-session を使ってください。


コレクション — 積極的に活用する

コレクションは、引き継ぎ用にセッションを整理します。セッションを作成する前に、既存のコレクションを一覧表示し、どこに属するかを判断してください。 名前は必須で、コレクションが自動作成されることはありません。

npx tsx caido-client.ts collections                         # query first
npx tsx caido-client.ts create-collection "Swagger - petstore.yaml"
npx tsx caido-client.ts rename-collection "old name" "new name"
状況コレクションの判断
ユーザー向けに1 件のリクエストを再現するデフォルトのコレクションを使用します — コレクションは作成しないでください。セッションに名前を付け、その名前をユーザーに伝えます。
JS ファイル内のエンドポイントごとに再生タブを作成する新しいコレクション JS File Endpoints を作成します。
Swagger 仕様内のエンドポイントごとに再生タブを作成する新しいコレクション Swagger - <filename> を作成します。
脆弱性向けの複数リクエストのチェーン新しいコレクション Vuln chain - <description> を作成し、各ステップに 1. …、2. … のように名前を付けます。
/api/v2 配下のすべてのエンドポイント新しいコレクション /api/v2/* を作成します。

コレクションは名前で指定します。CLI が解決し、存在しない場合は先に作成するよう案内します。

npx tsx caido-client.ts create-session 8431 --name "1. login" --collection "Vuln chain - IDOR to ATO"

報告する際は、コレクション名とセッション名を記載し、ID は使わないでください。


Match & Replace — トラフィックを自動的に書き換える

Match & Replace(Caido 内部では 「Tamper」ルールと呼ばれます)は、リクエストやレスポンスが Caido を通過する際に自動的に書き換えます。特に便利な用途は、プロキシで認証情報を挿入することです。これにより、curl コマンドに認証情報を含めずに済みます。すべてのプロキシリクエストに Authorization を設定するルールを追加すれば、curl -x <proxy> -k "$BASE/path" は -K やヘッダーを指定しなくても認証されます。

ルールは、1 つのセクション(対象部分)× 1 つの操作× 1 つのマッチャー× 1 つの置換方法で構成され、任意で条件(HTTPQL の範囲)とソースを指定できます。

要素選択肢
sectionreq: req-method req-path req-query req-body req-first-line req-header req-all req-sni · resp: resp-body resp-status resp-first-line resp-header resp-all · ws: ws-up ws-down
operationraw(セクション内を照合)· update/add/remove(ヘッダーとクエリのみ。名前で指定)· メソッド/ステータスには update のみ
matcher--match-value <str> · --match-regex <re> · --match-full(セクション全体)· --match-name <n>(ヘッダー/クエリの update/add/remove)
replacer--replace <term>(リテラル。"" も指定可能)· --workflow <id>(ワークフローを実行)
condition--condition '<httpql>' — リクエストが条件に一致する場合のみ適用します(例:特定のホスト)
sources--sources INTERCEPT,REPLAY,… — 適用対象のトラフィック

注意点は 4 つあります。いずれもデフォルトで設定されています。

  • 新しいルールは無効状態で作成されます。 toggle-mr-rule <id> --on で有効にします。
  • デフォルトのコレクションは Caido の「Default Collection」です(--collection <name|id> で変更できます)。
  • デフォルトのソースは INTERCEPT(プロキシトラフィック)で、Caido の設定と一致します。適用範囲を広げるには --sources を追加します。
  • JS の対象 — 照合対象に合わせてマッチャーを選びます。 安定したリテラル(文字列定数、JSON キー、固定された API パス)には --match-value を使用できます。圧縮された識別子の近くを照合する場合は --match-regex を使用してください。シンボル名はバンドルのデプロイごとに変わるため(例:_.ex → _.Ww)、リテラルルールはエラーを出さずに照合されなくなります。圧縮された識別子自体ではなく、周囲の文字列リテラル、既知の関数名、固定された JSON キーなど、構造的に安定した要素を基準に正規表現を指定してください。

確定前にプレビュー: test-mr-rule はルールを未加工のリクエストに適用しますが、何も作成しません。ルールが意図どおりに動作するか確認するために使用してください。

# Preview: would this add the header correctly?
npx tsx caido-client.ts test-mr-rule --section req-header --operation add \
  --match-name X-Test --replace hi --raw 'GET / HTTP/1.1\r\nHost: t.com\r\n\r\n'

# Inject auth on all proxied requests to one host (then enable it)
ID=$(npx tsx caido-client.ts create-mr-rule --section req-header --operation add \
  --match-name Authorization --replace "Bearer eyJ…" \
  --condition 'req.host.eq:"target.com"' --name "auth inject" | jq -r '.created.id')
npx tsx caido-client.ts toggle-mr-rule "$ID" --on

# Other patterns
npx tsx caido-client.ts create-mr-rule --section req-header --operation remove \
  --match-name If-None-Match --sources REPLAY --name "drop INM"           # strip a header
npx tsx caido-client.ts create-mr-rule --section req-body --match-regex '"admin":false' \
  --replace '"admin":true' --name "force admin"                            # body regex
npx tsx caido-client.ts create-mr-rule --section resp-status --replace 403 --name "fake 403"  # response

npx tsx caido-client.ts mr-rules                # list rules (+ enabled state)
npx tsx caido-client.ts toggle-mr-rule <id> --off
npx tsx caido-client.ts delete-mr-rule <id>

mr-collections、create-mr-collection、rename-mr-collection、delete-mr-collection でコレクションを管理します。move-mr-rule <id> <collection> でルールを移動します。update-mr-rule <id> … でルールを再設定します(作成時と同じフラグを使用)。rename-mr-rule <id> <name> でルール名を変更します。


出力制御(get、get-response、replay、edit、send-raw、edit-session で動作)

フラグ説明
--max-body <n>レスポンス本文の最大行数(デフォルトは 200、0 = 無制限)
--max-body-chars <n>本文の最大文字数(デフォルトは 5000、0 = 無制限)
--no-request出力から生リクエストを省略します
--headers-onlyヘッダーのみを表示し、本文は表示しません
--compact短縮形:--no-request --max-body 50 --max-body-chars 5000

HTTPQL リファレンス

HTTP 履歴を検索するための Caido のクエリ言語です。

重要:文字列値は必ず引用符で囲んでください。整数は引用符で囲みません。

重要:HTTPQL に NOT 演算子はありません。代わりに否定形の演算子を使用してください:

  • ncont(含まない)、nlike、nregex、ne(等しくない)
  • 誤り:NOT req.path.cont:"/admin" — 正しい:req.path.ncont:"/admin"
名前空間とフィールド
名前空間フィールド型説明
reqextstringファイル拡張子(. を含む)
reqhoststringホスト名
reqmethodstringHTTP メソッド(大文字)
reqpathstringURL パス
reqquerystringクエリ文字列
reqrawstring生のリクエスト全体
reqportintポート番号
reqlenintリクエスト本文の長さ
reqcreated_atdate作成日時
reqtlsboolHTTPS かどうか
resprawstring生のレスポンス全体
respcodeintステータスコード
resplenintレスポンス本文の長さ
resproundtripint往復時間(ms)
rowidintリクエスト ID
source-special"intercept"、"replay"、"automate"、"workflow"
preset-specialフィルタープリセットの参照
演算子
  • 文字列: eq、ne、cont、ncont、like、nlike、regex、nregex
  • 整数: eq、ne、gt、gte、lt、lte
  • ブール値: eq、ne
  • 論理: AND、OR、グループ化のための括弧
例
req.method.eq:"POST" AND resp.code.eq:200       # POSTs with 200s
req.host.cont:"api" OR req.path.cont:"/api/"    # API traffic
"password" OR "secret" OR "api_key"             # bare string searches req AND resp raw
resp.code.gte:400 AND resp.code.lt:500          # 4xx
resp.len.gt:100000                              # large responses (data exposure)
req.path.regex:"/(login|auth|signin|oauth)/"    # auth endpoints
source:"replay" OR source:"intercept"           # tool-generated vs proxied traffic
req.created_at.gt:"2024-01-01T00:00:00Z"        # date filter
req.path.ncont:"/static"                        # exclude (no NOT keyword)
preset:"My Filter"                              # saved filter preset

その他の機能(参考)

検出結果 — Caido の Findings タブに表示
npx tsx caido-client.ts findings --limit 50
npx tsx caido-client.ts create-finding 8431 --title "IDOR on /api/user/:id" \
  --description "Reads other users' profiles by changing id" --reporter "rez0" --dedupe-key "idor-user"
npx tsx caido-client.ts update-finding <id> --title "…" --description "…"
スコープ/フィルタープリセット/環境
npx tsx caido-client.ts create-scope "Target" --allow "*.target.com" --deny "*.cdn.target.com"
npx tsx caido-client.ts create-filter "API 4xx" --query 'req.path.cont:"/api/" AND resp.code.gte:400' --alias "api4xx"
npx tsx caido-client.ts search 'preset:"API 4xx"' --compact
npx tsx caido-client.ts create-env "IDOR-Test"; npx tsx caido-client.ts env-set <env-id> victim_id "user_999"
ファジング/インターセプト/プロジェクト/タスク/情報
npx tsx caido-client.ts create-automate-session 8431   # configure payloads in UI, then: fuzz <session-id>
npx tsx caido-client.ts intercept-status | intercept-enable | intercept-disable
npx tsx caido-client.ts projects ; npx tsx caido-client.ts viewer ; npx tsx caido-client.ts plugins

コマンドの完全なリファレンス

すべてのコマンドを実行するには、npx tsx caido-client.ts <command> を使います。セッション/コレクションは名前または IDで指定でき、特記がない限り出力は JSON です。フラグの一覧は --help を実行してください。

コマンド機能
履歴とテスト
search <httpql>履歴を検索します。新しい順です。--limit --after --ids-only --asc/--oldest --compact
recent新しいリクエストを表示します。--limit --compact
get <id> / get-response <id>リクエスト全体/レスポンスのみを取得します(出力制御フラグあり)。
raw <id>バイト単位で正確な未加工リクエストを出力します。--out <file> --response
export-curl <id>ユーザー向けの、完全に自己完結した curl を出力します。
export-curl <id> --config再利用可能な -K 設定ファイルです。すべての認証ヘッダーとインライン Cookie を忠実に含む静的スナップショットです(内部向け)。--out <file> · --cookie-jar(ローテーションを追跡) · --exclude <h>
送信/編集
replay <id> --name <n>新しい名前付きセッションにリプレイします。--raw --collection と接続のオーバーライドを指定できます。
send-raw --host <h> --raw <s|@file|-> --name <n>新しい名前付きセッションを使って未加工リクエストを送信します。--port --tls/--no-tls --collection
edit <id>リプレイに編集内容を送信します。--method --path --set-header --remove-header --body --replace --session --name/--new-name/--nonach --collection
edit-session <name|id>セッションのアクティブなエントリを編集して送信します(--nonach または --new-name が必要です)。
リプレイタブの検索
get-session <name|id>セッションとアクティブなエントリを取得します。--compact
replay-entries <name|id>タブ内のリクエスト履歴を取得します(別名 session-entries)。--limit --raw
セッション
create-session <id> --name <n>リクエストから新しい名前付きセッションを作成します。--collection
rename-session <name|id> <new> · move-session <s> <collection>名前変更/移動
sessions(別名 replay-sessions) · delete-sessions <id,id,…>一覧表示/削除
コレクション
collections(別名 replay-collections)コレクションを一覧表示します。
create-collection <name> · rename-collection <c> <new> · delete-collection <name|id>作成/名前変更/削除
ファジングcreate-automate-session <id> · fuzz <session-id>(ペイロードは UI で設定)
検出結果findings · get-finding <id> · create-finding <id> --title … · update-finding <id>
スコープscopes · create-scope <name> --allow --deny · update-scope <id> · delete-scope <id>
フィルターfilters · create-filter <name> --query [--alias] · update-filter <id> · delete-filter <id>
環境envs · create-env <name> · env-set <env> <var> <val> · select-env [id] · delete-env <id>
プロジェクトprojects · select-project <id>
タスクtasks · cancel-task <id>
ホストされたファイルhosted-files · delete-hosted-file <id>
インターセプトintercept-status · intercept-enable · intercept-disable
マッチと置換mr-rules · mr-collections · create-mr-rule --section … [--operation] [--match-*] [--replace/--workflow] [--name --collection --condition --sources] · test-mr-rule --raw … --section …(プレビュー。変更は行いません) · toggle-mr-rule <id> --on|--off · rename-mr-rule <id> <n> · move-mr-rule <id> <coll> · update-mr-rule <id> … · delete-mr-rule <id> · create-mr-collection <n> · rename-mr-collection <c> <n> · delete-mr-collection <c>
情報/認証viewer · plugins · health · setup <pat> [url] [--proxy] · auth-status

アーキテクチャ

@caido/sdk-client v0.2.0+ を基盤としています。生の fetch は使用せず、高レベルの SDK メソッドと、SDK で公開されていない一部の機能に対する gql ドキュメントを使った client.graphql.query/mutation を使用します。

caido-client.ts          # CLI entry — arg parsing + dispatch
lib/
  client.ts              # SDK Client singleton, SecretsTokenCache, auth, resolveProxy
  graphql.ts             # gql docs for features not in the SDK
  output.ts              # raw formatting (truncation, headers-only, raw→curl)
  types.ts               # OutputOpts
  commands/
    requests.ts          # search, recent, get, get-response, raw, export-curl (+ --config)
    replay.ts            # replay, send-raw, edit, sessions, collections (CRLF-normalized), automate
    findings.ts          # findings
    management.ts        # scopes, filters, environments, projects, hosted-files, tasks
    intercept.ts         # intercept status/enable/disable
    matchreplace.ts      # match & replace (tamper) rules — buildTamperSection + commands
    info.ts              # viewer, plugins, health, setup, auth-status

Claude への指示(チェックリスト)

  1. curl でのテストは、必ず Caido 経由で行います — プロキシを経路に含めてください(設定に含まれています。そうでない場合は -x <proxy> を指定します)。例外:ブルートフォース/ファジング(ffuf)、または一度に 100 件以上のリクエストを送る場合は、HTTP 履歴が肥大化しないように直接送信し、興味深い結果は Caido に取り込みます。
  2. 認証情報を一度だけキャッシュします: export-curl <id> --config → /tmp/caido/<host>/auth.cfg(すべての認証ヘッダーとインライン Cookie を忠実に保存した静的スナップショットです)。curl -K auth.cfg "$BASE/path" でテストします。
  3. 必要なときだけ更新します — 401/403/ログインへのリダイレクトが発生した場合にのみ、新しいリクエストから設定を再生成します。
  4. 自己完結した完全な curl をユーザーに提示します(export-curl <id>)。-K の行は提示しないでください。
  5. **--compact で閲覧し、**作業に使うリクエストだけを get/export-curl します。
  6. オペレーターにリクエストを見せるには、Replay に送信します(名前付きセッション)。Replay は引き渡し専用です。名前は必須で、コレクションは頻繁に使用し、名前で参照します。
  7. セッションの編集には --nonach または --new-name が必要です。
  8. 実際の問題については、必ず所見を作成します。
  9. HTTPQL では絶対に NOT を使わないでください — ne/ncont/nlike/nregex を使います。

運用上の注意(シェルでの落とし穴)

  • CLI 呼び出しを while/for ループ内でまとめて実行しないでください。 シェルによっては、ループ内のサブシェルで PATH が削除されるため、head/python3 などが「command not found」になり、ループ本体がエラーを表示せずに失敗します(セッションが作成されなかったように見えます)。各 send-raw/create-session を個別のトップレベルコマンドとして実行するか、export PATH=… を明示した単独の bash スクリプトとして実行してください。
  • search --ids-only が返すのは、単独の ID ではなく JSON 配列です(["123"])。再利用する前に、たとえば ID=$(… --ids-only | jq -r '.[0]') のように配列から値を取り出してください。
  • sessions/collections は現在、すべての項目を一覧表示します(最初のページだけではなく、ページネーションされます)。そのため、新しく作成した項目も必ず表示されます。短い一覧が必要な場合は、--limit N で件数を制限できます。

エラー処理

  • 認証エラー → auth-status を実行し、setup <pat> を再実行します(または CAIDO_PAT を設定します)。
  • curl が 401/403/ログインへのリダイレクトを受け取る → トークンの有効期限が切れています。新しいリクエストから設定を更新してください。
  • curl がプロキシ経由で接続できない → auth-status でプロキシを確認してください。Caido が起動している必要があります。
  • 接続が拒否される/準備ができていない → Caido が起動していないか、起動中です。health を確認してください。

コメント