我尝试使用DOMPurify清理用户提交的模板。此模板使用mustache-syntax嵌入变量等。清理本身没有问题，但mustache-Sections被移动到模板中的不同部分，DOMPurify似乎尝试修复HTML结构本身。
我假设这个“自动修复”是在扰乱模板。有没有办法防止这种情况？
以下代码用于清理：
DOMPurify.sanitize(model.html_template);消毒前模板：
<table>
<tr>
<td>{{value1}}</td>
</tr>
{{#section}}
<tr>
<td>{{value2}}</td>
</tr>
{{/section}}
</table>消毒后模板：
{{#section}}
{{/section}}
<table>
<tbody>
<tr>
<td>{{value1}}</td>
</tr>
<tr>
<td>{{value2}}</td>
</tr>
</tbody>
</table>
1条答案
按热度按时间2ledvvac1#
我认为你最安全的选择是先渲染再消毒，而不是相反。我知道这效率较低;当然，如果你可以只清理模板一次，然后不做任何进一步的处理就可以重复使用它，这将是最理想的。2但是，DOMPurify文档明确警告不要在清理之后再做任何HTML处理：
“有没有潜在的威胁
好吧，请注意，如果你 * 先 * 清理HTML，然后 * 再 * 修改它，你可能很容易使清理的效果无效。如果你 * 在 * 清理之后 * 将清理过的标记提供给另一个库，请确保这个库不会自己弄乱HTML。
你可能会说Mustache没有“弄乱”HTML，但这显然不是真的。考虑下面这个有问题的例子：
如果忽略Mustache语法，HTML看起来是有效的，但是生成的代码将是无效的，除非
rows解析为长度正好为1的代码。另一个明显的迹象是DOMPurify的选项迎合了相反的情况：
SAFE_FOR_TEMPLATES: true将 * 剥离 * 所有模板语法。如果您需要更多理由：DOMPurify将其大部分清理逻辑交给浏览器。移动部分的问题很可能是您正在测试的浏览器特有的，因此它甚至不是DOMPurify所能控制的。此外，其他浏览器可能会以您甚至还没有意识到的其他方式损坏您的模板。通过首先呈现，并将清理作为DOM插入之前的最后一步，您可以避免大量潜在问题。