java防注入原理和sql运行过程

                                   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：

select * from user where name = '${name}'

• 前端页面的简略的代码：

       前端页面通过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级，

文章参考了大佬的博文，但是之前一直保存在草稿箱中，无法批注复制博主的地址，有知道的，请大家留言，我附到文章后面。