java处理sql注入方法——sql转义

昨天被扫描出来sql注入问题,之前以为已经解决了,没想到还是出现了。

网上现有方法:

1、preparestatement

由于每次执行都需要prepare,所以不推荐使用

2、一个单引号变成两个

replace("'","''")
其他的字符串替代方法有着局限性,就不列举了。

我最开始使用的是2方法,但是还是有方法可以破解。

后来参考php的addslashes函数,写了一个java的escapeSql方法,如下:

public static String escapeSql(String str) {
		if (str == null) {
			return null;
		}
		StringBuilder sb = new StringBuilder();
		for (int i = 0; i < str.length(); i++) {
			char src = str.charAt(i);
			switch (src) {
			case '\'':
				sb.append("''");// hibernate转义多个单引号必须用两个单引号
				break;
			case '\"':
			case '\\':
				sb.append('\\');
			default:
				sb.append(src);
				break;
			}
		}
		return sb.toString();
	}

经测试,已修复sql注入问题。

### 如何在Java中防止SQL注入的最佳实践和方法 #### 使用参数化查询 为了有效预防SQL注入,推荐采用参数化查询。这种方式通过预编译SQL语句并绑定变量来实现安全的数据访问操作[^3]。 ```java String sql = "SELECT * FROM users WHERE username=? AND password=?"; try (PreparedStatement pstmt = connection.prepareStatement(sql)) { pstmt.setString(1, userInputUsername); pstmt.setString(2, userInputPassword); ResultSet rs = pstmt.executeQuery(); } ``` 此代码片段展示了如何利用`PreparedStatement`接口创建带有问号占位符的SQL命令字符串,并随后调用相应类型的setter方法设置实际值。由于这些值不会被解释为SQL的一部分而是作为单独传递给数据库引擎处理的数据项对待,因此可以有效地抵御恶意构造输入带来的风险。 #### 利用ORM框架特性 现代对象关系映射(ORM)工具通常内置了防范措施以应对潜在威胁。例如MyBatis框架支持使用`${}`语法直接嵌入未经转义的内容到最终构建出来的SQL表达式里;然而更建议的做法是运用`#{}`形式指定字段名,这会触发内部机制自动转换为目标表单上的参数位置标记——即前述提到过的问号符号,从而确保整个流程遵循严格的验证逻辑[^4]。 ```xml <select id="getUserById" parameterType="int" resultType="User"> SELECT * FROM users WHERE id=#{id}; </select> ``` 上述XML配置文件定义了一个简单的数据检索请求模板,其中`#{id}`部分会被替换成由外部传入的具体数值而不必担心引起任何意外后果。 #### 输入校验与清理 除了依赖底层API提供的保护手段外,应用层面上也应当加强对用户提交信息合法性的审查力度。具体而言就是针对不同场景设定合理的约束条件并对不符合预期格式的部分予以适当调整或拒绝接收: - 对于纯文本型别的属性可考虑限定最大长度; - 数字序列则需确认其范围合理性; - 特殊字符集务必经过严格筛选过滤掉可能引发解析错误甚至破坏结构稳定性的成分。 综上所述,在开发过程中始终贯彻以上原则有助于显著降低遭受SQL注入攻击的可能性,保障信息系统整体运行环境的安全可靠程度。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值