HTML转义字符有哪些？避免XSS的5种安全编码方案

煙雲

发布时间：2025-07-16 15:40:03

596人浏览过

来源于php中文网

原创

xss防御需针对不同上下文进行安全编码。1.html内容中转义&为&、<为、"为"、'为'。2.javascript字符串中对特殊字符使用\xhh或\uhhhh格式编码。3.url中非字母数字字符转换为%hh形式。4.css属性值中非字母数字字符用\hh或\hhhhhh编码。5.推荐使用自动编码框架根据上下文自动选择编码方式。此外还需输入验证、csp策略、httponly cookie、html净化库等多层防护以构建完整防御体系。

HTML转义字符有哪些？避免XSS的5种安全编码方案

HTML转义字符是网页内容安全的基础，它们主要包括 & (和号)、< (小于号)、> (大于号)、" (双引号) 和 ' (单引号)。这些字符在HTML中拥有特殊含义，如果不进行转义，恶意输入可能会被浏览器解析为代码，从而引发跨站脚本（XSS）攻击。避免XSS，核心在于针对不同上下文进行正确的安全编码。

解决方案

谈到HTML转义字符，我们首先要明确几个核心的实体引用：

& (和号) 应该被转义为 &。这是最基础的，因为 & 符号是所有HTML实体引用的起始符。
< (小于号) 应该被转义为 。它常用于定义HTML标签的开始，恶意用户可能利用它来注入新的标签。
> (大于号) 应该被转义为 >。它通常用于定义HTML标签的结束。
" (双引号) 应该被转义为 "。在HTML属性值中使用双引号时，如果用户输入包含双引号，可能导致属性提前闭合，注入新的属性或事件处理器。
' (单引号) 应该被转义为 ' 或 ' (HTML5推荐使用 ')。类似双引号，在属性值使用单引号时，也需对其进行转义。

这些转义字符的运用，是抵御XSS攻击的第一道防线，但绝非全部。更全面的“安全编码方案”需要考虑到数据输出的不同上下文环境：

立即学习“前端免费学习笔记（深入）”；

HTML实体编码 (HTML Entity Encoding): 这是最直观的，将用户提供的数据插入到HTML页面的文本内容中（例如，一个 <div> 标签内部），就必须对上述特殊字符进行转义。比如，你想显示用户输入的 <script>alert(1)</script>，转义后它会变成 <script>alert(1)</script>，浏览器会将其视为普通文本而不是可执行脚本。
JavaScript字符串编码 (JavaScript String Encoding): 当用户输入的数据要被嵌入到 <script> 标签内部的JavaScript字符串中时，仅进行HTML实体编码是不够的。此时，你需要对数据中的特殊字符（如 \、"、'、换行符等）进行JavaScript字符串编码，通常使用 \xHH 或 \uHHHH 格式。例如，" 应该编码为 \x22 或 \u0022。直接HTML转义在这里是无效的，因为JS引擎解析的是JS语法，而不是HTML实体。
URL编码 (URL Encoding / Percent-Encoding): 如果用户输入的数据要作为URL的一部分（例如，查询参数、路径段），则需要进行URL编码。这意味着将非字母数字字符转换为 %HH 的形式。比如，空格变成 %20，& 变成 %26。这防止了恶意用户通过注入特殊字符来改变URL的结构或注入新的参数。
CSS编码 (CSS Encoding): 当用户输入的数据被用作CSS属性值时，比如 background-image: url('javascript:alert(1)');，需要对数据进行CSS编码。这通常涉及将非字母数字字符编码为 \HH 或 \HHHHHH 的形式。这可以防止注入恶意CSS规则或利用CSS特性执行脚本。
上下文敏感的自动编码框架/库 (Context-Sensitive Auto-Encoding Frameworks/Libraries): 这是最推荐的实践。现代Web框架和安全库（如OWASP ESAPI、DOMPurify、或许多模板引擎自带的自动转义功能）能够根据数据输出的上下文自动选择正确的编码方式。开发者无需手动判断并应用编码，大大降低了出错的概率。例如，一个成熟的模板引擎在将变量渲染到HTML属性中时，会自动进行属性值编码；渲染到JS字符串时，则进行JS字符串编码。

XSS攻击的本质：不仅仅是字符转义那么简单

XSS攻击，全称跨站脚本攻击，它的本质是攻击者将恶意脚本（通常是JavaScript）注入到受信任的网页中，当其他用户访问这个网页时，恶意脚本就会在用户的浏览器上执行。这可不是简单地显示一个错别字那么无害，它可以窃取用户的Cookie、会话令牌，篡改网页内容，甚至进行钓鱼攻击。

回想起来，我最初接触XSS时，也曾天真地以为只要把所有 < 和 > 转义掉就万事大吉了。但很快就发现，这只是冰山一角。XSS之所以复杂，因为它利用的是浏览器对不同上下文的解析规则差异。

举个例子，假设你有一个评论系统，用户可以输入评论内容。如果你只是简单地对评论内容进行HTML实体编码，然后将其显示在 <div> 标签内，那通常是安全的。因为 <script> 会变成 <script></script>，浏览器不会执行它。

但如果你的应用逻辑不慎，将用户输入直接插入到JavaScript代码块中，比如：

<script>
  var userName = "用户输入的内容";
  alert("Hello, " + userName);
</script>

如果用户输入的是 "; alert(document.cookie); //，那么经过HTML实体编码后，它可能依然是 "; alert(document.cookie); //，或者即便HTML实体编码了，在JS字符串上下文中，它依然能突破字符串的边界：

var userName = ""; alert(document.cookie); //";
alert("Hello, " + userName);

你看，" 闭合了前面的字符串，alert(document.cookie) 被执行，后面的 // 注释掉了多余的引号，完美绕过。这说明了，在JavaScript上下文里，你需要对 " 这样的字符进行JavaScript特有的编码，比如 \x22。

XSS攻击主要分为几类：

Otter.ai

一个自动的会议记录和笔记工具，会议内容生成和实时转录

下载

反射型XSS (Reflected XSS): 恶意脚本作为URL参数发送到服务器，服务器未经处理直接“反射”回响应中，在用户浏览器上执行。例如，搜索结果页面将搜索词直接显示出来。
存储型XSS (Stored XSS): 恶意脚本被存储在服务器上（如数据库），当用户访问包含该脚本的页面时，脚本被从服务器取出并执行。评论区、论坛帖子是常见场景。
DOM型XSS (DOM-based XSS): 恶意脚本并非来自服务器响应，而是客户端JavaScript代码在处理DOM时，将恶意数据作为代码执行。比如，JavaScript从URL的hash部分读取数据并直接写入DOM。

这些攻击的共同点在于，它们都试图利用数据和代码之间的边界模糊性，将数据“提升”为可执行的代码。理解这一点，才能真正认识到上下文敏感编码的必要性。

深入理解：不同上下文的编码策略与陷阱

真正让安全编码变得复杂的是“上下文”。数据在HTML文档的不同位置，其解析规则截然不同。忽视这一点，是导致XSS漏洞的常见原因。

HTML内容上下文：
- 策略： 对所有用户输入进行HTML实体编码。这是最基本也是最常用的。
- 示例： 将 <h1>Hello & World!</h1> 中的 & 转义为 &。
- 陷阱： 很多人以为只要做了HTML实体编码就高枕无忧，却忘了其他上下文。
HTML属性值上下文：
- 策略： 对属性值中的 " (双引号) 和 ' (单引号) 进行编码。如果属性值不带引号，还需要编码空格等可能破坏属性结构的字符。
- 示例： <img src="user_image.jpg" alt="用户输入的标题，包含 "引号" ">，这里的双引号必须编码为 "。
- 陷阱： 忽略了单引号，或者在属性值中直接插入未编码的 javascript: 伪协议。比如 <a href="javascript:alert(1)">，这里的 javascript: 无法通过常规HTML实体编码来防御，因为它不是HTML实体，而是URL的一部分。
JavaScript字符串上下文：
- 策略： 对所有可能中断字符串或引入新语句的字符进行JavaScript编码。这包括 \、"、'、换行符 (\n, \r)、以及所有非字母数字字符（出于安全考虑，尽管不总是必须）。
- 示例： 如果 var name = "用户输入";，用户输入 test"; alert(1); var x="，那么 " 必须编码为 \x22 或 \u0022。
- 陷阱： 很多人会错误地在这里使用HTML实体编码。比如 var name = "<script>alert(1)</script>"; 这段代码在JS字符串里是安全的，但如果 name 后来被 innerHTML 赋值到DOM，那就又可能出问题。关键在于最终数据将如何被解析。
URL上下文：
- 策略： 对URL路径、查询参数、片段标识符中的所有非安全字符进行URL编码（百分号编码）。
- 示例： https://example.com/search?q=hello world&foo=bar 中的空格会变成 %20，& 会变成 %26。
- 陷阱： 编码不完整，或者对整个URL进行编码而不是只对参数值编码，导致URL无法识别。另外，javascript: 伪协议的滥用也是URL上下文的常见问题。
CSS上下文：
- 策略： 对CSS属性值中可能中断CSS语法或引入恶意内容的字符进行CSS编码。
- 示例： width: expression(alert(1)) (IE早期漏洞) 或 background-image: url("data:image/svg+xml;base64,...")。
- 陷阱： 尽管现代浏览器对CSS注入的执行能力有所限制，但仍需警惕。比如，在CSS属性值中注入 url()，如果其中包含 javascript: 伪协议，就可能导致问题。

一个常见的错误就是“双重编码”：数据先被HTML编码，又被URL编码，或者反过来。这可能导致数据无法正确解析，甚至在某些情况下绕过安全机制。另一个陷阱是“编码不一致”，即输入数据在不同阶段被不同地编码，最终导致解析错误。我的经验告诉我，理解数据流和它在每个解析器（HTML解析器、JS解析器、URL解析器、CSS解析器）中如何被处理，是避免这些陷阱的关键。

构建坚固防线：除了编码，还有哪些XSS防御体系？

仅仅依靠编码来防御XSS，就像只用一个沙袋去挡洪水，风险太高了。一个健壮的Web应用安全体系，需要多层防御，形成一个立体的防护网。除了上述的各种编码策略，我们还有：

输入验证 (Input Validation): 在数据进入系统时就进行严格的验证。这通常是“白名单”策略，只允许符合预期格式、类型、长度和内容的输入通过。例如，如果一个字段只接受数字，那就只允许数字；如果只接受邮件地址，就用正则表达式验证其格式。虽然输入验证主要用于数据完整性，但它也能阻止许多明显的恶意输入，从而减少需要编码的数据量。
内容安全策略 (Content Security Policy, CSP): 这是一项强大的浏览器安全功能。通过设置HTTP响应头，开发者可以告诉浏览器哪些资源可以加载（如脚本、样式、图片、字体等）以及它们可以从哪里加载。例如，你可以禁止内联脚本和来自未知域的脚本执行，极大地降低了XSS攻击成功的可能性。一个简单的CSP头可能看起来像这样：Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; object-src 'none'; 这意味着所有内容默认只能从当前域加载，脚本只能从当前域和 trusted.cdn.com 加载，禁止 <object> 标签。
HTTP Only Cookies: 将敏感的会话Cookie设置为 HttpOnly 属性。这意味着JavaScript无法通过 document.cookie 访问这些Cookie。即使XSS攻击成功注入了脚本，攻击者也无法直接窃取用户的会话Cookie，从而保护了用户会话的安全。
X-XSS-Protection Header (已不推荐): 这是一个历史遗留的HTTP响应头，旨在启用浏览器内置的XSS过滤器。然而，由于它可能引入新的安全漏洞（例如，绕过或误报），现代Web开发中已不推荐使用。但了解其存在和局限性有助于理解浏览器安全的发展。
DOMPurify等净化库： 对于那些必须允许用户输入HTML的场景（比如富文本编辑器），简单的编码是不够的。这时需要使用专门的HTML净化库（如DOMPurify），它们能够解析HTML，并根据预设的白名单规则，移除所有潜在的恶意标签、属性和JavaScript事件。这比手动编码复杂得多，也更安全。
安全开发实践和框架： 许多现代Web框架（如React、Vue、Angular、Django、Rails等）都内置了对XSS的防护机制，例如模板引擎的自动转义。利用这些框架的内置功能，并遵循其推荐的安全实践，可以大大降低XSS漏洞的风险。同时，定期的代码审查、安全测试（如渗透测试、静态/动态代码分析）也是不可或缺的环节。