MyBatis中#{}与${}的区别

  在mybatis中#{}可以防止SQL注入而${}不可以。举个例子：http://www.xx.com/news.jsp?id=1 。这里的sql语句中如果使用${}，

1

SELECT title,content FROM news WHERE id = ${id}；

执行时，参数id会被直接拼接入sql语句：

1

SELECT title,content FROM news WHERE id = 1

如果攻击者提交的参数为“id=1 and 1=2 UNION SELECT username, password FROM admin”。拼接的sql语句就变为了：

1

SELECT title,content FROM news WHERE id = 1 and 1=2 UNION SELECT username, password FROM admin

  这条sql的原意就会被改变，导致将管理员数据表中的用户显示在页面title位置，密码显示在页面content位置，达到成功攻击的效果。而如果用#{},

1

SELECT title,content FROM news WHERE id = #{id}

在用户提交参数之前，sql语句会进行一次预编译，

1

SELECT title,content FROM news WHERE id = ?

  攻击者提交的参数中包含的sql编译字符，不会被带入sql进行编译，只作为参数，不能造成sql注入。而且由于只进行一次预编译，sql的性能也会得到提升。在项目中，大部分SQL语句对参数的处理方式都是用了#{}这种预编译方式。但在模糊查询中，使用#{}会报错。所以使用了${ }方式代替#{}，其实在项目中可以使用concat的方式，进行参数的拼接。

MyBatis框架下易产生SQL注入漏洞场景分析

  MyBatis框架下易产生SQL注入漏洞的情况主要分为以下三种：

模糊查询like

  以按照标题进行模糊查询为例，如果考虑安全编码规范问题，其对应的SQL语句如下：

1

select * from news where title like '%#{title}%'

  但由于这样写程序会报错，所以将SQL查询语句修改如下：

1

select * from news where title like '%${title}%'

  在这种情况下程序不再报错，但是此时产生了SQL语句拼接问题，如果java代码层面没有对用户输入的内容做处理势必会产生SQL注入漏洞。

in之后的参数

  在进行同条件多值查询的时候，如当用户输入1001,1002,1003…100N时，如果考虑安全编码规范问题，其对应的SQL语句如下：

1

select * from news where id in (#{id})

  但由于这样写程序会报错，研发人员将SQL查询语句修改如下：

1

select * from news where id in (${id})

  修改SQL语句之后，程序停止报错，但是却引入了SQL语句拼接的问题，如果没有对用户输入的内容做过滤，势必会产生SQL注入漏洞。

order by之后

  当根据发布时间、点击量等信息进行排序的时候，如果考虑安全编码规范问题，其对应的SQL语句如下：
　　　　

1

select * from news where title =‘test’ order by #{time} asc

  但由于这样写程序会报错，将SQL查询语句修改如下：

1

select * from news where title =‘test’ order by ${time} asc

  修改之后，程序通过预编译，但是产生了SQL语句拼接问题，极有可能引发SQL注入漏洞。

Mybatis框架下SQL注入漏洞修复建议

模糊查询like SQL注入修复建议

  按照标题进行模糊查询，可将SQL查询语句设计如下：

1

select * from news where tile like concat('%',#{title}, '%')

采用预编译机制，避免了SQL语句拼接的问题，从根源上防止了SQL注入漏洞的产生。

in之后的参数SQL注入修复建议

  在对进行同条件多值查询的时候，可使用Mybatis自带循环指令解决SQL语句动态拼接的问题：

1
2
3
4

select * from news where id in
<foreach collection='ids' item='item' open='(' separator=',' close=')'>
    #{item}
</foreach>

order by SQL注入修复建议–在Java层面做映射

  预编译机制只能处理查询参数，其他地方还需要研发人员根据具体情况来解决。如前面提到的排序情景：
　　　　

1

select * from news where title =‘test’ order by #{time} asc

  这里无法使用预编译机制，只能这样拼接：
　　　

1

select * from news where title =‘title’ order by ${time} asc

  针对这种情况可以在java层面做映射来进行解决。如当存在发布时间time和点击量click两种排序选择时，可以限制用户只能输入1和2。当用户输入1时，在代码层面将其映射为time，当用户输入2时，将其映射为click。而当用户输入1和2之外的其他内容时，可以将其转换为默认排序选择time(或者click)。

参考

• 公司内部分享

  电脑：win7 64位。最近做项目需要修改hosts文件来映射，可是修改后，hosts文件的映射并不生效。网上的方法试了好多，都不行。

  比如：以ascII编码的形式保存hosts，修改注册表，关闭dns client，命令行输入ipconfig/flushdns，修改hosts后重启浏览器或者电脑，浏览器隐身模式访问等等，都没有成功。

  最后看到一篇文章http://blog.phpdr.net/windows7-x64-hosts-ignore.html，成功解决问题。

解决方法：

  刚开始我本机hosts文件的内容都是从别人那里copy过来的，这样其实存在一个问题，就是不同操作系统换号、空格或者tab是不一样的，编码也可能不同，直接copy到自己本机上的hosts里，系统可能会解析不了。

  参照文章中的方法，使用C:\Windows\System32\notepad新建一个hosts文件，覆盖原来的hosts（内容提前备份），新建hosts的内容不要copy，手动录入，最后问题解决。

以下内容选自《从PAXOS到ZOOKEEPER分布一致性原理与实践》

  事务(Transaction)是由一些列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元，狭义上的事务特指数据库事务。一方面，当多个应用程序并发访问数据库时，事务可以在这些应用程序之间提供一个隔离方法，以防止彼此的操作互相干扰。另一方面，事务为数据库操作提供了一个从失败中恢复到正常状态的方法，同时提供了数据库即使在异常状态下仍能保持数据一致性的方法。

  事务具有四个特征，分别是原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、和持久性(Durability)，简称为事务的ACID特性。

原子性

  事务的原子性是指事务必须是一个原子的操作序列单元。事务中包含的各项操作在一次执行过程中，只允许出现以下两种状态之一。

• 全部成功执行。
• 全部不执行。

  任何一项操作失败都将导致整个事务失败，同时其他已经被执行的操作都将被撤销并回滚，只有所有的操作全部成功，整个事务才算是成功完成。

一致性

   事务的一致性是指事务的执行不能破坏数库的完整性和一致性，一个事务在执行之前和执行之后，数据库都必须处于一致性状态。也就是说，事务执行的结果必须是使数据库从一个一致性状态转移到另一个一致性状态，因此当数据库只包含成功事务提交的结果时，就能说数据库处于一致性状态。而如果数据库在运行过程中发生故障，有些事务尚未完后就被迫中断，这些未完成的事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。

隔离性

  事务的隔离性是指在并发环境中，并发的事务是相互隔离的，一个事务的执行不能被其他事务干扰。也就是说，不同的事务并发操作相同的数据时，每个事务都有各自完整的数据空间，即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能相互干扰。

  在标准SQL规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同，如未授权读取、授权读取、可重复读取和串行化。

• 未授权读取:未授权读取也被成为读未提交(Read Uncommitted)，该隔离级别允许脏读取，其隔离级别最低。换句话说，如果一个事务正在处理某一项数据，并对其进行了更新，但同时尚未完成事务，因此还没有进行事务提交；而与此同时，允许另一个事务也能够访问该数据。举个例子来说，事务A和事务B同时进行，事务A在整个执行阶段，会将某数据项的值从1开始，做一些列加法操作（比如说加1操作）知道变成10之后进行事务提交，此时事务B能够看到这个数据项在事务A操作过程中的所有中间值（如1变成2、2变成3等），而对这一些列的中间值的对去就是未授权读取。
• 授权读取:授权读取也被称为读已提交(Read Committed)，它和未授权读取非常相近，唯一的区别就是授权读取只允许获取已经被提交的数据。同样以上面的例子来说，事务A和事务B同时进行，事务A进行与上述同样的操作，此时事务B无法看到这个数据项在事务A操作过程的所有中间值，只能看到最终的10。另外，如果说一个事务C。和事务A进行非常类似的操作，只是事务C是将数据项从10加到20，此时事务B同样可以读取到20，即授权读取允许不可重复读取。
• 可重复读取:可重复读取(Repeatable Read)，简单地说，就是保证在事务处理过程中，多次读取同一个数据时，其值都和事务开始时刻是一致的。因此该事物级别禁止了不可重复读取和脏读取，但是有可能出现幻影数据。所谓幻影数据，就是指同样的事务操作，在前后两个时间段内执行对同一个数据项的读取，可能出现不一致的结果。在上面的例子，可重复读取隔离级别能够保证事务B在第一次事务操作过程，始终对数据项读取到1，但是在下一次事务操作中，即使事务B（注意，事务名字虽然相同，但是指的是另一次事务操作）采用同样的查询方式，就可能会读取到10或20。
• 串行化:串行化(Serializable)是最严格的事务隔离级别。它要求所有事务都被串行执行，即事务只能一个接一个地进行处理，不能并发执行。

  以上4个隔离级别的隔离性一次增强，分别解决了不同的问题，下表对这4个隔离级别进行了一个简单的对比。

  事务隔离级别越高，就越能保证数据的完整性和一致性，但同时对并发性能的影响也越大。通常，对于绝大多数的应用程序来说，可以优先考虑将数据库系统的隔离级别设置为授权读取，这能够在避免脏读取的同时保证较好的并发性能。尽管这种事务隔离级别会导致不可重复读、虚读和第二类丢失更新等并发问题，但较为科学的做法是在可能出现这类问题的个别场合中，由应用程序主动采用悲观锁或乐观锁来进行事务控制。

持久性

  事务的持久性也被称为永久性，是指一个事务一旦提交，它对数据库中对应数据的状态变更就应该是永久性的。换句话说，一旦某个事务成功结束，那么它对数据库所做的更新就必须被永久保存下来–即使发生系统崩溃或机器宕机等故障，只要数据库能够重新启动，那么一定能够将其恢复到事务成功结束时的状态。

以下内容选自微信公众号–java一日一条《深入理解spring事务原理》

spring事务传播机制

  所谓spring事务的传播机制，就是定义在存在多个事务同时存在的时候，spring应该如何处理这些事务的行为。