Question

这是一个针对PDO准备语句的安全问题。使用PDO我知道SQL注入的风险几乎是不可能的，并且该类为您处理所有这些。使用它们mysql_ * stack我总觉得好像我没有很好地处理安全问题。我通常习惯于编写数百行代码来处理安全问题，而现在我只是编写查询。

对于PDO语句是否真的存在任何安全威胁，除了db中的字符串长度之外我还要担心吗？

Answer 1

肯定是的。

事实上，本土预备陈述仅适用于简单的教科书案件意味着你仍然需要为任何复杂的情况写一些“数百行”。我在PDO tag wiki中对这些案例做了一个小摘要。主要缺点是

没有标识符的占位符。您必须手动格式化并注入它们，就像旧的mysql_ *代码一样。
数组没有占位符。意味着您仍然需要手动编写一些代码，然后将其注入查询中 - 因此，仍有可能陷入困境。

因此，即使在PDO上，您也需要更高级别的抽象。一个常见的解决方案是使用某种 Query Builder ，它们由每个现代框架提供。

但我个人讨厌查询构建器，因为它们对我来说似乎太臃肿了，假装替换整个SQL但显然没有用它。所以，我不明白为什么在使用纯SQL时使用PHP编写的SQL。为此，我创建了一个我的抽象库，以纠正本机预处理语句safeMysql的所有缺点。它拥有您需要的所有内容的占位符，因此使查询比PDO更安全，但它使应用程序代码显着缩短。

使用safeMysql表示你确实可以“只是字面上写查询”：

$sql  = "SELECT * FROM articles WHERE id IN(?a) ORDER BY ?n LIMIT ?i"
$data = $db->getAll($sql, $ids,$_GET['order'], $limit);

$sql  = "INSERT INTO stats SET pid=?i,ip=inet_aton(?s),?u ON DUPLICATE KEY UPDATE ?u";
$db->query($sql, $pid, $ip, $data, $data);

只需将这些2行与您需要使用原始PDO编写的代码量进行比较。

Answer 2

我认为答案与“sql注入攻击”非常接近。 mysqli prepared statements and mysqli_real_escape_string

还有许多其他类型的攻击，但至少所有值都被转义。

依靠PDO“修复”您的安全性就像依靠编译器来查找您的错误。

你甚至还需要数据库安全吗？

2 个答案: