【Web 安全】SQL 注入

想变厉害的大白菜

已于 2022-08-22 11:22:15 修改

阅读量860

点赞数

分类专栏：安全文章标签： SQL注入预编译参数绑定输入验证防御策略

于 2022-08-22 10:45:20 首次发布

本文链接：https://blog.csdn.net/weixin_44211968/article/details/126459770

版权

安全专栏收录该内容

10 篇文章 17 订阅

订阅专栏

文章目录

一、SQL 注入是什么？
二、SQL 注入原理
三、SQL 注入存在的原因
四、SQL 注入的防御
五、其他知识
六、参考链接

一、SQL 注入是什么？

SQL 注入是一种攻击方式，在这种攻击方式中，在字符串中插入恶意代码，然后将该字符串传递到 SQL Server 的实例以进行分析和执行。

构成 SQL 语句的任何过程 都应进行 注入漏洞审阅，因为 SQL Server 将执行其接收到的所有语法有效的查询。

一个有经验的、坚定的攻击者甚至可以操作参数化数据。

二、SQL 注入原理

SQL 注入的主要形式包括直接 将代码插入到与 SQL 命令串联在一起 并使其得以执行的用户输入变量。一种间接的攻击会将恶意代码注入要在表中存储或作为元数据存储的字符串。在存储的字符串随后串连到一个动态 SQL 命令中时，将执行该恶意代码。

一种注入过程的工作方式是提前终止文本字符串，然后追加一个新的命令。由于插入的命令可能在执行前追加其他字符串，因此攻击者将用注释标记“–”来终止注入的字符串。执行时，此后的文本将被忽略：

用户将被提示输入一个市县名称。如果用户输入 Redmond，则查询将由与下面内容相似的脚本组成：

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'

但是，假定用户输入以下内容：

Redmond'; drop table OrdersTable--

此时，脚本将组成以下查询：

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

分号 (;) 表示一个查询的结束和另一个查询的开始。双连字符 (--) 指示当前行余下的部分是一个注释，应该忽略。如果修改后的代码语法正确，则服务器将执行该代码。 SQL Server 处理该语句时， SQL Server 将首先选择 OrdersTable 中的所有记录（其中 ShipCity 为 Redmond）。然后， SQL Server 将删除 OrdersTable。

只要注入的 SQL 代码语法正确，便无法采用编程方式来检测篡改。因此，必须验证所有用户输入，并仔细检查在您所用的服务器中执行构造 SQL 命令的代码。

下一部分说明了编写代码的最佳做法。

三、SQL 注入存在的原因

SQL 注入漏洞存在的原因，就是拼接 SQL 参数。也就是将用于输入的查询参数，直接拼接 在 SQL 语句中，导致了SQL 注入漏洞。

sql注入的原因，表面上说是因为拼接字符串，构成 SQL 语句，没有使用 SQL 语句预编译，绑定变量。

但是更深层次的原因是，将用户输入的字符串，当成了 “SQL语句” 来执行。

比如上面的 String sql = “select id,no from user where id=” + id;

我们希望用户输入的 id 的值，仅仅作为一个字符串字面值，传入数据库执行，但是当输入了： 2 or 1=1 时，其中的 or 1=1 并没有作为 where id= 的字面值，而是作为了SQL语句来执行的。所以其本质是 将用户的输入的数据，作为了命令来执行。

所以防御方法就是，要对用户的输入做验证和防范！！！

四、SQL 注入的防御

1. 预编译和绑定变量

采用 SQL 语句预编译和绑定变量，是防御sql注入的最佳方法。

String sql = "select id, no from user where id=?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setInt(1, id);
ps.executeQuery();

如上所示，就是典型的采用 SQL 语句预编译和绑定变量。为什么这样就可以防止 SQL 注入呢？

其原因就是：采用了 PreparedStatement，就会将 SQL 语句："select id, no from user where id=?" 预先编译好，也就是SQL引擎会预先进行语法分析，产生语法树，生成执行计划，也就是说，后面你输入的参数，无论你输入的是什么，都不会影响该 SQL 语句的语法结构了，因为语法分析已经完成了，而语法分析主要是分析 SQL 命令，比如 select ,from ,where ,and, or ,order by 等等。所以即使你后面输入了这些 SQL 命令，也不会被当成 SQL 命令来执行了，因为这些 SQL 命令的执行，必须先的通过语法分析，生成执行计划，既然语法分析已经完成，已经预编译过了，那么后面输入的参数，是绝对不可能作为 SQL 命令来执行的，只会被当做字符串字面值参数。所以 SQL 语句预编译 可以防御 SQL 注入。

注意：

实际项目中，一般我们都是采用各种的框架，比如 ibatis, hibernate,mybatis 等等。他们一般也默认就是 SQL 预编译的。对于 ibatis/mybatis，如果使用的是 #{name}形式的，那么就是 SQL 预编译，使用 ${name} 就不是 SQL 预编译的。

2. 严格检查参数的数据类型

但是不是所有场景都能够采用 sql语句预编译，有一些场景必须的采用字符串拼接的方式，此时，我们严格检查参数的数据类型，还有可以使用一些安全函数，来方式sql注入。

比如 String sql = "select id,no from user where id=" + id;

在接收到用户输入的参数时，我们就 严格检查 id，只能是 int 型。复杂情况可以使用正则表达式来判断。这样也是可以防止sql注入的。

安全函数的使用，比如：

MySQLCodec codec = new MySQLCodec(Mode.STANDARD);
name = ESAPI.encoder().encodeForSQL(codec, name);
String sql = "select id,no from user where name=" + name;

其中 ESAPI.encoder().encodeForSQL(codec, name)，该函数会将 name 中包含的一些特殊字符进行编码，这样 SQL 引擎就不会将 name 中的字符串当成 SQL 命令来进行语法分析了。

Parameters SQL Server 集合提供了类型检查和长度验证。如果使用 Parameters 集合，则输入将被视为 文字值 而不是可执行代码。使用 Parameters 集合的另一个好处是可以 强制执行类型和长度检查。范围以外的值将触发异常。

3. 验证所有输入

始终通过测试类型、长度、格式和范围来验证用户输入。实现对恶意输入的预防时，请注意应用程序的体系结构和部署方案。请注意，设计为在安全环境中运行的程序可能会被复制到不安全的环境中。以下建议应被视为最佳做法：

对应用程序接收的数据不做任何有关大小、类型或内容的假设。例如，您应该进行以下评估：

如果一个用户在需要邮政编码的位置无意中或恶意地输入了一个 10 MB 的 MPEG 文件，应用程序会做出什么反应？
如果在文本字段中嵌入了一个 DROP TABLE 语句，应用程序会做出什么反应？
测试输入的大小和数据类型，强制执行适当的限制。这有助于防止有意造成的缓冲区溢出。
测试字符串变量的内容，只接受所需的值。拒绝包含二进制数据、转义序列和注释字符的输入内容。这有助于防止脚本注入，防止某些缓冲区溢出攻击。
使用 XML 文档时，根据数据的架构对输入的所有数据进行验证。
切勿直接从用户输入生成 Transact-SQL 语句。
使用存储过程来验证用户输入。
在多层环境中，所有数据都应该在验证之后才允许进入可信区域。未通过验证过程的数据应被拒绝，并向前一层返回一个错误。
实现多层验证。对无目的的恶意用户采取的预防措施对坚定的攻击者可能无效。更好的做法是在用户界面和所有跨信任边界的后续点上验证输入。

例如，在客户端应用程序中验证数据可以防止简单的脚本注入。但是，如果下一层认为其输入已通过验证，则任何可以绕过客户端的恶意用户就可以不受限制地访问系统。
绝不串联未验证的用户输入。字符串串联是脚本注入的主要输入点。
不接受以下来自可构造文件名的字段中的字符串：AUX、CLOCK $、 COM 1 到 COM 8 、 CON 、 CONF I G$ 、LPT1 到 LPT8、NUL 和 PRN。