PHP 的 mysql_real_escape_string 和 MySQL 注入

发布于 2025-01-05 16:59:45 字数 308 浏览 0 评论 0原文

我一直在试图弄清楚 \x00、\n、\r、\ 或 \x1a 到底是如何导致 SQL 注入的(正如 https://www.php.net/manual/en/function.mysql-real-escape -string.php)

我理解单引号和双引号的概念,但是我如何以及为什么需要处理其他项目以使我的查询安全?

I have been trying to figure out how exactly \x00, \n, \r, \, or \x1a can cause an SQL Injection (as it is mentioned at https://www.php.net/manual/en/function.mysql-real-escape-string.php)

I understand the idea of single quote and double quotes, but how and why I need to take care of the other items to make my query safe?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(2

泪之魂 2025-01-12 16:59:45

我想知道同样的问题,我在 MySQL的C API文档,它指出:

编码的字符有“\”、“'”、“””、NUL (ASCII 0)、“\n”、“\r”和
Control+Z (\x1a)。严格来说,MySQL 只需要反斜杠和
用于在查询中引用字符串的引号字符被转义。
mysql_real_escape_string() 引用其他字符来制作它们
更容易在日志文件中阅读

字符串文字中还解释了:

如果满足以下条件,mysql 客户端将截断包含 NUL 字符的带引号的字符串:
它们不会被转义,并且 Control+Z 可能会被用作 END-OF-FILE
Windows 如果没有转义。

NUL字符在C语言中表示字符串的结束,因此这可以错误地终止mysql客户端程序的输入参数。对于 \x1a 也是如此,它在 Windows 下标记文件结尾(尝试在命令提示符中使用 \x1a 键入 test.txt > 文件中间的字符)。

主要的一点是,如果管理员的日志文件阅读器未显示超出这些字符之一的数据,则管理员可能会错过日志文件中的重要信息。但谁还在 Windows 下使用不稳定的 type 命令或等效命令来读取日志文件呢?

换句话说,PHP 中的 \n\r\0\x1a 没有危险,除了可能使日志文件难以阅读之外。

至于反斜杠,如果没有转义的话,\' OR 1==1将被转换为\\' OR 1==1,从而取消了反斜杠的效果转义引用。

I was wondering about the same question and I found the answer in the C API documentation of MySQL, it states:

Characters encoded are “\”, “'”, “"”, NUL (ASCII 0), “\n”, “\r”, and
Control+Z (\x1a). Strictly speaking, MySQL requires only that backslash and
the quote character used to quote the string in the query be escaped.
mysql_real_escape_string() quotes the other characters to make them
easier to read in log files
.

It is also explained in String Literals that:

The mysql client truncates quoted strings containing NUL characters if
they are not escaped, and Control+Z may be taken for END-OF-FILE on
Windows if not escaped.

The NUL character represents the end of a string in C language, so this can falsely terminate the input argument of the mysql client program. Same thing for \x1a, it marks the end-of-file under Windows (try type test.txt in a command prompt with a \x1a character in the middle of the file).

The main point is that an admin can miss important information in a log file if his log file reader doesn't show the data beyond one of these characters. But who still uses precarious type command or equivalent under Windows to read a log file anyway?

In other terms, there is no danger with \n, \r, \0 or \x1a in PHP, other than potentially making a log file difficult to read.

As for the backslash, \' OR 1==1 would be converted to \\' OR 1==1 if it was not escaped too, cancelling the effect of the escaping of the quote.

倾城花音 2025-01-12 16:59:45

假设您有

$SQL="select * from mytable where myfield='$uservalue'"

\ -> \

尝试 \' 或 1=1; --',转义引号后,您将得到 \\' 或 1=1; --' 并且 SQL 将是 select * from mytable where myfield='\\' or 1=1; --'

\x00

对于 PHP 来说不重要,但是对于 C 来说

抱歉,太懒了。

let's assume you have

$SQL="select * from mytable where myfield='$uservalue'"

\ -> \:

try \' or 1=1; --', after escaping the quote, you would get \\' or 1=1; --' and the SQL would be select * from mytable where myfield='\\' or 1=1; --'

\x00

Not important for PHP, but for C

Sorry, too lazy for the rest.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文