当涉及到数据库查询时，始终尝试并使用准备好的参数化查询。这个mysqli和PDO图书馆支持这一点。这比使用转义函数(如mysql_real_escape_string.

是,mysql_real_escape_string实际上只是一个字符串转义函数。这不是一颗神奇的子弹。它所要做的就是转义危险字符，以便它们可以安全地在单个查询字符串中使用。但是，如果您不事先清理您的输入，那么您将容易受到某些攻击向量的攻击。

想象一下下面的SQL：$result = "SELECT fields FROM table WHERE id = ".mysql_real_escape_string($_POST['id']);

您应该能够看到这很容易被利用。

想象一下id参数包含公共攻击向量：1 OR 1=1

没有危险的字符在那里编码，所以它将直接通过转义过滤器。离开我们：SELECT fields FROM table WHERE id= 1 OR 1=1

这是一个可爱的SQL注入向量，允许攻击者返回所有行。或1 or is_admin=1 order by id limit 1

产SELECT fields FROM table WHERE id=1 or is_admin=1 order by id limit 1

它允许攻击者在这个完全虚构的示例中返回第一个管理员的详细信息。

虽然这些功能是有用的，但必须谨慎使用。您需要确保所有的web输入都在一定程度上得到验证。在这种情况下，我们发现我们可以被利用，因为我们没有检查我们作为数字使用的变量实际上是数字。在PHP中，您应该广泛地使用一组函数来检查输入是否为整数、浮点数、字母数字等等。但是当涉及到SQL时，请注意准备好的语句的值。如果是准备好的语句，上述代码将是安全的，因为数据库函数应该知道1 OR 1=1不是有效的文字。

至于htmlspecialchars()..那是自己的雷区。

PHP有一个真正的问题，因为它有一个完整的、与html相关的转义函数的选择，并且没有明确的指导说明哪些函数可以做什么。

首先，如果你在一个HTML标签中，你会遇到真正的麻烦。看echo '';

我们已经在HTML标记中了，所以我们不需要来做任何危险的事情。我们的攻击矢量可能是javascript:alert(document.cookie)

现在，生成的HTML看起来像

攻击直接通过。

情况会变得更糟。为什么？因为htmlspecialchars(这样称呼)只编码双引号，而不是单引号。所以如果我们有echo "";

我们邪恶的攻击者现在可以注入新的参数pic.png' οnclick='location.href=xxx' οnmοuseοver='...

给我们

在这种情况下，没有灵丹妙药，你只需要自己对输入进行santise。如果你试着过滤掉坏角色，你肯定会失败的。采取白名单的方法，只让通过的字符是好的。看XSS备忘单关于向量的多样性的例子

即使你用htmlspecialchars($string)在HTML标记之外，您仍然容易受到多字节字符集攻击向量的攻击.

您可以使用的最有效的方法是将mb_COMPATE_CONITY和html实体组合在一起，如下所示。$str = mb_convert_encoding($str, 'UTF-8', 'UTF-8');$str = htmlentities($str, ENT_QUOTES, 'UTF-8');

即使这样，IE6也很脆弱，因为它处理UTF的方式。但是，在IE6的使用率下降之前，您可能会退回到更有限的编码，比如ISO-8859-1。