バックスラッシュ (\) のURLエンコード

バックスラッシュ（\）はURLにおいて有効な文字ではなく、常に%5Cにエンコードする必要があります。スラッシュ（/）と異なり、バックスラッシュはURLにおいて構造的な役割を持たず、RFC 3986により安全でないと分類されています。ただし、一部のブラウザがバックスラッシュを暗黙的にスラッシュに変換するため、重大なセキュリティ上の懸念があります。

percent-encoding形式: %5Cはバックスラッシュを表します（ASCIIコード92、16進数で0x5C）。

ブラウザの正規化リスク: 多くのブラウザ（ChromeやEdgeを含む）はURLパス内のバックスラッシュを自動的にスラッシュに変換します。つまり、https://example.com\..\adminはhttps://example.com/../adminに正規化される可能性があります。この動作はオープンリダイレクトやパストラバーサル攻撃で悪用されてきました。セキュリティチェックがバックスラッシュを含むURL文字列を検証しても、ブラウザはスラッシュに変換して解釈するのです。

JavaScriptでの動作:

encodeURIComponent("\\")               // "%5C"
encodeURIComponent("C:\\Users\\file.txt") // "C%3A%5CUsers%5Cfile.txt"

// 重要: JS文字列ではバックスラッシュはエスケープ文字
// ソースコードでは\\で1つのバックスラッシュを表す
const path = "C:\\Windows\\System32";
encodeURIComponent(path) // "C%3A%5CWindows%5CSystem32"

よくあるシナリオ:

• URLパラメータとして渡されるWindowsファイルパス（最も頻繁なケース）
• UNCネットワークパス：\\\\server\\shareは%5C%5Cserver%5Cshareにエンコードが必要
• バックスラッシュエスケープを含む正規表現パターン
• URLで渡されるエスケープ文字を含むJSON文字列
• バックスラッシュエスケープを使用するLDAP識別名

セキュリティ上の影響: バックスラッシュはセキュリティの観点からURLで最も危険な文字の一つです：

1. オープンリダイレクト: バリデーションチェックがhttps://evil.com\\@good.comを外部URLとして認識しない可能性がある
2. パストラバーサル: ..%5Cは../のみをチェックするパストラバーサルフィルタをバイパスする可能性がある
3. SSRF: サーバーサイドのURLパーサーがバックスラッシュをブラウザとは異なる方法で処理する可能性がある

落とし穴: Windowsユーザーからファイルパス（ファイルアップロードパス、ログファイルの場所など）を受け取る場合は、URLに含める前にバックスラッシュをスラッシュに変換するか適切にエンコードしてください。信頼できないソースからのバックスラッシュを含むURLは決して信頼せず、ブラウザの正規化がクライアントとサーバー間でURLの意味を変える可能性があることに注意してください。