背景：
机房收费系统验收的时候，师父提到SQL注入攻击。自己以前看过类似的博客大概知道一些这方面的事情，于是自己动手查了查。
定义：
所谓SQL注入，通过SQL命令插入到Web表单提交或者输入域名或页面请求的查询字段，达到欺骗服务器执行恶意的SQL命令。
这样说大家可能对这个理解不是特别深刻，下面我就举一个生活中的小例子，大家一看就明白了。
这是一张相当有技术含量的车牌遮挡，其对交警系统SQL Injection的hack案例。当摄像头拍到这个车牌号，并转换成文本时，插入数据库的SQL注入。可能会执行该SQL语句，然后删除掉关于这个车的信息。这就是一个小的SQL注入。大家可以想象程序员不是“好惹”的吧！
分类：
关于SQL注入可以分为平台层注入和代码层注入。其中平台层注入由不安全的数据库配置或数据库平台的漏洞所致；代码层注入主要由于程序员对输入未进行细致的过滤，从而执行了非法的数据查询。
产生原因：
1、不当的类型处理。
2、不安全的数据库配置。
3、不合理的查询集处理。
4、不当的错误处理。
5、转义字符处理不合适。
6、多个提交处理不当。
攻击步骤：
发现SQL注入位置——判断后台的数据库类型——确定XP_CMDSHELL（xp_cmdshell 扩展存储过程将命令字符串作为操作系统命令 shell 执行，并以文本行的形式返回所有输出。）可执行情况——发现WEB虚拟目录——上传ASP木马（它是用ASP编写的网站程序。它和其它ASP程序没有本质区别，只要是能运行ASP的空间就能运行它，这种性质使得ASP木马非常不易被发觉。）——得到管理员权限——SQL注入式攻击（详细见：SQL注入攻击步骤）
如图为SQL注入攻击过程：
防SQL注入攻击过程：
现阶段的应对方法，从安全技术手段上来说，可以通过数据库防火墙实现对SQL注入攻击的防范，因为SQL注入攻击往往是通过应用程序来进攻，可以使用虚拟补丁技术实现对注入攻击的SQL特征识别，实现实时攻击阻断。
君子不立危墙之下：
在这个大数据时代，信息侵入防不胜防，我们要做的就是尽可能防止产生SQL注入攻击。所以要遵循几条非常基本的规则：
1、在构造动态SQL语句是，一定要使用类安全（type-safe）的参数加码机制。
2、在部署应用之前，始终要做安全审评（security review）。
3、千万别把敏感性数据在数据库里以明文存放。
4、确认你编写了自动化的单元测试，来特别校验你的数据访问层和应用程序不受SQL注入攻击。
5、锁定你的数据库安全，只给访问数据库的web应用功能所需的最低的权限。
6、很多新手从网上下载SQL通用防注入系统的程序，在需要防范注入的页面头部用来防止别人进行手动注入测试。
7、对于注入分析器的防范，笔者通过实验，发现了一种简单有效的防范方法。首先我们要知道SQL注入分析器是如何工作的。在操作过程中，发现软件并不是冲着“admin”管理员账号去的，而是冲着权限（如flag=1）去的。这样一来，无论你的管理员账号怎么变都无法逃过检测。
既然无法逃过检测，那我们就做两个账号，一个是普通的管理员账号，一个是防止注入的账号，为什么这么说呢？笔者想，如果找一个权限最大的账号制造假象，吸引软件的检测，而这个账号里的内容是大于千字以上的中文字符，就会迫使软件对这个账号进行分析的时候进入全负荷状态甚至资源耗尽而死机。下面我们就来修改数据库吧。
⒈对表结构进行修改。将管理员的账号字段的数据类型进行修改，文本型改成最大字段255（其实也够了，如果还想做得再大点，可以选择备注型），密码的字段也进行相同设置。
⒉对表进行修改。设置管理员权限的账号放在ID1，并输入大量中文字符（最好大于100个字）。
⒊把真正的管理员密码放在ID2后的任何一个位置（如放在ID549上）。
在TD时代，“存在的就是合理的”这个理论不仅仅应用于好的方面，对于SQL注入攻击也一样，为什么会有这样的弊端，说明我们的编程还不够完美，说明有好多人在一次又一次的挑战这个社会。本身应用程序开发过程中的不严密，对于大多数防火墙来说，这种攻击是“合法”的。我们要做的只有不断的完善编程~~~~~~