javaweb审计-sql注入

idea快捷键:

shift-ctrl-f 开启全局搜索

ctrl+左键查看上一级调用函数

statement.executeQuery(sql);

lombok模块可以自动生成setter/getter/tostring等方法

SQL注入

可以首先找到所有包含sql语句的点,随后观察传参类型是否是sring类型,只有当传参类型时string类型时我们才可能进行sql注入

2.PrepareStatement预编译后的 seletc * from user order by id中 id会自动添加单引号--> select * from user order by 'id'

statement执行sql语句

是java JDBC 中原生的执行方式 如果没有经过过滤会造成sql注入

String sql = "select * from user where id =" +id;

ps = conn.createStatement();

rs= ps.executeQuery(sql);

%和_模糊查询

由于java预编译查询中不会对%和_进行转义处理,他们刚好是like查询的通配符,如果没有做好过滤,导致恶意模糊查询 占用服务器性能,耗尽资源造成宕机

select * from user where username like '%user%'

orderby 注入

order by 子句后米娜需要添加字段名或者字段位置,而字段名是不能带引号的,否则会被认为是一个字符串而不是字段名 

1.preparastatement是使用占位符传入参数的,传递的字符会有单引号包裹

2.所以order by只能使用字符串拼接的方式 但是也也有可能造成sql注入

所以要对关键字符串过滤

mybatis注入

mybatis框架下,sql一般都发在xml文件下

1.${} #{}区别

#{}在底层实现用了"?"作为占位符生成preparesatement,也是参数化查询预编译机制

${} 将传入的数据直接显示成成在sql语句中,类似于字符串拼接,可以会出现sql注入的风险

SELECT * FROM user where id =#{id} safe 写法

select * from user where id =${id} 不安全的写法 直接拼接

 

2.order by 查询 

order by 的#{} ${} 使用不当

orderby是只能进行字符拼接的方式而不能进行参数化查询  #{} 这个是参数化

orderby的字符拼接 ${} 但是也有可能造成sql注入

 

3.like查询 

mybatis 的like自居使用#{} 程序会报错 例如:select * from users where name like '%#{user}%' 只能使用${},但是使用${}可能会造成sql注入

select * from users where name like '%${user}%'

4.in注入

in使用参数化查询的时候会将select * from users where name in (#{user}) 转变为 select * from users where name like ("user1','user2','user3','user")

所以只能用$(进行查询

要在mybatis框架中使用userMapper.xml定义映射文件中设置

<mapper namespace= "com.mybatis_orderby.userMapper">

<select id="getUser" resultType="com.mybatis_orderby.sql.User">

　　select * from users where name in (${user})

</select)
</mapper>

sql注入漏洞修复

sql注入漏洞最有效的防御手段便是进行预编译处理,.

为什么这样处理就能预防SQL注入提高安全性呢？其实是因为SQL语句在程序运行前已经进行了预编译，在程序运行时第一次操作数据库之前，SQL语句已经被数据库分析，编译和优化，对应的执行计划也会缓存下来并允许数据库已参数化的形式进行查询，当运行时动态地把参数传给PreprareStatement时，即使参数里有敏感字符如 or '1=1’也数据库会作为一个参数一个字段的属性值来处理而不会作为一个SQL指令，如此，就起到了防御SQL注入的作用了！