URL Hacking - 前端猥瑣流
0x00 目錄
0x01 連結的構成
0x02 瀏覽器算如何對url進行解析的
0x03 連結真的只能是這樣固定的格式麼?
0x04 連結真的是你看到的那樣麼?
0x01 連結的構成
連結真的只能固定成我們常用的格式麼?
不知道有多少人思考過這個問題!我們經常輸入的格式一般都是www.xxxx.com!
或者再加上協議名 http https 埠以及路徑什麼的 或者再加上賬號密碼!如下圖: 
第一部分:協議名(以單個冒號結束)
第二部分:使用者資訊 也就是賬號密碼!(登陸ftp時常用)
第三部分:主機名(也就是域名)
第四部分:埠
第五部分:查詢,這裡有個bug。。。 應該是?號後的內容才是查詢!
第六部分:片段ID(是不會傳送到伺服器的!)
0x02 瀏覽器是如何對url進行解析的
我們都知道我們訪問一個網站是帶有協議的比如http ftp https 等等!
首先瀏覽器會提取我們連結中的協議名,它是如何提取的呢?
(以下為copy web之困上的內容 他寫的比較詳細!)
1.提取協議名:
他會查詢第一個 :
號在哪,如何找到了 那麼:
號左邊的便是協議名!如果獲得的協議名中出現了不該有的字元,那麼認為這可能就是個相對的url 獲得的並不是協議名!
2.去除層級url標記符:
字串 //
應該算跟在協議名後面的 如果發現有該字元 則會跳過該字元 如果沒有找到便不管了!所以 http:baidu.com 也是可以訪問的! 瀏覽器中還可以用反斜槓來代替正斜杆 \\
代替 //
firefox除外!
3.獲取授權資訊部分:
依次掃描url,如果這三個符號中 哪個先出現便以哪個為準來擷取
/(正斜槓)
?(問號)
#(井號)
從url裡提取出來的資訊,就算授權部分資訊!
除了IE跟safari其他瀏覽器還接受 ;(分號)也算授權資訊部分中可接受的分隔符!
(1)定位登陸資訊,如果有的話:
授權部分資訊提取出來後,在擷取出來的資訊裡再來查詢 @ 如果找到了 那麼他前面的部分便是登陸資訊!登陸資訊再查詢 : (冒號) 冒號前面的便是賬號 後面便是密碼!
(2)提取目標地址
授權資訊部分剩下的便是目標地址了 第一個冒號分開的就算主機名跟埠!用方括號括起來的就是ipv6地址,這也是個特例!
結合以上資訊 我們分析下以下連結:
ftp://admin:[email protected]:21
這樣的連結我經常用來登陸ftp!這樣便會以admin的身份 密碼為:admin
ftp協議去登陸主機192.168.1.100,埠號是21埠!
4.確定路徑(如果的確存在)
如果授權部分的結尾跟著一個正斜杆,某些場景裡,跟著一個反斜槓或者分號,就像之前提到的,依次掃描下一個? # 或字串結尾符,那個先出現便以哪個為準!擷取出來的部分就是路徑資訊!最後根據unix路徑語義進行規範化整理!
5.提取查詢字串(如果的確存在)
如果在上一條解析裡,後面跟著的是一個問號,便繼續掃描下一個 # 或到字串結尾,哪個先出現便以哪個為準!中間的部分便是查詢字串。
6.提取片段ID
如果成功解析完上一條資訊,它最後還跟著#號 那麼從這個符號到字串的結尾便算片段ID了,片段ID是不會傳送到伺服器的!一般用來跳到A標籤的錨連結 或者用來js的 location.hash 取值 等等!
如果大家去年跟著wooyun的基友們一塊玩爛了基礎認證釣魚的話那麼應該能回想起來!當時很多網站在插入圖片的地方都判斷了字尾名是不是圖片的字尾名jpg gif等等!但是hook不是gif 什麼結尾的!當時的方法便是在hook後面加上#.jpg!這樣便可以成功的來釣魚了!原理也是一樣的!
下面我們拿幾個例子來解析一下:
例子1:
http://xss1.com&[email protected]
這樣一個連結在普通使用者看來 是會認為訪問xss1.com的!
但是實際上是去往www.baidu.com 的!為什麼呢?結合以上的知識我們分析一下!
首先 協議名提取出來了 然後獲得授權部分資訊,? / # 都未出現 瀏覽器便無法獲得一個字串來獲得主機地址![email protected] @符前面的便認為是登陸資訊 並不會當做主機名來解析!所以現在xss1.com&action=test 已經被當做登陸資訊了 現在唯一的主機名便只有www.baidu.com了!
而xss1.com&action=test在我們訪問網站的時候 被當做了登陸了資訊去訪問www.baidu.com了!
例子2:
http://xss1.com\@www.baidu.com
首先看下這個連結在chrome中的樣子:
很明顯的看到 這樣一個連結在chrome中是會去訪問xss1.com的!
現在我們來看下在firefox下的樣子:
會提示我們是否要用賬號為:xss1.com\的資訊去訪問www.baidu.com!
這是為什麼呢?瀏覽器差異 我們在之前也說了!
因為在除了firefox外,其他的瀏覽器都會把(反斜槓當做正斜槓來解析!)
而正斜槓的出現就代表授權資訊部分結束了!因為提取授權部分資訊是用 \ ? #
所以授權資訊部分結束 那麼前面的便當成了主機名!
而firefox是不會把\當成正斜槓的 [email protected] 便算登陸資訊 後面的就是主機名!所以當用firefox去訪問這個連結時 才出現了 上圖中的提示!
例子3:
http://xss1.com;.baidu.com/
由於機器沒有IE 就不上圖了吧!
微軟瀏覽器允許主機名稱中出現 ; (分號)併成功的解析到了這個地址!當然還需要baidu.com提前做了這樣的域名解析設定!
大多數其他瀏覽器會自動的把url糾正成http://xss1.com/;.baidu.com/
然後使用者就訪問到了xss1.com(safari除外,它會認為這個語法錯誤)
0x03 連結真的只能是這樣固定的格式麼?
不知道有多少人想過這個問題,連結真的只能是這樣麼!
透過上面的介紹後,相信大家應該會說No了!
我記得之前有篇文章講,xss載入鉤子的時候 http://
做黑名單內!於是那位兄弟便拆分了http://
var i='http';
var b='://';
這樣也是一種辦法 但是我們有沒有更好的辦法呢? 答案肯定是有的 //www.baidu.com 也是可以被載入的!
(當前網頁的協議是什麼 載入這個鉤子便用什麼協議來載入! 如在https協議的網頁中 這樣載入鉤子 那麼預設就是https去載入鉤子了!)
到了這裡,我們不得不思考 這樣能正常的開啟一個網頁 我們還有什麼方法來載入網頁?這時候我們可以fuzz一下!
如下圖:
可以看到//後面我們還能輸入tab,換行,/ @ \
等等!那我們來測試一下!構造如下連結去訪問一下!
\\/www.baidu.com
\\@www.baidu.com
\\[email protected]
\\\\\\\www.baidu.com
///////www.baidu.com
等等全部能正常的訪問到百度!大家可以自己試一下!最好的話寫在a 標籤 或者 img script裡把!這樣更貼近我們平常所遇到的環境!

既然我們在文章的標題提到了猥瑣 這樣夠猥瑣?No 還不夠!這樣我們的連線始終還是帶著一定的特徵!
www .com .net 什麼的特徵還在,既然說到猥瑣 我們就要更加猥瑣!比如下面這樣的一串字串!
ⅅʳºℙˢ --> drops
ʷººʸⓊⁿ —> wooyun
Ⓞʳℊ —> org
最後拼湊 :
ⅅʳºℙˢ.ʷººʸⓊⁿ.ºʳℊ
變成這樣也是能夠訪問的 大家可以試試!
那麼這樣一段字串是如何得來的呢?
我們可以透過http:/xsser.me/hf.html來fuzz!
在fuzz之前先給科普一下:
針對域名的編碼:Punycode
經過Punycode編碼後的域名是會被DNS伺服器所識別的!
就拿中文域名來說,因為作業系統的核心都是英文組成,DNS伺服器的解析也是由英文程式碼交換,所以DNS伺服器上並不支援直接的中文域名解析。 所有中文域名的解析都需要轉成punycode碼,然後由DNS解析punycode碼。最後我們成功的訪問到了我們要去網站!只不過今天我們這裡punycode編碼的解析過程並不是由dns伺服器來解析的 而是在瀏覽器訪問時就給解碼回來!
在drops中瞌睡龍的文章也提到過!
說了這麼多,開始把!(也順便講一下這個玩意應該怎麼用)
首先我們算要測試url 所以要先把 Callback 中的 x.protocol 改成hostname!
然後再把hostname等於的值也改掉,改成我們要測試的主機名!(別帶上協議名)
比如drops.wooyun.org
然後再在exp裡把A標籤的連結改成帶有協議名的主機名!(不帶的話不能訪問)
都設定好 如下圖:
下面的小引數可以使用預設的!引數都設定好了,現在我們要標識 我們要測試哪個字元,用:{chr} 代替該字元即可!
好,現在設定好後點選Fuzzing 槍打出頭鳥 我們就先測d吧!
可以看到右邊的框裡出現了一段數字,這段數字是ASCii碼每個字元以逗號分割!
我們可以使用工具把ASCii碼給轉換回來,不過我比較喜歡chrome 方便!
現在我們複製他們!然後丟chrome裡把他們給還原回來!開啟控制檯(F12)
輸入String.fromCharCode(ASCII碼) 回車便出來了!
好經過測試我們得出第一個字元 d 可以使用
DdⅅⅆⅮⅾⒹⓓDd
來代替!
這裡我就不一一的fuzz給大家看了!我們貼出最後經過fuzz後的字串吧!
http://ⅅʳºℙˢ.ʷººʸⓊⁿ.ºʳℊ
大家可以複製 然後訪問一下!依然是能夠訪問的到的!
但是這裡也侷限於需要一個可以解析的中介軟體才能訪問!
如果curl的話就不行了!
為什麼呢?很簡單因為沒解析 curl他不會去解析這個字串!
而瀏覽器為什麼能夠正常訪問 算因為他會對我們編碼後的值進行解析再訪問!
所以這點也算需要知道的!
可是這種情況我們在哪能用到呢?我們往下看!
如果在插入鉤子的時候或其他什麼的時候,對方算基於黑名單過濾的www .com .org什麼的,那麼便可以用這種方式去繞過!
這裡的思路大家就去擴散下 有什麼更猥瑣的思路求交流!
再來個例子吧!
首先拿一個被騰訊認為是危險網站的紅X站
可以看到這個連結發出來是會被當做危險網站的!
現在我們對其中的一個字元fuzz!為什麼是一個字元?
(因為你fuzz的字元多了 會被當成符號 讓騰訊認為這不是一個連結!然後就不 能一點就會開啟網頁了 比如這樣。。。)
可以看到這樣帶的符號多了 讓騰訊這不是一個連結 就不會生成個超連結了!
所以我們一般只fuzz幾個字元便好了!
說幹就幹,我們來開始測試吧!
原連結:http://laohujijiqiao8.com
還是用 http://xsser.me/hf.html 來fuzz
經過fuzz 測試出來 http://laohujijiqiao8.com 的o 可以用以下的字元來代替! 
O o º ℴ Ⓞ ⓞ O o
現在我們來測試一下!
http://laohujijiqiaº8.com
發出去 看還帶沒帶危險網站的標識!上圖: 
現在已經沒有標識這是個危險網站的 並且還能夠正常開啟!是不是已經達到我們的目的了呢?
之前用這種方式把一個藍色標示的網站弄成顯示為騰訊官網!連結如下:
http:[email protected]#
(ps:以前沒加#號時 還是藍色連結 但是加了#號就顯示為騰訊的官網了!)
因為前面的連結:www.qq.com 傳送出去是會顯示為騰訊官方網站的!但是現在好像不行了!
0x04 連結真的是你看到的那樣麼?
有人在社群裡發了這麼個帖子:百度URL跳轉 繞過騰訊紅XX
可是我們真的需要要有url跳轉漏洞才能跳轉麼?
No 任何網站都可以!如下:
http:[email protected]
把這段地址填入瀏覽器中 訪問會發現去了 www.qq.com了 而並不是平常大家所認為的www.baidu.com 這是為什麼,我們可以看看此篇文章的開頭!
http:// 後面可以算userinfo 也就算使用者資訊 賬號密碼什麼的!
[email protected]! 所以我們這段連結為什麼去qq.com 而不是去baidu.com [email protected] 讓瀏覽器認為www.baidu.com 算一段使用者資訊 而後面的才算主機名 他要去訪問的地址!
所以我們有時候偽裝找不到跳轉漏洞也可以如此實現!
然而在chrome 跟firefox下 還可以這麼寫:
http:[email protected]
協議名沒有// 也會被認為是http://
沒看過web之困或者之前沒接觸過data uri的基友們!可能看了上面這個小例子就會很驚歎了 原來還可以這樣!
在web之困中還講了其實url地址是可以用進位制來代替的!只不過算把ip地址給轉換成進位制來訪問!
十進位制 ---||||||> 十六進位制 ---||||||> 八進位制 然後在訪問時 指定協議然後加個0
http://0[八進位制] 比如 115.239.210.26 首先用.分割數字 115 239 210 26 然後選擇10進位制轉換16進位制!
(要用0來表示字首,可以是一個0也可以是多個0 跟XSS中多加幾個0來繞過過濾一樣!)
首先把這四段數字給 轉成 16 進位制!結果:73 ef d2 1a 然後把 73efd21a 這十六進位制一起轉換成8進位制!

結果:16373751032
然後指定協議 http:// 用0表示字首 加上結果 連結:
http://0016373751032
成功解析成我們原來的ip了!
結合最開始的一個例子:
http://xss1.com&[email protected]
後面還帶著www.baidu.com 太打眼了,現在把我們上面轉換後的地址加在後面 記得帶上0字首!
http://xss1.com&[email protected]
這樣就不打眼了 看上去舒服多了 有木有?
既然解析回來了 那我們看看能不能用這個地址來載入一些資源比如圖片 js什麼的!

可以看到成功載入了圖片!那應該也是載入js等等的!
相信有擴散性的基友們都有想法了,平時用來繞過一些限制等等!
具體的大家去實驗吧!web的世界 無窮大啊!
相關文章
- 程式設計師,猥瑣發育,別浪!2019-03-19程式設計師
- 做一猥瑣的而高潔的單身狗2021-09-09
- PHP後門新玩法:一款猥瑣的PHP後門分析2020-08-19PHP
- 猥瑣發育別浪?《王者榮耀》這次告訴你:該浪就浪2019-07-29
- Hacking PostgreSQL2020-08-19SQL
- Hacking weblogic2020-08-19Web
- Hacking with Unicode2020-08-19Unicode
- 檔案下載(URL,文件流)2019-03-26
- 前端補充:url編碼2024-04-09前端
- Hacking Hit Tests2019-02-27
- Embedded devices hacking2020-08-19dev
- Hacking Oracle with Sql Injection2020-08-19OracleSQL
- 前端工作流2018-03-18前端
- 前端基礎迴歸-URI和URL2022-01-26前端
- 前端自動化部署伺服器, 告別繁瑣部署過程2019-11-15前端伺服器
- 瑣碎記錄2019-02-18
- Hacking ipcam like Harold in POI2020-08-19PCA
- 前端常用的小函式(1)—解析url2019-02-16前端函式
- php函式瑣記2019-05-11PHP函式
- [ARC059F] Unhappy Hacking2024-04-01APP
- Pocket Hacking: NetHunter實戰指南2020-08-19
- 滲透Hacking Team過程2020-08-19
- 前端必知必會--操作URL的黑科技2019-06-14前端
- [前端 · 面試 ]HTTP 總結(十二)—— URL 和 URI2021-08-14前端面試HTTP
- 【前端 · 面試 】HTTP 總結(十二)—— URL 和 URI2021-08-14前端面試HTTP
- Hacking Team攻擊程式碼分析2020-08-19
- 前端工程工作流規範2019-03-03前端
- 前端如何下載檔案流2021-10-22前端
- Hacking Team系列 Flash 0Day分析2020-08-19
- Hacking Team 新 Flash 0day分析2020-08-19
- Hacking the D-Link DIR-890L2020-08-19
- C語言瑣碎知識2020-11-21C語言
- 前端效能優化之節流-throttle2018-11-19前端優化
- 精讀《前端資料流哲學》2018-07-10前端
- Mvvm 前端資料流框架精講2018-04-01MVVM前端框架
- 談談 Java 中的那些“瑣”事2020-09-22Java
- 關於http的瑣碎筆記2019-06-13HTTP筆記
- Mybatis-flex代替繁瑣的JPA2024-10-06MyBatisFlex