開発者ツール · URL エンコーダーとデコーダー
クエリ パラメーター内のリダイレクト URL を改行せずにエンコードする
· 仕組み
URLエンコーディング クエリパラメータ セキュリティ 認証
ある URL を別の URL の中に入れ子にすることは、パーセント エンコーディングが失敗する最も一般的な場所です。この投稿では、内部 URL の ?、&、および = をエンコードする必要がある理由、その方法、および結果を確認する方法を示します。
パラメータの半分を削除したリターン先リンク (内部 URL であり、外部クエリ文字列に飲み込まれています)
パラメータの半分が削除された return-to リンクは、すべての開発者が遭遇するデバッグ パターンです。ユーザーがログインすると、アプリケーションは ?next=https://example.com/page?id=1&user=alice, にリダイレクトしようとしますが、最終的には example.com/page?id=1. に到達します。内部 URL のアンパサンドが外部クエリ パラメーター間の区切り文字として解析されました。異なる区切り文字を持つ 2 つの URL は、内側の URL をエンコードする必要があることを意味します。
ある URL をクエリ パラメーターとして別の URL 内にネストすると、その内部アドレスは外部レイヤーに対して不透明なデータになります。疑問符、アンパサンド、等号は構造区切り文字として読み取れないようにしてください。パーセントエンコーディングはそれらを変換します。は %3F になり、& は %26 になり、= は %3D になります。次に、外側のパーサーは、エンコードされた文字列を 1 つのパラメーター値として処理します。
2 つの URL、2 セットの区切り文字 — 内側の URL が外側の URL に対する単なる値である理由
encodeURIComponent は完全な保護を生成します: encodeURIComponent("https://example.com/a?b=1&c=2") returns "https%3A%2F%2Fexample.com%2Fa%3Fb%3D1%26c%3D2"。すべての構造文字は %XX 表記になるため、外側のパーサーはネストされた区切り文字を誤って解釈できません。encodeURI のような競合するアプローチでは、スラッシュと疑問符が残ります。そのままでは、その結果がクエリ値になるときに再びあいまいさが生じます。
サーバーは 1 回だけデコードします。次のパラメータを抽出した後、1 回の decodeURIComponent 呼び出しで内部 URL を元の形式に復元します。結果を新しいクエリ文字列として解析すると、正しいパラメータ構造がわかります。同じ値が複数のレイヤーを通過する場合、二重デコードは危険です。 %26 は 1 回のデコード後に & になり、2 回目以降は & のままになります。
内部 URL 全体の encodeURIComponent — :、/、? を含む何がエンコードされるか
基本的なルールは単純です。: / ? など、URL 構文で意味を持つ任意の文字です。 = & # は、クエリ パラメーター値に使用する場合はパーセントでエンコードする必要があります。これにより、外側のパーサーは意図したパラメータ構造のみを参照し、渡した値の中に隠された偶発的な区切り文字は認識しないようにします。このエンコードを完全かつ確実に処理するには、encodeURIComponent を使用します。
URL エンコーダとデコーダでこのエンコードをテストします。内部 URL を貼り付け、値モードでエンコードし、%XX 出力を観察します。デコーダ モードを使用して、ラウンドトリップが正確に一致することを確認します。このツールはエンコーディングをエンドツーエンドでデモンストレーションするため、自信を持って結果をアプリケーション コードに直接コピーできます。
うまくいった例: ?next=https://example.com/a?b=1&c=2 を正しく構築 - サーバー側でエンコードされた文字列とデコード
エンコーディングには重要なセキュリティ境界が存在します。サーバーは、デコードされた宛先が実際に安全にリダイレクトできるかどうかを検証する必要があります。パーセントエンコーディングにより、URL 構造が明確になります。任意の URL を安全にするわけではありません。オープンリダイレクトの脆弱性は、アプリケーションがユーザーが指定した URL に盲目的に従う場合に発生します。検証には、明示的な許可リスト、ドメイン検証、またはユーザー確認が必要です。
エンコーディングにより解析の問題が解決されます。検証によりセキュリティ問題が解決されます。これらは異なるレイヤーでの個別の懸念事項です。 URL エンコーダとデコーダは、エンコードが正しく行われることを示します。サーバーは、リストとの照合、ドメインの検証、または確認の要求などの検証を追加する必要があります。検証がなければ、適切にエンコードされた任意のドメインへのリダイレクトが悪用される可能性があります。
オープンリダイレクトのリスク — サーバーが単にデコードするだけでなく、デコードされた宛先を検証する必要がある理由
よくある間違いがここに蓄積されます。開発者は、スラッシュをそのままにしてクエリ部分のみをエンコードする場合があり、これにより構造が壊れます。他のものは、?next= を含む構築されたパラメータ全体をエンコードし、二重エンコーディングを作成します。デコードせずに解析し、エンコードされた構造を誤って読み取ることで、妥当性をチェックするものもあります。 encodeURIComponent を使用してビルドすると、あらゆる場合において一貫性と正確性が保証されます。
もう 1 つのよくある間違いは、ブラウザーが不正なパラメータを自動的に修正すると信じることです。 URL はデータであり、データとして正確に扱う必要があります。 encodeURIComponent は、このジョブの標準ツールです。 URL エンコーダとデコーダはこのプロセスをローカルに保持するため、本番環境に出荷する前に正確なバイトを確認できます。
よくある間違い — クエリ部分のみをエンコードする、またはブラウザーが修正することを信頼する
OAuth redirect_uri パラメーターは、これとまったく同じパターンに従います。認可サーバーは、既知のアドレス (多くの場合、複数のパラメーターを含む完全な URL) でクライアントに制御を渡します。単一の値としてエンコードすると、パラメータが転送後も存続することが保証され、クライアントは使用前に一度デコードします。 OAuth フローでエンコードが誤って処理されると、トークンとコールバック パラメータが送信中に消失します。
OAuth の状態パラメーターは、CSRF 保護のために暗号化署名と組み合わせたエンコーディングを使用します。フラグメント識別子はクライアント側に留まり、サーバーに送信されることはありません。 URL はログ、ブラウザー履歴、およびリファラー ヘッダーに表示されるため、エンコードに関係なく、ベアラー トークンをリダイレクト URL に配置してはなりません。
これでカバーされないもの — OAuth 状態パラメーターと CSRF 保護設計
テスト戦略: 実際のパラメーターを使用して内部 URL を構築し、それを外部値としてエンコードし、受信コードでデコードします。デコードされた結果が元の結果とバイト単位で同一であることを確認します。本番展開の前に URL エンコーダとデコーダを使用してください。ネットワーク トラフィックとログを調べて、正しく到着し、エンコードされたデータが切り捨てられたり破損したりしていないことを確認します。
%2E ではなく %2e のようなタイプミスは、正しくデコードされる可能性がありますが、一貫性を期待するセカンダリ システムではラウンドトリップ チェックに失敗します。異なるプラットフォーム間でライブラリ間のエンコーディングの不一致はまれですが、発生する可能性はあります。完全なラウンドトリップをテストすることで、生産上の問題や顧客からの苦情を引き起こす前に問題を発見できます。
要点: 内部 URL をデータとして扱う — URL エンコーダーとデコーダーの単一値モードがそれを完全にエンコードし、そのデコーダーがラウンドトリップを確認する方法
エンコード境界は明確です。encodeURIComponent は入力を不透明なデータとして扱い、予約されていない句読点を除くすべての文字をエスケープするため、任意の URL レイヤーに安全にネストできます。検証境界は個別です。デコード後、目的地がユーザーが意図した場所であることを確認します。 URL エンコーダとデコーダを使用して、エンコードのエンドツーエンドのデモンストレーションを確認します。
内部URLを最初からデータとして扱います。単一のクエリ値としてエンコードし、受信時に 1 回だけデコードして、リダイレクトする前に検証を適用します。 URL エンコーダおよびデコーダは、完全な URL のパーセント エンコーディングを単一のクエリ値として表示し、ラウンド トリップをローカルで検証します。エンコードと検証の両方が不可欠です。このツールはエンコードを正しく処理します。