DNS Rebinding 廣泛用於繞過同源策略、SSRF過濾等。
為什么需要SSRF過濾器：
• 由於一些業務的需要，他們就是需要讓用戶輸入URL，然后進行跳轉，如果過濾得好，這就是一個正常功能，如果過濾得不好，那么這里就存在SSRF漏洞。
SSRF過濾器設計
有漏洞的SSRF過濾器執行步驟如下：
- 獲取輸入的URL，從該URL中提取HOST，如果提取出來的是IP，那么直接跳到第三步；
- 對該HOST進行DNS解析，獲取到解析的IP；
- 檢測該IP是否是合法的，比如是否是私有IP等（是就直接終止流程）；
- 如果IP檢測為合法的，則進入CURL發包；
漏洞點：
我們從DNS解析的角度看，該檢測方式一共有兩次，第一次是步驟2中對該HOST進行DNS解析，第二次是使用CURL發包的時候進行解析。這兩次DNS解析是有時間差的，我們可以使用這個時間差進行繞過。
其實上面就已經講清楚DNS Rebinding漏洞的原理了，只不過只有大致步驟，下面我們就通過具體實現來深入了解。
背景知識
了解DNS Rebinding漏洞的利用步驟前，了解一些這些背景知識還是很有必要的。
DNS TTL
TTL值全稱是“生存時間（Time To Live)”，簡單的說它表示DNS記錄在DNS服務器上緩存時間，數值越小，修改記錄各地生效時間越快。
當各地的DNS(LDNS)服務器接受到解析請求時，就會向域名指定的授權DNS服務器發出解析請求從而獲得解析記錄；該解析記錄會在DNS(LDNS)服務器中保存一段時間，這段時間內如果再接到這個域名的解析請求，DNS服務器將不再向授權DNS服務器發出請求，而是直接返回剛才獲得的記錄；而這個記錄在DNS服務器上保留的時間，就是TTL值。
常見的設置TTL值的場景：
• 增大TTL值，以節約域名解析時間
• 減小TTL值，減少更新域名記錄時的不可訪問時間
公網DNS服務器
比如大名鼎鼎的：
114.114.114.114
8.8.8.8
...
DNS重綁定
需要自己持有一個域名，然后將這個域名解析指向自己的DNS Server，在該域名寫2個解析服務。
同樣是test.exploitcat.xyz.域名，卻寫上了兩個A記錄。這樣做的目的就是，寫2個解析服務，這樣每次請求的時候都能返回不同的解析結果。
• 第一次請求DNS查詢，結果返回的是101.191.60.117，是一個合法的公網IP；
• 第二次請求時，變成了私有IP 10.36.5.215；
簡單來說就是已知服務器會向DNS服務器發送兩次解析請求，目的就是要讓第一次解析出來是個外網ip，第二次解析出來是個內網ip。
同一個域名綁定兩條A記錄。這樣解析是隨機的。 (ps:同時綁定兩條A記錄，在請求解析的時候並不一定交替返回)
注意，這兩條記錄的ttl都是0，這是為了防止有DNS服務器對解析結果進行緩存。現在國內購買的域名大都無法直接將TTL設置為0，例如我的阿里雲的域名，最小的TTL是10分鍾。而某些國外的域名可以設置TTL=0。
記住：TTL數值越小，修改記錄各地生效時間越快。
自建DNS服務器
上面說的DNS重綁定，有個不好的點，就是解析是隨機的，需要多次訪問才能得到自己想要的內網IP。但是如果使用自建DNS服務器，那么就可以穩定的控制返回結果。
常見的技術方案：搭建DNS服務器采用python的twisted庫中的name模塊。具體技術細節自行搜索吧。
利用步驟圖解
有了上面的背景知識鋪墊，下面就可以開始看利用步驟圖了。
建議看看里面的流程圖：https://www.freebuf.com/column/194861.html
步驟6解釋，當你請求外部惡意http://www.a.com時，www.a.com就加載了一個JS腳本，這個腳本的作用就是等待你機器的DNS緩存時間一到，就立馬重新自動訪問www.a.com。
這個圖畫了多個箭頭，會讓一些人覺得是發送了多次HTTP請求，其實只發送了一次HTTP請求，只不過進行了兩次DNS解析操作。
實戰中的注意事項
抄這里的：https://blog.csdn.net/u011721501/article/details/54667714
事實上，基於DNS Rebinding的繞過方式在實戰中可能會遇到一些問題。
問題一是DNS緩存的問題，即使我們在前面實現的時候設置了TTL為0，但是有些公共DNS服務器，比如114.114.114.114還是會把記錄進行緩存，完全不按照標准協議來，遇到這種情況是無解的。但是8.8.8.8是嚴格按照DNS協議去管理緩存的，如果設置TTL為0，則不會進行緩存，從效果上來看，每次dig都會跑去我們的NS服務器上去查詢一遍。
問題二是DNS迭代查詢和遞歸查詢的問題，往往這邊發起攻擊，DNS服務器會收到很多不同IP的查詢請求，無法確定與受害服務器相關的來源IP是哪個。為此我一共實現了3版解析腳本，第一版很容易想到，首先對來源IP進行搜集，保存在文件中，然后真實發起請求的時候基於IP列表進行解析，但是后來發現還是很多莫名其妙的來源IP過來。但是仔細查看這些IP，發現都是某個B段或者C段的，很固定，因此第二版是基於IP段過濾，但是又有這種解析flag標志位交替不准確的問題。
最終，我實現一個時間窗口，用這個時間窗口去返回解析內容，比如前5s返回結果1，后5s返回結果2，對於時間窗口的具體值，需要探測階段進行統計和嘗試。
防御
可以重新設計一下SSRF過濾器，在第四步中：4.如果IP檢測為合法的，則進入CURL發包。 執行到發包流程的時候，直接換成IP訪問訪問WEB服務，並且判斷IP是否符合規則，不符合規則的IP直接結束流程。
參考
https://blog.csdn.net/u011721501/article/details/54667714
https://www.freebuf.com/column/194861.html
http://bendawang.site/2017/05/31/關於DNS-rebinding的總結/