整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
信
51rgb
網頁自動跳轉頁面的代碼在很多時候都非常的有用，下面的是兩個簡單的例子。僅供參考。
方案一，用<meta>里直接寫刷新語句：
<html>
<head>
<meta http-equiv="Content-Language" content="zh-CN">
<meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=gb2312">
<meta http-equiv="refresh" content="5;url=http://www.51rgb.com">
<title>html網頁自動跳轉代碼--西農大網站</title>
</head>
<body>
測試：html網頁自動跳轉代碼<br/>
你可以在這里寫下你想的一切東西！<br />
如：西北農林科技大學是一所985、211院校。<br />
</body></html>
方案二，用javascript腳本來跳轉
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>正在進入西農大網站</title>
</head>
<body>
<form name=loading>
<p align=center> <font color="#0066ff" size="2">正在進入，請稍等</font><font color="#0066ff" size="2" face="Arial">...</font>
<input type=text name=chart size=46 style="font-family:Arial; font-weight:bolder; color:#0066ff; background-color:#fef4d9; padding:0px; border-style:none;">
<inputtype=text name=percent size=47 style="color:#0066ff; text-align:center; border-width:medium; border-style:none;">
<script>
var bar=0
var line="||"
var amount="||"
count
function count{
bar=bar+2
amount =amount + line
document.loading.chart.value=amount
document.loading.percent.value=bar+"%"
if (bar<99)
{setTimeout("count",100);}
else
{window.location =http://www.51rgb.com;}
}</script>
</p>
</form><p align="center">
測試：html網頁自動跳轉代碼<br/>
你可以在這里寫下你想的一切東西！<br />
如：西北農林科技大學是一所985、211院校。<br /><br />
如果您的瀏覽器不支持跳轉,<astyle="text-decoration: none" ><font color="#FF0000">請點這里</font></a>.</p>
</body>
</html>
↓↓↓
家對URL任意跳轉都肯定了解，也知道他的危害，這里我就不細說了，過~
大家遇到的肯定都是很多基于這樣的跳轉格式
http://www.xxx.xxx/xxx?xxx=http://www.xxx.xxx/xxxxx
基本的思路大家就是直接替換后面的URL來檢測是否存在任意URL跳轉，如果不存在，就直接返回到它自己的域名，如果存在，就跳轉到你指定的URL，
這里我講述我所知道的所有小點。
0x01 利用問號繞過限制
利用問號，這是一個特性，利用問號可以成功繞過URL限制
比如：http://www.aaa.com/acb?Url=http://login.aaa.com 這是一個跳轉鏈接，跳轉到它的二級域名下，那么這個問號放哪里可以繞過呢？其實就是放到它自身的域名前面也就是你添加的想要跳轉的域名的后面，如：http://www.aaa.com/acb?Url=http://test.com?login.aaa.com 那么，它其實是會跳轉到這個test.com域名下，這個域名是我想要跳轉的任意域名，而后面的它自身域名一定要帶上，不帶上就無法輔助用問號?這個特性來跳轉到指定域名了，而跳轉后，問號和問號后面的內容會變為這樣：http://www.test.com/?login.aaa.com
0x02 利用反斜杠和正斜杠繞過限制
這個是我自己研究出來的，不知道是否網上有人說過。
比如：http://www.aaa.com/acb?Url=http://login.aaa.com/ 同樣是在它本身域名前加上正斜杠，然后正斜杠前面跟上你想跳轉的域名地址。
如：http://www.aaa.com/acb?Url=http://test.com/login.aaa.com
反斜杠有三種思路
兩個反斜杠繞過方法
比如：http://www.aaa.com/acb?Url=http://login.aaa.com/ 同樣是在它本身域名前加上兩個反斜杠，然后兩個反斜杠前面跟上你想跳轉的域名地址。
如：http://www.aaa.com/acb?Url=http://test.com\login.aaa.com
一個反斜杠繞過方法
如：http://www.aaa.com/acb?Url=http://test.comlogin.aaa.com
另一種思路，一個反斜杠一個點
利用.這樣的格式，也就是一個反斜杠加一個點來跳過限制，
如：http://www.aaa.com/acb?Url=http://test.com.login.aaa.com
0x03 利用@繞過URL限制
如果你用這方法在火狐里進行跳轉，會有彈窗提示，在其它游覽器則沒有。
如：<a href=”http://www.aaa.com/acb?Url=http://login.aaa.com@test.com“”>http://www.aaa.com/acb?Url=http://login.aaa.com@test.com 后面的test.com就是要跳轉到的域名，前面的域名都是用來輔助以繞過限制的。
0x04 利用白名單缺陷繞過限制
有的域名白名單限制是不全的，比如如果想利用一個跳轉，而這個跳轉是通用，在這個公司網站很多子域名等都可以跳轉，那么你買個域名也不算貴對吧。
為什么這么說呢，這個問題就是白名單限制不當，比如，當跳轉的域名包含這個網站下的所有域名，比如：http://www.aaa.com/acb?Url=http://login.aaa.com
這個login.aaa.com也可以改成aaa.com同樣可以跳轉對吧，因為白名單里只要有包含這個域名就直接成功跳轉。
那么當我在這個域名前面加上如testaaa.com，白名單里會檢查是否包含aaa.com這個域名，如果包含，就直接跳轉，而并沒有檢查這個域名的整個信息，然后可以利用這個問題，直接注冊一個testaaa.com這個域名就可以利用這個跳轉。
0x05 多重驗證&跳轉繞過限制
現在很多網站都有多重驗證，比如你登陸賬戶后會出現另一個驗證頁面，輸入手機驗證碼進行驗證，此時這上面的URL很可能存在任意跳轉的問題。
多重跳轉的問題導致可繞過URL限制
比如http://www.aaa.com/acb?Url=http: … ttp://login.aaa.com
當然，還有多重的，這個結構的多重跳轉你修改最后面的URL就可以達到任意URL跳轉，中間的URL就沒必要動了。
0x06 點擊觸發達到繞過URL跳轉限制
比如很多登陸頁面的地方，其URL是一個跳轉的URL
如：http://www.aaa.com/acb?Url=http://test.com
你直接修改了后面為任意URL，但是還是停留在原地，似乎沒什么問題，但是，當你輸入賬號和密碼后點擊登陸按鈕后，就會觸發跳轉。
當然，這個賬戶和密碼不一定要對的，隨便都可以，但得視系統而定吧。
這個我遇到了很多，比如你修改了域名，然后點擊登陸，登陸成功后便可觸發跳轉，這也是一個比較隱蔽的繞過URL限制的跳轉。
0x07 利用xip.io繞過
這個我還沒有在測試中應用過，其請求是http://www.127.0.0.1.xip.io 這個繞過是在SSRF場景中的繞過，比如SSRF你要讀取內網地址，一般都做了限制，可以嘗試用這方法進行繞過限制，從而訪問到內網。
另外一點，URL跳轉涉及的安全問題大家常見的就是釣魚，那么利用這個思路也可達成一個釣魚問題，如，http://www.qq.com.220.181.57.217.xip.io
當你訪問qq這個域名時，其實這個鏈接已經被解析到后面這個ip地址上了，那么實際訪問的就是后面這個IP地址。
0x08 利用超鏈接繞過可信站點限制
比如一個URL，它是可以直接跳轉的，但是一般測試跳轉時大家習慣用www.baidu.com或qq.com這樣的可信站點進行測試，但是有些網站是可以跳轉這些網站的。
只要是可信站點且常用，基本都可以跳轉，那么這就屬于正常的業務邏輯了，難度就這樣錯失一個URL跳轉漏洞了？
其實不然，只要你的URL被百度收錄過，那么直接搜索你的域名，site:xxx.xxx
因為你在百度里點擊你的域名，它會先是一個302跳轉，而這個302跳轉就是百度下的302跳轉，那么這樣就可以繞過可信站點的限制，從而達到跳轉到指定URL。
當然，百度這個302有點長，你給它進行加密就行。
0x09 POST參數中的URL跳轉
當然，這個影響就很小了，比如當你填什么表格或者需要填寫什么的，當你上傳圖片，點擊下一步的時候，通常下一步就是預覽你填寫的信息，最后才是提交。
當你上傳了圖片后點擊下一步抓包，如果過濾不嚴，你會看到圖片的完整地址包含在POST參數里，你就可以直接修改這個地址為任意URL，然后到達下一步。
這時是確定信息也就是預覽自己填寫的信息的正確還是不正確，由于你剛剛修改了圖片地址，這里是沒有顯示出來的，圖像會是一個小XX。
當點擊圖片右鍵選擇查看圖像時，就會觸發URL跳轉問題，其實這個也可以利用來進行釣魚，釣后臺審核員的信息。
為什么呢，比如審核看到圖片無法加載，一般都會點擊查看圖片，然后跳轉，如果安全意識不知就會造成安全影響。
當然，如果POST參數里就只是URL跳轉參數，那么你可以給它轉成GET方式，然后進行跳轉就可以了，只要網站支持這樣的GET方式就行。
在Burp Suite里可以一鍵轉換提交方式，右鍵選擇Change request method就可以！
0x10 利用#號繞過
如：http://www.aaa.com/acb?Url=http://test.com#login.aaa.com
小結，想找到任意URL跳轉問題，就不要光看表面，一個修改一個回車，不存在就不繼續深入了，這將永遠無法成長。
我總結了我對于URL跳轉繞過限制的一些小點，希望能夠幫助到大家！
原文地址：http://blog.xbbai.site/post-150.html
要：在全球軟件大會上，華為云工程師深度分析了網站在各類極端重大災難場景下，如何快速恢復的高可用保障方案和工程化實踐。
最近，某CDN服務故障，導致海外大批知名新聞網站無法正常訪問或加載，一石激起千層浪。確實，隨著越來越多的業務上云，一個網站或者某個業務能否保證持續的在線，非常考驗背后的高可用、高可靠方案設計。
在第七屆全球軟件大會上，華為軟件工程師杜志剛，就為廣大開發者分享了華為云官網的高可用保障方案，深度分析了網站在各類極端重大災難場景下，如何快速恢復的方案和工程化實踐。
從網站所有者角度來看：網站不可用直接導致的是經濟收入方面的影響，特別對于電商類網站，每分每秒都在產生交易，一旦訪問中斷，經濟損失的影響顯而易見。除此之外，從客戶角度來看，面對網站不可訪問，最直觀的感受是不靠譜，對網站以及網站背后的企業品牌產生不可挽回的口碑及信任度方面的負面影響。
從近十年的互聯網重大故障事件來看，DNS、CDN導致的大范圍影響歷歷在目，其他IT基礎設施導致的區域型及全局型故障也影響甚大。
業界廣泛使用的網站可用性指標包括網站不可用時間及網站年度可用率，不同類型的網站和應用對可用性的要求也不盡相同。
其中網站不可用時間（故障時間）=故障恢復時間點-故障發生時間點。網站年度可用率（Yearly Uptime Percentage）=（1-網站不可用時間/年度總時間）*100%。
華為云官網作為云基礎設施提供商的互聯網訪問入口，對可用性有著極高的要求，面向最終用戶的核心頁面要做到7*24小時在線，如果出現重大故障，如云服務區級別，或基礎設施導致的單云全局故障，5分鐘內告警通知到相關責任人，15分鐘內完成故障切換。
下面結合圖例分析一下網站頁面訪問的整體流程及關鍵故障點：
在①處，DNS故障會通常會導致網站整體不可訪問，到了②是CDN故障會讓部分地理區域用戶不可訪問，③是單云全局故障會導致網站整體不可訪問，④是云服務區級別故障會導致分流到該區域的用戶不可訪問，⑤是云服務可用區級別故障會導致路由到故障AZ的用戶不可訪問，⑥是容器集群故障導致路由到對應容器服務的用戶不可訪問，⑦是服務節點故障會導致路由到故障服務節點的用戶不可訪問。
綜上，云化場景下，頁面訪問面臨諸多的關鍵技術挑戰，包括：
針對以上關鍵挑戰，通過華為云官網近幾年的實踐，總結了4個方案分享給大家，我們將一一拆解，為大家展示這些方案的實際效果。
DNS是相對來說非常重要但卻沒有得到應有重視的薄弱環節，對于可用性要求極高的商業門戶網站，將DNS依托于一家服務商，不出問題風平浪靜，一旦發生全局性故障，導致的影響可能是災難性的。
我們當前的策略是：采用雙DNS廠商域名解析方案，在一家服務商發生部分或整體故障時，可以在短時間內自動實現故障切換，將域名解析工作交給其他服務商完成。此外，我們還構建了統一運維平臺實現多廠商域名解析的統一配置，以及DNS可用性監控、故障服務的快速剔除能力。
雙廠商DNS配置如圖所示：
這個配置的前提是域名注冊商及域名解析商支持多廠商Name Server配置。具體配置方面，首先將域名注冊托管遷移到支持多廠商NS配置的注冊商，然后同步DNS廠商配置的解析記錄到新廠商，最后域名注冊服務及解析服務同時配置NS記錄指向雙廠商Name Server（0~72小時生效）。
這樣配置可以在單個廠商Name Server發生故障時，ISP Local DNS自動將故障Name Server降低選擇優先級（BIND SRTT算法，失敗懲罰），使用優選的Name Server進行A記錄或CNAME域名解析。
演練步驟可以拆解為：
第一步：雙廠商NS記錄配置。
第二步：通過瀏覽器檢查服務可正常訪問。
第三步：撥測Name Server可用性，驗證不同地域ISP是否使用了不同廠商的Name Server進行域名解析。
第四步：關停Bind模擬單個廠商DNS故障。
最后，通過HTTP從多個地域撥測服務是否可以正常訪問。
下面介紹一下多CDN廠商的配置與切換，如圖所示：
使用這個方案的限制條件有三個：DNS協議不支持多廠商CDN的CNAME解析配置；DNS智能解析支持不同地域或網絡配置不同的CNAME解析記錄；CDN出現整體故障概率較低，更多是區域性故障。
多CDN廠商的配置要先對國內及海外訪問分別做主備CDN加速，然后CDN CNAME解析TTL設置為60s，讓單CDN廠商服務不可用時，故障切換生效時間更短；最后是構建CDN管理平臺，對接多廠商DNS管理API，預先配置切換和回切策略，出現故障一鍵切換。
最后的配置效果也很明顯，CDN告警廠商A大面積故障后，可通過CDN運維管理平臺，將對應區域的CNAME解析Failover到廠商B提供服務，生效時間1分鐘。
下圖是我們運維平臺的切換界面示例，可按不同二級域名分國內及海外用戶訪問場景分別切換。
在2020年和2021年我們遇到了實際的現網故障，CDN的故障切換功能得到了有效應用，讓頁面訪問實現了快速故障恢復。
這里介紹了我們中國站和國際站雙站異地多活的組網策略，如圖所示：
如果發生區域性地理災難場景，我們使用站點多Region多活部署，使用這個解決方案要保證內容管理服務發布的頁面內容在多云服務區保持同步。同時，LB及網關路由配置多活云服務區保持一致。
具體配置時，先將國內及海外用戶CDN回源流量按比例分流至不同云服務區；隨后配置健康檢查策略，當出現云服務區級別故障時告警，便于自動或手動切換回源流量至健康的云服務區；如果海外與國內服務存在差異時，通過云廠商內部專線在LB或網關進行跨云服務區路由。
這樣，在非容災場景下，多云服務區同時提供頁面訪問服務，降低單云服務區回源壓力。即便出現云服務區級別故障時，也可通過CDN Admin API實現一鍵故障切換，CDN回源快速回到可用狀態。
如圖所示，通過我們的運維平臺，在單個云服務區故障場景下，可實現故障云服務區的快速剔除，這個過程主要通過批量切換二級域名Region級別回源DNS A記錄實現的。
最后介紹一下整個高可用方案的最底層的保底方案：網站備份與故障切換，首先來看一下網站的備份流程，如圖所示：
運維人員先配置站點元數據及配置備份策略，站點管理根據備份策略下發備份任務到調度服務，然后調度服務再定時調用備份服務執行備份任務。
采集的話是由備份服務啟動Headless Browser加載入口頁，再加載靜態頁面資源，執行頁面腳本加載動態頁面資源，然后執行預置腳本加載動態頁面資源，最后識別頁面跳轉URL，包括HTML標記及腳本觸發的動態跳轉點，啟動新Headless Browser實例，實現級聯爬取。
采集完是存儲，頁面主文檔及相關頁面資源加載完成后通過OBS接口轉儲到對象存儲服務，再通過云廠商提供的對象存儲跨Region同步能力實現頁面內容異地容災。跨云復制則通過跨云同步工具將備份站點頁面內容，同步到其他云廠商對象存儲服務，實現跨云容災。
備份結束后，再看一下故障切換流程。當基礎設施問題等原因導致的單云多Region故障使得Web服務整體不可用時，開始故障檢測，頁面可用性撥測服務監測到云服務區A、B不可用，在5分鐘內發出告警。
往下是故障轉移，成立重大問題應急處理作戰小組，同時打開運維容災管理平臺，查看不可用區域、備份站點撥測是否正常。如果同云備份站點可用，優先切換同云備份站點；如果不可用，第三方云廠商備份站點可用，切換到備份站點。整個切換通過更新回源域名A記錄解析地址指向OBS公網訪問地址實現。
最后是故障修復階段，先定位解決問題，撥測Web Server可用，再手動執行故障回切，然后用戶回歸正常訪問。
以上是在各種極端場景下如何保證網站持續在線的一些實踐經驗的總結，相關方案已經在實際場景下驗證有效，并且做到持續的例行化演練。
另外，對于不同類型或規模的網站，高可用并沒有具體量化的標準，可以給幾個比較粗的級別供參考：最基礎的保證功能可用，不考慮網元的單點問題。要求再高一點，考慮應用服務集群化部署、DB、緩存等中間件進行相應的高可用部署，確保沒有基本的單點問題。再往上考慮多數據中心部署，解決單數據中心不可用問題。最后是考慮異地多活或容災，應對某一地理區域災難的場景。
除了以上傳統套路外，隨著越來越多的企業都在上云，還要考慮單個云廠商基礎設施發生整體故障時如何快速替換及逃生的問題，例如CDN，DNS等，這些都是網站訪問基礎場景要重點考慮的故障點。
關注@華為云，了解更多資訊
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
