java专家之路（四）——Web安全之——SQL注入风险

简介：

https://www.owasp.org/index.php/SQL_Injection
SQL注入攻击（SQL Injection），简称注入攻击，是Web开发中最常见的一种安全漏洞。可以用它来从数据库获取敏感信息，或者利用数据库的特性执行添加用户，导出文件等一系列恶意操作，甚至有可能获取数据库乃至系统用户最高权限。

而造成SQL注入的原因是因为程序没有有效过滤用户的输入，使攻击者成功的向服务器提交恶意的SQL查询代码，程序在接收后错误的将攻击者的输入作为查询语句的一部分执行，导致原始的查询逻辑被改变，额外的执行了攻击者精心构造的恶意代码。

防范方法：

一：根本解决方法（规范框架写法）

• 避免使用动态SQL、拼接SQL语句的方式。

  一般来说，底层提供的持久化框架都提供了比较完善的能够用于满足80%左右业务需求的操作，当我们在使用框架的标准接口进行操作时，一般都不会发生SQL注入，是因为框架在进行SQL语句翻译的时候进行了预处理，通常都是使用了preparestatement进行SQL语句的预处理。因此，我们可以放心地使用这些标准的API。
  特殊情况，提供了原生的SQL语句查询，这个时候我们就需要格外注意，例如：一些ORM框架，JPA标准的实现等

• 避免直接操作jdbc的接口进行编程，推荐使用更高级抽象的框架.

  例如：JPA的实现Hibernate、Spring-data-jpa，spring-template-jdbc，mybatis等
  如果业务特殊，非得使用的话，一定要使用preparedstatement进行预处理，并使用？占位符。其实就是对参数进行了编码预处理

• 使用参数化参数，而不是拼接动态SQL语句

各类持久化框架仿SQL注入写法参考：

1、 Mybatis

参考文章：https://blog.csdn.net/aosica321/article/details/56675368

错误示例：

正确写法：

2、 JPA

基本不用考虑注入类问题。
但是，如果有以下写法的话：

String expected = "SELECT e FROM Customer e WHERE e.name = :name"

请使用如下方式：

3、 原生JDBC

错误示例：

// Example #1
String query = "SELECT * FROM users WHERE userid ='"+ userid + "'" + " AND password='" + password + "'";
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(query);

// Example #2
String query = "SELECT * FROM users WHERE userid ='"+ userid + "'" + " AND password='" + password + "'";
PreparedStatement stmt = connection.prepareStatement(query);
ResultSet rs = stmt.executeQuery();

正确的打开姿势如下！

JDBC的预处理

在上文的接口中，DAO使用了比较基础的JDBC的方式进行数据库操作，直接使JDBC构建DAO在比较老的系统中还是很常见的，但这并不意味着使用JDBC就一定不安全，如果我将传入的参数 xxxx’or’a’=’a 整体作为参数进行name查询，那就不会产生SQL注入。在JDBC中，提供了 PreparedStatement （预处理执行语句）的方式，可以对SQL语句进行查询参数化，使用预处理后的代码如下：

所有的 ’ 都被 \’ 转义掉了,从而可以确保SQL的查询参数就是参数，不会被恶意执行，从而防止了SQL注入。

4、 JdbcTempleta

使用参数化查询来避免SQL注入的问题
示例：

String sql = " delete from wb_label_relation where sourceid= ?"  + "and type= ?";
this.getJdbcTemplate().update(sql,id,type);

参考资料：
https://www.jianshu.com/p/c1a92243b1f2