不久前对学校的一个主机进行友情渗透，网站采用的是一套自行开发的ASP+Access程序。也没问是什么表结构，顺利找到一注入点。文章表取了5个字段，能够正常显示的字段索引值为（2、3、5），管理员表为Admin，猜中两个常用字段：ID、Password，采用逆推法：union select 1,1,* from admin时正常返回，得知admin表有3个字段，用户名字段不得而知。遗憾的是，这个用户名字段只能显示在4的位置（后来得知为adminuser），如表1所示： 1 2 3 4 5 1 1 ID Adminuser Password 表1 想来是心有不甘，我随随便便将2改为ID提交（union select 1,ID,* from admin），令人意想不到的是，系统报错： Microsoft JET Database Engine 错误 ’80040e14’ 在联合查询中所选定的两个数据表或查询中的列数不匹配。 /list_kx.asp，行11 我以为看错了眼，核实了一下列数，1+ID+*（3）= 5，怎么不对啊？计算机连数个数都错了？既然你说我错了，我给你凑！ 提交union select ID,* from admin，错！union select 1,1,ID,* from admin，正常！我就纳闷了：1+1+ID+*（3）= 6，你居然还能正常返回！？6怎么就等于5了呢？还好学了点数据库理论： DBMS 和RDBMS的重要区别在于：RDBMS提供丁一种面问集合的数据库语言。对于大多数的RDBMS，这种面向集合的数据库语言就是SQL。“向向集合”是指SQL同时处理—组数据，换句话说，每次查询的返回结果，是一个集合（结果集）。而一个集合中的元素是没有重复出现的，在两个集合的并集中，两个元素的公共元素只能出现一次。于是，union select 1,1,* from admin的结果集等同于union select 1,1,ID,* from admin，不同之处在于，*（所有列）变了： *1 = {ID,Adminuser,Password},*2 = {Adminuser,Password} 请注意这样一个重要事实：我们改变了“*”（所有列）！ 但是仅仅这样的改变对于我们的猜解仍是毫无意义的，用户名字段Adminuser还是在列索引为4的位置上，幸好我们还有一张王牌：Password字段！ 提交union select 1,1,Password,* from admin！如愿以偿，通过改造*，成功的将用户名字段曝光。如表2所示。 1 2 3 4 5 1 1 Password ID Adminuser
表2 以上只是最简单的一种情况，以动力文章3.0版(Access)为例，printpage.asp有SQL注入漏洞，变量ArticleID未作过滤，sql="select * from article where ArticleID=" & ArticleID & ""，查询的是ARTICLE表，28个字段，我们Union了ADMIN表，这个表有8个字段，表结构如下： ID | Username | Password | Purview | LastLoginIP | LastLoginTime | LastLogoutTime | LoginTimes 观察出能够显示的字段索引值为（3、4、5、8、14），如果未猜得足够的字段名，假设我们只知道ID字段，使用*，加上对ADMIN表进行3次自联接，再加4位配凑字段，提交这样的查询语句： union select 1,1,1,1,* from ((admin as a inner join on admin as b on a.id = b.id) inner join on admin as c on a.id = c.id)，结果很不幸，Password字段不能显示出来，如表3所示： 5 …… 8 …… 14 a.ID …… a.Purview …… b.Username
