PreparedStatement 如何避免或防止 SQL 注入？

Question

我知道PreparedStatements 可以避免/防止SQL 注入。它是如何做到的？使用PreparedStatements 构造的最终表单查询是字符串还是其他形式？

Answer 1

考虑做同样事情的两种方法：

PreparedStatement stmt = conn.createStatement("INSERT INTO students VALUES('" + user + "')");
stmt.execute();

或者

PreparedStatement stmt = conn.prepareStatement("INSERT INTO student VALUES(?)");
stmt.setString(1, user);
stmt.execute();

如果“用户”来自用户输入，并且用户输入是

Robert'); DROP TABLE students; --

那么在第一种情况下，你会被淹没。在第二种情况下，您会安全，并且小鲍比桌将在您的学校注册。

Answer 2

要了解PreparedStatement如何防止SQL注入，我们需要了解SQL查询执行的阶段。

1.编译阶段。
2.执行阶段。

每当SQL Server引擎收到查询时，它必须经过以下阶段，

1. 解析和规范化阶段：
   在此阶段，检查查询的语法和语义。它检查引用表和
   查询中使用的列是否存在。
   它还还有许多其他任务要做，但我们不详细介绍。

2. 编译阶段：
   在此阶段，查询中使用的关键字（如 select、from、where 等）将转换为格式
   机器可以理解。
   这是解释查询并决定要采取的相应操作的阶段。
   它还还有许多其他任务要做，但我们不详细介绍。

3. 查询优化计划：
   在此阶段，创建决策树以查找执行查询的方式。
   它找出可以执行查询的方式数量以及与每种方式相关的成本
   执行查询。
   它选择执行查询的最佳计划。

4. 缓存：
   查询优化计划中选择的最佳计划存储在缓存中，以便下次查询时
   当相同的查询进来时，它不必再次经过阶段1、阶段2和阶段3。
   下次查询进来时，会直接在Cache中检查并从那里取出
   执行。

5. 执行阶段：
   在此阶段，执行提供的查询，并将数据作为 ResultSet 对象返回给用户。

PreparedStatement API 在上述步骤中的行为

1. PreparedStatements 不是完整的 SQL 查询并包含占位符，
   在运行时被实际用户提供的数据替换。

2. 每当任何包含占位符的PreparedStatment被传递到SQL Server引擎时，
   它经历以下阶段

   1. 解析和规范化阶段
   2. 编译阶段
   3. 查询优化计划
   4. 缓存（带有占位符的编译查询存储在缓存中。）

更新用户集用户名=？和密码=？哪里 id=？

3. 以上查询将被解析、使用占位符编译作为特殊处理、优化和
   被缓存。
   此阶段的查询已经编译并转换为机器可理解的格式。
   所以我们可以说存储在缓存中的查询是预编译的并且
   仅占位符需要替换为用户提供的数据。

4. 现在，在运行时，当用户提供的数据到来时，将从缓存中获取预编译查询，并将占位符替换为用户提供的数据。

（记住，占位符替换为用户数据后，最终的查询不是
再次编译/解释，SQL Server 引擎将用户数据视为纯数据，而不是
需要重新解析或编译的SQL；这就是PreparedStatement的美妙之处。）

如果查询不必再次经过编译阶段，那么无论替换什么数据
占位符被视为纯数据，对 SQL Server 引擎没有任何意义，它直接
执行查询。

注意：解析阶段之后的编译阶段，理解/解释查询
结构并赋予其有意义的行为。对于PreparedStatement，查询是
仅编译一次，并且始终选取缓存的编译查询来替换

由于PreparedStatement的一次性编译特性，它不会受到SQL注入的影响
攻击。

您可以在这里通过示例获得详细说明：
https://javabypatel.blogspot .com/2015/09/how-prepared-statement-in-java-prevents-sql-injection.html

Answer 3

SQL 注入的问题在于，用户输入被用作 SQL 语句的一部分。通过使用准备好的语句，您可以强制将用户输入作为参数的内容进行处理（而不是作为 SQL 命令的一部分）。

但是，如果您不使用用户输入作为准备好的语句的参数，而是通过将字符串连接在一起来构建 SQL 命令，那么即使使用准备好的语句，您仍然容易受到 SQL 注入的攻击。

Answer 4

在PreparedStatement 中使用的SQL 是在驱动程序上预编译的。从那时起，参数将作为文字值而不是 SQL 的可执行部分发送到驱动程序；因此不能使用参数注入 SQL。 PreparedStatements（预编译+仅发送参数）的另一个有益的副作用是，即使参数值不同（假设驱动程序支持PreparedStatements），多次运行该语句时也会提高性能，因为驱动程序不必每次都执行 SQL 解析和编译参数改变的时间。

Answer 5

我猜它将是一个字符串。但输入的参数会被发送到数据库&在创建实际的 SQL 语句之前将应用适当的转换/转换。

举个例子，它可能会尝试看看 CAST/转换是否有效。
如果可行的话，它可以创建一个最终声明。

   SELECT * From MyTable WHERE param = CAST('10; DROP TABLE Other' AS varchar(30))

尝试使用接受数字参数的 SQL 语句示例。
现在，尝试传递一个字符串变量（具有可接受作为数字参数的数字内容）。它会引发任何错误吗？

现在，尝试传递一个字符串变量（其内容不可接受作为数字参数）。看看会发生什么？

Answer 6

准备好的语句更安全。它将参数转换为指定类型。

例如，stmt.setString(1, user); 会将 user 参数转换为字符串。

假设参数包含一个包含可执行命令的 SQL 字符串：使用准备好的语句将不允许这样做。

它添加了元字符（又名自动转换）。

这使得它更加安全。

Answer 7

SQL注入：当用户有机会输入可能成为sql语句一部分的内容

时例如：

String query =“INSERT INTO Students VALUES('”+ user +“')”

当用户输入“Robert”时；丢掉桌子的学生； –”作为输入，会导致SQL注入，

准备好的语句如何防止这种情况发生？

字符串查询=“INSERT INTO Students VALUES('”+“:name”+“')”

parameters.addValue(“name”, user);

=>当用户再次输入“Robert”时）；丢掉桌子的学生； –“，输入字符串在驱动程序上预编译为文字值，我猜它可能会被转换为：

CAST('Robert');丢掉桌子的学生； –' AS varchar(30))

因此，最后，该字符串将作为名称逐字插入到表中。

http://blog .linguiming.com/index.php/2018/01/10/why-prepared-statement-avoids-sql-injection/

Answer 8

PreparedStatement：

1）SQL语句的预编译和数据库端缓存导致整体执行速度更快，并且能够批量重用相同的SQL语句。

2) 通过内置的引号和其他特殊字符转义自动防止 SQL 注入攻击。请注意，这要求您使用任何PreparedStatement setXxx() 方法来设置该值。

Answer 9

PreparedStatement<如果您仍在连接字符串，那么单独 /code>并不能帮助您。

例如，一名恶意攻击者仍然可以执行以下操作：

• 调用睡眠函数，使所有数据库连接都繁忙，从而使您的应用程序不可用
• 从数据库中提取敏感数据
• 绕过用户身份验证

不仅是 SQL，甚至是 JPQL 或 HQL如果您不使用绑定参数，则可能会受到损害。

最重要的是，在构建 SQL 语句时绝对不应该使用字符串连接。为此目的使用专用 API，例如 JPA Criteria API。

Answer 10

在准备好的语句中，用户被迫输入数据作为参数。如果用户输入一些易受攻击的语句，例如 DROP TABLE 或 SELECT * FROM USERS，则数据不会受到影响，因为这些语句将被视为 SQL 语句的参数