java的sql注入一般是在两个场景下会产生，一个是JDBC未对参数进行过滤，一个是对mybatis使用${}来进行传参。让我们先来了解一下JDBC。

　　在几年前框架还未盛行的时候，很多cms和项目都是采用JDBC进行数据库连接和获取数据的。在使用JDBC时，代码中如果存在拼接SQL语句，就有可能产生注入，例如：

　　　　String sql = "SELECT * FROM users WHERE name ='"+ name + "'";

　　　　Statement stmt = connection.createStatement();

　　　　ResultSet rs = stmt.executeQuery(sql);

　　而注入一般的防御方法都是采用预编译，利用占位符？来对参数进行类型的绑定。JDBC中使用的是PreparedStatement。

　　　　String sql = "SELECT * FROM users WHERE name= ? ";

　　　　PreparedStatement ps = connection.prepareStatement(sql);

注：1、例如order by、column name需要手工过滤，可以使用白名单的方式来限制参数值

　　2、在使用 PreparedStatement 之前，存在拼接 sql 语句，仍然会导致注入

　　现在java开发大部分使用ssm框架来进行开发，m即是mybatis。在 MyBatis 中，使用 XML 文件 或 Annotation 来进行配置和映射，将 interfaces 和 Java POJOs (Plain Old Java Objects) 映射到 database records。

　　MyBatis 使用 #{} 和 ${} 来进行参数值替换。使用 #{} 语法时，MyBatis 会自动生成 PreparedStatement ，使用参数绑定 (?) 的方式来设置值。而使用 ${} 语法时，MyBatis 会直接注入原始字符串，即相当于拼接字符串，因而会导致 SQL 注入。

　　如需使用${}时，可进行白名单过滤，在xml文件中设置一个if判断。如

　　　　SELECT * FROM user

　　　　<if test="xxx == 'name' or xxx == 'email'"> order by ${xxx} </if>

在若依4.6.2版本中，就存在${}的注入漏洞。

　　入口处在，可以看出访问地址是system/role/list，一个后台注入漏洞，调用了roleService的selectRoleList进行处理。

　　接着直接查看sql语句的执行即可，一般都会存在xml的执行语句

　　可以看出，最后一行使用了${}对参数进行处理，了解过ssm框架防注入的都知道，这种情况是存在注入的。

　　后台角色管理处，抓包修改