简单分析SQL注入中对汉字的猜解

Access中汉字猜解

    对于Access，其字符处理函数与SQL Server中不一样，见下表。

Access SQL Server 说明
asc(字符) unicode(字符) 返回某字符的编码
chr(数字) nchar(数字) 与asc相反，根据数字编码返回字符
mid(字符串,N,L)
substring(字符串,N,L)

    返回字符串从N个字符起长度为L的子字符串，即N到N+L之间的字符串

    在猜测汉字时，我们也可以用 GetFieldValue(iUrl,TableName,FieldName,PrimaryKey,PKValue,minlen,maxlen) 函数调用，不过有几点需要注意：

    1．查询条件，由于字符处理函数与SQL Server中不同，修改为：

    CheckFieldValue=" and 1=(select count(*) from [TABLE] where [IDN]=[ID] and asc(mid([FN],[POS],1))> [N])"

    2．Asc码的取值范围。汉字通过ASC 函数运算后的取值范围，我没有试验过，不知道最小值是负的多少。所以这儿的取值范围下限指定多少就看你的了，只要包括你猜解的汉字就行了。不过范围适当大一点也没有关系，毕竟这儿的处理函数指数级缩小猜测范围，大不了多计算几次而已。

    至于上限值，去零肯定不会有问题。如果有ASCII字符,取值上限指定为255就可以了，我想这对计算时间来说，几乎没有什么影响，至多猜一个字符多计算一次而已。为了通用性，还是取255吧。

    3．GetFieldValue函数中得到ASC值后，直接用chr()函数转化成汉字或字符，不用再调用字符对照表。

    我重看了这篇文章N遍，感觉Asscess中汉字猜测范围总有些不妥，毕竟时间就是生命，这儿多几次，那儿多几次，对于单个字符来说，可能不算什么，可如果猜测的数据量比较大后这就可能对程序执行效率造成很大的影响。经过我对chr函数的参数测试后，发现chr函数的参数有效范围是-32768- 65535，所以汉字的ASC码取值范围（-32768，0），经过16次猜测运算，便可以知道对应的ASC码，如果加上ASCII字符，则需要17次猜解运算。

    本文对SQL自动注入中的汉字问题，提出了自己的一点看法和主张。如果有什么不妥的地方，希望大家批评指正。同时附上一个字符编码综合查询工具，可以在汉字－汉字Unicode编码－Asc码中互查。