java防注入原理和sql运行过程
谈及java防注入就要谈及sql运行过程，只有理解了sql运行过程，才能理解预编译，才能深入了解java防注入的实现原理
1 sql注入
sql注入，简单来说就是用户在前端web页面输入恶意的sql语句（拼接的sql语句）来欺骗后端服务器去执行恶意的sql代码，从而导致数据库数据泄露或者遭受攻击。
2 解决sql注入方法
2.1 那么如何解决sql注入？
在JDBC进行连接时使用PreparedStatement类去代替Statement,或者传入的条件参数完全不使用String字符串，同样地，在用mybatis时，则尽量使用#{param}占位符的方式去避免sql注入（${param}可以通过拼接参数实现sql注入）。
2.2 防止sql注入原理
这两个不同环境下解决sql注入实际原理是一致的。当使用PreparedStatement去写sql语句时，程序会对该条sql首先进行预编译，然后会将传入的字符串参数以字符串的形式去处理，即会在参数的两边自动加上单引号（’param’），而Statement则是直接简单粗暴地通过人工的字符串拼接的方式去写sql，那这样就很容易被sql注入。这里就需要理解sql运行过程（后面会讲到）
那么，如果PreparedStatement只是仅仅简单地通过把字符串参数两边加上引号的方式去处理，一样也很容易被sql注入，下面举个例子带着大家简单了解下sql注入。
创建user表（id,name,class）;
create table user
(
id int4 PRIMARY KEY,
name VARCHAR(20) not null,
class VARCHAR(20)
)
里面有如下几条数据：
INSERT INTO `user` VALUES ('1', 'Tom', '1班');
INSERT INTO `user` VALUES ('2', 'Jeery', '2班');
这里我们使用mybatis的$ {param} 和 #{param} 两个不同的占位符来作为示例解释 Statement 和 PreparedStatement (mybatis和jdbc的低层原理是一样的)。不了解mybatis的读者可以暂时放下这个疑问，或者搜索查看下${}和#{}的区别。
首先{}是不能防止sql注入的，它能够通过字符串拼接的形式来任意摆弄你的sql语句，而#{}则可以很大程度上地防止sql注入，下面是关于这个的一条sql：
<mapper namespace="com.sky.dao.UserMapper">
<select id="query" parameterType="com.sky.model.User" resultType="com.sky.model.User">
select * from user where name = '${name}'
</select>
</mapper>
- 前端页面的简略的代码：
<form action="<%=basePath%>query" method="get">
<input type="input" placeholder="请输入姓名" name="name"/><input type="submit" value="查询"/>
</form>
前端页面通过form表单的形式输入查询条件并调用后端sql。如果使用的是${param}占位符
select * from user where name = ${name}
当在前端传入参数为：Tom，则对应sql为：select * from user where name = ‘Tom’；这时只显示Tom的数据。
但是，如果其传入参数为：‘Tom’ or 1=’1；则传到后台之后其对应的sql就变为：select * from user where name = ‘Tom’ or 1=’1’；此时得到的为全表数据，这个就有了很大的问题。
将mybatis中的sql语句改为：select * from user where name = #{name}
如果传入的参数为：Tom，依旧为Tom的一行数据，输入：张三’ or 1=’1 则显示为空。
那么它的原理又是什么呢？我带着这个问题去寻找答案，很显然，寻找答案的最好方式就是去看源代码。于是找到mysql-jdbc连接的源代码，查看PreparedStatement类的源代码，其中setString()方法的源代码如下：
这段代码的作用是将java中的String字符串参数传到sql语句中，并通过驱动将其转换成sql语句并到数据库中执行。这段代码中前面一部分做了一些是否需要对字符串进行转义的判断。后面一部分则是如何有效防止sql注入的重点，代码中通过一个for循环，将字符串参数通过提取每一位上的char字符进行遍历，并通过switch()….case 条件语句进行判断，当出现换行符、引号、斜杠等特殊字符时，对这些特殊字符进行转义。那么，此时问题的答案就出来了，当我们使用PreparedStatement进行传参时，若传入参数为：'Tom’ or 1 = ‘1 时，经过程序后台进行转义后，真正的sql其实变成了： select * from user where name = ‘Tom\’ or 1 = \’1’；显然这样查询出来的结果一定为空。
/**
* 传入下标和参数
* @param parameterIndex
* @param x
* @throws SQLException
*/
/** Is this query a LOAD DATA query? */
//此查询是加载数据查询吗？
protected boolean isLoadDataQuery = false;
public void setString(int parameterIndex, String x) throws SQLException {
synchronized (checkClosed().getConnectionMutex()) {
// if the passed string is null, then set this column to null
//如果传递的字符串为空，则将此列设置为空
if (x == null) {
setNull(parameterIndex, Types.CHAR);
} else {
checkClosed();
//获取参数长度
int stringLength = x.length();
if (this.connection.isNoBackslashEscapesSet()) {
// Scan for any nasty chars
//调用isEscapeNeededForString()方法扫描任何恶意的字符(防注入检测)，
//返回Boolean类型的needsHexEscape，有字符返回true
boolean needsHexEscape = isEscapeNeededForString(x,
stringLength);
if (!needsHexEscape) {
//定义一个Byte类型的数组，用于接收转换后的字符串
byte[] parameterAsBytes = null;
//看这里，这里对数据进行了改造，前后都有拼接
StringBuffer quotedString = new StringBuffer(x.length() + 2);
quotedString.append('\'');
quotedString.append(x);
quotedString.append('\'');
if (!this.isLoadDataQuery) {
parameterAsBytes = StringUtils.getBytes(quotedString.toString(),
this.charConverter, this.charEncoding,
this.connection.getServerCharacterEncoding(),
this.connection.parserKnowsUnicode(), getExceptionInterceptor());
} else {
// Send with platform character encoding
//使用网络字符编码发送
parameterAsBytes = StringUtils.getBytes(quotedString.toString());
}
setInternal(parameterIndex, parameterAsBytes);
} else {
byte[] parameterAsBytes = null;
//isLoadDataQuery定义的Boolean类型的变量，初始值为false，判断是否此查询是加载数据查询
if (!this.isLoadDataQuery) {
parameterAsBytes = StringUtils.getBytes(x,
this.charConverter, this.charEncoding,
this.connection.getServerCharacterEncoding(),
this.connection.parserKnowsUnicode(), getExceptionInterceptor());
} else {
// Send with platform character encoding
//转化为字符类型的数组
parameterAsBytes = StringUtils.getBytes(x);
}
setBytes(parameterIndex, parameterAsBytes);
}
return;
}
String parameterAsString = x;
boolean needsQuoted = true;
if (this.isLoadDataQuery || isEscapeNeededForString(x, stringLength)) {
needsQuoted = false; // saves an allocation later
StringBuffer buf = new StringBuffer((int) (x.length() * 1.1));
buf.append('\'');
//
// Note: buf.append(char) is _faster_ than
// appending in blocks, because the block
// append requires a System.arraycopy()....
// go figure...
//
for (int i = 0; i < stringLength; ++i) {
//charAt()方法返回指定索引位置的char值
char c = x.charAt(i);
switch (c) {
case 0: /* Must be escaped for 'mysql' */
buf.append('\\');
buf.append('0');
break;
case '\n': /* Must be escaped for logs */
buf.append('\\');
buf.append('n');
break;
case '\r':
buf.append('\\');
buf.append('r');
break;
case '\\':
buf.append('\\');
buf.append('\\');
break;
case '\'':
buf.append('\\');
buf.append('\'');
break;
case '"': /* Better safe than sorry */
if (this.usingAnsiMode) {
buf.append('\\');
}
buf.append('"');
break;
case '\032': /* This gives problems on Win32 */
buf.append('\\');
buf.append('Z');
break;
case '\u00a5':
case '\u20a9':
// escape characters interpreted as backslash by mysql
if(charsetEncoder != null) {
CharBuffer cbuf = CharBuffer.allocate(1);
ByteBuffer bbuf = ByteBuffer.allocate(1);
cbuf.put(c);
cbuf.position(0);
charsetEncoder.encode(cbuf, bbuf, true);
if(bbuf.get(0) == '\\') {
buf.append('\\');
}
}
// fall through
default:
buf.append(c);
}
}
buf.append('\'');
parameterAsString = buf.toString();
}
byte[] parameterAsBytes = null;
if (!this.isLoadDataQuery) {
if (needsQuoted) {
//定义的变量charConverter:要使用的字符转化器（默认null），定义的变量charEncoding：要使用的字符编码
parameterAsBytes = StringUtils.getBytesWrapped(parameterAsString,
'\'', '\'', this.charConverter, this.charEncoding, this.connection
.getServerCharacterEncoding(), this.connection
.parserKnowsUnicode(), getExceptionInterceptor());
} else {
parameterAsBytes = StringUtils.getBytes(parameterAsString,
this.charConverter, this.charEncoding, this.connection
.getServerCharacterEncoding(), this.connection
.parserKnowsUnicode(), getExceptionInterceptor());
}
} else {
// Send with platform character encoding
parameterAsBytes = StringUtils.getBytes(parameterAsString);
}
setInternal(parameterIndex, parameterAsBytes);
this.parameterTypes[parameterIndex - 1 + getParameterIndexOffset()] = Types.VARCHAR;
}
}
}
private boolean isEscapeNeededForString(String x, int stringLength) {
boolean needsHexEscape = false;
for (int i = 0; i < stringLength; ++i) {
//charAt()方法返回指定索引位置的char值
char c = x.charAt(i);
switch (c) {
case 0: /* Must be escaped for 'mysql' */
needsHexEscape = true;
break;
case '\n': /* Must be escaped for logs */
needsHexEscape = true;
break;
case '\r':
needsHexEscape = true;
break;
case '\\':
needsHexEscape = true;
break;
case '\'':
needsHexEscape = true;
break;
case '"': /* Better safe than sorry */
needsHexEscape = true;
break;
case '\032': /* This gives problems on Win32 */
needsHexEscape = true;
break;
}
if (needsHexEscape) {
break; // no need to scan more
}
}
return needsHexEscape;
}
}
看了java中PreparedStatement的底层源码，对于防止sql注入有了了解，但是这只停留在java编程层面，对数据库的具体操作还是由sql语句在数据库中执行生成，那么为什么PreparedStatement中的‘？‘占位符就可以在sql中使用囊？那么sql语句如何执行成功的呢？Statement和PreparedStatement到底有什么区别囊？带着问题我们一起去看sql执行过程。
3 sql运行过程
词法分析→语法分析→语义分析→生成执行计划进行性能优化→执行。
这里就要说到基本上与其他编译系统差不多。SQL语句本意就是要避开复杂的底层操作，用非常利于普通人理解的简单语句完成对于二维表的查询。
从程序到sql执行的具体过程：
第一步：应用程序把查询SQL语句发给服务器端执行
我们在数据层执行SQL语句时，应用程序会连接到相应的数据库服务器，把SQL语句发送给服务器处理。
第二步：服务器解析请求的SQL语句（这里需要注意一下java中的sql缓存和数据库中的sql缓存，这里不细讲）
SQL计划缓存，经常用查询分析器的朋友大概都知道这样一个事实，往往一个查询语句在第一次运行的时候需要执行特别长的时间，但是如果你马上或者在一定时间内运行同样的语句，会在很短的时间内返回查询结果。原因是：
- 服务器在接收到查询请求后，并不会马上去数据库查询，而是在数据库中的计划缓存中找是否有相对应的执行计划。如果存在，就直接调用已经编译好的执行计划，节省了执行计划的编译时间。
- 如果所查询的行已经存在于数据缓冲存储区中，就不用查询物理文件了，而是从缓存中取数据，这样从内存中取数据就会比从硬盘上读取数据快很多，提高了查询效率。数据缓冲存储区会在后面提到。
如果在SQL计划缓存中没有对应的执行计划，服务器首先会对用户请求的SQL语句进行语法效验，如果有语法错误，服务器会结束查询操作，并用返回相应的错误信息给调用它的应用程序。
注意：此时返回的错误信息中，只会包含基本的语法错误信息，例如select 写成selec等，错误信息中如果包含一列表中本没有的列，此时服务器是不会检查出来的，因为只是语法验证，语义是否正确放在下一步进行。
语法符合后，就开始验证它的语义是否正确。例如，表名、列名、存储过程等等数据库对象是否真正存在，如果发现有不存在的，就会报错给应用程序，同时结束查询。
接下来就是获得对象的解析锁，我们在查询一个表时，首先服务器会对这个对象加锁，这是为了保证数据的统一性，如果不加锁，此时有数据插入，但因为没有加锁的原因，查询已经将这条记录读入，而有的插入会因为事务的失败会回滚，就会形成脏读的现象。
接下来就是对数据库用户权限的验证。SQL语句语法，语义都正确，此时并不一定能够得到查询结果，如果数据库用户没有相应的访问权限，服务器会报出权限不足的错误给应用程序，在稍大的项目中，往往一个项目里面会包含好几个数据库连接串，这些数据库用户具有不同的权限，有的是只读权限，有的是只写权限，有的是可读可写，根据不同的操作选取不同的用户来执行。稍微不注意，无论你的SQL语句写的多么完善，完美无缺都没用。
解析的最后一步，就是确定最终的执行计划。当语法、语义、权限都验证后，服务器并不会马上给你返回结果，而是会针对你的SQL进行优化，选择不同的查询算法以最高效的形式返回给应用程序。例如在做表联合查询时，服务器会根据开销成本来最终决定采用hash join,merge join ，还是loop join，采用哪一个索引会更高效等等。不过它的自动化优化是有限的，要想写出高效的查询SQL还是要优化自己的SQL查询语句。
当确定好执行计划后，就会把这个执行计划保存到SQL计划缓存中，下次在有相同的执行请求时，就直接从计划缓存中取，避免重新编译执行计划。
第三步：语句执行
服务器对SQL语句解析完成后，服务器才会知道这条语句到底表态了什么意思，接下来才会真正的执行SQL语句。
此时分两种情况：
- 如果查询语句所包含的数据行已经读取到数据缓冲存储区的话，服务器会直接从数据缓冲存储区中读取数据返回给应用程序，避免了从物理文件中读取，提高查询速度。
- 如果数据行没有在数据缓冲存储区中，则会从物理文件中读取记录返回给应用程序，同时把数据行写入数据缓冲存储区中，供下次使用。
说明：SQL缓存分好几种，这里有兴趣的朋友可以去搜索一下。有时因为缓存的存在，使得我们很难马上看出优化的结果，因为第二次执行因为有缓存的存在，会特别快速，所以一般都是先消除缓存，然后比较优化前后的性能表现，这里有几个常用的方法：
1 DBCC DROPCLEANBUFFERS
2 从缓冲池中删除所有清除缓冲区。
3 DBCC FREEPROCCACHE
4 从过程缓存中删除所有元素。
5 DBCC FREESYSTEMCACHE
6 从所有缓存中释放所有未使用的缓存条目。
SQL Server 2005 数据库引擎会事先在后台清理未使用的缓存条目，以使内存可用于当前条目。但是，可以使用此命令从所有缓存中手动删除未使用的条目。
这只能基本消除SQL缓存的影响，目前好像没有完全消除缓存的方案，如果大家有，请指教。
执行顺序：
- FROM 子句返回初始结果集。
- WHERE 子句排除不满足搜索条件的行。
- GROUP BY 子句将选定的行收集到 GROUP BY 子句中各个唯一值的组中。
- 选择列表中指定的聚合函数可以计算各组的汇总值。
- 此外，HAVING 子句排除不满足搜索条件的行。
- 计算所有的表达式；
- 使用order by对结果集进行排序。
- 查找你要搜索的字段。
预处理编译 SQL 是占用资源的，所以在使用后注意及时使用 DEALLOCATE PREPARE 释放资源，这是一个好习惯。
useServerPrepStmts参数
默认使用PreparedStatement是不能执行预编译的，这需要在url中给出useServerPrepStmts=true参数（MySQL Server 4.1之前的版本是不支持预编译的，而Connector/J在5.0.5以后的版本，默认是没有开启预编译功能的）。
例如：jdbc:mysql://localhost:3306/test?useServerPrepStmts=true
这样才能保证mysql驱动会先把SQL语句发送给服务器进行预编译，然后在执行executeQuery()时只是把参数发送给服务器。
这里Statement和PreparedStatement的区别其实就体现在了预编译上。
预编译语句的优势在于归纳为：一次编译、多次运行，省去了解析优化等过程；此外预编译语句能防止sql注入。
备注：MySQL中的预编译语句作用域是session级，
文章参考了大佬的博文，但是之前一直保存在草稿箱中，无法批注复制博主的地址，有知道的，请大家留言，我附到文章后面。