資訊來源：邪惡八進位資訊安全團隊（www.eviloctal.com）
先來說URL編碼，%加兩位的16進製表示一個字元，比如’經過編碼之後就是%27，這是人人都知道的URL編碼規則，UrlUnescapeInPlace之類的API函數甚至於程式師自己寫的URL解碼函數都是基於這一思想。
然而，我們何必如此聽話，試想一下要是%後跟的不是16進制數位而是像abc%hh會發生什麼事呢。先看UrlUnescapeInPlace，
寫個小程式試一下，abc%hh經過解碼還是abc%hh；再看asp.dll是怎麼解碼的，在asp頁面中寫入 response.Write(request.QueryString("str"))，然後用?str=abc%hh訪問它，頁面顯示abchh，它直接把%給去掉了。
現在來思考要是我們提交sele%ct，資訊監控系統得到的字串還是sele%ct，當然它不是危險字元，它就不會攔截，但對於ASP，它得到的可就是select了，其它的同理，’可用%’表示，比如and exists(select * from admin)可轉化為以下字串a%nd ex%ists(%select * %from ad%min)。此方法可舉一反三，比如用%%代替%都可以，還可以是其它的，具體的可以去看RFC2396。
以上僅是對於GET方式的分析，POST沒試過，不過猜想也是可以的。並且經測試以上方法對目前的所有IIS防火牆都有效，包括VIF。
補充：其實發現這個漏洞已經有好些日子了，本來我是不想公開的，前些天兩次給一流資訊監控的人發寄件提醒他們，但他們就是沒認真考慮我說的問題，還說一流資訊系統可以把經過編碼的注入字元也加到過濾清單中，不知道他們是怎麼想的，他是覺得再加一條sele%ect過濾規則就可以了？那sele%%ct呢，也加上？那sele%%%ct呢？？鑒於一流這種無所謂的態度我就公開此漏洞，希望他們能以此為鑒。
全站熱搜
留言列表
