sql防注入

sql语句：通过SQL语句，实现无帐号登录，甚至篡改数据库。

SQL注入攻击实例

比如在一个登录界面，要求输入用户名和密码：
可以这样输入实现免帐号登录：
用户名： ‘or 1 = 1 –
密 码：
点登陆,如若没有做特殊处理,那么这个非法用户就很得意的登陆进去了.(当然现在的有些语言的数据库API已经处理了这些问题)
这是为什么呢? 下面我们分析一下：
从理论上说，后台认证程序中会有如下的SQL语句：
String sql = “select * from user_table where username=
’ “+userName+” ’ and password=’ “+password+” ‘”;
当输入了上面的用户名和密码，上面的SQL语句变成：
SELECT * FROM user_table WHERE username=
‘’or 1 = 1 – and password=’’
分析SQL语句：

条件后面username=”or 1=1 用户名等于 ” 或1=1 那么这个条件一定会成功；
然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用，这样语句永远都能正确执行，用户轻易骗过系统，获取合法身份。

最简单的方法解决办法
1：PreparedStatement

PreparedStatement 实例包含已编译的 SQL 语句。这就是使语句“准备好”。包含于 PreparedStatement 对象中的 SQL 语句可具有一个或多个 IN 参数。IN参数的值在 SQL 语句创建时未被指定。相反的，该语句为每个 IN 参数保留一个问号（“？”）作为占位符。每个问号的值必须在该语句执行之前，通过适当的setXXX 方法来提供。

注入是发生在预编译过程中，setXXX传参过去，只是将其当做字符串传过去。避免了对sql进行解析。

当然其他的，有诸如字符串过滤，正则表达式之类的方法，就不赘述了，我认为最简单的就是最好的方法。

那么在常见的例如ssm框架中，mybatis，我们是如何防注入的呢???

这就要知道，mybatis和entity之间联系是如何建立的。

在mybatis中通过mapper映射到接口层->resultMap映射到具体的entity类->constructor里面再去对应表的每一个列单元
见下图

对于防注入，要点破的是，它的底层还是PrepaerStatement预编译在起作用。
但在取值的形式上，#{}和${}是由区别的

尽量采用“#{xxx}”这样的格式。若不得不使用“${xxx}”参数，做好过滤工作，来防止SQL注入攻击。

#{}：相当于JDBC中的PreparedStatement

${}：是输出变量的值