開放式重新導向（Open Redirect）發生在使用者拜訪某網站後，被該網站送往另一個 URL，而那個 URL 可能屬於不同網域。這類漏洞的核心是濫用網域信任，把使用者誘導到惡意網站。

漏洞概觀#

危害形式#

雖然 Open Redirect 本身只是「換地方」，但結合其他攻擊就能放大影響：

  • 釣魚（Phishing）：使用者以為自己仍在可信站點上輸入資訊，實際上已被導去攻擊者的偽造頁
  • 散播惡意軟體：透過信任網域的跳板誘使下載
  • 竊取 OAuth Token：在授權流程中被導向攻擊者控制的 redirect URI（第 17 章詳述）

因為單獨的 Open Redirect 影響有限，部分計畫（如 Google）視為低風險不予獎勵；OWASP 也在 2017 年的 Top 10 把它移除。即便如此，本章仍是學習瀏覽器重新導向機制的好起點。

觸發來源#

Open Redirect 出現於開發者信任了攻擊者可控的輸入並用它決定跳轉目的地。常見媒介有三種：

  • URL 參數：例如 ?redirect_to=...
  • HTML <meta> refresh 標籤：透過 content 屬性指定延遲與目的網址
  • DOM 的 window.location 屬性：透過 JavaScript 設定

三種重新導向機制#

1. URL 參數重新導向#

許多網站合法地使用參數帶目的網址，例如：

https://www.google.com/?redirect_to=https://www.gmail.com

伺服器收到 GET 後，會以 3xx（通常是 302，有時是 301、303、307、308）回應，並在 Location 標頭塞入跳轉目的地。

當伺服器未驗證 redirect_to 是否為自家網域時：

https://www.google.com/?redirect_to=https://www.attacker.com

瀏覽器就會被導去 attacker.com，攻擊者可繼續發動下一階段攻擊。

找這類漏洞時，留意 url=、redirect=、next=、return_to=、r=、u= 等命名——名稱因站而異，有時只用單字母。

2. HTML <meta> refresh#

<meta http-equiv="refresh" content="0; url=https://www.google.com/" />

content 屬性同時指定：

  • 延遲時間（範例為 0 秒）
  • 目的網址（GET 請求對象）

只要攻擊者能控制 <meta> 的 content 內容，或能注入新的 <meta> 標籤，就能誘發跳轉。

3. DOM window.location#

JavaScript 可直接改寫位置：

window.location = "https://www.google.com/";
window.location.href = "https://www.google.com";
window.location.replace("https://www.google.com");

通常需要先取得 JS 執行能力（如透過 XSS）或網站本身允許使用者定義跳轉 URL。

實務上會搭配 Proxy（如 Burp Suite）追蹤所有 GET 請求，挑出帶有「目的網址型」參數的呼叫來逐一測試。

案例 1：Shopify Theme Install Open Redirect#

漏洞描述#

Shopify 提供商店管理者預覽佈景主題的功能，跳轉 URL 形如：

https://app.shopify.com/services/google/themes/preview/supply--blue?domain_name=attacker.com

domain_name 參數本應是商店所屬網域，後端會在它後面接上 /admin。但 Shopify沒有驗證 domain_name 屬於 Shopify 自家網域，因此攻擊者可隨意填入：使用者最終會被導向 http://attacker.com/admin/。

Takeaways#

漏洞不必複雜——只要參數值未經白名單檢查，把它換成外部網域就成立。

案例 2：Shopify Login Open Redirect#

漏洞描述#

第二個 Shopify 案例展示了「只能控制部分 URL 仍能跳轉外部」的技巧。

登入後使用 checkout_url 參數做跳轉，後端會把這個參數值黏到 Shopify 子網域之後：

http://mystore.myshopify.com/account/login?checkout_url=.attacker.com

最終實際被瀏覽器解析的網址是：

http://mystore.myshopify.com.attacker.com/

由於 DNS 解析從最右邊的標籤開始，這個域名實際指向 attacker.com，不是 myshopify.com。

Takeaways#

當你只能控制 URL 的一部分時，加入 .、@ 等特殊字元嘗試改變 URL 的語意。即便 URL 前段被硬編碼，只要後段能控，就有機會把網域劫走。

案例 3：HackerOne Interstitial Redirect#

背景：什麼是 Interstitial Page#

部分網站採用**中介頁（Interstitial）**做防護：跳轉前先顯示一個提示頁告訴使用者「即將離開本站」。HackerOne 對外部連結就這麼處理。

但同站內服務之間（例如 HackerOne 的 Zendesk 客服系統）為了體驗順暢，常會被列為信任網域而免顯示中介頁——這正是攻擊者可乘之機。

漏洞描述#

研究者 Mahmoud Jamal 注意到：

  • HackerOne 過去把 hackerone.com/zendesk_session 跳轉到 Zendesk 子網域時沒有顯示中介頁
  • 任何人都能在 Zendesk 上自行建立子網域
  • Zendesk 主題編輯器允許在 Header 注入 JavaScript

於是他在自建的 compayn.zendesk.com 主題裡塞入：

<script>
  document.location.href = "http://evil.com";
</script>

只要受害者點擊：

https://hackerone.com/zendesk_session?locale_id=1&return_to=https://support.hackerone.com/ping/redirect_to_account?state=compayn:/

連結看起來來自 hackerone.com、不會出現中介頁；但跳轉到 Zendesk 後，Jamal 注入的 JS 立刻把瀏覽器再度導去 evil.com。

Jamal 一開始向 Zendesk 回報「跳轉缺少中介頁」被認為不算漏洞。他繼續挖掘，最終找出可實際串接的 JS 攻擊鏈，HackerOne 為此發了獎金。

Takeaways#

  • 觀察站點使用的第三方服務：每一個外部服務都是新的攻擊面，本案就是 HackerOne ＋ Zendesk 的合體
  • 回報時主動說明影響：第 19 章會深入「如何寫出能被計畫方理解的報告」
  • 被否決時不要立刻放棄：嘗試把單一弱點與其他漏洞串接，證明它的真實衝擊

章末總結#

  • Open Redirect 的本質是利用使用者對網域的信任——讓他以為仍在熟悉的站上，實際被帶往攻擊者的網站
  • 三類觸發點：URL 參數、<meta> refresh、window.location
  • 找漏洞時鎖定目的網址型參數（不論名字直白或縮寫）
  • 即便只能控制部分 URL，也可嘗試加入 .、@ 等特殊字元改變語意
  • 留意網站使用的第三方服務——它們是放大攻擊鏈的常見著力點
  • 當公司對單一漏洞反應不大時，結合其他漏洞或證明完整 PoC 往往能扭轉局面
Backward Bug Bounty 基礎 HTTP 參數污染 Forward