ParamTrace

バグバウンティや許可されたペネトレーションテスト向けの高速なHTTPパラメータ探索ツール。 ParamTraceはワードリストのエントリをパラメータとして送信し、ベースラインと比較して レスポンスに変化をもたらすものを検出します。

法的注意: ParamTraceは、自身が所有するシステム、またはテストの明示的な書面による 許可を得ているシステム（例えば、スコープ内のバグバウンティ対象）でのみ使用してください。 使用方法についてはあなたが責任を負います。

なぜParamTraceなのか？

パラメータ探索ツールはすでに存在します（Arjun、x8、Burp向けのParam Miner）。ParamTraceは小型で焦点を絞った代替ツールです：

• 単一バイナリ、ランタイム不要。 Rustで書かれているため、Python環境やBurpは不要です。Termux（Android）でもビルドして実行できます。
• ノイズを考慮したベースライン。 まず3つのランダムパラメータリクエストを送信して通常のステータスとサイズ範囲を学習し、--toleranceでリクエストごとに変化するページに対応します。
• リフレクション検出。 ステータスやサイズがほとんど変化しない場合でも、値がレスポンスに現れるパラメータを検出します。
• ワークフローに適合。 カスタムヘッダー、GETとPOST、プロキシサポート（CaidoまたはBurp）、他のツールにパイプできるJSON出力を備えています。
• 小さくて読みやすい。 ツール全体が1つのソースファイルなので、監査や拡張が容易です。

別のツールを使うべき場合： すでにBurpを常用しているなら、Param Minerの方が適しています。リクエストごとに多数のパラメータをバッチ処理する場合、Arjunやx8のような成熟したツールの方が現時点では高速です。バッチ処理はParamTraceのロードマップに含まれています。

仕組み

1. ランダムな偽パラメータを付けた3つのリクエストを送信して「通常の」レスポンス （ステータスコードとサイズ範囲）を学習します。
2. ワードリストの各エントリを、制限付きの並行処理でテストします。
3. ステータスが変化した場合、ボディサイズがベースライン範囲を外れた場合、 または値がレスポンスに反映された場合に、そのパラメータを検出します。

インストール

ビルド済みバイナリ（Linux x86_64およびaarch64、macOS Apple Silicon、Windows）はReleasesページにあり、それぞれ.sha256チェックサムファイルが付属しています。例えば、Linuxの場合（スマートフォン上のKali NetHunterではaarch64ファイルを使用してください）：

tar -xzf paramtrace-*-linux-x86_64.tar.gz
sudo cp paramtrace-*-linux-x86_64/paramtrace /usr/local/bin/

TermuxはAndroidのCライブラリを使用しているため、Linuxバイナリはそこで動作しません。代わりにソースからインストールしてください: cargo install --git https://github.com/CurioTrace/paramtrace

テスト状況: Linux aarch64バイナリ（Kali NetHunter）とTermuxのソースビルドは作者によってテスト済みです。Linux x86_64、macOS、Windowsのバイナリはリリースごとに自動ビルドされますが、作者による実行テストはまだ行われていません。動作しない場合はissueを開いてください。バイナリは署名されていないため、WindowsやmacOSでは初回実行時に警告が表示される場合があります。ダウンロードしたファイルは.sha256ファイルで検証できます。

またはソースからビルド:

git clone https://github.com/CurioTrace/paramtrace
cd paramtrace
cargo build --release
# binary: target/release/paramtrace

# optional: install it so you can just type `paramtrace`
cargo install --path .

Termux（Android）とKali NetHunterでテスト済みです。Rustが動作する環境であればどこでもビルドできるはずです（rustlsを使用しており、OpenSSLは不要です）。

使用方法

以下の例では、paramtrace がPATH上にあることを前提としています（上記の cargo install --path . を参照）。 cargo build --release のみを実行した場合は、代わりに ./target/release/paramtrace を使用してください。 インストール後にコマンドが見つからない場合は、CargoのbinフォルダをPATHに追加してください： export PATH="$HOME/.cargo/bin:$PATH"

paramtrace -u https://example.com/search -w wordlists/common.txt
paramtrace -u https://example.com/api -w words.txt -m post -t 20
paramtrace -u https://example.com/ -w words.txt -H "Cookie: session=abc" --proxy http://127.0.0.1:8080
paramtrace -u https://example.com/ -w words.txt -o out.json -f json

フラグ	説明
-u, --url	対象URL
-w, --wordlist	パラメータのワードリスト
-m, --method	get（デフォルト）または post
-t, --threads	同時リクエスト数（デフォルト10）
-H, --header	追加ヘッダー、繰り返し指定可能
--timeout	リクエストのタイムアウト秒数（デフォルト10）
--delay	リクエストごとの遅延（ミリ秒）
--tolerance	Nバイトまでのサイズ差を無視（動的なページで有用）
--value	各パラメータに送信する値（4文字未満の値ではリフレクションチェックが無効になる）
--proxy	プロキシURL（Caido、Burp）
-k, --insecure	TLS検証をスキップ
-q, --quiet	起動バナーを非表示
-o, --output / -f, --format	結果を text または json として保存

結果の例

PortSwigger Web Security Academyのラボの自身のインスタンスに対してテストしました。6,454件のエントリを持つワードリスト（6,453件の誤った名前と実際のパラメータ productId）を使用し、ParamTraceは10スレッドで約3分間に productId のみを検出し、誤検知はありませんでした。サーバーはパラメータの有無にかかわらず 400 を返したため、ステータスコードのみのチェックでは見逃していたでしょう。ParamTraceはレスポンスサイズを比較することでこれを検出しました。

速度はネットワークに大きく依存し、パラメータ名は大文字と小文字を区別するため、ワードリストにはサーバーが期待する正確な名前が含まれている必要があります。

制限事項

• 1リクエストにつき1つのパラメータをテストします（バッチ処理は計画中）。
• リクエストごとにサイズが変化するページでは、自動許容範囲がノイズより小さい実際の変化を隠す可能性があります（ステータスの変化、より大きなサイズ変化、リフレクションは引き続き検出されます）。正確に比較するには --tolerance 0 を使用してください。
• リダイレクトを追跡しないため、リダイレクトの差異は検出結果としてカウントされます。

ワードリスト

小さなスターターリストは wordlists/common.txt にあります。より大きなリストについては、 SecLists を参照してください。

実際のターゲットに対しては、より大きなリスト（約6,000件の名前）をダウンロードし、控えめにスキャンしてください:

curl -L -o wordlists/burp-params.txt https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/burp-parameter-names.txt
paramtrace -u https://example.com/page -w wordlists/burp-params.txt -t 5 --delay 100

パラメータ名は大文字と小文字を区別します。 productId を期待するサーバーは productid には反応しないため、ParamTrace はターゲットが使用する正確な綴りでワードリストに含まれている名前しか見つけられません。多くのリストはすべて小文字なので、まず自分のリストを確認してください。例: grep -c -x productId yourlist.txt。

FAQ

レート制限にはどう対応しますか？

• -t, --threads は同時に実行中のリクエスト数を制限します（デフォルト 10）。
• --delay N は各リクエストの前に N ミリ秒待機します。これはすべての並行リクエストに適用されるため、スレッドを増やせば全体として 1 秒あたりのリクエスト数は依然として増えます。
• --timeout は遅いリクエストがスキャンを停止させないようにします。
• ターゲットが 429 Too Many Requests を返した場合、ParamTrace はそれらのレスポンスを検出結果として報告しません。結果が不完全になる可能性があるため、それらをカウントし、最後に警告を表示します。--threads を下げ、--delay を追加し、ターゲットのリクエストレートに関するルールを確認してください。

現時点では自動的なバックオフやリトライは行いません。私自身のラボテストでは、-t 3 --delay 150 は約 6 リクエスト/秒、-t 10 --delay 0 は約 30 リクエスト/秒で動作したため、速度はターゲットとあなたの接続に大きく依存します。

パラメータのバッチ処理は実装されますか？

はい、それが主な予定機能です。1 回のリクエストで多数の名前を送信し、レスポンスが変化したときに絞り込むことで、必要なリクエスト数を大幅に減らせるはずです。ParamTrace は趣味のプロジェクトなので、時期は未定です。

サポート

ParamTrace がアセスメントやバグバウンティで役立ったなら、他の人が見つけられるように ⭐（リポジトリページ上部の Star ボタン）を付けていただけると嬉しいです。

バグ報告やアイデアは Issues で歓迎します。

ライセンス

MIT