就 jQuery(或 Javascript)而言,当一个人在 Facebook、Twitter 或博客上发表评论时,幕后会发生什么?
例如,他们是否首先清理文本,然后将 URL 模式匹配到实际链接中?除了对后端进行一些检查之外,客户端是否还有其他需要检查的事项?
我找到了一些将 URL 转换为链接的正则表达式,但我不确定是否有更好的解决方案。
我试图解决这个问题,但我很难知道从哪里开始。非常感谢您提供的任何指导!
这是一个意见问题(在我看来),所以我会 CW 这个答案。作为一名真正的互联网公民,这是我的看法:
至于第 1 点,我认为防御性清理是错误的,因为它忽略了上面的第 2 点:在不知道您要防御恶意输入的环境的情况下,如果不大大限制输入字母表,甚至是过程,就无法真正清理它可能是在和自己战斗。它对用户不利,因为它不必要地限制了合法用户可以对他们想要保留在其帐户中的数据执行的操作。谁说我想在我的“评论”或“昵称”或“注释”字段中包含看起来像 XML、SQL 或任何其他语言的特殊字符的字符?如果没有语义上的理由来过滤输入,为什么要对您的用户这样做?
第 2 点才是真正的症结所在。用户输入可能很危险,因为服务器端代码(或客户端代码,就此而言)可以将其直接交给毫无戒心的解释环境,其中对每个不同环境很重要的元字符可能会导致意外行为。如果您通过将未修改的用户输入直接粘贴到查询模板中将其直接传递给 SQL,则恶意用户可以使用特殊的 SQL 元字符(如引号)以您绝对不希望的方式控制数据库。然而,仅此一点并不能阻止我告诉你我的名字是“O'Henry”。
第 2 点的关键问题是存在许多不同的解释环境,就用户输入带来的威胁而言,它们中的每一个都是完全不同的。让我们列出几个:
这里的关键点是,保护这些环境免受格式错误或恶意输入影响所需的确切技术因人而异。保护您的 SQL 服务器免受恶意引号的攻击与保护 HTML 或 JavaScript 中的这些引号是完全不同的问题(请注意,这两者也完全不同!)。
底线:因此,我的观点是,当担心潜在的格式错误或恶意输入时,正确关注的焦点是写入用户数据的过程,而不是读取它的过程。由于您的软件与每个解释环境合作使用用户提供的数据的每个片段,因此必须执行“引用”或“转义”操作,并且必须是特定于目标环境的操作。具体如何安排可能因地而异。例如,传统上在 SQL 中,人们使用准备好的语句,尽管有时准备好的语句的缺陷使这种方法变得困难。吐出 HTML 时,大多数服务器端框架都有各种内置的 HTML 或 XML 挂钩,使用实体表示法进行转义(如&
为了 ”&”)。如今,为 Javascript 保护内容的最简单方法是利用 JSON 序列化程序,当然还有其他方法可以使用。