本文介绍了如何解决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
