Langouster
First, let's talk about URL encoding. The hexadecimal notation of % plus two characters represents a character. For example, 'After encoding is % 27. This is a URL encoding rule that everyone knows, URL Decoding functions such as UrlUnescapeInPlace are based on this idea.
However, why should we be so obedient? Imagine what would happen if % followed by a hexadecimal number but abc % hh. First look at UrlUnescapeInPlace,
Try writing a small program, abc % hh After decoding or abc % hh; then look at asp. how to decode the dll and write response to the asp page. write (request. queryString ("str"), and then use? Str = abc % hh access it. The page displays abchh, which directly removes %.
Now let's take a look at whether the string obtained by the Information Monitoring System is sele % ct if we submit sele % ct. Of course it is not a dangerous character and it will not intercept, but for ASP, the result can be select. Similarly, '%' can be used, for example, and exists (select * from admin) it can be converted to the following string a % nd ex % ists (% select * % from ad % min ). This method can be used in the same way. For example, you can use % to replace %, or you can use other methods. For details, see RFC2396.
The above is only for the GET method analysis, POST has not been tried, but conjecture is also acceptable. The above method is effective for all current IIS firewalls, including VIF.
Supplement: I have discovered this vulnerability for some days. I didn't want to disclose it. I sent an email to top-level information monitoring people two times the other day to remind them, however, they did not seriously consider what I said. They also said that the first-class information system could add encoded injection characters to the filter list, and they did not know what they thought, he thinks it's okay to add a sele % ect filter rule? What about sele % ct? What about sele % ct ?? In view of this indifferent attitude, I made public this vulnerability and hoped that they could learn from it.