SQL 注入

什么是 SQL 注入？

SQL 注入实际上就是通过把 SQL 命令添加到表单中或者通过拼接到 URL 字符串中，在输入的参数未经过滤的情况下，最后拼接到后台的 SQL 代码中，从而被 SQL 服务器的解析执行的最终达到欺骗服务器执行恶意的 SQL 命令的一种攻击手法。

SQL 注入产生的原因是什么？

本质原因：就是没有对可以添加参数的地方进行严格的验证
因为在单个请求中可以添加参数的地方实在是太多了（GET 请求：URL，POST 请求：方法体、表单里，HTTP 头信息，Cookie…），开发人员没有办法对所有可以添加参数的地方进行参数过滤，总归会有没检测到的地方，这就会让恶意攻击有机可乘
数据库在执行 SQL 之前没有做相应的安全配置，容易导致恶意攻击非常轻易的执行

注：如果提到了，那么可能问到以下几个问题

GET 和 POST 请求有什么区别？

聊聊 HTTP 协议？HTTP 请求主要分为哪几个部分

请求行，请求首部，换行，请求体

请求行主要包括请求方法，URL 地址，协议版本

Cookie 和 Session 有什么区别和相同点？了解 JWT 吗？

Session 是基于 Cookie 实现的，每次都需要将 SessionId 封装在 Cookie 中传递给服务器

Cookie 不能够实现跨域，Session 因为基于 Cookie，也不可以实现跨域

Cookie 和 Session 对于移动端的支持都不够好

Cookie 是保存在客户端的存在 JS 脚本篡改的风险，不过可以设置 http-only 避免 JS 脚本获取 Cookie，Session 是保存在服务端的相对安全

Cookie 最多只能够容纳 4kb 大小的内容，且只能够是字符串类型，浏览器也最多只能够存储 300 个，Session 理论上可以容纳无限多的内容，取决于服务器的内存大小，存储内容的格式不限

Session 还存在分布式 Session 的问题， Cookie 不存在这种问题

分布式 Session 是什么？如果解决这个问题呢？

粘性 IP、增加缓存层（Redis），Session 存放在持久层中，Session 复制

SQL 注入会带来什么危害呢？如何进行 SQL 注入？

常见的 SQL 注入主要分为两种：

第一种是数字注入，很容易获取到不可以访问的敏感信息
第二种就是字符串注入，可以轻易执行非常危险的行为，比如直接删除整个数据库的内容

-- 这种方式可以去网站上尝试下，会被直接拦截的

-- 1. 前端在传递参数的时候直接将 id=1 or 1=1 作为参数传递到后台
-- 2. 而后台没有对这些参数进行过滤就直接拼接到 SQL 语句中
-- 3. 最后这个 SQL 语句就会等价于 select * from user, 可以直接查询到所有用户的信息
select * from user where id = {#id} or 1=1
-- 1. 前端在传递参数的时候将 id=1;delete from user; 整个语句作为参数传递
-- 2. 后台依旧没有严格的验证, 最终会导致在执行完查询语句后, 执行相应的删除语句
-- 3. 这样最终就会导致数据库中的内容被删除, 是非常严重的
select * from user where id = #{id}; delete from user;

如何解决 SQL 注入问题？

严格检查输入参数的类型和格式
- 针对整数类型的参数，必须要求不为空，参数类型必须为数字，不可以传递字符串
- 针对字符串类型的参数，可以使用正则表达式对其进行过滤，避免错误信息进入

Mybatis 如何解决 SQL 注入问题？

Spring 如何解决 SQL 注入问题？

参考内容：

https://blog.csdn.net/github_36032947/article/details/78442189

慕课网：Web 安全之 SQL 注入