静态防护SQL注入
SQL注入的防护一直是焦点话题，从编程角度看最有效的防护是对用户输入的变量通过参数来传递，而不是直接嵌入到SQL语句，但缺陷：
1.不是所有的数据库和编程语言都有相应的参数化功能;
2.编写时面对众多的输入模块，难免会有疏漏;
3.难以批量化和统一部署。
还有一些方法就是把参数进行分类，比如用户递交的参数值统一转换成纯数字或纯字符串类型、加密用户输入、限制输入长度等，但和以上方法的缺陷一样。
比如这段代码是直接把用户输入放置数据库的SQL语句中进行执行，如果不对member_login变量进行过滤和判断是可以注入攻击的：
---漏洞代码段---
member_login=trim(request("login"))
set rs=server.createobject("ADODB.Recordset")
sql="select * from job_Member where Member_login='"&member_login&"'"
rs.open sql,conn,1,3
如果一一检查和修复需要花费大量的精力，而很多网站上线运营之后需要提高安全性的普遍举措是采用一些编写好的通用性的函数，原理是对输入进行判断和过滤，它在一定程度上能缓解攻击行为，并且花费成本相对不大.
以上代码首先需要定义相对完整的过滤字符集，然后分别处理用GET和POST方式提交的数据报文，在需要防护的页面里调用包括它既可[an error occurred while processing this directive]
但是编写统一的防止注入函数有缺陷：
1.需要考虑不同语言的不同语法，不能统一，比如ASP、PHP、Java;
2.要充分考虑每一个可能用户输入的地方，但往往会有疏漏;
3.虚拟机往往有大量站点，而管理者是单个站点的属主，系统管理员没权利也没能力统一定制防护措施;
4.如果是IDC或者大型企业的机房，会有更大量不同类型的WEB应用服务器，要实现批量防护则更困难;
5.消耗服务器运算资源和网络带宽，因为大批量的网络连接和提交数据都需要经过函数来处理;
6.过滤不严谨则容易被攻击者绕过。
最后一点其实很关键，不仅仅是过滤不严谨，而且攻击者对于输入可变化大小写，拼接攻击语句，甚至构造字符的不同编码方式，比如字符 < 可被编码为 <、<、< 或 %3c，而编码方式又是如此之多，Unicode、十六进制、ASIIC、UTF-8等，所以用防护函数方式是非常困难的。
通过上面描述，我们知道了从编程方式来防御攻击具有它的局限性，简单概括：会有疏漏、消耗性能、难以统一、运算复杂等。
而这时WAF的优点就体现出来了，绿盟科技WAF内置了50多条精心配制的规则，用于防护SQL注入，有人可能会疑问这么少的规则能有效防御吗?要知道虽然SQL注入的语句千变万化，但规则只需要找出共同点进行匹配即可，并且可在此基础上自定义规则。规则制定后可用于WAF后需要保护的不同类型的多台WEB服务器，类型一致的可使用同一规则，对于大型WEB群来说这具有无可比拟的优越性。它的优点如下：
1.统一定制的规则能批量适用于不同类型的网站;
2.花费时间和精力最少，无论是应用或编辑规则都方便，不用每台WEB服务器去部署;
3.即使网站存在漏洞，也能在前端把攻击流量给予清洗和阻断;
4.网站无需处理错误的探测，避免把错误处理方式和信息暴露给攻击者，同时也节省了服务器的处理资源。
