一、该问题的重现步骤是什么？
1.
2. 
3.
Condition.getQueryWrapper 造成sql注入 ，SqlkeyWord只做了insert、update等关键字的注入检测，(1 = 1) or仍有注入风险
二、你期待的结果是什么？实际看到的又是什么？
三、你正在使用的是什么产品，什么版本？在什么操作系统上？
四、请提供详细的错误堆栈信息，这很重要。
五、若有更多详细信息，请在下面提供。
你“注入”这个1=1是没有意义的，为什么没意义我列出以下几点：
1. 你要调用通接口，首先需要拿到合法token，如果你想黑入系统，没有账号密码的前提是无法轻松拿到token的（因为token有signkey可以配置，如果signkey不对，是无法伪造的）。只能撞库、木马等手段，但如果你撞库，5次密码错误就会锁定，并且把你ip记录下来。如果能有木马的手的手段，已经无需sql注入了，登录系统后台就能进行所有操作
2. 假如你第一阶段成功，拿到了合法token，那么你会发现你注入所谓的1=1是没有用的。最终到sql执行的时候，你会发现他被括号包起来了，1=1条件并不在最外层。更何况最后还有一个limit会强制加上。
3. 这种情况，你还不如直接把现成的size参数改大一点，根本不需要注入（当然你把size改成99999，系统默认也只会返回500条）
4. 一般重要接口都会有数据权限，你的token权限有多少，后台最终都会加上条件，最终就变成了
where is_deleted=0 and (1=1 or name like '%1%'') and (create_dept=123456789)
5. 这样1=1就起不到任何作用了，所以你如果能有手段拿到token，还不如去修改current和size的值轮训获取到所有这个token能看到的数据。
如果使用
${ew.customSqlSegment}
生成的where语句会没有括号
where 1 = 1 or (name like '%11%' and tenant_id = '000000' and is_deleted = 0) limit 10。
这里需要使用创建人、修改人的名字模糊查询，但是不使用mybatisplus-join依赖插件的话，querywrapper不支持关联查询。使用自动生成的代码，少修改代码，有没有其他好的解决方案。
${ew.customSqlSegment}
这个不是sqlkeyword考虑的事，而是写这个sql的人考虑的事。如果这个能算注入漏洞，那mybatis-plus就没有存在的必要了。而且你看最后也已经加上了limit 10，那么1=1依旧无效。还有就是上面说的，一些重要接口都是需要加上数据权限的。你加上创建人、创建部门等条件后，就算多了1=1，那依旧无法获取到所有数据。
这种可以执行任意参数的接口，如果token被别人拿到了，那就能随意执行，建议非特殊情况不要这么写，如果要写也要加重重认证。
写个很简单的比喻，世界上没有绝对安全的防盗锁，如果密码或者钥匙都让人拿到了，那就不能怪这个防盗锁不行。而是要自己做好安全手段，保护好密码和钥匙。
你的sql看下图
但是能把删除的数据查出来。没关系，不行就自己写了，只是觉得生成代码不想改太多。
SqlKeyword类只能控制用mybatis-plus自带api的查询，针对用户自己写的SQL是无法控制干预的。
最稳妥的方式就是用类去接收参数，然后将类转换成Wrapper条件，这样1=1就无法被纳入了。
扫一扫访问 Blade技术社区 移动端
加载中...
苏公网安备 32041102000998号