通过阻止 HTML 输入、清理数据、保护 Cookie 和部署 Web 应用程序防火墙 (WAF) 来防止执行恶意脚本和窃取用户信息。
阅读本文后，您将能够：
复制文章链接
Cross-site scripting (XSS) 是攻击者通过一个或多个 Web 脚本将恶意代码注入合法网站或 Web 应用程序的策略。当用户加载网站或运行 Web 应用程序时，这些脚本会在用户的浏览器中执行。
这些脚本可以执行各种恶意操作，例如窃取用户的 HTTP cookie、会话令牌或其他敏感信息。攻击者可以利用这些信息冒充用户，并在未经授权的情况下访问不同平台（如社交媒体平台或银行网站）上的帐户。此外，这些脚本还可以破坏网站、将用户重定向到恶意网站，或从 Web 应用程序中提取机密数据。
要了解更多信息，请参阅什么是 Cross-site scripting？
最主要的两种 XSS 攻击是反射型（非持久性）XSS 和存储型（持久性）XSS。
当合法网站未能验证或清理用户输入时，就会发生反射型 XSS 攻击。这些攻击通常从社会工程学开始，攻击者会发送网络钓鱼电子邮件或在在线论坛帖子中留下带有链接的留言，诱使用户点击链接。通常，链接中包含附有恶意代码的合法网站的 URL。
当用户点击链接时，他们的浏览器会向合法网站发送请求，该网站会将注入的代码反射回用户的浏览器。由于该网站没有正确清理输入，恶意脚本会在用户的浏览器中执行。
该代码可以复制用户的 Cookie 并将其发送给攻击者。如果攻击者获取了会话 Cookie，他们就可以控制会话，从而进行欺诈性购买、窃取银行信息或在社交媒体平台上发布垃圾邮件等恶意行为。
这种类型的 XSS 被称为“反射”攻击，因为恶意脚本会从 Web 服务器反射并在用户的浏览器中执行。它也被称为“非持久性”攻击，因为脚本仅在页面加载时在用户的浏览器中运行，而不是持续运行。
存储型 XSS 攻击比反射型 XSS 攻击更严重。存储型 XSS 会将恶意脚本永久存储在目标服务器上。
攻击者通常通过在表单字段（例如评论框、用户个人资料或任何接受和存储用户内容的输入字段）中嵌入恶意脚本来执行这种形式的 XSS。提交帖子、评论或表单后，脚本将被注入 Web 应用程序并保存在 Web 应用程序的数据库中。当其他用户加载受影响的页面时，存储的脚本将在他们的浏览器中执行。与反射型 XSS 攻击一样，该脚本可能会窃取 cookie 或其他用户信息，然后将其发送回攻击者。
这种类型的 XSS 也被称为“持久性”XSS，因为每次访问页面时都会执行。这也是存储型 XSS 攻击特别危险的原因：它们可以影响大量用户，且无需任何交互，只需查看网页即可。
个人用户可以采取几个步骤来降低 XSS 攻击的风险：
由于许多 XSS 攻击都是从网络钓鱼或其他社会工程学策略开始的，因此用户应该学会如何识别可疑的电子邮件和消息。用户可将此类可疑邮件通知相应的 IT 或安全团队，帮助阻止 XSS 攻击并解决其他安全问题。
如果用户在在线论坛中或在他们不认识或不信任的人的社交帖子中看到链接，他们应该慎重点击。即使链接看起来合法，用户也应该谨慎行事。许多触发 XSS 攻击的链接看起来是合法的，因为它们包含合法的 URL。但用户应该检查整个链接，包括 .com、.org、.gov 或其他后缀后的所有内容。页面地址后的意外文本可能是恶意代码。
开发人员可以通过实施一些关键的最佳实践，在防止 XSS 攻击方面发挥重要作用：
开发人员可以实施规则，阻止用户在页面或表单中发布数据，除非数据符合某些条件。例如，如果表单要求输入社会安全号码或电话号码，开发人员可以创建一条规则，规定此输入只能包含数字、破折号或括号。为了更有效地防止攻击，开发人员可以设置验证规则，明确拒绝 XSS 攻击中常用的标签或字符，例如 < script > 标签。
开发人员还可以阻止用户在评论、帖子和表单输入中使用 HTML。HTML 内容可以成为发布恶意脚本或隐藏包含恶意代码的 URL 链接的手段。
如果组织希望允许用户发布富文本内容（例如格式化文本或图像），他们可以整合 Markdown（一种轻量级标记语言）或在“所见即所得”(WYSIWYG) 编辑器中启用富文本格式。这两种方法都是支持富文本内容的更安全的方法。
开发人员可以实施一个流程，在数据发布到 Web 服务器之后、显示给其他用户之前对其进行检查，从而帮助防止 XSS 攻击造成的危害。例如，即使开发人员允许使用 HTML，他们也可以对所有 HTML 输入进行清理，并在恶意代码在浏览器中执行之前将其过滤掉。
输出编码和“转义”遵循类似的方法。其理念是在将任何内容写入页面之前，将用户输入中的恶意脚本或其他代码转换为普通文本。输出编码将代码转换为不同的格式；转义将特殊字符添加到代码中（如反斜杠或引号）。无论哪种情况，浏览器都不会将生成的文本解释为代码并执行它。清理会过滤掉代码，而输出编码和转义会保留代码，同时使其无害。
开发人员应在整个 Web 应用程序开发过程中整合安全性。例如，他们应该进行代码审查，特别关注接受和显示用户输入的区域。他们还应该在应用程序上线之前进行威胁建模和测试以识别漏洞。
安全团队可以实施多种最佳实践来帮助防范和快速应对 XSS 攻击：
安全团队可以采取几个步骤来帮助确保 Web 服务器正确配置，以阻止恶意脚本并防止攻击者窃取用户 cookie：
实施内容安全策略：开发人员和安全团队应共同为网站和 Web 应用程序定义强大的内容安全策略 (CSP)，并在 Web 服务器上实施这些策略。CSP 是一种额外的安全层，可以检测和缓解某些类型的攻击。为了防止 XSS 攻击，它会限制可以执行的脚本。可以配置 Web 服务器以返回 CSP HTTP 响应标头，禁止浏览器加载有害脚本。
安全 Cookie：安全团队可以针对 Web 服务器处理 Cookie 的方式设置特殊规则，以降低 Cookie 被盗的可能性。例如，他们可以将 Cookie 与特定 IP 地址绑定。由于大多数用户都拥有动态 IP 地址，因此 IP 地址与 Cookie 之间的联系不会持续很长时间。这样，攻击者就无法窃取和使用这些 Cookie。
此外，安全团队可以完全阻止 JavaScript 访问 Cookie。一种方法是在生成 Cookie 时向其添加 HttpOnly 标志。该标志表示 Cookie 可能包含敏感的用户信息，例如会话令牌或身份验证凭据。支持 HttpOnly 标志的浏览器不会泄露该信息。
Web 应用程序防火墙 (WAF) 可提供抵御 XSS 攻击的关键防线。WAF 充当位于 Web 应用程序前方的反向代理服务器，通过监控和过滤应用程序与互联网之间的 HTTP 流量来保护这些应用程序。组织可以设置 WAF 规则来检查 URL 中是否存在恶意脚本，并阻止将其反射给用户。具有机器学习功能的 WAF 解决方案通过检测绕过规则的尝试并识别已知攻击的变体来提供更强大的保护。
由于许多 XSS 攻击都是从网络钓鱼开始的，安全团队应加强对网络钓鱼攻击的防御。除了教育用户如何识别可疑电子邮件和消息外，安全团队还可以实施阻止垃圾邮件的安全功能，使用浏览器隔离服务来防止恶意软件的执行，安装安全 Web 网关 (SWG) 以防止用户下载恶意文件，以及部署电子邮件安全工具来实时检测和阻止网络钓鱼尝试。
安全团队应在生产环境中测试漏洞。团队可以运行手动渗透测试或使用自动 XSS 扫描程序。
即使采取了广泛的防范措施，组织仍有可能遭受 XSS 攻击。制定事件响应计划对于快速恢复至关重要。该计划应包括监控 Web 应用程序活动和在发生可疑事件时采取行动的策略。然后，团队应分析根本原因并确定攻击方法。攻击结束后，他们应该吸取经验教训，来增强安全功能、更新策略并修补 Web 应用程序中的漏洞。
Cloudflare 有多种产品和功能可以帮助组织和用户防止 XSS 攻击：
了解有关 Cloudflare WAF 的更多信息。