【保存版】バグバウンティ実践者のための curl ― 偵察からPoC構築まで

Posted at 2026-03-18

はじめに

バグバウンティや脆弱性診断の現場では、Burp Suite が主力ツールとして広く使われています。
一方で、curl だけでも実務で使えることは想像以上に多いです。

ターゲットの技術スタックを数秒で把握する
認証フローを再現してセッションを操作する
IDOR・SSRF・CORS misconfiguration の初期検証を素早く行う
レスポンスの差分から権限の境界を特定する
再現性のある PoC をそのままレポートに貼る

複雑な UI フローやブラウザ依存の挙動確認は Burp やブラウザ開発者ツールのほうが向いていますが、多くのケースでは curl のワンライナーだけでも十分に初動調査や PoC 構築が可能です。
シェルスクリプトとの親和性が高く、再現性のある PoC をそのままレポートに貼れるのも大きな利点です。

にもかかわらず、日本語では curl をバグバウンティ文脈で体系的に整理した記事はまだ多くありません。この記事では、バウンティの各フェーズで実際に使える curl テクニックを、注意点も含めて整理していきます。

想定読者: curl の基本操作は知っている方。バグバウンティや脆弱性診断で curl の引き出しを増やしたい方。

免責事項: この記事は、バグバウンティや正規の脆弱性診断における技術的な知識共有を目的としています。記載されているテクニックは、必ず対象プログラムの規約・スコープの範囲内で使用してください。許可のないシステムに対する無断テストは、不正アクセス禁止法等に抵触する可能性があります。本記事の内容を悪用したことによる一切の責任は負いかねます。

1. 偵察フェーズでの curl

偵察 (Recon) の目的は、ターゲットの技術スタック・構成・攻撃面を把握することです。curl を使えば、ブラウザを開かずにターミナルから素早く情報を引き出せます。

1-1. レスポンスヘッダーから技術スタックを読む

# HEAD リクエストでヘッダーだけ取得（本文はダウンロードしない）
curl -sI https://target.example.com

注目すべきヘッダーはこのあたりです。

ヘッダー	わかること	例
`Server`	Webサーバーの種類・バージョン	`nginx/1.24.0`, `Apache/2.4.58`
`X-Powered-By`	バックエンドの言語/FW	`Express`, `PHP/8.2.0`, `ASP.NET`
`X-AspNet-Version`	.NET のバージョン	`4.0.30319`
`X-Generator`	CMS の特定	`WordPress 6.4`, `Drupal 10`
`Set-Cookie`	セッション管理の設定	フラグの有無を確認（後述）

バウンティ的ポイント: バージョン情報が露出していれば、CVE データベースと突合して既知の脆弱性を探せます。ただし X-Powered-By の露出だけでは、ほとんどのプログラムで Informative（報酬対象外）になります。具体的な CVE と組み合わせて攻撃パスを示せるかどうかが勝負です。

1-2. Cookie のセキュリティフラグを確認する

# Set-Cookie ヘッダーだけ抽出
curl -sI https://target.example.com | grep -i set-cookie

チェックポイントはこちらです。

フラグ	意味	欠落時のリスク
`HttpOnly`	JavaScript から Cookie にアクセス不可	XSS 時のセッション窃取リスク増大
`Secure`	HTTPS でのみ送信	平文通信時の漏洩リスク増大
`SameSite=Strict/Lax`	クロスサイト送信を制限	CSRF リスク増大

ただし、Cookie 属性の不備も単独では Informative 扱いになるケースが多く、実際には XSS や CSRF の成立条件と組み合わせて評価されます。

1-3. セキュリティヘッダーの監査

# セキュリティ関連ヘッダーを一括確認
curl -sI https://target.example.com | grep -iE \
  '(strict-transport|content-security-policy|x-frame-options|x-content-type|referrer-policy|permissions-policy)'

注目しやすいヘッダーは次のようなものです。

Strict-Transport-Security
Content-Security-Policy
X-Frame-Options
X-Content-Type-Options
Referrer-Policy
Permissions-Policy

セキュリティヘッダーの欠落は、単体では Informative 扱いになることが多いです。
ただし、クリックジャッキングの成立や MIME sniffing 起因の実害など、具体的な攻撃シナリオと結びつく場合は報告価値が上がります。

1-4. リダイレクトチェーンの追跡

# リダイレクトを追従しつつ、各ステップのヘッダーを表示
curl -sIL https://target.example.com 2>&1 | grep -iE '(HTTP/|location:)'

出力例:

HTTP/2 301
location: https://www.target.example.com/
HTTP/2 302
location: https://www.target.example.com/en/
HTTP/2 200

バウンティ的ポイント: リダイレクト先に外部ドメインへの遷移がないか、HTTP→HTTPS のリダイレクトが正しく行われているかを確認しましょう。ここからオープンリダイレクトの兆候が見つかることもあります。

1-5. robots.txt と security.txt

# 管理画面や非公開パスの手がかりを取得
curl -s https://target.example.com/robots.txt

# セキュリティ連絡先・ポリシーの確認
curl -s https://target.example.com/.well-known/security.txt

robots.txt には、クロール対象外にしたいパスや管理系パスの手がかりが含まれていることがあります。
ただし、robots.txt の内容だけで脆弱性になるわけではなく、あくまで追加確認の出発点として扱うのが基本です。

1-6. TLS/証明書情報の取得

# TLS ハンドシェイクの詳細（証明書チェーン、プロトコル、暗号スイート）
curl -vI https://target.example.com 2>&1 | grep -iE '(subject:|issuer:|expire|SSL connection|TLSv)'

証明書の SAN (Subject Alternative Name) フィールドから、サブドメインが判明することもあります。

# 証明書の SAN からサブドメインを抽出
curl -vI https://target.example.com 2>&1 | grep -i "subject alternative"

2. 認証・セッション操作

バウンティでは「認証済みの状態でリクエストを送る」場面がとても多いです。curl で認証フローを再現できれば、テストの自動化がかなり楽になります。

2-1. Cookie の保存と再利用

# ログインして Cookie をファイルに保存
curl -s -c cookies.txt \
  -d "username=testuser&password=testpass" \
  https://target.example.com/login

# 保存した Cookie を使って認証済みリクエスト
curl -s -b cookies.txt https://target.example.com/dashboard

-c cookies.txt : レスポンスの Set-Cookie をファイルに保存
-b cookies.txt : リクエスト時にファイルから Cookie を送信

2-2. Bearer Token / API Key

# Bearer Token
curl -s -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs..." \
  https://target.example.com/api/v1/me

# API Key（ヘッダー方式）
curl -s -H "X-API-Key: your-api-key-here" \
  https://target.example.com/api/v1/users

2-3. Basic 認証

curl -s -u "admin:password123" https://target.example.com/admin/
# 内部的に Authorization: Basic YWRtaW46cGFzc3dvcmQxMjM= が送信されます

2-4. CSRF トークンの取得→送信ワンライナー

多くのアプリケーションは CSRF トークンをフォームに埋め込んでいます。これを取得して次のリクエストに含めるワンライナーがこちらです。

# 1. ページから CSRF トークンを抽出  2. そのトークンを使って POST
TOKEN=$(curl -s -c cookies.txt https://target.example.com/settings \
  | grep -oP 'name="csrf_token" value="\K[^"]+')

curl -s -b cookies.txt \
  -d "csrf_token=${TOKEN}&email=newemail@example.com" \
  https://target.example.com/settings/update

2-5. 複数アカウントの切り替え

IDOR テストでは 2 つのアカウントを行き来します。Cookie ファイルを分けるだけで簡単に切り替えられます。

# アカウント A でログイン
curl -s -c cookies_a.txt -d "username=user_a&password=pass_a" https://target.example.com/login

# アカウント B でログイン
curl -s -c cookies_b.txt -d "username=user_b&password=pass_b" https://target.example.com/login

# アカウント A の認証でアカウント B のリソースにアクセス試行
curl -s -b cookies_a.txt https://target.example.com/api/users/USER_B_ID/profile

バウンティ的ポイント: 必ず自分が所有する 2 アカウント間だけでテストしてください。他人のアカウントには絶対にアクセスしないこと。これは鉄則です。

3. リクエスト改変テクニック

脆弱性テストの核心は「正規のリクエストを改変して、想定外の挙動を引き出す」ことです。curl はリクエストの要素を細かく操作できます。

3-1. HTTP メソッドの切り替え

# DELETE メソッドを自分のリソースに対して試行
curl -s -X DELETE \
  -H "Authorization: Bearer <token>" \
  https://target.example.com/api/v1/posts/MY_POST_ID

# PUT で上書き
curl -s -X PUT \
  -H "Content-Type: application/json" \
  -d '{"role": "admin"}' \
  https://target.example.com/api/v1/users/me

# PATCH で部分更新
curl -s -X PATCH \
  -H "Content-Type: application/json" \
  -d '{"is_admin": true}' \
  https://target.example.com/api/v1/users/me

バウンティ的ポイント: まずは自分のリソースに対して PUT/DELETE/PATCH を試し、本来 GET のみのはずのエンドポイントがそれらを受け付けるか確認します。405 以外が返ってきたら、自分の 2 アカウント間でクロスアカウントの検証に進みましょう。他人のリソースに対して直接試すのは NG です。

3-2. Content-Type の偽装

# JSON を期待するエンドポイントに Form データで送信
curl -s -X POST \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "username=admin&role=admin" \
  https://target.example.com/api/v1/users

# 逆に Form を期待するところに JSON で送信
curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"username": "admin", "role": "admin"}' \
  https://target.example.com/api/v1/users

# XML で送信（XML パーサー差異の観測）
curl -s -X POST \
  -H "Content-Type: application/xml" \
  -d '<?xml version="1.0"?><user><name>test</name></user>' \
  https://target.example.com/api/v1/users

サーバー側のパーサーが Content-Type に応じて処理を切り替えている場合、意図しないパーサーが発動して入力検証をバイパスできることがあります。

3-3. カスタムヘッダー注入

# 上流ヘッダーの扱いを観察
curl -s -H "X-Forwarded-For: 127.0.0.1" https://target.example.com/admin/
curl -s -H "X-Original-URL: /admin/" https://target.example.com/anything

これらは主に、リバースプロキシやアプリケーションが上流ヘッダーを誤って信頼している構成で意味を持ちます。すべての環境で有効な手法ではありません。

バウンティ的ポイント: 403 が返されるパスや、プロキシ配下と思われるエンドポイントに対して試す価値があります。

3-4. リクエストボディの操作

# -d: URL エンコードされたデータ（改行は除去される）
curl -s -X POST -d "key=value&key2=value2" https://target.example.com/api

# --data-raw: エスケープなしで生データを送信
curl -s -X POST --data-raw '{"key": "value with special chars: @&="}' \
  -H "Content-Type: application/json" \
  https://target.example.com/api

# --data-binary: バイナリデータをそのまま送信（改行も保持）
curl -s -X POST --data-binary @payload.bin \
  -H "Content-Type: application/octet-stream" \
  https://target.example.com/upload

# --data-urlencode: 値を自動 URL エンコード
curl -s -G --data-urlencode "search=<script>alert(1)</script>" \
  https://target.example.com/search

3-5. ファイルアップロード

# マルチパートでファイルアップロード
curl -s -X POST \
  -F "file=@sample.jpg;type=image/jpeg" \
  -F "description=profile photo" \
  https://target.example.com/api/upload

# ファイル名を偽装
curl -s -X POST \
  -F "file=@sample.txt;filename=innocent.jpg" \
  https://target.example.com/api/upload

バウンティ的ポイント: Content-Type とファイル名・拡張子の扱いがサーバー側でどのように評価されるかを観察します。実行可能形式や危険なファイルをアップロードするテストは、プログラムのルールで明示的に許可されている場合を除き避けてください。

4. 脆弱性テスト別 curl レシピ

ここからは、脆弱性タイプごとに curl でどう初期検証するかを具体的に整理します。

4-1. IDOR (Insecure Direct Object Reference)

リソースの識別子（ID）を差し替えることで、本来アクセスできないはずの他ユーザーのデータにアクセスできてしまう脆弱性です。

自分が所有する 2 アカウント（A と B）を使って検証します。

# アカウント A のプロフィール（自分の ID: 1001）
curl -s -b cookies_a.txt https://target.example.com/api/users/1001/profile | jq .

# アカウント A の認証で、自分のもう一つのアカウント B（ID: 1002）にアクセス試行
curl -s -b cookies_a.txt https://target.example.com/api/users/1002/profile | jq .

レスポンス比較で検証しましょう。

# 2 つのレスポンスを保存して diff
curl -s -b cookies_a.txt https://target.example.com/api/users/1001/profile > resp_own.json
curl -s -b cookies_a.txt https://target.example.com/api/users/1002/profile > resp_other.json
diff resp_own.json resp_other.json

アカウント A の認証でアカウント B の情報が取得できてしまえば IDOR の可能性があります。検証は必ず自分の 2 アカウント間だけで行ってください。

小さな範囲での確認例:

# 自分の 2 アカウントで作成したリソースの前後数件だけ確認
for id in $(seq 1000 1010); do
  code=$(curl -s -o /dev/null -w '%{http_code}' \
    -b cookies_a.txt "https://target.example.com/api/users/${id}/profile")
  echo "ID: ${id} -> HTTP ${code}"
done

⚠️ 連番走査は、自分の 2 アカウントで作成したリソースの前後数件だけに限定し、広範囲スキャンは避けましょう。

4-2. SSRF (Server-Side Request Forgery)

サーバーに任意の URL を取得させて、想定外の宛先へアクセスさせる脆弱性です。

SSRF の検証では、まずは自分が管理する受信サーバーやコラボレーション用エンドポイントで外部到達性を確認するのが基本です。

# 自分が管理する受信エンドポイントで外部到達性を確認
curl -s "https://target.example.com/api/fetch?url=https://your-collab.example.com/ssrf-test"

そのうえで、URL バリデーションやパーサー差異の確認として、次のような入力を観察対象にできます。

# ループバックアドレスの基本例
curl -s "https://target.example.com/api/fetch?url=http://127.0.0.1:8080/"

クラウドメタデータや内部ネットワークへのアクセス確認は、高リスク操作として制限されているプログラムもあります。
内部 IP やクラウドメタデータ系へのアクセスは、プログラムルールで明示的に許可されている場合のみ実施してください。

4-3. Open Redirect

# リダイレクト先を外部ドメインに変更
curl -sI "https://target.example.com/redirect?url=https://example.org" | grep -i location

# プロトコル相対 URL
curl -sI "https://target.example.com/redirect?url=//example.org" | grep -i location

# エンコードでフィルタ回避
curl -sI "https://target.example.com/redirect?url=https%3A%2F%2Fexample.org" | grep -i location

バウンティ的ポイント: Location ヘッダーに指定した外部ドメインがそのまま入っていれば、Open Redirect の可能性があります。単体では低評価の場合もありますが、OAuth やリセットフローと組み合わさると深刻度が上がります。

4-4. CORS Misconfiguration

# Origin ヘッダーを任意のドメインに設定して送信
curl -sI -H "Origin: https://example.org" https://target.example.com/api/user/me

# レスポンスの CORS ヘッダーを確認
curl -sI -H "Origin: https://example.org" https://target.example.com/api/user/me \
  | grep -i access-control

危険なレスポンスパターンの一例:

Access-Control-Allow-Origin: https://example.org
Access-Control-Allow-Credentials: true

この組み合わせが返ってくる場合は要注意です。攻撃者ドメインから認証済みデータを読み取れる可能性があります。

# null Origin のテスト
curl -sI -H "Origin: null" https://target.example.com/api/user/me \
  | grep -i access-control

# サブドメイン反映テスト
curl -sI -H "Origin: https://evil.target.example.com" https://target.example.com/api/user/me \
  | grep -i access-control

ただし、CORS ヘッダーの反射や設定ミスらしき挙動だけでは不十分で、実際に機密レスポンスを読み取れるかまで見て初めて報告価値が上がります。

4-5. Host Header Injection

# Host ヘッダーを改変（自分のメールアドレスでテスト）
curl -s -H "Host: example.org" https://target.example.com/password-reset \
  -d "email=your-own-test-account@example.com"

# X-Forwarded-Host の注入
curl -s -H "X-Forwarded-Host: example.org" https://target.example.com/password-reset \
  -d "email=your-own-test-account@example.com"

⚠️ 必ず自分のメールアドレス・自分のアカウントでのみ検証してください。

自分宛に届いたリセットメールのリンクに、送信したホスト名が反映されていれば、パスワードリセットリンク改ざんの可能性があります。

4-6. HTTP Request Smuggling

※ HTTP Request Smuggling は共有インフラや他ユーザー通信に影響しやすいため、本記事では具体的なリクエスト例ではなく、観点と注意点の整理に留めます。

HTTP Request Smuggling は、フロントエンドとバックエンドで HTTP リクエスト境界の解釈がズレることを悪用する問題です。
CDN / WAF / Reverse Proxy / App Server などが多段になっている構成で起きやすく、単なるアプリ単体のバグではなく、構成全体の解釈差に起因します。

バグバウンティでも重要論点ですが、共有インフラや他ユーザー通信に影響を与えやすいため、一般公開記事では概念理解に留めるのが無難です。

Content-Length と Transfer-Encoding の扱いが前段・後段で異なると起こりうる
認証バイパス、キャッシュ汚染、レスポンス混線などにつながることがある
学習や再現は、ローカル検証環境や CTF 用環境で行うのが安全

⚠️ 公開プログラムでの検証は、ルールで明示的に許可されている場合のみ慎重に行ってください。

4-7. CRLF Injection

# レスポンスヘッダーへの注入観測
curl -sI "https://target.example.com/redirect?url=https://target.example.com/%0d%0aX-Test: injected"

レスポンスヘッダーの構造が崩れたり、意図しないヘッダーが追加されたりする場合は、CRLF Injection の可能性があります。

⚠️ これもレスポンス分割やキャッシュ汚染につながりうるため、プログラムで明示的に許可されている範囲でのみ慎重に実施してください。

5. レスポンス解析テクニック

リクエストを送った後、レスポンスから何を読み取るかが勝負を分けます。curl の出力機能を使いこなしましょう。

5-1. `-w` でメトリクスを取得する

# レスポンスコード・サイズ・時間を一括取得
curl -s -o /dev/null -w "\
HTTP Code:    %{http_code}\n\
Size:         %{size_download} bytes\n\
Time Total:   %{time_total}s\n\
Time Connect: %{time_connect}s\n\
Time TTFB:    %{time_starttransfer}s\n\
Redirect URL: %{redirect_url}\n" \
  https://target.example.com/api/endpoint

Time-based テストでの活用例:

# 通常リクエスト
curl -s -o /dev/null -w '%{time_total}\n' \
  "https://target.example.com/api/search?q=test"

# 遅延差の観測例
curl -s -o /dev/null -w '%{time_total}\n' \
  "https://target.example.com/api/search?q=test-delayed"

時間差の観測は有用ですが、タイムベースの脆弱性検証はノイズの影響も大きいため、複数回測定して一貫性を見ることが重要です。

5-2. jq との組み合わせ

# JSON レスポンスから特定フィールドを抽出
curl -s -b cookies.txt https://target.example.com/api/users/me | jq '.email, .role'

# 配列から ID だけ取り出す
curl -s -b cookies.txt https://target.example.com/api/users | jq '.[].id'

# レスポンスを整形して読みやすく
curl -s -b cookies.txt https://target.example.com/api/users/me | jq .

5-3. diff で権限差分を特定する

IDOR や権限昇格のテストで非常に強力な方法です。

# 一般ユーザーアカウントでリクエスト
curl -s -b cookies_user.txt https://target.example.com/api/admin/users | jq . > resp_user.json

# 管理者アカウント（テスト用に権限付与されたもの）でリクエスト
curl -s -b cookies_admin.txt https://target.example.com/api/admin/users | jq . > resp_admin.json

# 差分を比較
diff --color resp_user.json resp_admin.json

一般ユーザーにも管理者と同じデータが返っていれば、認可の不備が疑われます。両方とも自分のアカウントで検証するのが前提です。

5-4. レスポンスサイズでの判定

# 自分が作成したドキュメントの ID 範囲でレスポンスサイズを比較
for id in $(seq 1 20); do
  size=$(curl -s -o /dev/null -w '%{size_download}' \
    -b cookies.txt "https://target.example.com/api/documents/${id}")
  echo "ID: ${id} -> ${size} bytes"
done

存在しないリソースは固定サイズ、存在するリソースは可変サイズになることがあります。サイズ差からアクセス制御の有無を推測できる場合があります。
ただし、他人のリソースの中身を取得・保存するのは避け、ステータスコードやサイズ差だけで認可の欠落を示せるかを意識すると安全です。

6. 自動化・スクリプティング

curl の真価は自動化にあります。bash と組み合わせることで、手動では面倒な確認を効率化できます。

6-1. 連番 ID の走査

#!/bin/bash
# IDOR テスト: 自分の 2 アカウント間で連番 ID のアクセス制御を確認
# ※ 自分のアカウント B で作成した注文 ID の範囲を、アカウント A の認証で走査
for id in $(seq 1000 1010); do
  result=$(curl -s -o /dev/null -w '%{http_code} %{size_download}' \
    -b cookies_a.txt "https://target.example.com/api/orders/${id}")
  echo "ID: ${id} -> ${result}"
  sleep 1  # レートリミット遵守
done

⚠️ 広範囲の連番スキャンは避け、自分の 2 アカウントで作成したリソース周辺だけに限定しましょう。

6-2. ワードリストベースのファジング

# パスのファジング（ffuf の簡易版）
while IFS= read -r path; do
  code=$(curl -s -o /dev/null -w '%{http_code}' \
    "https://target.example.com/${path}")
  [ "$code" != "404" ] && echo "[${code}] /${path}"
done < wordlist.txt

6-3. xargs で並列実行

# 10 並列でサブドメインの生存確認
cat subdomains.txt | xargs -P 10 -I {} \
  curl -s -o /dev/null -w '{} -> %{http_code}\n' "https://{}/"

⚠️ 並列数は対象プログラムのレートリミットに応じて調整してください。

6-4. ステータスコードでフィルタ

# 200 以外のレスポンスだけ表示
for endpoint in /api/v1/users /api/v1/admin /api/v2/users /api/internal/debug; do
  code=$(curl -s -o /dev/null -w '%{http_code}' \
    -b cookies.txt "https://target.example.com${endpoint}")
  [ "$code" != "200" ] && echo "[${code}] ${endpoint}"
done

6-5. 結果をファイルに保存して後から解析

# タイムスタンプ付きでレスポンスを丸ごと保存
mkdir -p responses
curl -s -D - -b cookies.txt \
  https://target.example.com/api/users/me \
  > "responses/users_me_$(date +%Y%m%d_%H%M%S).txt"

-D - を使うと、レスポンスヘッダーも含めて保存できます。

6-6. タイムアウトとリトライ

# 最大 5 秒でタイムアウト、3 回リトライ
curl -s --max-time 5 --retry 3 --retry-delay 2 \
  https://target.example.com/api/slow-endpoint

7. セキュリティとマナー

バグバウンティは「許可された攻撃」ですが、ルールの範囲内で行動する責任があります。curl は便利ですが、雑に使うと過剰トラフィックや意図しない影響につながります。

7-1. レートリミットの遵守

# curl 7.88+ : --rate-limit でリクエスト間隔を制御
curl --rate-limit 10/m https://target.example.com/api/endpoint

# スクリプト内での制御
for id in $(seq 1 100); do
  curl -s "https://target.example.com/api/users/${id}" > /dev/null
  sleep 2
done

7-2. DNS 固定でスコープ外アクセスを防止

# --resolve で DNS を固定
curl -s --resolve "target.example.com:443:93.184.216.34" \
  https://target.example.com/api/endpoint

DNS の変化や外部委譲により、意図しないホストへアクセスしてしまうリスクを下げられます。

7-3. プロキシ経由で全通信をログ

# Burp Suite をプロキシとして使用
curl -s -x http://127.0.0.1:8080 -k \
  https://target.example.com/api/endpoint

# SOCKS5 プロキシ経由
curl -s --socks5 127.0.0.1:9050 \
  https://target.example.com/api/endpoint

すべてのリクエストをプロキシ経由にすることで、後から「何を送ったか」を正確に確認できます。

7-4. User-Agent にハンター ID を入れる

curl -s -A "BugBountyHunter-YourHackerOneUsername" \
  https://target.example.com/api/endpoint

一部のプログラムでは、User-Agent にハンドル名を入れることが推奨されています。サーバーログから「誰が送った通信か」を切り分けやすくなります。

7-5. 証跡の保存

# verbose 出力をファイルに保存
curl -v https://target.example.com/api/vulnerable-endpoint 2>&1 | tee poc_evidence.txt

# リクエストとレスポンスの両方を記録
curl -s -D resp_headers.txt -o resp_body.json \
  -H "Authorization: Bearer <token>" \
  https://target.example.com/api/users/me

さらに詳細な証跡を残したい場合は --trace-ascii も便利です。

curl --trace-ascii trace.txt https://target.example.com/api/endpoint

8. 知っておくと便利な小技

8-1. `--resolve` で DNS を上書き

# ステージング環境の IP に向けつつ、本番の Host 名でアクセス
curl -s --resolve "api.target.example.com:443:10.0.0.5" \
  https://api.target.example.com/endpoint

8-2. `--path-as-is` でパスの正規化を無効化

# パストラバーサル系の挙動確認
curl -s --path-as-is "https://target.example.com/api/files/../../../../tmp/example.txt"

通常 curl は /../ を正規化することがありますが、--path-as-is を使うとそのまま送信できます。

8-3. `--compressed` でレスポンスを自動展開

# gzip / brotli 圧縮レスポンスを自動展開
curl -s --compressed https://target.example.com/api/large-response

8-4. `-k` で SSL 検証をスキップ

# 自己署名証明書の環境やプロキシ経由でのテスト時
curl -s -k https://staging.target.example.com/api/endpoint

⚠️ 本番環境で常用するのは避けましょう。証明書エラー自体が重要な観測ポイントになることもあります。

8-5. `--json` で JSON 送信を簡略化 (curl 7.82+)

# 従来の書き方
curl -s -X POST \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{"key": "value"}' \
  https://target.example.com/api

# --json なら簡略化できる
curl -s --json '{"key": "value"}' https://target.example.com/api

8-6. `.curlrc` で共通オプションをプリセット

cat << 'EOF' > ~/.curlrc
--silent
--compressed
--max-time 30
--user-agent "BugBountyHunter-YourHandle"
EOF

毎回長いオプションを打たなくて済みます。ただし、-k のようなセキュリティに影響するオプションは常用設定に入れないほうが安全です。

8-7. HTTP/2 と HTTP/1.1 の切り替え

# 明示的に HTTP/1.1 を使用
curl -s --http1.1 https://target.example.com/

# HTTP/2 を強制
curl -s --http2 https://target.example.com/

HTTP/1.1 と HTTP/2 でサーバー挙動が異なることがあります。プロトコル差分の観察は地味に有効です。

8-8. よく使うオプションの最小チートシート

-i           # レスポンスヘッダー込みで表示
-D file      # レスポンスヘッダーをファイル保存
-o file      # 本文をファイル保存
-L           # リダイレクト追従
-v           # 通信詳細を表示
-s           # 進捗表示を消す
-b file      # Cookie を送信
-c file      # Cookie を保存

9. レポートに貼れる PoC としての curl

curl がバグバウンティで特に強いのは、PoC をそのまま文章化しやすいことです。

たとえば、Burp のスクリーンショット中心の報告では、

どのヘッダーを送ったか
Cookie がどう付いていたか
再現に何クリック必要か

が曖昧になりやすいことがあります。

一方で curl なら、1 本のコマンドとして

リクエストメソッド
URL
ヘッダー
Cookie
ボディ
送信オプション

を明示できます。

つまり、「再現可能なテキスト PoC」になりやすいということです。
トリアージ担当者や開発者がコピペで確認しやすく、レポートの品質も上げやすくなります。

まとめ

curl は単なる HTTP クライアントではなく、バグバウンティの全フェーズで使える実用ツールです。

フェーズ	curl でできること
偵察	技術スタック特定、ヘッダー監査、TLS 確認
認証操作	Cookie 管理、Token 送信、CSRF フロー再現
リクエスト改変	メソッド変更、ヘッダー注入、ボディ操作
脆弱性テスト	IDOR / SSRF / CORS / Host Header 等の初期検証
レスポンス解析	サイズ・時間計測、diff による権限差分分析
自動化	ループ走査、並列実行、結果のフィルタリング

Burp Suite との使い分け

用途	curl が向いている	Burp が向いている
再現性のある PoC	◎ コマンドをそのまま貼れる	△ スクリーンショットが必要になりがち
自動化	◎ シェルスクリプトと統合しやすい	○ Intruder / Extender
インターセプト	× できない	◎ リアルタイム改変
複雑な UI フロー	△ 手動で再現が必要	◎ ブラウザ連携
レポート記載	◎ テキストベースで再現手順が明確	△ 画像中心になりやすい

PoC の再現性とレポートへの貼りやすさでは、curl はかなり強いです。
Burp と対立する道具ではなく、Burp で観察し、curl で再現性のある PoC に落とし込むという使い分けが実務では非常に有効です。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

Why not login to Qiita and try out its useful features?