当前位置：文江博客话题详情

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

发布于 2024-08-08 16:03:41 字数 92 浏览 6 评论 0原文

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

记忆里有你的影子 2024-08-15 16:03:41

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

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; --

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

Consider two ways of doing the same thing:

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();

If "user" came from user input and the user input was

Robert'); DROP TABLE students; --

Then in the first instance, you'd be hosed. In the second, you'd be safe and Little Bobby Tables would be registered for your school.

回复收藏 0 原文

夜雨飘雪 2024-08-15 16:03:41

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

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

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

解析和规范化阶段：
在此阶段，检查查询的语法和语义。它检查引用表和
查询中使用的列是否存在。
它还还有许多其他任务要做，但我们不详细介绍。
编译阶段：
在此阶段，查询中使用的关键字（如 select、from、where 等）将转换为格式
机器可以理解。
这是解释查询并决定要采取的相应操作的阶段。
它还还有许多其他任务要做，但我们不详细介绍。
查询优化计划：
在此阶段，创建决策树以查找执行查询的方式。
它找出可以执行查询的方式数量以及与每种方式相关的成本
执行查询。
它选择执行查询的最佳计划。
缓存：
查询优化计划中选择的最佳计划存储在缓存中，以便下次查询时
当相同的查询进来时，它不必再次经过阶段1、阶段2和阶段3。
下次查询进来时，会直接在Cache中检查并从那里取出
执行。
执行阶段：
在此阶段，执行提供的查询，并将数据作为 ResultSet 对象返回给用户。

PreparedStatement API 在上述步骤中的行为

PreparedStatements 不是完整的 SQL 查询并包含占位符，
在运行时被实际用户提供的数据替换。
每当任何包含占位符的PreparedStatment被传递到SQL Server引擎时，
它经历以下阶段
1. 解析和规范化阶段
2. 编译阶段
3. 查询优化计划
4. 缓存（带有占位符的编译查询存储在缓存中。）

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

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

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

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

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

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

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

To understand how PreparedStatement prevents SQL Injection, we need to understand phases of SQL Query execution.

1. Compilation Phase.
2. Execution Phase.

Whenever SQL server engine receives a query, it has to pass through below phases,

Parsing and Normalization Phase:
In this phase, Query is checked for syntax and semantics. It checks whether references table and
columns used in query exist or not.
It also has many other tasks to do, but let's not go in detail.
Compilation Phase:
In this phase, keywords used in query like select, from, where etc are converted into format
understandable by machine.
This is the phase where query is interpreted and corresponding action to be taken is decided.
It also has many other tasks to do, but let's not go in detail.
Query Optimization Plan:
In this phase, Decision Tree is created for finding the ways in which query can be executed.
It finds out the number of ways in which query can be executed and the cost associated with each way
of executing Query.
It chooses the best plan for executing a query.
Cache:
Best plan selected in Query optimization plan is stored in cache, so that whenever next
time same query comes in, it doesn't have to pass through Phase 1, Phase 2 and Phase 3 again.
When next time query come in, it will be checked directly in Cache and picked up from there
to execute.
Execution Phase:
In this phase, supplied query gets executed and data is returned to user as ResultSet object.

Behaviour of PreparedStatement API on above steps

PreparedStatements are not complete SQL queries and contain placeholder(s),
which at run time are replaced by actual user-provided data.
Whenever any PreparedStatment containing placeholders is passed in to SQL Server engine,
It passes through below phases
1. Parsing and Normalization Phase
2. Compilation Phase
3. Query Optimization Plan
4. Cache (Compiled Query with placeholders are stored in Cache.)

UPDATE user set username=? and password=? WHERE id=?

Above query will get parsed, compiled with placeholders as special treatment, optimized and
get Cached.
Query at this stage is already compiled and converted in machine understandable format.
So we can say that Query stored in cache is Pre-Compiled and
only placeholders need to be replaced with user-provided data.
Now at run-time when user-provided data comes in, Pre-Compiled Query is picked up from Cache and placeholders are replaced with user-provided data.

(Remember, after place holders are replaced with user data, final query is not
compiled/interpreted again and SQL Server engine treats user data as pure data and not a
SQL that needs to be parsed or compiled again; that is the beauty of PreparedStatement.)

If the query doesn't have to go through compilation phase again, then whatever data replaced on the
placeholders are treated as pure data and has no meaning to SQL Server engine and it directly
executes the query.

Note: It is the compilation phase after parsing phase, that understands/interprets the query
structure and gives meaningful behavior to it. In case of PreparedStatement, query is
compiled only once and cached compiled query is picked up all the time to replace
user data and execute.

Due to one time compilation feature of PreparedStatement, it is free of SQL Injection
attack.

You can get detailed explanation with example here:
https://javabypatel.blogspot.com/2015/09/how-prepared-statement-in-java-prevents-sql-injection.html

回复收藏 0 原文

别挽留 2024-08-15 16:03:41

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

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

回复收藏 0 原文

浊酒尽余欢 2024-08-15 16:03:41

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

回复收藏 0 原文

她比我温柔 2024-08-15 16:03:41

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

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

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

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

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

I guess it will be a string. But the input parameters will be sent to the database & appropriate cast/conversions will be applied prior to creating an actual SQL statement.

To give you an example, it might try and see if the CAST/Conversion works.
If it works, it could create a final statement out of it.

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

Try an example with a SQL statement accepting a numeric parameter.
Now, try passing a string variable (with numeric content that is acceptable as numeric parameter). Does it raise any error?

Now, try passing a string variable (with content that is not acceptable as numeric parameter). See what happens?

回复收藏 0 原文