如何在项目中有效的防止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框架的版本升级（全）