mysql_real_escape_string 和 html_special_chars 足够了吗？

Question

这个问题被问了很多，但我仍然没有在 stackoverflow 上找到直接的答案。这两个功能够不够？网上有很多相互矛盾的评论“是的，可以吗？”，“不，永远不要使用它”。其他人说，使用 PDO，我不明白。我只是 PHP 的初学者，所以我不'不完全了解安全的所有来龙去脉。 我尝试阅读和理解以下内容，但很多内容对我来说没有多大意义。

http://ha.ckers.org/xss.html
执行 htmlspecialchars 和 mysql_real_escape_string保护我的 PHP 代码免受注入？

如果我使用 preg_replace 去除不需要的字符会怎样？

我非常困惑，不知道从哪里开始。

编辑：有人还可以建议我如何理解准备好的陈述（假设这是最好的选择）。

Answer 1

Sam，如果您将输入存储在数据库中，为了避免 SQL 注入和 XSS，那么这两个函数就足够了。如果您要存储密码，则必须使用单向加密对密码进行加密（即密码无法解密）。

让我扩展我的答案：
首先，SQL注入是一种恶意用户试图修改你的SQL语句以使其按照他们的意愿行事的方法。例如，假设您有一个登录表单。通过将以下值之一插入到不受保护的表单中，我将能够在不知道用户名或密码的情况下登录第一个帐户：

' or 1=1 -- 

上述注入有很多版本。让我们检查一下它对数据库上执行的 SQL 做了什么：

PHP：
mysql_query("SELECT * FROM users WHERE username='" . $username."' AND password='" . $password . "';");

当执行上述命令时，将向数据库发送以下 SQL：

SELECT * FROM users WHERE username='' or 1=1-- ' AND password='' or 1=1--';

该 SQL 的有效部分是这样的：
SELECT * FROM users WHERE username='' or 1=1

因为双破折号（后面有空格）是注释，删除了语句的其余部分。

现在，恶意用户就可以访问了。通过使用转义函数（例如 mysql_real_escape_string），您可以对内容进行转义，以便将以下内容发送到数据库：

SELECT * FROM users WHERE username='\' or 1=1-- ' AND password='\' or 1=1--';

现在转义引号，生成预期的字符串，就是字符串。

现在让我们看看一些 XSS。
另一个恶意用户想要更改页面的布局。众所周知的 XSS 攻击是 2005 年针对 Facebook 的 Facespace 攻击。这涉及将原始 HTML 插入表单中。数据库将保存原始 HTML，然后将其显示给用户。恶意用户可以使用 script 标签插入一些 javascript，这可以做任何 javascript 可以做的事情！

这是通过转换 < 来转义的。和>至分别。为此，您可以使用 html_special_chars 函数。

这应该足以保护网站上的正常内容。然而密码却是另一回事。

对于密码，您还必须对密码进行加密。为此，建议使用 PHP 的 crypt 函数。

但是，一旦密码被加密并作为加密密码保存在数据库中，如何解密它以检查它是否正确？简单的答案 - 你不会解密它。提示：密码始终加密为相同的值。

您是否在想“我们可以在用户登录时对密码进行加密，并根据数据库中的密码进行检查”，您是对的......

Answer 2

取决于您使用输入的目的以及输入的去向。

在清理 php 应用程序的输入时唯一需要假设的是，那里有很多聪明的人，如果他们真的想破坏你的应用程序，他们会找到一种方法来做到这一点。

遵循您列出的指南和其他指南是一个很好的开始。但是，您所做的每一点清理都会花费大量的时间和内存来执行。

所以这实际上取决于您使用输入的目的以及输入的去向。

mysql_real_escape_string 和 html_special_chars 是很好的实用程序，但您不应该仅仅依赖它们，而且并不总是需要它们。

不要气馁，因为即使是成熟且编程良好的网站也必须跟上 xss 和其他攻击的最新情况。有趣的猫和老鼠游戏。

你可以从框架开始，我喜欢 codeignitor。浏览他们的安全课程，看看他们是如何处理的。

或者更好的是，编写一个简单的表单处理器，并尝试想出自己运行任意代码的方法。你会惊讶地发现你能想出这么多的方法。

Answer 3

假设您询问安全性，则 mysql_real_escape_string 有一个问题。

这个函数与安全性完全无关。

每当你需要转义时，不管“安全性”如何，你都需要它，但只是因为它是 SQL 语法所需要的。并且在哪里你不需要它，逃避对你没有任何帮助。

这个函数的用法很简单：当你必须在查询中使用带引号的字符串时，你必须转义它的内容。不是因为一些想象中的“恶意用户”，而仅仅是为了转义这些用于分隔字符串的引号。这是极其简单的规则，但 PHP 人员却犯了极大的错误。

这只是与语法相关的功能，与安全无关。

根据安全问题上的此功能，相信它会“保护您的数据库免受恶意用户的攻击”将导致您注入。

您可以自己得出一个结论：
不，这个功能还不够。

准备好的陈述也不是灵丹妙药。它只能在一半可能的情况下保护您的背部。