1

就 jQuery（或 Javascript）而言，当一个人在 Facebook、Twitter 或博客上发表评论时，幕后会发生什么？

例如，他们是否首先清理文本，然后将 URL 模式匹配到实际链接中？除了对后端进行一些检查之外，客户端是否还有其他需要检查的事项？

我找到了一些将 URL 转换为链接的正则表达式，但我不确定是否有更好的解决方案。

我试图解决这个问题，但我很难知道从哪里开始。非常感谢您提供的任何指导！

4

1 回答 1

4

这是一个意见问题（在我看来），所以我会 CW 这个答案。作为一名真正的互联网公民，这是我的看法：

  1. 有两种广泛的“清理”：一种是语义清理，检查输入以确保它是应该的（电话号码、邮政编码、货币金额等）。另一个是防御性消毒，这（在我看来，再次）是一种通常被误导的、对用户怀有敌意的活动。
  2. 真的，输入永远不会真正可怕，直到它接触到一些东西：数据库服务器、HTML 渲染器、JavaScript 解释器等等。名单很长。

至于第 1 点，我认为防御性清理是错误的，因为它忽略了上面的第 2 点：在不知道您要防御恶意输入的环境的情况下，如果不大大限制输入字母表，甚至是过程，就无法真正清理它可能是在和自己战斗。它对用户不利，因为它不必要地限制了合法用户可以对他们想要保留在其帐户中的数据执行的操作。谁说我想在我的“评论”或“昵称”或“注释”字段中包含看起来像 XML、SQL 或任何其他语言的特殊字符的字符？如果没有语义上的理由来过滤输入，为什么要对您的用户这样做？

第 2 点才是真正的症结所在。用户输入可能很危险，因为服务器端代码（或客户端代码，就此而言）可以将其直接交给毫无戒心的解释环境，其中对每个不同环境很重要的元字符可能会导致意外行为。如果您通过将未修改的用户输入直接粘贴到查询模板中将其直接传递给 SQL，则恶意用户可以使用特殊的 SQL 元字符（如引号）以您绝对不希望的方式控制数据库。然而，仅此一点并不能阻止我告诉你我的名字是“O'Henry”。

第 2 点的关键问题是存在许多不同的解释环境，就用户输入带来的威胁而言，它们中的每一个都是完全不同的。让我们列出几个：

  • SQL - 用户输入中的引号是一个很大的潜在问题；特定的数据库服务器可能有其他可利用的语法约定
  • HTML - 当用户输入直接放入 HTML 时，浏览器的 HTML 解析器将很高兴地服从任何嵌入的标记告诉它做的事情，包括运行脚本、加载跟踪器图像以及其他任何事情。关键的元字符是“<”、“>”和“&”（后者不是因为攻击，而是因为它们造成的混乱）。在这里担心引号可能也很好，因为用户输入可能需要进入 HTML 元素属性。
  • JavaScript - 如果页面模板需要将一些用户输入直接放入一些正在运行的 JavaScript 代码中，则需要担心的事情可能是引号（如果输入被视为 JavaScript 字符串）。如果用户输入需要进入正则表达式，则需要进行更多的清理。
  • 日志文件 - 是的，日志文件。你如何看待日志文件？我在我的 Linux 机器上的一个简单命令行窗口上执行此操作。这种命令行“控制台”应用程序通常遵循可追溯到旧 ASCII 终端的古老“转义序列”，用于控制光标位置和各种其他事情。好吧，巧妙设计的用户输入中嵌入的转义序列可用于利用这些转义序列的疯狂攻击；一般的想法是将一些用户输入放入某个日志文件（可能作为页面错误日志的一部分）并诱使管理员在 xterm 窗口中滚动浏览日志文件。狂野吧？

这里的关键点是，保护这些环境免受格式错误或恶意输入影响所需的确切技术因人而异。保护您的 SQL 服务器免受恶意引号的攻击与保护 HTML 或 JavaScript 中的这些引号是完全不同的问题（请注意，这两者也完全不同！）。

底线：因此，我的观点是，当担心潜在的格式错误或恶意输入时，正确关注的焦点是写入用户数据的过程，而不是读取它的过程。由于您的软件与每个解释环境合作使用用户提供的数据的每个片段，因此必须执行“引用”或“转义”操作，并且必须是特定于目标环境的操作。具体如何安排可能因地而异。例如，传统上在 SQL 中，人们使用准备好的语句，尽管有时准备好的语句的缺陷使这种方法变得困难。吐出 HTML 时，大多数服务器端框架都有各种内置的 HTML 或 XML 挂钩，使用实体表示法进行转义（如&amp;为了 ”＆”）。如今，为 Javascript 保护内容的最简单方法是利用 JSON 序列化程序，当然还有其他方法可以使用。

于 2011-02-10T23:22:19.583 回答