本文介绍了如何解决mybatis使用$ {}时的sql注入问题。内容非常详细,有兴趣的朋友可以参考一下,希望对你有帮助。
mybatis使用${}时sql注入的问题
最近,在线项目启动时,代码审查失败,表明存在sql注入的风险。
ORDERBY${orderBy}是一个简单的排序字段,但是由于使用了$ {}占位符,因此存在sql注入的风险。相信大家都经常使用这个占位符,不知道大家有没有考虑过sql注入的问题。这里简单介绍一下# {}和$ {}的区别,以及为什么使用$ {}会导致sql注入问题。
00-1010 # {}是参数占位符,字符串类型将自动添加“”,但其他类型不会。由于Mybatis采用预编译,后续的参数不会用SQL编译,所以在一定程度上阻止了SQL注入。
$ {}是一个简单的字符串替换,字符串是什么,解析就是什么。
类,如order by。如果前端传来的参数是id(假设id是String类型),对于order by #{id},对应的sql语句是order by“id”;对于按${id}排序,相应的sql语句是按id排序。在这种情况下,当用户传递参数id 1=1时,将会发生不可预测的后果。
00-1010向原始实体类添加映射。
publicMapString,StringindexMap=new hashmapstring,String(){ 0
{
put('spaceId ',' space _ id ');//key是前端传输的值,value是数据库对应的列值。
put('optTime ',' opt _ time ');
}
};传递参数时,判断该参数是否在映射的键中,如果在,则将对应的值作为排序的依赖条件。
if(paramOptLog.getOrderBy()!=NullStrings . IsNullOrempty(ParAmoptLog . GetOrderby())()
OptLogoptLog=NewOptlog();
paramOptlog . setorderby(Optlog . index map . getordefault(paramOptlog . getorderby(),' id '));
}
ListOptLoglist=Optlogmapper . query 4 page(ParamOptlog);
} Summary是指程序员通过映射来决定$ { transmission的参数,即动态sql改为静态sql的方式可以解决这个问题,这样在实际调用时就不会有sql注入的风险。
00-1010
区别
不会被预编译,而是由sql注入。
注射方式如下:
只要用户名正确,您可以通过输入任何密码来通过验证。
以这种方式输入查询语句在数据库中如下:
选择身份证,用户名,密码从用户登录这里用户名='管理员'或1=1和密码=' 23 'sql解释:,并具有比或更高的优先级。首先判断最后1=1,密码=' 23 '为假,然后判断之前的用户名=' admin '为真。
如果连接为OR,即最后为真OR假,最后为真,则直接验证,管理员用户可以正常登录。
00-1010这将被预编译以防止sql注入。Sql注入只在编译时有效,但它只对?不是参数,而是在实际执行时替换参数?
如何解决mybatis使用$ {}时的sql注入问题,这里就分享一下。希望
内容来源网络,如有侵权,联系删除,本文地址:https://www.230890.com/zhan/148255.html