1.由於應用越來越多的需要和其他的第三方應用互動，以及在自身應用內部根據不同的邏輯將使用者引 向到不同的頁面，譬如乙個典型的登入介面就經常需要在認證成功之後將使用者引導到登入之前的頁面，整個過程中如果實現不好就可能導致一些安全問題，特定條件下可能引起嚴重的安全漏洞。
2.成因
對於url跳轉的實現一般會有幾種實現方式：
(1)meta標籤內跳轉
(2)j**ascript跳轉
(3)header頭跳轉
通過以get或者post的方式接收將要跳轉的url，然後通過上面的幾種方式的其中一種來跳轉到目標url。一方面，由於使用者的輸入會進入meta，j**ascript，http頭所以都可能發生相應上下文的漏洞，如xss等等，但是同時，即使只是對於url跳轉本身功能方面就存在乙個缺陷，因為會將使用者瀏覽器從可信的站點導向到不可信的站點，同時如果跳轉的時候帶有敏感資料一樣可能將敏感資料洩漏給不可信的第三方。
譬如乙個典型的登入跳轉如下：
<?php
$url=$_get['jumpto'];
header("location:$url");
?>
如果jumpto沒有任何限制，所以惡意使用者可以提交
http://@@@@@@r/login.php?jumpto=http:/@@@@@@3.惡意使用者完全可以借用url跳轉漏洞來欺騙安全意識低的使用者，從而導致「中獎」之類的欺詐，這對於一些有**業務的企業如**等，危害較大，同時借助url跳轉，也可以突破常見的基於「白名單方式」的一些安全限制，如傳統im裡對於url的傳播會進行安全校驗，但是對於大公司的網域名稱及url將直接允許通過並且顯示會可信的url，而一旦該url裡包含一些跳轉漏洞將可能導致安全限制被繞過。
如果引用一些資源的限制是依賴於「白名單方式」，同樣可能被繞過導致安全風險，譬如常見的一些應用允許引入可信站點如youku.com的**，限制方式往往是檢查url是否是youku.com來實現，如果youku.com內含乙個url跳轉漏洞，將導致最終引入的資源屬於不可信的第三方資源或者惡意站點，最終導致安全問題。
4.a通過url跳轉突破im的安全校驗，從而傳播惡意url
b通過url跳轉欺騙交易使用者對url的信任，從而實現欺詐
c通過url跳轉繞過應用程式對引用資源的限制，從而導致安全漏洞
d借助未驗證的url跳轉，可以將應用程式內部敏感的資料傳遞到不安全的第三方區域
5.理論上講，url跳轉屬於csrf的一種，我們需要對傳入的url做有效性的認證，保證該url來自於正確的地方，限制的方式同防止csrf一樣可以包括：
1 referer的限制
2 加入有效性驗證token
我們保證所有生成的鏈結都是來自於我們可信域的，通過在生成的鏈結裡加入使用者不可控的token對生成的鏈結進行校驗，可以避免使用者生成自己的惡意鏈結從而被利用，但是如果功能本身要求比較開放，可能導致有一定的限制。
nginx rewrite 實現URL跳轉
最近工作中常常要改nginx配置，學習了nginx中rewrite的用法 這裡說的url跳轉就是使用者在訪問乙個url時將其跳轉到另乙個url上。常見的應用場景是讓多個網域名稱跳轉到同乙個url上，例如讓舊網域名稱跳轉到新網域名稱上 將靜態檔案請求跳轉到cdn上等 根據使用者裝置跳轉到不同站點 pc...
ios設定跳轉url
到其他的設定頁面，例如 定位服務 wifi facetime等等 功能 url 關於本機 prefs root general path about 輔助功能 prefs root general path accessibility 飛行模式 prefs root airplane mode 自動...
跳轉到 URL重定向跳轉繞過
本實驗僅用於資訊防禦教學，切勿用於它用途url重定向重定向漏洞利用點302跳轉即設定http響應頭locatioin url，如果url包含了crlf 回車換行 就可能隔斷了http響應頭，使得後面部分落到了http body，從而跳轉到構造的 註冊登入跳轉開啟連線功能使用者分享 收藏內容過後等等利...