如何在项目中有效的防止SQL注入
写给需要的人,所有的问题源自我们的不重视。
本章略过“什么是SQL注入”,“如何去利用SQL注入”的讲解,仅讲如何去防御
PS在这里讲的不是Postscript
来自
E序列 技术支持小组
贾少雄(360企业安全) 联合编辑
本项目涉及的技术
ORM框架:Mybatis/Hibernate(HQL)/Spring Data-JPA(JPQL)
目录
- 事前须知
- SQL注入的产生
- PreparedStatement
- 正则表达式过滤和筛选器
1、 如何新项目设计避免SQL注入?
- 数据库本身的安全设计
- JPA与参数化(已鸽,坐等4月15日)
2、老项目修复
- 2.1 数据库的安全防范与防火墙技术
- 1.2 技术升级/停用
事前须知
SQL注入的产生
String sql = new StringBuilder();
sql="select * from user where username="+username;
然后各种append
10年的一个类,E**.java,使用StringBuilder 拼接了一个原生SQL的“HQL”(PS:这没有任何安全上的提升),完全暴力append过去,就在最近我终于知道为什么了,hibernate的insert并不好使,他们就是因为懒而弄了个拼接类,在这里我推荐用保存对象的形式。
尽管这种天才般的想法极大的增加了开发的效率,但依然给我们挖了深坑,给我打开了新世界的大门。
任何拼接的方式都会产生sql注入,sql注入主要产生在查询上
PreparedStatement
String sql = "select * from user where username=?";
p = connect.prepareStatement(sql);
p.setString(1,payload);
p.executeQuery();
PrepareStatement是一种预编译的Statement对象,通过占位符的方式占位,随后通过Set方法赋值,随后通过execute相关方法执行,效率也更高,尽管避免了普通拼接造成的安全问题,防范了大量的SQL注入。
他做的东西就是转义,将截断转义成其他符号或者空字符串,但是对于一些恶意耗尽资源的查询力不从心,重要的是依然可以绕过……
不同数据库连接的PrepareStatement方法均有出入
1、 如何新项目设计避免SQL注入?
1.1数据库本身的安全设计
数据库是信息安全的最后一道防线,里面存储着金融信息,用户个人信息。都2019年了,CICD技术慢慢的展现自己。(待补)
通过上传代码自动部署测试环境,自动集成。
数据库环境分离设计
因此段没参考任何资料,全凭脑补,如有错误,谬误欢迎各位指出。
数据库应分有:
开发环境库:简易,排除无用数据,直观,更有效防止了弱口令导致的数据泄露,各种花式删库。特点是有sql文件(ddl)和初始化数据来支持简单的测试和新人上手。
测试环境库:用于测试,也无法接触生产数据库,防止数据泄露,多用于黑盒,白盒测试,就算你删了库,被勒索病毒勒索比特币也没什么事,推荐批量生成测试数据来测试。
生产环境库(指生产环境,由1个至多个构成)不再介绍,是重点花式被删库和脱库的对象。
每个环境的数据库用途和数据量均不一样,开发人员的数据较少便于开发,减少搭建问题,测试环境生成部分数据用于测试。然而开发环境也可以用来直接测试,根据情况初始化,使数据干净,便于管理。
数据库加密有如下几种分类
重要字段加密:对关键字段进行加密,在国内,常用的加密方式是MD5,但这并不安全(link王小云博士05年crypto大会提出,09年碰撞算法加强)我并不是说md5就能完美逆向。
MySQL数据库自带加密
加密推荐aes和des,程序设计避免输入弱密码,对强度进行校验。
我本已经写好包括MD5+6的介绍枚举很多种问题
但是请大家参考 owasp数据库审计基准 |
今天是28日,团队召集已经结束
项目时间:2月10日-4月15日
挖坑相关:
Tomcat中间件安全
Weblogic中间件安全
Jboss中间件安全
Apache HTTPD正向代理安全[写完了呢]
Nginx 反向代理安全
JAVA框架的版本升级(全)