3

这个问题不是关于为经过验证的函数创建一个实际的替代方案来防止注入，而是关于如何与那些没有看到他们自制的注入预防代码中的缺陷的人争论！

我试图向一位同事说明一点，但似乎他对 SQL 注入的“解决方案”对我来说似乎相当安全。

他通过执行清除查询

$query = $_POST['username'];
$look = array('&', '#', '<', '>', '"', '\'', '(', ')', '%');
$safe = array('&amp;', '&#35;', '&lt;', '&gt;', '&quot;', '&#39;', '&#40;', '&#41;', '&#37;');
str_replace($look, $safe, $query);

然后继续登录

"SELECT * FROM users WHERE username = '" . $query . "'
    AND password = '" . md5($_POST['password']) . "'";

我试图让他使用 PDO 或等效项，但你怎么能真正违反这种保护？我没有答案，这真的让我很烦，因为我无法向他解释这有多不安全以及为什么不应该这样做。

4

3 回答 3

2

虽然这可能涵盖最典型的 SQL 注入问题 - 有几个已知问题使用多字节字符集和服务器上的某些区域设置。

然而，这不仅仅是逃避——这实际上是在改变输入到数据库的数据。考虑在适当的地方简单地添加斜杠，或者在将数据重新显示到浏览器时使用其中一种内置的转义方法，例如mysqli_real_escape_string在输入数据时等等。htmlentities这可以确保您存储在数据库中的内容始终是用户实际输入的内容 - 除非您有理由不这样做。

更好的是，当有疑问时，使用准备好的语句和绑定参数。然后你就可以完全避免 SQL 注入了。

于 2013-01-25T15:12:26.643 回答
2

我建议“是否可以违反这种方法”的问题是不相关的。真正要问的问题是“为什么要使用自产的临时解决方案，而不是已经编写、测试和调试过并且已经被数千名用户使用的解决方案？”

于 2013-01-25T15:16:13.130 回答
1

这实际上是一种可怕的“逃跑”方式，陷阱很多，而且只有少数是

  1. 此代码实际上是在假设唯一的输出媒体是 HTML 的情况下更改数据。根据我 15 年的经验，我会说这不是真的。改变你的数据总是一件坏事，它会导致未来的不一致和很多痛苦。其中一个直接原因是这样的“格式”将在每次编辑时成倍增加，从而使 &ampamp 仅靠引用。
  2. 通过数字注射。
  3. 通过标识符注入。
  4. 二阶注射。

...以及更多。
本网站的严格规则使我无法使用适当的词语来命名这样的“保护”，但您可以自己想象它们。

于 2013-01-27T09:00:21.607 回答