这几天sql-inject的量有些大，每天snort记录的扫描探测都有几万条。特别是有一些小分网站脚本陈旧，这方面的处理存在很大漏洞，的确存在一些sql-inject的漏洞，有些探测已经得到了web应用的用户管理表数据。
脚本众多，要协调程序部门修改是一个过程，很头疼。只好临时在nginx上做了一些URL判断，把符合规则的一些url访问导向到临时页面中。
nginx中内置的变量函数可以达到这个目的：
nginx.conf
# 定义一个错误吗和相应页面
error_page 519 http://www.wp1998.cn/ids444.html;
# 判断$request_uri中包含的字符是否同时含有and select from，定义的比较宽松，如果严格点可以把所有含有%20and%20的都转移到错误输出上。当然，也可以把return改为rewrite重写到另外的url。
if ($request_uri ~* "(%20and%20)*(select%20)*(%20from%20)") {
return 519;
}
# 定义一个错误吗和相应页面
error_page 519 http://www.wp1998.cn/ids444.html;
# 判断$request_uri中包含的字符是否同时含有and select from，定义的比较宽松，如果严格点可以把所有含有%20and%20的都转移到错误输出上。当然，也可以把return改为rewrite重写到另外的url。
if ($request_uri ~* "(%20and%20)*(select%20)*(%20from%20)") {
return 519;
}
应用之后构造如下的url试试，直接转移到定义的错误页面了。
http://www.wp1998.cn/read.php?152 and (select ascii(substr(user_pwd,5,1)) from admin where 1=1 limit 36,1)>128 and 1=1
希望代码人员不要因为这样暂时做了URL字符匹配，仍不改变那些不良的代码习惯。
sql-inject的确是目前web上很普遍的一个安全问题，特别是一些缺少维护能力的政府和公司网站，简单尝试了几个基本都能拿到表结构，看来去做web安全的生意还是很有市场的 
dfadfs