javascript - DOM 文本节点是否保证不会被解释为 HTML？

Question

有谁知道 Text 类型的 DOM Node 是否保证不会被浏览器解释为 HTML？

更多详细信息如下。

背景

我正在为一个 friend 构建一个简单的网络评论系统，我一直在思考 XSS 攻击。我不认为过滤或转义 HTML 标签是一个非常优雅的解决方案——想出一个可以绕过过滤器的卷积太容易了。根本问题是，我想保证，对于某些内容(即随机未经身份验证的网络用户发布的内容)，浏览器从不尝试解释或运行该内容。

一个普通的(文本)开始

首先想到的是使用Content-Type: text/plain，但这必须应用于整个页面。您可以将纯文本 IFRAME 放在页面中间，但这很丑陋，并且如果用户点击进入框架，它会产生焦点问题。

innerText/textContent/JQuery

事实证明，有一些特定于浏览器的属性(IE 中的 innerText，FF、Safari 中的 textContent 等)属性在设置时需要创建单个 Text 节点。

JQuery 试图通过实现单个函数 text(val) 来避免特定于浏览器的属性的差异，该函数跳过特定于浏览器的属性并直接转到 document.createTextNode(text )，正如您猜到的那样，它创建了一个 Text 节点。

W3 DOM 文本 节点

所以我认为这接近我想要的，它看起来不错——Text 节点不能有子节点，而且看起来它们不能被解释为 HTML。但我不是 100% 从官方文档中确定。

• 接口(interface)节点:http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1950641247
• 界面文本:http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1312295772
• textContent:http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent

textContent 中的部分特别令人鼓舞，因为它说“在设置时，也不执行解析，输入字符串被视为纯文本内容。”但这是所有 Text 节点的基础，还是仅设置了 textContent 的节点的基础？这可能看起来像一个愚蠢的狡辩，但它可能很重要，因为 IE 不支持 textContent(见上文)。

回到最初的问题

任何人都可以确认/拒绝这行得通吗？也就是说，兼容 w3 DOM 的浏览器永远不会将 Text 节点解释为 HTML，无论内容是什么？如果能解决这个令人痛苦的小不确定性，我将非常感激。

感谢您的宝贵时间!

Answer 1

是的，这已得到证实，无论是哪种浏览器，该浏览器都会有 严重 缺陷。呈现除文本以外的任何内容的文本节点将是矛盾的。通过使用 document.createTextNode("some string");并附加该节点，字符串保证呈现为文本。