SQL注入#和$区别与总结

子豪_002

1.#{}  将传入的数据都当成一个字符串，会对自动传入的数据加一个双引号。  
如：order by #user_id#，如果传入的值是111,那么解析成sql时的值为order by "111",   
如果传入的值是id，则解析成的sql为order by "id".  

2.$将传入的数据直接显示生成在sql中。如：order by $user_id$，如果传入的值是111,那么解析成sql
时的值为order by user_id,   
如果传入的值是id，则解析成的sql为order by id.  

3.#{}方式能够很大程度防止sql注入。  

4.$方式无法防止Sql注入。  

5.$方式一般用于传入数据库对象，例如传入表名.  

6.一般能用#的就别用$.  

MyBatis排序时使用order by 动态参数时需要注意，用$而不是#  

防范SQL注入攻击的方法：  

既然SQL注入式攻击的危害这么大，那么该如何来防治呢?下面这些建议或许对数据库管理员防治SQL
注入式攻击有一定的帮助。  
　　1、 普通用户与系统管理员用户的权限要有严格的区分。  
　　如果一个普通用户在使用查询语句中嵌入另一个Drop Table语句，那么是否允许执行呢?由于Drop
语句关系到数据库的基本对象，故要操作这个语句用户必须有相关的权限。在权限设计中，对于终端
用户，即应用软件的使用者，没有必要给他们数据库对象的建立、删除等权限。那么即使在他们使用
SQL语句中带有嵌入式的恶意代码，由于其用户权限的限制，这些代码也将无法被执行。故应用程序
在设计的时候，最好把系统管理员的用户与普通用户区分开来。如此可以最大限度的减少注入式攻击
对数据库带来的危害。  

　　2、 强迫使用参数化语句。  
　　如果在编写SQL语句的时候，用户输入的变量不是直接嵌入到SQL语句。而是通过参数来传递这
个变量的话，那么就可以有效的防治SQL注入式攻击。也就是说，用户的输入绝对不能够直接被嵌
入到SQL语句中。与此相反，用户的输入的内容必须进行过滤，或者使用参数化的语句来传递用户输
入的变量。参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。采用这种措施，可以
杜绝大部分的SQL注入式攻击。不过可惜的是，现在支持参数化语句的数据库引擎并不多。不过数据
库工程师在开发产品的时候要尽量采用参数化语句。  

3、 加强对用户输入的验证。  

　　总体来说，防治SQL注入式攻击可以采用两种方法，一是加强对用户输入内容的检查与验证;二
是强迫使用参数化语句来传递用户输入的内容。在SQLServer数据库中，有比较多的用户输入内容
验证工具，可以帮助管理员来对付SQL注入式攻击。测试字符串变量的内容，只接受所需的值。拒
绝包含二进制数据、转义序列和注释字符的输入内容。这有助于防止脚本注入，防止某些缓冲区溢
出攻击。测试用户输入内容的大小和数据类型，强制执行适当的限制与转换。这即有助于防止有意
造成的缓冲区溢出，对于防治注入式攻击有比较明显的效果。  

　　如可以使用存储过程来验证用户的输入。利用存储过程可以实现对用户输入变量的过滤，如拒
绝一些特殊的符号。如以上那个恶意代码中，只要存储过程把那个分号过滤掉，那么这个恶意代
码也就没有用武之地了。在执行SQL语句之前，可以通过数据库的存储过程，来拒绝接纳一些特殊
的符号。在不影响数据库应用的前提下，应该让数据库拒绝包含以下字符的输入。如分号分隔符，
它是SQL注入式攻击的主要帮凶。如注释分隔符。注释只有在数据设计的时候用的到。一般用户
的查询语句中没有必要注释的内容，故可以直接把他拒绝掉，通常情况下这么做不会发生意外损
失。把以上这些特殊符号拒绝掉，那么即使在SQL语句中嵌入了恶意代码，他们也将毫无作为。

　　故始终通过测试类型、长度、格式和范围来验证用户输入，过滤用户输入的内容。这是防止
SQL注入式攻击的常见并且行之有效的措施。  

实例：JSP使用过滤器防止SQL注入  

　　4、 多多使用SQL Server数据库自带的安全参数。  
　　为了减少注入式攻击对于SQL Server数据库的不良影响，在SQLServer数据库专门设计了相对安
全的SQL参数。在数据库设计过程中，工程师要尽量采用这些参数来杜绝恶意的SQL注入式攻击。  
　　如在SQL Server数据库中提供了Parameters集合。这个集合提供了类型检查和长度验证的功能。
如果管理员采用了Parameters这个集合的话，则用户输入的内容将被视为字符值而不是可执行代码。
即使用户输入的内容中含有可执行代码，则数据库也会过滤掉。因为此时数据库只把它当作普通的
字符来处理。使用Parameters集合的另外一个优点是可以强制执行类型和长度检查，范围以外的值
将触发异常。如果用户输入的值不符合指定的类型与长度约束，就会发生异常，并报告给管理员。
如上面这个案例中，如果员工编号定义的数据类型为字符串型，长度为10个字符。而用户输入的内
容虽然也是字符类型的数据，但是其长度达到了20个字符。则此时就会引发异常，因为用户输入的
内容长度超过了数据库字段长度的限制。  

　　5、 多层环境如何防治SQL注入式攻击?  
　　在多层应用环境中，用户输入的所有数据都应该在验证之后才能被允许进入到可信区域。未通
过验证过程的数据应被数据库拒绝，并向上一层返回一个错误信息。实现多层验证。对无目的的恶
意用户采取的预防措施，对坚定的攻击者可能无效。更好的做法是在用户界面和所有跨信任边界的
后续点上验证输入。如在客户端应用程序中验证数据可以防止简单的脚本注入。但是，如果下一层
认为其输入已通过验证，则任何可以绕过客户端的恶意用户就可以不受限制地访问系统。故对于多
层应用环境，在防止注入式攻击的时候，需要各层一起努力，在客户端与数据库端都要采用相应的
措施来防治SQL语句的注入式攻击。  

　　6、 必要的情况下使用专业的漏洞扫描工具来寻找可能被攻击的点。  
　　使用专业的漏洞扫描工具，可以帮助管理员来寻找可能被SQL注入式攻击的点。不过漏洞扫描
工具只能发现攻击点，而不能够主动起到防御SQL注入攻击的作用。当然这个工具也经常被攻击者
拿来使用。如攻击者可以利用这个工具自动搜索攻击目标并实施攻击。为此在必要的情况下，企业
应当投资于一些专业的漏洞扫描工具。一个完善的漏洞扫描程序不同于网络扫描程序，它专门查找
数据库中的SQL注入式漏洞。最新的漏洞扫描程序可以查找最新发现的漏洞。所以凭借专业的工具，
可以帮助管理员发现SQL注入式漏洞，并提醒管理员采取积极的措施来预防SQL注入式攻击。如果
攻击者能够发现的SQL注入式漏洞数据库管理员都发现了并采取了积极的措施堵住漏洞，那么攻击
者也就无从下手了。  

7、设置陷阱账号：  

设置两个帐号，一个是普通管理员帐号，一个是防注入的帐号。将防注入的账号设置的很象管理员，
如 admin，以制造假象吸引软件的检测，而密码是大于千字以上的中文字符，迫使软件分析账号的
时候进入全负荷状态甚至资源耗尽而死机。  

攻击与防御一直是对立存在的两面，有新的攻击方式就会有更好的防护方法！在计算机网络方面两
者更是通过长期竞争实现共同的进步；任何系统都不是完美的，既然我们不能开发出绝对安全的系
统，那我们就要时刻防范各种可能的攻击。出现漏洞及时修复，这样才能保证我们系统的安全与稳定！