Question

我对mysql_real_escape_string和addslashes有疑问。我的PHP文件中有一个表单$_POST['title']，然后我有：

$title = mysql_real_escape_string(addslashes($_POST['title']));

我将$title插入我的数据库。当我想从我的数据库中获取此值时，我有：

$title = stripslashes($results['title']);

问题是当我提交这样的内容时：abs"'@，我的结果是：abs\"\'@。

我不知道这个错误在哪里。

Answer 1

根本不打扰使用addslashes，mysql_real_escape_string能够自行完成。所以使用：

$title = mysql_real_escape_string($_POST['title']);

从检索代码中删除stripslashes。如果问题仍然存在，您可能会选择其中一个magic_quotes选项 - 如果是，请将其关闭！

Answer 2

请勿使用addslashes。您只需要mysql_real_escape_string。

$title = mysql_real_escape_string($_POST['title']);

Answer 3

不要使用任何一种。 mysql扩展已过时并正在弃用。而是使用PDO或mysqli和准备好的语句。准备好的语句参数不易受到注入攻击，您从不会引用数据或忘记引用数据。

还有其他类型的注入要考虑转义和预处理语句参数无法解决。确保您的生产代码防范cross site scripting。在示例中，海报可以在标题元素中提交任意HTML。

Answer 4

addslashes()和stripslashes()调用以及magic_quotes设置是早期PHP开发人员尝试提供防范SQL注入的措施。然而，从那时起，防御性编程的最新技术已经发生了变化。

这种方法存在一些问题，第一种是每个数据库专用函数使用的转义算法（例如mysql_real_escape_string()）与addslashes()略有不同。

另一个大问题是，在进入处理之前转义数据已被证明是一个不好的地方，因为现在PHP代码必须处理转义数据。这使得代码比必要的更复杂，因为这不是需要转义的东西。不幸的是，许多PHP安装仍然启用了magic_quotes，这意味着程序员仍然需要处理它。

（如果你无法关闭magic_quotes，一招就是做这样的事情：

$stripslashes = (get_magic_quotes_gpc() ? "stripslashes" : create_function('$f', 'return $f;'));

...靠近页面顶部，然后您可以在检索变量时执行$stripslashes($_POST[$form_field])。最大的缺陷就是你必须在每一页上都这样做 - 但有时这是你唯一的选择。一个更好的选择是编写一个调度程序，在一个地方处理传入的变量。）

在需要转义之前，正确的数据转义位置就在它之前。这就是为什么人们建议在组装SQL时使用mysql_real_escape_string()。这种方法的另一个优点是，当您从数据库中检索值时，您不必对它执行任何特殊操作。

当然，正确的前瞻性解决方案是使用mysqli函数。这意味着使用new mysqli()创建数据库连接对象并使用实例方法real_escape_string()。