這里作者準備分享一個在去年Google賞金計劃中發(fā)現(xiàn)的相當罕見漏洞，也是作者在整個滲透測試生涯中***一次遇到的。

[[163451]]

目標網(wǎng)站使用了微軟 SQL Server 數(shù)據(jù)庫并且其中一個存在 SQL 盲注。你問我怎么知道的?當然是通過觸發(fā)真/假條件判斷的。

http://bounty/yadayada.asp?id=8888'+AND+'1'+LIKE+'1 --> 頁面正常顯示

http://bounty/yadayada.asp?id=8888'+AND+'2'+LIKE+'1 --> 頁面顯示空白

這里沒什么特別的地方，就是一個常見的 SQL 注入測試，但隨后問題來了：

1. 手工測試表明存在 SQL 盲注漏洞

2. 但掃描器/SQLMap 不起作用

3. 好像使用了存儲過程方法(不確定)

我嘗試了多種方法提供 POC 但沒有一種能夠成功，再進一步研究后發(fā)現(xiàn)，應用程序只會對用戶權(quán)限提交的整數(shù)值進行響應。

對此我一點辦法也沒有，直到發(fā)現(xiàn)了 v1d0q 提供的一個方法 https://rdot.org/forum/showthread.php?t=826 (ps:俄語，小編表示看不懂啊(ノ=Д=)ノ┻━┻)

當時這對我來說是種全新的方法，但令人驚訝的是這樣真的管用!

http://bounty/yadayada.asp?id=8888'+AND+(@@TEXTSIZE>@@LANGID)+AND+'1'+LIKE+'1 --> 頁面正常加載

http://bounty/yadayada.asp?id=8888'+AND+(@@LANGID>@@TEXTSIZE)+'1'+LIKE+'1 --> 頁面顯示空白

進一步閱讀后發(fā)現(xiàn)，我實際上是在嘗試查詢 MSSQL 里是否存在 Transact-SQL 其返回類型為 int 或 smallint。通常，返回類型都有自己自身的值。例如：

@@LANGID 默認通常為 0 (英語)

@@TEXTSIZE 可能比 1000 大

繼續(xù)進行測試，我嘗試使用其他 Transact-SQL 語句來確保結(jié)果不為假，的確最終大部分的查詢語句都返回為真:)

在提交了這個有限的 POC 給網(wǎng)站的所有者后，非常幸運的他們確認了這個漏洞并給予獎勵!

下面是在一臺測試服務器上進行的實驗：

聲明：我仍然沒有理解這到底是為什么，還需要在后續(xù)花一些時間進行研究以找到原因:)