实际中HTML文档的最大深度是多少？

发布时间：2020-12-14 22:20:44 所属栏目：资源来源：网络整理

导读：我想允许嵌入HTML，但是由于深度嵌套的HTML文档会使某些浏览器崩溃，从而避免使用DoS。我想能够容纳99.9％的文件，但拒绝那些嵌套太深的文档。两个密切相关的问题：浏览器内置什么文件深度限制？例如。浏览器X无法解析或不构建深度为的文档。一些限制。文

我想允许嵌入HTML，但是由于深度嵌套的HTML文档会使某些浏览器崩溃，从而避免使用DoS。我想能够容纳99.9％的文件，但拒绝那些嵌套太深的文档。

两个密切相关的问题：

>浏览器内置什么文件深度限制？例如。浏览器X无法解析或不构建深度为>的文档。一些限制。
>文档的文档深度统计信息是否可以在网络上使用？是否有一个网站统计资料，解释说，一些百分比的真实文件在网络上的文档深度小于某些价值。

文档深度定义为1从文档中的任何节点到达文档根所需的父遍历的最大数目。例如，in

<html>                   <!-- 1 -->
  <body>                 <!-- 2 -->
    <div>                <!-- 3 -->
      <table>            <!-- 4 -->
        <tbody>          <!-- 5 -->
          <tr>           <!-- 6 -->
            <td>         <!-- 7 -->
              Foo        <!-- 8 -->

文本节点“Foo”有8个祖先，最大深度为8。这里的祖先是非严格的解释，即永远的节点是它自己的祖先和它自己的后裔。

Opera具有一些表嵌套统计信息，表明99.99％的文档的表嵌套深度小于22，但该数据不包含整个文档深度。

编辑：

如果人们想批评HTML消毒图书馆，而不是回答这个问题，请做。 http://code.google.com/p/owasp-java-html-sanitizer/wiki/AttackReviewGroundRules解释了如何找到代码，在哪里可以找到一个可以让您尝试攻击的测试平台，以及如何报告问题。

编辑：

我问Adam Barth，他非常彬彬有礼地指出了处理这个问题的webkit代码。

至少Webkit至少强制执行此限制。当treebuilder是created时，它接收到一个可配置的树限制：

06001

并通过block-nesting-cap测试进行测试。

解决方法

请问coderesearch@google.com可能值得。他们从2005年( http://code.google.com/webstats/)开始的研究没有涵盖你的具体问题。他们采集了超过十亿份文件，并且有兴趣听取任何你觉得值得考虑的内容。

– [更新] –

这是一个粗糙的脚本，我写了测试我有的浏览器(把数量的嵌套到查询字符串)：

var n = Number(window.location.search.substring(1));

var outboundHtml = '';
var inboundHtml = '';

for(var i = 0; i < n; i++)
{
    outboundHtml += '<div>' + (i + 1);
    inboundHtml += '</div>';
}

var testWindow = window.open();
testWindow.document.open();
testWindow.document.write(outboundHtml + inboundHtml);
testWindow.document.close();

这里是我的发现(可能具体到我的机器，Win XP，3Gb Ram)：

> Chrome 9：3218嵌套元素将呈现，3129崩溃选项卡。 (Chrome 9老了，我知道，
更新程序在我的公司LAN上失败)
> Safari 5：3477将呈现，3478浏览器完全关闭。
> IE8：1000000将呈现(允许内存)，尽管当滚动/移动鼠标/等时，由于事件冒泡，当高4位数字的性能下降显着。超过10000的东西似乎锁定，但我认为只是花了很长时间，所以有效的DoS。
> Opera 11：只是受到内存的限制，就我所知，即使我的脚本耗尽了内存10000000.对于大型文档，尽管如此，似乎没有像IE那样的性能下降。
> Firefox 3.6：?1500000将渲染，但测试超过此范围导致浏览器崩溃与Mozilla Crash Reporter或只是挂起，有时一个工作的数字将失败在随后的时间，但更大的数字?1700000将直接从重新启动Firefox。

更多Chrome：

将DIV更改为SPAN会导致Chrome在崩溃之前嵌套9202个元素。所以这不是HTML的大小(尽管SPAN元素可能更轻巧)。

嵌套2077个表格单元格(< table>< tr>< td>)工作(6231个元素)，直到您向下滚动到单元格445，然后它崩溃，因此您无法嵌套445个表格单元格(1335个元素)。

使用从脚本生成的文件进行测试(而不是写入新窗口)给出略高的公差，但是Chrome仍然崩溃。

您可以在崩溃之前嵌套1409个列表项(< ul>< li>)，这是有趣的，因为：

> Firefox在99之后停止缩进列表项，也可能是编程约束。
>歌剧院在250,376,502,628,754,880 …中出现故障

设置DOCTYPE在IE8中有效(将其放入标准模式，即var outboundHtml =’<！DOCTYPE html>‘;)：它不会嵌套792个列表项(标签崩溃/关闭)或1593个DIV。测试是从脚本生成还是从文件加载，IE8没有任何区别。

因此，浏览器的嵌套限制显然取决于攻击者注入的HTML元素的类型和布局引擎。可能会有一些比这更小的HTML。而对于IE8，Chrome和Safari用户来说，我们有一个简单的HTML DoS，其负载相当小。

看来，如果您要允许用户发布在您的一个页面上呈现的HTML，那么如果存在大量限制，那么值得考虑嵌套元素的限制。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!