gists

q

クライアントサイドパストラバーサルの概要

a

クライアントサイド・パストラバーサル（Client-side Path Traversal）は、ブラウザ側（JavaScriptなど）で組み立てられるファイルパスやURLパスに対して、ユーザー入力が適切に制限・正規化されないまま使われることで起きる問題の総称です。典型的には ../ などを混ぜて、想定外の場所（親ディレクトリ側など）を参照させようとします。

何が起きるか（影響）

クライアント側だけで成立する場合もありますが、多くは「クライアントの不備がサーバ側のファイル参照APIや静的配信と組み合わさって」影響が顕在化します。

• 想定外のリソース取得（本来見せない画面・ファイル・内部用テンプレートなど）
• 機微情報の露出につながる可能性（設定ファイル、ソースマップ、ログ断片などが公開設定だと危険）
• 別機能への足掛かり（ディレクトリ構造の推測、管理画面の発見など）

※ただし、実際にサーバが厳密にパス検証していれば、クライアント側で ../ を作れても被害は限定的です。

典型例（イメージ）

• フロントエンドが fetch("/docs/" + userInput) のようにURLを組み立てる
• userInput に ../admin や %2e%2e%2f（URLエンコード）等を入れる
• 結果として /admin 側のリソース参照が試みられる

また、SPAで「テンプレート名」「言語ファイル名」「画像パス」などを入力やURLパラメータから決めて import() / fetch() / img.src に入れるケースも類型です。

ありがちな発生箇所

• ルーティング（?page=... など）からテンプレート/HTML断片を読み込む
• i18n（翻訳JSON）を lang パラメータで切り替えて動的ロード
• プレビュー機能（file= で画像/文書のパスを指定）
• Electron等のデスクトップWeb技術（ローカルファイルアクセスが絡むと影響が大きい）

対策（要点）

「クライアント側で頑張る」だけでは不十分で、基本はサーバ側（または提供基盤）で防ぐのが重要です。

• 許可リスト（allowlist）：選べるファイル名/IDを固定（例：about, help のみ）
• 正規化と拒否：../ やそのエンコード表現、\、NULLバイト等を検出して拒否
• パス結合の安全化：サーバ側で安全な join + ルート固定（chroot的に範囲を限定）
• 権限チェック：参照先がどこであれ、認可でブロック
• 不要公開物の削除：ソースマップや内部ファイルを本番に置かない/配信しない

補足（よく混同される点）

• パストラバーサルは本質的にサーバ側の検証が最重要です。クライアント側の問題は「攻撃用のパスが簡単に作れてしまう」「本来UIで選べないものを選べる」といった入口になりやすい、という位置づけです。
• Electron/モバイルWebViewなどでローカルファイルに届く設計だと、クライアントサイドでも実害が大きくなります。

必要なら、対象が「Webサイト（SPA）」「Electronアプリ」「特定のコード断片」どれかを教えてください。想定される攻撃パターンと、最小変更での具体的な対策案に落とし込んで説明できます。

q

ディレクトリトラバーサルと何が違う？

a

ディレクトリトラバーサル（Path/Directory Traversal）とクライアントサイド・パストラバーサルの違いは、「脆弱性の主戦場がどこか」と「成立条件」です。

1) どこで起きるか（主戦場）

• ディレクトリトラバーサル（一般に言うTraversal）
  サーバ側の処理（例：/download?file=... をサーバがファイルパスとして扱う）が原因で、../ などによりサーバ上の想定外ファイルを読めたりする問題。
  → 本質的に サーバ側の入力検証・パス解決の不備。

• クライアントサイド・パストラバーサル
  ブラウザ側（JSなど）が fetch("/docs/" + input) のようにパス/URLを組み立てる際、入力が未制限で ../ 等を混ぜられて想定外のURL/パスへ誘導できる問題。
  → 本質的に クライアント側のパス組み立て・制御不備（ただし被害はサーバ側の挙動次第）。

2) 影響の出方（成立条件）

• ディレクトリトラバーサルは、サーバがそのパスで実際にファイルへアクセスするので、
  サーバ側に穴があれば単体で 機密ファイル読み取り等の実害になりやすい。
• クライアントサイドは、クライアントが変なURLを作れても、
  サーバが正しくルーティング/認可/静的配信制御していれば、実害は出ない（単に404/403になる）ことも多い。
  実害が出るのは、例えば次のような“組み合わせ”があるとき：
  • 静的ファイル配信が広く、予期しないパスが公開されている
  • サーバ側のパス検証が甘いAPIにそのまま到達できる
  • Electron/WebView等で file:// やローカル資産アクセスに繋がる

3) 攻撃者視点での違い（何が「できる」か）

• ディレクトリトラバーサル：../../etc/passwd のような入力で、サーバのファイルシステム上の外側を読みに行く（典型的・直接的）。
• クライアントサイド：本来UIで選べないテンプレート名/言語ファイル名/画像パス等を、../ やエンコードで“選べてしまう”ことで、想定外のエンドポイントや静的資産を取りに行かせる（間接的）。
  ※結果としてサーバ側のTraversalと同じ被害に繋がることもあるが、単体では「変なリクエストを作れる」止まりになりがち。

4) まとめ（短く）

• ディレクトリトラバーサル＝サーバ側のパス解決が破られて、サーバ上のファイルアクセスが漏れる問題
• クライアントサイド・パストラバーサル＝クライアント側のパス組み立てが破られて、想定外のURL/資産参照を起点に問題が起きる（多くはサーバ側の設定/検証と組み合わさる）

必要なら、例（SPAのfetch、i18nの動的ロード、Electronのfile:// 等）を挙げて「これはどっちの分類？」「実害が出る条件は？」をあなたのケースに合わせて整理します。

This site is open source. Improve this page.