【挖坑】2019年JAVA安全总结:SQL注入——新项目的开发与老项目的修复

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

原文地址:https://www.cnblogs.com/legiorange/p/10277267.html