MySql sql注入问题
什么是SQL注入?
SQL注入是影响企业运营最具有破坏性的漏洞之一。
应用程序向后台数据库进行SQL查询时,如果为攻击者提供了影响该查询的能力,就会引起SQL注入。
示例:
name = "Robert');DROP TABLE students;--"
query = "INSERT INTO students (name) VALUES ('%s')" % (name)
conn.executescript(query)
也就是说,这段包含DROP TABLE关键字的数据项使得原有的简单的插入姓名信息的SQL语句:
INSERT INTO students (name) VALUES ('Robert')
变为了同时包含另外一条清除表单命令的语句:
INSERT INTO students (name) VALUES ('Robert');DROP TABLE students;
防护方法与解决方案
例如:
1使用PreparedStatement,避免直接使用Statement对象
Statement对象可能造成sql注入:
直接使用 JDBC 的场景,如果代码中存在拼接 SQL 语句,那么很有可能会产生注入,如
// concat sql
String sql = "SELECT * FROM users WHERE name ='"+ name + "'";
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(sql);
安全的写法是使用 参数化查询 ( parameterized queries ),即 SQL 语句中使用参数绑定( ? 占位符 ) 和 PreparedStatement,如
// use ? to bind variables
String sql = "SELECT * FROM users WHERE name= ? ";
PreparedStatement ps = connection.prepareStatement(sql);
// 参数 index 从 1 开始
ps.setString(1, name);
还有一些情况,比如 order by、column name,不能使用参数绑定,此时需要手工过滤,如通常 order by 的字段名是有限的,因此可以
使用白名单的方式来限制参数值
使用了 PreparedStatement 并不意味着不会产生注入,如果在使用 PreparedStatement之前,存在拼接 sql 语句,
那么仍然会导致注入,如
// 拼接 sql
String sql = "SELECT * FROM users WHERE name ='"+ name + "'";
PreparedStatement ps = connection.prepareStatement(sql);
PreparedStatement 是如何防止 SQL 注入的?
正常情况下,用户的输入是作为参数值的,而在 SQL 注入中,用户的输入是作为 SQL 指令的一部分,会被数据库进行编译/解释执行。
当使用了 PreparedStatement,**带占位符 ( ? ) 的 sql 语句只会被编译一次,**之后执行只是将占位符替换为用户输入,并不会再次编译/解
释,因此从根本上防止了 SQL 注入问题。
在 select * from table where 后面拼接一些条件来获取你的信息
Mybatis下注入防范
应尽量避免采用{}的方式传
参),那就需要对传入参数自行进行转义过滤。
使用 #{} 语法时,MyBatis 会自动生成 PreparedStatement ,使用参数绑定 ( ?) 的方式来设置值,上述两个例子等价的 JDBC 查询代码如下:
String sql = "SELECT * FROM users WHERE id = ?";
PreparedStatement ps = connection.prepareStatement(sql);
ps.setInt(1, id);
因此 #{} 可以有效防止 SQL 注入,
但有些时候,如 order by 语句,使用 #{} 会导致出错,如
ORDER BY #{sortBy}
sortBy 参数值为 name ,替换后会成为
ORDER BY "name"
即以字符串 “name” 来排序,而非按照 name 字段排序
这种情况就需要使用 ${}
ORDER BY ${sortBy}
使用了 ${}后,使用者需要自行过滤输入,方法有:
代码层使用白名单的方式,限制 sortBy 允许的值,如只能为 name, email 字段,异常情况则设置为默认值 name
在 XML 配置文件中,使用 if 标签来进行判断
Mapper 接口方法
List<User> getUserListSortBy(@Param("sortBy") String sortBy);
<select id="getUserListSortBy" resultType="org.example.User">
SELECT * FROM user
<if test="sortBy == 'name' or sortBy == 'email'">
order by ${sortBy}
</if>
</select>
因为 Mybatis 不支持 else,需要默认值的情况,可以使用 choose(when,otherwise)
<select id="getUserListSortBy" resultType="org.example.User">
SELECT * FROM user
<choose>
<when test="sortBy == 'name' or sortBy == 'email'">
order by ${sortBy}
</when>
<otherwise>
order by name
</otherwise>
</choose>
</select>
JPA注入防范
从SQL注入防范的角度来说,这种将安全责任抛给框架远比依靠程序员自身控制来的保险。因此如果项目使用JPA作为数据访问层,基本
上可以很大程度的消除SQL注入的风险。但是话不能说的太死,在我见过的一个Spring Boot项目中,虽然采用了JPA作为持久框架,但是
有一位老程序员不熟悉于使用JPQL来构建查询接口,依旧使用字符串拼接的方式来实现业务,而为项目安全埋下了隐患。
,程序员只要遵循JPA的开发规范,就无需担心注入问题,框架都为你做好幕后工作了。
sql注入的其他防范方法
- 一切输入都是不安全的:对于接口的调用参数,要进行格式匹配,例如admin的通过name查询的接口,与之匹配的Path应该使用正
则匹配(因为用户名中不应该存在特殊字符),从而确保传入参数是程序控制范围之内的参数,即只接受已知的良好输入值,拒绝不
良输入。注意:验证参数应将它与输出编码技术结合使用。 - 利用分层设计来避免危险:前端尽量静态化,尽量少的暴露可以访问到DAO层的接口到公网环境中,如果现有项目,很难修改存在注
入的代码,可以考虑在web服务之前增加WAF进行流量过滤,当然代码上就不给hacker留有攻击的漏洞才最好的方案。也可以在拥有
nginx的架构下,采用OpenRestry做流量过滤,将一些特殊字符进行转义处理。 - 尽量使用预编译SQL语句:由于动态SQL语句是引发SQL注入的根源。应使用预编译语句来组装SQL查询。
- 规范化:将输入安装规定编码解码后再进行输入参数过滤和输出编码处理;拒绝一切非规范格式的编码。