URLリダイレクト

URL リダイレクト( URL 転送とも呼ばれる) は、Web ページを複数のURLアドレスで利用できるようにするWorld Wide Web技術です。Webブラウザーがリダイレクトされた URL を開こうとすると、別の URL のページが開きます。同様に、ドメイン リダイレクトまたはドメイン転送は、URLドメイン内のすべてのページが異なるドメインにリダイレクトされることです。たとえば、wikipedia.com と wikipedia.net は自動的に wikipedia.org にリダイレクトされます。

URL リダイレクトはさまざまな理由で実行されます。

• URL短縮用;
• ウェブページを移動したときにリンクが壊れるのを防ぐため。
• 同じ所有者に属する複数のドメイン名が単一のWeb サイトを参照できるようにする。
• ウェブサイトへのナビゲーションとウェブサイトからのナビゲーションをガイドする。
• プライバシー保護のため（YouTubeとTwitter のリンクをそれぞれInvidiousとNitterにリダイレクトしたり、 AMPリンクを通常のリンクに変換したりするなど）
• フィッシング攻撃やマルウェア配布などの悪意のある目的で使用する。

URL リダイレクトを使用する理由はいくつかあります。

ウェブサイトは、安全なHTTPS URI スキームとプレーン HTTP (「http://」で始まる安全でない URI) の両方でアクセスできる可能性があります。

ユーザーが URI を入力したり、安全でないバージョンを参照するリンクをクリックしたりした場合、Web サイトがアプリケーションに付属のHSTSプリロード リストに含まれているか、ユーザーが過去にそのオリジンを既に訪問していた場合は、ブラウザーは自動的に安全なバージョンにリダイレクトします。

それ以外の場合、Web サイトは HTTP 経由でアクセスされます。Web サイトの運営者は、代わりにブラウザを HTTPS バリアントにリダイレクトし、将来のアクセスのために HSTS を準備することで、このようなリクエストに対応することを決定する場合があります。

ユーザーは URL を誤って入力することがあります。組織では、こうしたスペルミスのあるドメインを登録し、目的の場所にリダイレクトすることがよくあります。この手法は、同じ名前の他のトップレベル ドメイン(TLD) を「予約」したり、「.edu」や「.net」のサイトで「.com」と入力するユーザーに対応しやすくしたりするためによく使用されます。

Web ページが新しいドメインにリダイレクトされる理由は 3 つあります。

• サイトがドメイン名の変更を希望したり、変更する必要が生じたりする場合があります。
• 著者は個々のページを新しいドメインに移動するかもしれません。
• 2 つの Web サイトが統合される可能性があります。

URL リダイレクトを使用すると、古い URL への着信リンクを正しい場所に送ることができます。これらのリンクは、変更に気付いていない他のサイトからのリンクや、ユーザーがブラウザに保存したブックマーク/お気に入りからのリンクである可能性があります。同じことが検索エンジンにも当てはまります。検索エンジンのデータベースには古い/古いドメイン名とリンクが含まれていることが多く、検索ユーザーをこれらの古い URL に送ります。新しい URL への「恒久的に移動」リダイレクトを使用すると、訪問者は正しいページに到達します。また、次の検索エンジン パスでは、検索エンジンが新しい URL を検出して使用します。

ほとんどのウェブ サーバーのアクセス ログには、訪問者がどこから来たか、ホストされているサイトをどのように閲覧したかに関する詳細な情報が記録されています。ただし、訪問者がどのリンクから離れたかは記録されません。これは、訪問者が外部リンクをクリックしたときに、訪問者のブラウザーが元のサーバーと通信する必要がないためです。この情報は、いくつかの方法で取得できます。1 つの方法は、URL リダイレクトです。訪問者を他のサイトに直接送信する代わりに、サイト上のリンクを元の Web サイトのドメインの URL に誘導し、実際のターゲットに自動的にリダイレクトすることができます。この手法には、元の Web サイトのサーバーへの追加要求によって遅延が発生するという欠点があります。この追加要求によってサーバー ログに痕跡が残り、どのリンクがクリックされたかが正確にわかるため、プライバシーの問題になることもあります。^[1]同じ手法は、一部の企業 Web サイトでも使用されており、後続のコンテンツは別のサイトにあり、必ずしも企業と関係があるわけではないというステートメントを実装しています。このようなシナリオでは、警告を表示すると追加の遅延が発生します。

ウェブアプリケーションでは、URL にデータ階層、コマンド構造、トランザクション パス、セッション情報を表す長い説明属性が含まれることがよくあります。このため、見た目が悪く覚えにくい URL になり、マイクロブログサイトのサイズ制限内に収まらない場合があります。URL短縮サービスは、ユーザーを短い URL から長い URL にリダイレクトすることで、この問題を解決します。^[1]

コンテンツが同じであっても、ページの URL が変わることがあります。そのため、URL リダイレクトはブックマークを持つユーザーに役立ちます。これは、Wikipedia ではページ名が変更されるたびに定期的に行われます。

Post/Redirect/Get (PRG) は、ユーザー がフォームを送信した後に更新ボタンをクリックした場合に、重複したフォームの送信を防ぎ、ユーザー エージェント(ユーザー) にとってより直感的なインターフェイスを作成する Web 開発設計パターンです。

リダイレクトは、ジオターゲティングなどのターゲティングに効果的に使用できます。モバイルクライアントの台頭により、デバイスターゲティングがますます重要になっています。モバイルユーザーにサービスを提供するには、Web サイトをレスポンシブにするか、モバイル Web サイト バージョンにリダイレクトするかの 2 つの方法があります。モバイル Web サイト バージョンが提供される場合、モバイルクライアントを持つユーザーは、対応するモバイル コンテンツに自動的に転送されます。デバイスターゲティングには、クライアント側リダイレクトまたはキャッシュ不可能なサーバー側リダイレクトが使用されます。ジオターゲティングは、ローカライズされたコンテンツを提供し、要求された URL のローカライズされたバージョンにユーザーを自動的に転送する方法です。これは、複数の場所や言語のユーザーをターゲットとする Web サイトに役立ちます。通常、サーバー側リダイレクトはジオターゲティングに使用されますが、要件によってはクライアント側リダイレクトもオプションになる場合があります。^[2]

リダイレクトは、 URLハイジャックなどの非倫理的な目的で検索エンジンを操作するために使用されてきました。誤解を招くリダイレ​​クトの目的は、検索トラフィックを、それ自体では十分なランキング力を持たない、または検索ターゲットとほとんどまたはまったく関連のないランディングページに誘導することです。このアプローチでは、検索者をターゲットページに転送するために巧妙なリダイレクトを使用するいくつかのURLを含む、さまざまな検索用語のランクが必要です。この方法は、モバイルデバイスとデバイスターゲティングの台頭により復活しました。URLハイジャックは、検索エンジンによる一時リダイレクトの処理の性質を利用したオフドメインリダイレクト手法^[3]です。一時リダイレクトに遭遇した場合、検索エンジンは、リダイレクトを初期化するURLにランキング値を割り当てるか、リダイレクトターゲットURLにランキング値を割り当てるかを決定する必要があります。リダイレクトは一時的な性質を示しているため、リダイレクトを開始するURLは検索結果に表示されたままになる場合があります。特定の状況下では、ランキング上位の URL に一時的なリダイレクトを適用することでこの動作を悪用することが可能であり、その結果、検索結果の元の URL がリダイレクトを開始した URL に置き換えられ、ランキングが「盗まれる」ことになります。この手法は通常、巧妙なリダイレクトと組み合わせて、ユーザー ストリームを検索結果からターゲット ページに再ターゲットします。検索エンジンは、このような操作的なアプローチを検出するための効率的なテクノロジを開発しました。大手検索エンジンは通常、このような手法を適用していることが判明したサイトに対して厳しいランキング ペナルティを適用します。^[4]

URL リダイレクトは、訪問者がどの Web サイトにアクセスしているのかを混乱させるフィッシング攻撃の一部として使用されることがあります。 ^[5]最近のブラウザでは、アドレス バーに実際の URL が常に表示されるため、脅威は軽減されます。ただし、リダイレクトによって、他の方法で攻撃を試みるサイトに誘導される可能性もあります。たとえば、リダイレクトによって、ユーザーを騙してウイルス対策ソフトウェアをダウンロードさせ、代わりに何らかの トロイの木馬をインストールさせようとするサイトに誘導される可能性があります。

リンクをクリックすると、ブラウザはHTTP リクエストで、リンクのソースを示すrefererというフィールドを送信します。このフィールドには現在の Web ページの URL が入力され、外部リンクを提供するサーバーのログに記録されます。機密性の高いページには機密性の高い URL ( など) が含まれることがあるため、 URL が組織外に漏れることhttps://company.com/plans-for-the-next-release-of-our-productは望ましくありません。リファラを非表示にするリダイレクト ページをすべての外部 URL に埋め込むことで、たとえばに変換できます。この手法では、セッション IDなどの機密性の高い可能性のある他の情報もリファラ URL から削除され、エンドユーザーに別のサイトへの明確なゲートウェイを通過したことを示すことで 、フィッシングの可能性を減らすことができます。referrerhttps://externalsite.com/pagehttps://redirect.company.com/https://externalsite.com/page

ブラウザへの応答にはさまざまな種類があり、その応答がHTTP ヘッダーに影響を及ぼすか HTML コンテンツに影響を及ぼすかによって異なります。使用される手法は、通常、実装する人の役割とシステムのさまざまな部分へのアクセスによって異なります。たとえば、ヘッダーを制御できない Web 作成者はRefresh メタ タグを使用する可能性がありますが、サイトのすべてのページをリダイレクトする Web サーバー管理者はサーバー構成を使用する可能性が高くなります。

最も簡単な手法は、通常は次のような HTML アンカーを使用して、訪問者に新しいページへのリンクをたどるように依頼することです。

< a  href = "https://www.example.com/" >このリンク</ a >に従ってください。

この方法はフォールバックとしてよく使用されます。ブラウザが自動リダイレクトをサポートしていない場合でも、訪問者はリンクをたどることで対象のドキュメントにアクセスできます。

World Wide Webで使用されるHTTP プロトコルでは、リダイレクトは3で始まるステータス コードを持つ応答であり、ブラウザに別のページを表示します。クライアントがリダイレクトに遭遇した場合、リダイレクトの処理方法についていくつかの決定を行う必要があります。クライアントは、リダイレクトの目的、キャッシュの処理方法、および後続のリクエストに使用するリクエスト メソッドを理解するために、さまざまなステータス コードを使用します。

HTTP/1.1 では、リダイレクト用のいくつかのステータス コードが定義されています (RFC 7231)。

• 300 の複数の選択肢（例：異なる言語を提供する）
• 301 永久的に移動(ある URL から別の URL に永久的にリダイレクトし、リダイレクトされたページにリンク エクイティを渡します)
• 302 が見つかりました(元々は HTTP/1.0 の「一時的なリダイレクト」で、CGI スクリプトでよく使用されていました。HTTP/1.1 では 303 と 307 に置き換えられましたが、下位互換性のために保持されています)
• 303 see other (元のリクエストが POST であっても、新しい URL に GET リクエストを強制します)
• 305 プロキシを使用する(クライアントが要求したリソースはプロキシ経由でのみ利用可能であることを示します)
• 307 一時リダイレクト(ブラウザが GET または POST リクエストを再送信するための新しい URL を提供します)
• 308 永続リダイレクト(ブラウザが GET または POST リクエストを再送信するための新しい URL を提供します)

ステータス コード304 (変更なし)および305 (プロキシを使用)はリダイレクトではありません。

これらのステータス コードはすべて、HTTP 応答の Location: ヘッダーにリダイレクト先の URL を指定する必要があります。300 の複数選択肢では通常、メッセージの本文にすべての選択肢がリストされ、Location: ヘッダーにデフォルトの選択肢が表示されます。

301「永久に移動」リダイレクトによる HTTP応答は次のようになります。

HTTP / 1.1  301 恒久的に移動
場所:  https://www.example.org/
コンテンツタイプ:  text/html
コンテンツ長:  174

< html > 
< head > 
< title >移動しました</ title > 
</ head > 
< body >
=移動しました=
< p >このページは< a  href = "https://www.example.org/" > https://www.example.org/ </ a >に移動しました。</ p > 
</ body > 
</ html >

HTML コンテンツを作成する Web 作成者は、通常、HTTP ヘッダーを使用してリダイレクトを作成することはできません。これは、HTML ファイルを提供するときに Web サーバー プログラムによって自動的に生成されるためです。CGI スクリプトを作成するプログラマーでも同じことが言えますが、一部のサーバーではスクリプトでカスタム ヘッダーを追加できます (たとえば、「非解析ヘッダー」を有効にするなど)。多くの Web サーバーでは、スクリプトが「Location:」ヘッダー行を出力すると、3xx ステータス コードが生成されます。たとえば、PHPでは、「header」関数を使用できます。

ヘッダー( 'HTTP/1.1 301 永久に移動しました' );
ヘッダー( '場所: https://www.example.com/' ); 
exit ();

キャッシュを防ぐために、より多くのヘッダーが必要になる場合があります。^[7]プログラマーは、ヘッダーが本文の前に出力されるようにする必要があります。これは、コードによる制御の自然な流れに簡単には適合しない可能性があります。これを支援するため、サーバー側コンテンツ生成用の一部のフレームワークでは、本文データをバッファリングできます。ASPスクリプト言語では、これを使用して実現することもできます。HTTP/1.1 ではresponse.buffer=true、response.redirect "https://www.example.com/"相対 URI 参照または絶対 URI 参照のいずれかが許可されています。^[8] URI 参照が相対的である場合、クライアントは RFC 3986 で定義された規則に従って、必要な絶対 URI 参照を計算します。^[9]

Apache HTTP Server のmod_alias 拡張機能を使用して、特定のリクエストをリダイレクトできます。一般的な設定ディレクティブは次のようになります。

 永久リダイレクト/oldpage.html https://www.example.com/newpage.html
 301リダイレクト/oldpage.html https://www.example.com/newpage.html
     

より柔軟なURL 書き換えとリダイレクトには、Apache mod_rewrite を使用できます。たとえば、リクエストを正規のドメイン名にリダイレクトするには、次のようにします。

RewriteCond %{HTTP_HOST}のRewriteEngine ^([^.:]+\.)*oldsite\.example\.com\.?(:[0-9]*)?$ [NC]
 RewriteRule ^(.*)$ https://newsite.example.net/$1 [R=301,L]
 
      

このような構成は、サーバー構成ファイルを通じてサーバー上の 1 つまたはすべてのサイトに適用することも、.htaccessファイルを通じて単一のコンテンツ ディレクトリに適用することもできます。

Nginxにはhttp書き換えモジュールが統合されており^[10]、高度なURL処理やWebページ生成（returnディレクティブを使用）にも使用できます。書き換えモジュールの高度な使用例としては、mdoc.suがあります。これは、nginx設定言語のみを使用して決定論的なURL短縮サービスを実装しています。 ^{[11] [12]}

例えば、 のリクエスト/DragonFlyBSD/HAMMER.5が来た場合、まず最初に/d/HAMMER.5以下の最初の書き換えディレクティブによって内部的に にリダイレクトされます（内部状態のみに影響し、クライアントにはまだHTTP応答は発行されません）。次に2番目の書き換えディレクティブによって、302 FoundステータスコードのHTTP応答がクライアントに発行され、実際にweb- manの外部cgiスクリプトにリダイレクトされます。^[13]

 場所/DragonFly {書き換え^/DragonFly(BSD)?([,/].*)? $ /d $2 last ; }場所/d { $db を"https://leaf.dragonflybsd.org/cgi/web-man?command="に設定し、$ds を"§ion=" に設定し、書き換え^/./([^/]+)\.([1-9]) $ $ db$1$ds$2 をリダイレクトします; }  
     
 
   
    
    
      
 

Netscape は、一定時間後にページを更新するメタリフレッシュ機能を導入しました。この機能では、新しい URL を指定して、あるページを別のページに置き換えることができます。この機能は、ほとんどの Web ブラウザでサポートされています。 ^{[14] [15]}タイムアウトが 0 秒の場合、即時リダイレクトが実行されます。これは、Google によって 301 永続リダイレクトとして扱われ、PageRank をターゲット ページに転送できます。^[16]

これは、この手法を使用した単純な HTML ドキュメントの例です。

< html > 
< head > 
  < meta  http-equiv = "Refresh"  content = "0; url=https://www.example.com/"  /> 
</ head > 
< body > 
  < p > < a  href = "https://www.example.com/" >このリンク</ a >に従ってください。</ p > 
</ body > 
</ html >

この手法は、メタ タグがドキュメント自体に含まれているため、 Web 作成者が使用できます。メタ タグは、HTML ファイルの「head」セクションに配置する必要があります。この例の数字「0」を別の数字に置き換えると、その秒数の遅延を実現できます。「body」セクションのアンカーは、この機能をサポートしていないブラウザーを使用するユーザー向けです。

同じ効果は HTTPrefreshヘッダーでも実現できます。

HTTP / 1.1  200  OK
更新:  0; url=https://www.example.com/
コンテンツタイプ:  text/html
コンテンツ長:  78
< a  href = "https://www.example.com/" >このリンク</ a >
に従ってください。

この応答は、デフォルトのステータス コードを変更する必要がないため、CGI プログラムによって生成する方が簡単です。

このリダイレクトを実行する簡単な CGI プログラムを次に示します。

# !/usr/bin/perl 
print "Refresh: 0; url=https://www.example.com/\r\n" ; print "Content-Type: text/html\r\n" ; print "\r\n" ; print "<a href=\"https://www.example.com/\">このリンク</a>に従ってください!" 
 
 
 

注: 通常、HTTP サーバーはステータス行と Content-Length ヘッダーを自動的に追加します。

W3Cはメタリフレッシュの使用を推奨していません。メタリフレッシュは元のリソースや新しいリソースに関する情報をブラウザ (または検索エンジン) に伝えないからです。W3C の Web コンテンツ アクセシビリティ ガイドライン (7.4) ^[17]では、ほとんどの Web ブラウザでユーザーがリフレッシュ レートを無効にしたり制御したりできないため、自動リフレッシュ ページの作成を推奨していません。この問題について W3C が書いた記事には、W3C Web コンテンツ アクセシビリティ ガイドライン (1.0): 時間的制約のあるコンテンツ変更のユーザー制御の確保、標準リダイレクトの使用: 戻るボタンを壊さない! ^[18]、Web コンテンツ アクセシビリティ ガイドライン 1.0 のコア テクニック セクション 7 などがあります。^[19]

JavaScript では、属性を設定することでリダイレクトを発生させることができますwindow.location。例:

ウィンドウ.location = 'https://www.example.com/ '

通常、JavaScript はリダイレクトサイトのURL をブラウザの履歴にプッシュします。これにより、ユーザーが戻るボタンを押すとリダイレクト ループが発生する可能性があります。次のコマンドを使用すると、この種の動作を防ぐことができます。^[20]

ウィンドウ.場所.置換( 'https://www.example.com/' )

ただし、セキュリティ上の理由や、一部のブラウザや多くのWeb クローラーでは JavaScript が実行されないため、HTTP ヘッダーまたは更新メタ タグが推奨される場合があります。

インラインフレームを作成すると、少し異なる効果が得られます。

< iframe  height = "100%"  width = "100%"  src = "https://www.example.com/" > < a  href = "https://www.example.com/" >リンク</ a >
に従ってください。
 </ iframe >

上記のリダイレクト方法との主な違いは、フレームリダイレクトの場合、ブラウザはURLバーにターゲットページのURLではなく、フレームドキュメントのURLを表示することです。このクローキング技術は、読者に覚えやすいURLを見せたり、ウェブサイトのなりすましの一環としてフィッシングサイトを不正に隠したりするために使用されることがあります。^[21]

HTML5以前は^[22] 、対象ページを含む HTMLフレームで同じ効果を実現できました。

< frameset  rows = "100%" > 
  < frame  src = "https://www.example.com/" > 
  < noframes > 
    < body > < a  href = "https://www.example.com/" >リンク</ a >に従ってください。</ body > 
  </ noframes > 
</ frameset >

リダイレクト チェーンでは、1 つのリダイレクトが別のリダイレクトにつながる場合があります。リダイレクトが別のリダイレクトにつながる場合、これは二重リダイレクトとも呼ばれます。^[23]たとえば、URL「https://wikipedia.com」(ドメインは「*.com」) は、最初に https://www.wikipedia.org/ (ドメイン名は.org ) にリダイレクトされ、そこで言語固有のサイトに移動できます。チェーン内の異なるリンクが異なるサーバーによって提供される場合、これは避けられませんが、リダイレクトとしてブラウザーに返す前に、サーバー上で URL を可能な限り書き換えることで最小限に抑える必要があります。

場合によっては、間違いが原因で、ページが他のページを経由してそのページ自体にリダイレクトされ、リダイレクトの無限シーケンスが発生することがあります。ブラウザは、一定数のホップの後でリダイレクトを停止し、エラー メッセージを表示する必要があります。

HTTP/1.1標準では次のように述べられている: ^[24]

クライアントは、循環的なリダイレクト (つまり、「無限」リダイレクト ループ) を検出し、介入する必要があります。

注: この仕様の以前のバージョンでは、最大 5 回のリダイレクトが推奨されていました ([RFC 2068]、セクション 10.3)。コンテンツ開発者は、一部のクライアントがこのような固定制限を実装する可能性があることに注意する必要があります。

技術的な作業や、サイトがホストされている Web サーバーへのアクセスを必要とせずに、オンデマンドで URL リダイレクトを実行できるサービスが存在します。

リダイレクト サービスは、ユーザーを目的のコンテンツにリダイレクトするインターネット リンクを提供する情報管理システムです。ユーザーにとっての一般的な利点は、覚えやすいドメイン名の使用と、URL または Web アドレスの長さの短縮です。リダイレクト リンクは、ドメインネーム システムと同様に、ホストが頻繁に変更されるコンテンツの永続的なアドレスとして使用することもできます。URL リダイレクト サービスに関連するハイパーリンクは、ブログや wiki に宛てられたスパム メッセージで頻繁に使用されます。したがって、スパムを削減する 1 つの方法は、既知の URL リダイレクト サービスへのハイパーリンクを含むすべての編集とコメントを拒否することです。ただし、これにより正当な編集とコメントも削除されるため、スパムを削減する効果的な方法ではない可能性があります。最近、URL リダイレクト サービスでは、短縮 URL を作成するための効率的でユーザー フレンドリな方法としてAJAX を使用するようになりました。一部の URL リダイレクト サービスの主な欠点は、収益を上げるために遅延ページまたはフレーム ベースの広告を使用することです。

最初のリダイレクト サービスは、 「 .to」（トンガ）、「.at」（オーストリア）、「.is 」（アイスランド）などのトップレベル ドメイン（TLD）を活用しました。その目的は、覚えやすい URL を作ることでした。最初の主流のリダイレクト サービスは V3.com で、2000 年のピーク時には 400 万人のユーザーを誇りました。V3.com の成功は、「r.im」、「go.to」、「i.am」、「come.to」、「start.at」など、覚えやすい短いドメインを幅広く取り揃えていたことに起因しています。V3.com は、1999 年初頭に大手無料 Web ホスティング会社である FortuneCity.com に買収されました。^[25]トップレベル ドメインの販売価格が年間50 ドルから10 ドル未満に下がり始めると、リダイレクト サービスの利用は減少しました。2002 年にTinyURLが開始され、 URL 短縮という新しい種類のリダイレクト サービスが誕生しました。彼らの目標は、長い URL を短くして、インターネット フォーラムに投稿できるようにすることでした。2006 年以降、非常に人気のあるTwitterサービスに 140 文字の制限が設けられ、これらの短縮 URL サービスが頻繁に使用されるようになりました。

リダイレクト サービスは、リンクがあるページとそのリンク先の間に中間ページを配置することで、リファラーを隠すことができます。これらは概念的には他の URL リダイレクト サービスに似ていますが、目的が異なり、リンク先 URL を短縮したり難読化したりすることはほとんどありません (意図されている唯一の副作用は、リファラー情報を隠し、他の Web サイト間の明確なゲートウェイを提供することです)。このタイプのリダイレクトは、潜在的に悪意のあるリンクがリファラーを使用して情報 (クエリ文字列内のセッション IDなど) を取得するのを防ぐためによく使用されます。多くの大規模なコミュニティ Web サイトでは、外部リンクでリンク リダイレクトを使用して、アカウント情報を盗むために使用される可能性のあるエクスプロイトの可能性を減らし、ユーザーがサービスを離れるタイミングを明確にして、効果的なフィッシングの可能性を減らしています 。

以下は、 PHPで記述された、このようなサービスの単純な例です。

<?php 
$url  =  htmlspecialchars ( $_GET [ 'url' ]); 
header ( 'Refresh: 0; url=https://'  .  $url ); 
?> 
<!-- meta refresh を使用してフォールバックします。 --> 
< html > 
 < head > 
  < title >リダイレクトしています... </ title > 
  < meta  http-equiv = "refresh"  content = "0;url=https:// <? =  $url ;  ?> " > 
 </ head > 
 < body > < a  href = "https:// <? =  $url ;  ?> " > https:// <? =  $url ;  ?> </ a >
 にリダイレクトしようとしています。
  </ body > 
</ html >

上記の例では、誰が呼び出したかは確認されません (たとえば、リファラーによる呼び出しですが、これは偽装される可能性があります)。また、提供された URL も確認されません。つまり、悪意のある人物が、Web サーバーのリソースを使用する任意のページから、自分で選択した URL パラメータを使用してリダイレクト ページにリンクできるということです。

URL リダイレクトは、攻撃者がフィッシング攻撃を実行するために悪用される可能性があります。リダイレクト先が Web アプリケーションによって十分に検証されていない場合、攻撃者は Web アプリケーションを任意の Web サイトにリダイレクトすることができます。この脆弱性はオープン リダイレクト脆弱性として知られています。^{[26] [27]}オープン リダイレクトが認証フローの一部として発生する特定のケースでは、脆弱性は隠れたリダイレクトとして知られています。^{[28] [29]}隠れたリダイレクトが発生すると、攻撃者の Web サイトは被害者の Web サイトから認証情報を盗むことができます。 ^[26]オープン リダイレクト脆弱性は Web 上でかなり一般的です。2022 年 6 月、TechRadar は、GoogleやInstagramなどのサイトを含む、Web 上で 25 を超えるオープン リダイレクト脆弱性のアクティブな例を発見しました。^[30]オープン リダイレクトには、独自の CWE 識別子 CWE-601 があります。^[31]

URLリダイレクトは、クロスサイトリーク攻撃を実行するためのメカニズムも提供します。ウェブサイトが特定のページに戻るまでにかかった時間を計測したり、ある宛先ページを別のページと区別したりすることで、攻撃者は別のウェブサイトの状態に関する重要な情報を得ることができます。2021年、KnittelらはChromeのパフォーマンスAPI実装に脆弱性を発見し、クロスオリジンリダイレクトを確実に検出できるようになりました。^[32]

• 正規リンク要素
• クリーンなURL
• ドメインマスキング
• HTTP ロケーション
• リンクの腐敗
• URI 正規化

• URL をファイルシステムの場所にマッピングする - Apache HTTP Server バージョン 2.4
• JavaScript リダイレクト スパムの分類 (Microsoft Live Labs)
• URL リダイレクタのセキュリティ脆弱性 Web アプリケーション セキュリティ コンソーシアムの脅威分類