很多人都知道SQL存在SQL注入引起的安全问题,但是很少有开发者去尝试过是怎样一个注入,下面将复现Mybatis的SQL注入问题并给出正确操作。
1.复现SQL注入操作
1.新建一张表(MqSQL):
SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;
-- ----------------------------
-- Table structure for test
-- ----------------------------
DROP TABLE IF EXISTS `test`;
CREATE TABLE `test` (
`id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`age` int(10) UNSIGNED NULL DEFAULT NULL,
`name` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
PRIMARY KEY (`id`) USING BTREE,
UNIQUE INDEX `age`(`age`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 3 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
-- ----------------------------
-- Records of test
-- ----------------------------
INSERT INTO `test` VALUES (1, 25, 'Robert');
SET FOREIGN_KEY_CHECKS = 1;
2.执行like查询操作
select *
from test
where name like '%Ro%'
查询结果:
3.查询内容换成SQL注入语句
Robert';DROP TABLE test;--
这样SQL就变成:
select *
from test
where name like '%Robert';DROP TABLE test;--%'
执行后会发现我们的表被删掉了。这就是SQL注入漏洞。
2.解决SQL注入隐患
我们Mybatis中动态SQL有${}和#{}两种解释方式:
- ${}是直接将参数拼接到SQL中,这样就存在SQL注入的危险漏洞;
- #{}会先识别参数类型,是字符串的话会完全按照字符串去处理,也就是这种方式会直接将参数Robert’;DROP TABLE test;–当做一个字符串,这样就解决了SQL注入的问题。
如下使用${}:危险SQL
select *
from test
where name like '%${name}%'
使用#{}:安全SQL
select *
from test
where name like concat('%', #{name}, '%')
所以日常开发过程,一定要首选#{}方式,不得已情况下再使用${};
3.那么有人会问什么情况是不得已的情况?
比如如下场景:test表有很多临时表,这些临时表表名是随机生成的,我们不能将表名直接写死到SQL,所以需要使用动态参数,如下:
select *
from #{table_name}
where name like concat('%', #{name}, '%')
这种情况使用#{}方式就会报错,因为table_name会被解析成字符串如下:
select *
from 'test'
where name like concat('%', 'Ro', '%')
在执行SQL时就报错,语法错误
改为${}就可以了,那么这时候还存在SQL注入隐患吗?试一下:
select *
from test;DROP TABLE test;--
where name like concat('%', 'Ro', '%')
发现test表仍被删除掉了,所以只要使用了${}就存在SQL注入隐患。
解决办法:对使用${}的动态参数在Java端做好严格管控:
- 这种参数不应该由接口传入
- 由接口传入的应该做好参数校验,防止恶意参数
以上就是关于SQL注入隐患的解释及解决方案,作为后端开发人员要时刻保持安全意识,永远记住一点:对外开放的接口都不是绝对安全。