一個罕見的MSSQL注入漏洞案例
這里作者準備分享一個在去年Google賞金計劃中發現的相當罕見漏洞，也是作者在整個滲透測試生涯中***一次遇到的。
目標網站使用了微軟 SQL Server 數據庫并且其中一個存在 SQL 盲注。你問我怎么知道的?當然是通過觸發真/假條件判斷的。
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 但沒有一種能夠成功，再進一步研究后發現，應用程序只會對用戶權限提交的整數值進行響應。
對此我一點辦法也沒有，直到發現了 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 --> 頁面顯示空白
進一步閱讀后發現，我實際上是在嘗試查詢 MSSQL 里是否存在 Transact-SQL 其返回類型為 int 或 smallint。通常，返回類型都有自己自身的值。例如：
@@LANGID 默認通常為 0 (英語)
@@TEXTSIZE 可能比 1000 大
繼續進行測試，我嘗試使用其他 Transact-SQL 語句來確保結果不為假，的確最終大部分的查詢語句都返回為真:)
在提交了這個有限的 POC 給網站的所有者后，非常幸運的他們確認了這個漏洞并給予獎勵!
下面是在一臺測試服務器上進行的實驗：
聲明：我仍然沒有理解這到底是為什么，還需要在后續花一些時間進行研究以找到原因:)
