【问题标题】:Is there any way that my HTML securer could be exploited?有什么方法可以利用我的 HTML 安全器?
【发布时间】:2021-03-03 13:38:56
【问题描述】:

我终于设法制作了一个执行以下操作的函数:

  1. 将字符串作为输入。这可以是整个 HTML 文档,也可以是 HTML“sn-p”(甚至损坏)。
  2. 由此创建一个 DOMDocument 并遍历所有节点。
  3. 每当遇到其元素在基本结构元素白名单之外的任何节点时,它都会“将其标记为删除”。例如,<script> 未列入白名单。
  4. 每当任何节点具有以“on”开头的任何属性时,都会立即使用removeAttribute 将其删除。任何“style”属性以及任何值以“javascript:”开头的“href”属性也是如此。
  5. 当所有节点都循环通过时,标记为删除的节点会循环并删除($node->parentNode->removeChild($node))。这不是在第一个循环中完成的,因为如果您这样做,解析器会变得混乱。
  6. 此文档现在是 saveHTMLed 并以字符串形式返回,现在表示已清理/安全的 HTML 文档/sn-p。

据我所知,没有办法滥用它。除非 DOM 解析器中存在一些错误,否则我将无法使用/良心。

但也许还有另一个“onsomething”属性或其他我没有想到的东西?

在任何不受信任的外部/用户提供的源被我的这个功能破坏后,我对从任何不受信任的外部/用户提供的源输出任何 HTML 非常有信心,但也许我很自大?

(我真的希望 strip_tags 能够自己完成这项工作,这样我就不必编写自己的代码了。)

【问题讨论】:

    标签: php html security html-parsing domdocument


    【解决方案1】:

    如果您想防止 xss,所有 on* 属性都可以删除。此外,style 可能在某些浏览器中以各种方式包含 javascript,以及 href (javascript:)。 SVG我可以认为包括脚本等等。

    请查看here 获取有关如何绕过这些消毒剂的非完整列表,以及为什么很难自己构建消毒剂。

    为什么不直接使用 Google Caja 等知名的消毒剂,而不是重新发明它们?这比你想象的要难得多。

    【讨论】:

    • 首先,我自然不会用谷歌做的任何东西。其次,任何类型的第三方库本身都是一个巨大的安全问题,因为您必须以多种方式信任它们。其他 on* 属性是什么? javascript:href...嗯...这对我来说是新的。
    • 我实施了您的建议并更新了我的问题。虽然我不知道你所说的 SVG 是什么意思。
    • 我添加了一个指向我的答案的链接。如果您不喜欢 Google,您可以使用许多其他知名的消毒剂。此外,第 3 方组件是可管理的风险(但您确实必须管理该风险,这是真的)。正如您的示例已经表明的那样,从头开始编写所有内容的风险要大得多。话虽如此,您可以编写自己的清理程序,但考虑到其他人在实施众所周知的攻击向量时已经经历的所有潜在攻击向量 - 这一点都不简单。
    • 在阅读完该链接的列表后,我不仅会放弃所有工作并使用第三方 HTML 安全器(不是 Google 提供的),而且我对 HTML、浏览器和制定这些标准和软件的人。这份清单绝对是疯狂的,我不知道其中的一小部分。真是一团糟。 strip_tags 手册页上没有非常仔细地提到这一点?这让我大吃一惊。任何使用strip_tags 的人都具有 安全性,甚至我认为安全的脚本也可能以一百万种方式被绕过……难以置信。
    猜你喜欢
    • 1970-01-01
    • 2013-09-16
    • 1970-01-01
    • 1970-01-01
    • 2023-01-13
    • 1970-01-01
    • 2017-12-19
    • 2017-01-22
    • 1970-01-01
    相关资源
    最近更新 更多