MySQLi的准备是出于安全考虑吗?

发布于 2024-12-02 22:26:12 字数 613 浏览 1 评论 0原文

因此,我开始使用 MySQLi 扩展,因为我听说它将来会受到支持。我读到,出于安全原因,我必须使用 prepare() 而不是使用 mysql_real_escape_string() ,例如,当我在查询中使用 $_GET 或 $_POST 时。

这是真的吗?我发现prepare() 非常适合制作可以更改参数的SQL 查询模板。因此脚本在 SQL 级别上也可以是动态的。它真的很有用。但我找不到有关其安全措施的真实信息。它真的可以逃避邪恶的东西并防止注射吗?或者我必须在编程层面上处理它?

例如这段代码安全吗?正如您所看到的,它使用 $_GET 来填充模板,因此如果 MySQLi 准备没有按照我希望的方式工作,那可能会非常危险。

$stmt = $mysqli->prepare('SELECT description,title FROM menu WHERE name = ?');

$stmt->bind_param('s', $n);

$n = $_GET['b'];

$stmt->bind_result($meta_description,$meta_title);
$stmt->execute(); 

So, I started to use MySQLi extension as I heard it will be the supported one in the future. I read about that instead of using mysql_real_escape_string() I must use prepare() for security reasons, for example when I use a $_GET or $_POST in my query.

Is it true? I see that prepare() is good for making SQL query templates where I can change parameters. So the script can be dynamic on SQL level too. Its really useful. But I can't find real info about its security measures. Is it really escapes evil stuff and protects from injection? Or I have to deal with it on programming level?

For example this code is safe? As you can see it use a $_GET to fill the template so it can be really dangerous if MySQLi prepare isn't work as I want it to be.

$stmt = $mysqli->prepare('SELECT description,title FROM menu WHERE name = ?');

$stmt->bind_param('s', $n);

$n = $_GET['b'];

$stmt->bind_result($meta_description,$meta_title);
$stmt->execute(); 

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

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

发布评论

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

评论(1

再见回来 2024-12-09 22:26:12

准备好的参数不受注入的影响,因为它们是在解析 SQL 后提供给服务器的,即它们不可能被解释为 SQL 片段,而这是 SQL 注入攻击的基础。

在您的示例中,服务器将使用 $_GET['b'] 变量中的任何内容与 name 数据库字段进行比较,但是绝对没有WAY 服务器可能会被欺骗将该文本解释为布尔方程,语句结束后跟删除,...

因此,从设计上来说,它不提供 SQL 注入攻击面,这就是为什么使用准备好的语句比所有类型的语句都要优越得多转义和输入清理方案。

Prepared parameters are immune to injection because they get offered to the server after SQL was parsed, ie no way they can be interpreted as SQL fragments, which is the base of an SQL injection attack.

In your example whatever is in the $_GET['b'] variable will be used by the server to compare with the name database field but there is absolutely NO WAY the server could be tricked into interpreting that text as a boolean equation, an end of statement followed by say a delete, ...

So by design it doesn't offer SQL injection an attack surface, and that's why using prepared statements is so much superior to all kinds of escaping and input scrubbing schemes.

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