什么是 URL 的“足够的清理”[重复]答案

【问题标题】：What is "enough sanitization" for a URL [duplicate]什么是 URL 的“足够的清理”[重复]
【发布时间】：2011-01-04 00:19:45
【问题描述】：

网址是

strip_tags() 和 mysql_real_escape_string() 就够了吗？

【问题讨论】：

我收到了类似问题的一些很好的答案；如果您愿意，请查看stackoverflow.com/questions/549987/…。最好的解决方案可能是按照 Mike Boers 的回答建议完全重建 URL。

【解决方案1】：

“足够的消毒”完全取决于您所谈论的环境。 MySQL 的清理应该被视为与 Web 输出的清理完全分开，您应该单独处理它们以避免很多麻烦。

为 MySQL 清理

mysql_real_escape_string() 将清理一段数据并使其安全地放入 SQL 查询中。
应绝对忽略任何其他类型的恶意数据，例如字符串中的 HTML 标记。在这里尝试对其进行操作会令您头疼，因为您稍后会在将其从数据库中取出后尝试“取消操作”它。不良的“网络数据”不会损害您的数据库。

输出消毒

输出时的htmlspecialchars($val) 将阻止呈现任何恶意标签，因为< 和> 字符被转换为其实体表示，而不是作为标签分隔符呈现。
如果要输出 HTML 元素的引用属性内的内容，请使用 ENT_QUOTES 修饰符，例如 <input name="email" value="<?php echo htmlspecialchars($email,ENT_QUOTES); ?>" />

这应该就是您所需要的，除非您有特殊要求。 strip_tags() 不应该真正用于清理，因为它可能会被格式错误的 HTML 所愚弄。清理是一个有价值的目标，如果你可以将你的上下文分开，你会遇到更少的数据操作问题。

【讨论】：

+1 仅在需要时进行消毒。当然，清理 SQL 是邪恶的，只需使用参数化查询...
@sleske - 是的，这就是当今流行的智慧。不过，清理 SQL 并不是邪恶的。许多系统将使用较旧的数据库版本或驱动程序，并且可能无法访问 MySQLi。消毒得到坏名声的唯一原因是人们忘记去做。准备好的查询只是抽象出手动清理（以及其他优点）。
“参数化查询”是什么意思？
参数化查询是由 PHP 的 PDO (php.net/PDO) 和 MySQLi (php.net/mysqli) 驱动程序包提供的。本质上，您为数据创建了一个带有占位符的查询，并将数据单独传递给查询函数，在那里它们进行适当的转换和清理。如果您有兴趣，请阅读 PHP 手册中的这两个模块并在 Google 上搜索示例。它们值得一试和使用。

【解决方案2】：

我最初赞成弗兰克的回答，但想到了一个问题：htmlentities() 会破坏这样的合法网址：

也许去掉尖括号 + mysql_real_escape 就足够了？

【讨论】：

图片 URL 中不应该有和号之类的东西吗？
为什么不呢？脚本是完全有效的图像来源。
htmlentities() 将在该 URL 上正常工作。事实上，将 & 编码为 &在您的属性中是标准要求的。 <img src="http://example.com/?a&amp;b"> 是有效的 html（并且浏览器将按照预期将 URL 解释为 example.com/?a&b）。另一方面，<img src="http://example.com/?a&b"> 是无效的——但浏览器可能无论如何都会做正确的事情。举个例子，如果您在帖子中的 URL 上查看 Source，您会看到 SO 使用 &在 href 属性中。
re: 图片 URL 中的 & 符号，如果你看一下，这个页面上的 SO 头像就有它们，例如：gravatar.com/avatar/…

【解决方案3】：

在字符串上调用 htmlentities() 可能比在 strip_tags() 上调用更安全、更好。

strip_tags() 不会删除 html 特殊字符，例如 '"&

例如，如果您的代码是：

<img src="<?= strip_tags($myVar) ?>">

和

$myVar = '">something goes here<';

然后你会得到：

<img src="">something goes here<">

这很明显是 XSS 漏洞的根源；一个实际的漏洞作为练习留给读者。

【讨论】：