# 参数预编译方式防止SQL注入的原理： 参数化查询：数据库先完成SQL指令的编译，然后才套用参数运行。此时SQL语句的格式已经是规定好了的，需要查的数据也设置好了，缺的只是几个查询的数据。恶意参数难以生效 # mybatis框架环境下最容易出现SQL注入的场景及防御手段： * 模糊查询：这种场景可以采用预编译的机制，便面SQL语句拼接的问题，从根源上防止SQL注入漏洞的产生 * in之后的函数：使用自带循环指令解决 * order by之后的参数：在java层面做映射 # 在研发阶段通过技术手段避免SQL注入： * 参数预编译 * 正则表达式过滤传入参数 * 字符串过滤 * 横向渗透 # 如何感知到SQL注入漏洞正在被利用： * 对数据库监测：对数据库进行操作室，自动对执行的SQL语句进行语义分析，并划分威胁等级，根据划分的威胁等级进行不同的处理 * 创建蜜罐数据库：当对蜜罐数据库进行操作时，直接出发劲爆并阻断该IP的访问（蜜罐哎，放着看看人家的操作又怎么了！） # 如何高效扫描SQL注入漏洞： * 扫描速度：多线程，高并发，分布式 * 扫描结果准确度：收集cms注入漏洞的POC，在扫描时通过指纹识别和POC相结合 # 其他： * Prestatement和statement的区别：前者对批量处理可以提高效率，后者每次执行SQL语句都需要编译 * 预编译能完全防止SQL注入吗：一般情况下，能（但是生活中的情况的复杂度，呵呵） * order by举例：查询文章标题为“安全”的文章并根据阅读量或者ID排序，select * from article where title = '安全' order by # asc，这里readVolume不是查询参数，无法使用预编译机制，只能这样拼接select * from article where title = '安全' order by $ asc。针对这种情况研发人员可以在java层面做映射进行解决。如当在根据阅读量或者ID排序时，我们可以限制用户只能输入0和1，当用户输入0时，我们在代码层面将其映射为readVolume，当用户输入1时，将其映射为id。当用户输入0和1以外的内容时，可以将其转换为默认排序方式。 # 其他链接： * http://www.anyun.org/a/jishuguanzhu/wangluoanquan/2017/0602/8685.html