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

%{eEa U,X9M6N0本文对SQL自动注入中的汉字问题，提出了自己的一点看法和主张。如果有什么不妥的地方，希望大家批评指正。同时附上一个字符编码综合查询工具，可以在汉字－汉字Unicode编码－Asc码中互查。51Testing软件测试网6X:jT~[/\P]D(X

　　Access中汉字猜解
au!B+Da+sUgW]051Testing软件测试网'c?V j
pQl
　　对于Access，其字符处理函数与SQL Server中不一样，见下表。
6k%L t,iL$R051Testing软件测试网#jz.?&y3nd:Q.p~1w
　　Access SQL Server 说明
T1^9OA;fs c051Testing软件测试网K:oL)S6O*L Sd
　　asc(字符) unicode(字符) 返回某字符的编码
L5C:~1OL0
jZy9Sb8VH/GM!a3\0　　chr(数字) nchar(数字) 与asc相反，根据数字编码返回字符51Testing软件测试网k%D-k,J:G*O u-~Lb
51Testing软件测试网 }br0DV}
　　mid(字符串,N,L)51Testing软件测试网{V{1A%x!@

0u5G\&[w-zu$~*}0　　substring(字符串,N,L)51Testing软件测试网[NA#qgUu

w7zZ-HpIS9y0　　返回字符串从N个字符起长度为L的子字符串，即N到N+L之间的字符串51Testing软件测试网)Q?O`*Md _7z
51Testing软件测试网aONaI
　　在猜测汉字时，我们也可以用 GetFieldValue(iUrl,TableName,FieldName,PrimaryKey,PKValue,minlen,maxlen) 函数调用，不过有几点需要注意：
i5t?Osi3Wo0
a*n Fd8pqZe0　　1．查询条件，由于字符处理函数与SQL Server中不同，修改为：
D gK4f$O051Testing软件测试网"N\*x9amT;X0d
　　CheckFieldValue=" and 1=(select count(*) from [TABLE] where [IDN]=[ID] and asc(mid([FN],[POS],1))> [N])"51Testing软件测试网Hy&F0V/d~!w
51Testing软件测试网R&M(K-h-{ I1A$Wtu
　　2．Asc码的取值范围。汉字通过ASC 函数运算后的取值范围，我没有试验过，不知道最小值是负的多少。所以这儿的取值范围下限指定多少就看你的了，只要包括你猜解的汉字就行了。不过范围适当大一点也没有关系，毕竟这儿的处理函数指数级缩小猜测范围，大不了多计算几次而已。
9pOGmdS!cH H:}o0
7m\;|~9l0　　至于上限值，去零肯定不会有问题。如果有ASCII字符,取值上限指定为255就可以了，我想这对计算时间来说，几乎没有什么影响，至多猜一个字符多计算一次而已。为了通用性，还是取255吧。51Testing软件测试网2ah7t#FX;^U*v

4`~-Du#b#BI+UYH0　　3．GetFieldValue函数中得到ASC值后，直接用chr()函数转化成汉字或字符，不用再调用字符对照表。51Testing软件测试网7v,N$q8j?4}#O_'D
51Testing软件测试网4[ U1Yp`9p}
　　我重看了这篇文章N遍，感觉Asscess中汉字猜测范围总有些不妥，毕竟时间就是生命，这儿多几次，那儿多几次，对于单个字符来说，可能不算什么，可如果猜测的数据量比较大后这就可能对程序执行效率造成很大的影响。经过我对chr函数的参数测试后，发现chr函数的参数有效范围是-32768-65535，所以汉字的ASC码取值范围（-32768，0），经过16次猜测运算，便可以知道对应的ASC码，如果加上ASCII字符，则需要17次猜解运算。
K @5f+Pn,Y0
q0u+G#c"]bz0　　本文对SQL自动注入中的汉字问题，提出了自己的一点看法和主张。如果有什么不妥的地方，希望大家批评指正。同时附上一个字符编码综合查询工具，可以在汉字－汉字Unicode编码－Asc码中互查。