Question

这个问题不是关于为防止注射的已证实的功能创建一个实际的替代方案，而是关于如何与那些没有看到自制注射防止代码中的缺陷的人争论！ < / p>

我试图向同事说明一点，但似乎他对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或等价物，但你怎么能真正违反这种保护？我没有答案，这真的让我烦恼，因为我不能解释他这是不安全的，为什么不应该这样做。

Answer 1

虽然这可能涵盖了大多数典型的SQL注入问题 - 但在服务器上使用多字节字符集和某些区域设置存在一些已知问题。

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

更好的是，如果有疑问，请使用预准备语句和绑定参数。那么你完全可以免于SQL注入。

Answer 2

我建议“可以违反这种做法”的问题并不重要。要问的真正问题是“为什么要使用自行开发的 ad hoc 解决方案，而不是已经编写，测试和调试过的解决方案，并且已经被成千上万的用户使用？”

Answer 3

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

此代码实际上是在假设唯一的输出媒体是HTML的情况下更改数据。根据我15年的经验，我会说这不是真的。改变你的数据总是一件坏事，它将导致后期的不一致和很多痛苦。其中一个立刻就是这样的“格式化”会在每次编辑时成倍增加，使得＆amp; ampampamp不仅仅是引用。
通过数字注射。
通过标识符进行注入。
二次注射。

......还有更多。
本网站的严格规定阻止我在命名这样的“保护”时使用正确的词语，但可以自己想象它们。

如何破坏这种SQL注入保护

3 个答案: