网站安全和漏洞是一个全球性问题，网络安全漏洞正在增加。过去几年，这类案件的平均数量有了显著增长，2021 年达到了历史最高水平。

因此，在本教程中，我们将讨论 DOM XSS 跨站脚本安全问题以及它们对数据产生的影响。请务必阅读到最后。让我们从复习 DOM XSS 跨站脚本安全的基础知识开始。

什么是跨站脚本？

跨站脚本（也称为 XSS）是一种网站安全问题，当用户使用脆弱的应用程序时，会危害用户信息和数据。攻击者可以利用此漏洞绕过同源策略，该策略将两个网站彼此隔离。

攻击者可能会利用 XSS 假装自己是用户，执行用户将会执行的操作，并获取用户的信息。如果攻击者拥有权限和特权，攻击者便可以完全访问用户的信息。持续恶化下去，攻击者还可以接管网站的整个操作和性能。

为了帮助你更好地理解这些类型的攻击，我们将讨论 XSS 的运作原理和方法相关的基础知识。

XSS 如何运作？

跨站脚本利用技术操纵脆弱网站，使其向用户发送危险的 JavaScript。这使攻击者能够在脚本获得用户系统访问权限时完全获得用户在网站的权限。但这一切的开始是用户执行 JavaScript。

XSS 攻击的类型

反射型 XSS

这种恶意脚本来自 HTTP 请求。这是 XSS 攻击的最基本类型，在这种情况下，应用程序接收到恶意数据后立即向用户反映。

攻击者的负载必须是发送到服务器的请求的一部分，然后反映到用户的应用程序上并执行。

其中一个例子是攻击者想方设法让某人点击钓鱼链接，然后攻击才生效。

存储型 XSS

这种恶意脚本来自网站的数据库。攻击者在服务器上输入恶意请求，除非手动处理，否则它可能永久存在。

例如，攻击者可以在评论字段中输入恶意脚本，该脚本将对访问该页面的所有人显示。即使没有直接与脚本互动，页面访问者也可能成为此攻击的受害者

基于 DOM 的 XSS

这种是更高级的漏洞，它存在于客户端代码中的，而不是在服务器代码中。基于 DOM 的 XSS 既不是反射型的，也不存在于服务器上，而是存在于页面的文档对象模型（DOM）中。Web 应用程序读取恶意代码并将其作为 DOM 的一部分在浏览器中执行，这更难检测，因为它不通过服务器传递。

基于 DOM 的 XSS 攻击中涉及的安全漏洞对于大多数网站来说是一个严峻的问题。我们将讨论一些开源 Web 构建平台（例如 WordPress）上最常见的基于 DOM 的 XSS 风险。

攻击者在受害者的浏览器中执行恶意 JavaScript 代码，窃取敏感信息或以受害者的名义执行其他有害的操作。

以下是一个例子：

<script>
  //该函数接受一个用户提供的 URL 并展示在页面
  function displayURL(url) {
    // URL 通过 innerHTML 获得，执行 JavaScript 代码
    document.getElementById('display').innerHTML = url;
  }
</script>

<!-- 用户的输入传递给 displayURL 函数 -->
<p>Enter a URL to display: <input type="text" id="user-input" /></p>
<button onclick="displayURL(document.getElementById('user-input').value)">
  Display URL
</button>

<!-- URL 在 div 中显示 -->
<div id="display"></div>

请注意本教程仅用于教学目的，帮助你识别和防护 XSS。你不可以复刻类似攻击。

DOM XSS – WordPress 漏洞

WordPress 的 DOM XSS 攻击的主要目标是它的用户。用户输入他们的详细信息，账户和网站凭证以访问他们的 WordPress 站点，这就是 DOM XSS 攻击试图在线损害的内容。攻击者可以使用 DOM XSS 获取用户信息和详细信息，只需点击一下。

这也包括你的 cookies、信息等，使它成为最常见的 WordPress 安全漏洞。

以下是你应该牢记的一些顶级 WordPress 网站安全问题，以确保更好的跨站脚本安全

访问用户私人信息

一个最常见的 WordPress 安全漏洞与 DOM XSS 攻击有关，攻击者可以获得有用的信息，甚至完全控制用户的网站。这通常会使事态迅速升级，导致完全数据泄露。

假冒用户

攻击者可以假装是用户，与受害者的在线用户，客户互动，以获得信息。

破坏网站

另一个相关的 XSS 安全问题是，攻击者破坏网站并从用户那里夺取访问权限。这包括在网站上显示与原始网站不同的内容（或不是来自原始网站的内容）。

其他情况可能涉及改变 WordPress 在线的外观。其他人也可能通过安装特定工具使用网站。

社交工程

更严重的情况下，攻击者可能通过网络钓鱼影响 WordPress 网站。这是一个常见的网站构建平台安全漏洞，我们马上就要详细讨论。

XSS 跨站脚本安全问题对每个网站的影响各不相同。然而，WordPress 网站通常面临更高的风险，因为用户在网站上保存了个人信息。如果用户是管理员，风险进一步增加，因为攻击者可以破坏整个 WordPress 网站。

DOM XSS 和非开源网站构建平台

不同于 WordPress，如 Weebly、Squarespace、Webflow 和 Wix 这类网站构建器是非开源平台。它们允许用户通过拖放式 DIY 功能，在没有任何代码或设计经验的情况下，直观地为业务创建网站。这些平台也努力保护用户的安全。

有大量有用的工具、选项、易于整合的仪表板和托管方式，供用户使用并信任这些平台。当然，网站安全问题对于这些平台的大多数用户来说是一个主要关注点。

许多网站构建器都在努力保护用户网站免受黑客威胁。但是在所有可用的网站构建器中，我相信 Wix 在遵循 NIST 网络安全框架方面做得最好，并已成为该领域的重要贡献者。

Wix 使用如下工具保护用户不受这类攻击的影响：

• 第三方更新项目，防止 DOM XSS 攻击
• 安全的套接字层，防止网站上的用户被未经授权的访问
• 全天候的安全网络托管，防止任何不需要的登录或网络钓鱼攻击
• 只有给原始所有者控制和访问限制网站的管理员特权
• 显示弱密码并建议更难解密的密码

防御 XSS 攻击的方法

防御 XSS 攻击通常需要多维度的方法，以确保服务器和应用程序不受各种类型攻击的影响。

防御 XSS 攻击的最佳方法是适当地对用户输入进行清理。这意味着确保任何用户输入被正确编码，浏览器则不能将其解释为代码。

此外，你可以使用 web 应用程序防火墙（WAF）来帮助识别和阻止 XSS 攻击。最好将软件和 web 应用程序保持在最新版本，因为许多 XSS 漏洞可以通过最新的安全补丁来解决。

输入验证

这种编程技巧确保只有格式正确的数据才能进入软件系统。网站可以允许或阻止某些值，以确保不会有 XSS 侵入其服务器。

转义或编码用户输入

编码和转义将用户输入转换为更安全的形式。编码用更安全的等效物替换特殊字符（例如，将 < 转换为 &lt），而转义则添加特殊字符以防注入攻击。

执行内容安全策略（CSP）

内容安全策略帮助管理员通过限制页面在特定时间内加载的资源来减轻 XSS 攻击的影响。这些资源可以包括可能损害客户端和服务器的脚本和图像。

底线

DOM XSS 跨站脚本安全问题对网站用户是一个严峻的问题。但是封闭的代码网站构建平台提供的，如：管理员权限、密码最佳实践、第三方更新等功能，使它们比许多开放代码平台更加安全。

你可以通过过滤输入来防止 XSS 攻击。你也可以通过只接受有效输入来实现。

输出时对数据进行编码，该过程应在 HTTP 响应中完成，以免被读取为活跃内容。根据输出的上下文，可能需要更复杂的编码，例如应用 URL、JavaScript、CSS 和 HTML 编码的组合。

检查响应标头，以便浏览器对内容有适当的解释。

最后，使用内容安全策略（CSP）来最大程度地降低 XSS 攻击的严重性。

<meta
  http-equiv="Content-Security-Policy"
  content="default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';"
/>

CSP 允许网站从同一个源（即你自己的网站）加载脚本和样式，但它将阻止来自外部来源的脚本和样式。它还将允许使用内联脚本和样式，但阻止 eval() 语句，因为这个语句可用于执行任意代码。

当然，这只是一个简单的例子，你可以根据自己的特殊需求自定义 CSP。有关如何使用 CSP 来防御 XSS 攻击的更多信息，你可以参考内容安全策略级别 2 规范。

图片来自 Unsplash（Florian Olivo）。

例如，Jane 可能会在查看电子邮件的同时登录了她的网上银行，然后可能会点进钓鱼邮件中的自带转账请求的链接（比如迷惑性的短链接），要求 Jane 的银行转账至被攻击者控制的账户里。

由于 Jane 已经登陆了银行，该转账请求会被自动执行，因为是通过已被 Jane 授权了的浏览器发出的请求。

什么是 HTTP 请求（Requests）和 Cookie?

HTTP GET 请求

这个请求用于向 Web 服务器请求数据（比如输入 URL（请求网站）加载）。

HTTP POST 请求

这个请求用于向 Web 服务器发送数据（比如提交 Web 表单）。

某些 GET 和 POST 请求会自动触发，无需用户交互（例如获取搜索建议或使用 img src 属性加载图像内容）。

会话 Cookies

会话 cookie 是 HTTP 处理状态的一种方式（因为它本身不处理状态）。 网站使用会话 cookie（包含唯一 ID）来识别用户并保留他们的会话。

设置会话 cookie 后，用户浏览器会在每次请求时将 cookie 发送到服务器，以供站点识别用户。

攻击者可以通过强制用户浏览器发送请求来利用 cookie 来冒充用户，如果用户已经登录到站点，cookie 将随请求自动发送。

跨站点请求伪造是如何工作的?

攻击者进行 CSRF 攻击需要满足以下几点：

• 攻击者想在网站应用中执行一种操作 — 例如更改密码、转账等。
• 不包含不可猜测的请求参数 — 攻击者可以猜测（或知道）网站应用的此类请求中需要的所有参数。
• 该操作仅依赖 cookie 来验证请求是否来自用户，并可以通过 HTTP 请求执行。

CSRF 会影响网站使用 cookie，浏览器身份验证或客户端证书对用户进行身份验证的 Web 应用程序。基本上 CSRF 可能发生在应用程序自动将用户证书或身份添加到请求的任何情况下。

CSRF 攻击可以利用 GET 请求或 POST 请求（由于 POST 请求更复杂，因此不常见）。

两者都需要攻击者先诱骗受害者加载或将信息提交到 Web 应用程序。这可以通过多种方式发生 - 例如钓鱼链接。

另外，类似于 XSS（跨站点脚本），CSRF 可以是一个可以被存储型漏洞。 比如攻击者将攻击代码存储在被接受的 HTML 代码中就会导致存储型 CSRF（例如 IMG 或 IFRAME 标签）时。这意味着浏览该页面的任何人都可能受到影响。 该漏洞可以伪装成普通链接或隐藏在图像标签中。

例如，作为网页上的普通链接 <a href=“malicious link”>Unsubscribe here</a>

或者伪装成图片标签: <img src=“malicious link” width=“0” height=“0” border=“0”>

CSRF 示例

想象一下，你的银行（bank.com）使用 GET 请求处理转账，其中包括几个参数（收款人身份以及转账的金额）。

例如，如果 Jim 想给他的朋友 Bob 10 美元，请求可能如下所示：

http://bank.com/transfer?recipient=Bob&amount=10

该请求还包括一个会话 cookie，用于标识帐户所持有人，以便银行知道从哪里取款。

现在，攻击者可能成功使 Jim 单击如下所示的链接（但已被巧妙的用缩短器或超链接缩短）：

http://bank.com/transfer?recipient=Hacker&amount=100000

因为 Jim 已经登录，他的浏览器会将他的 cookie 和请求一并发送 — 所以他的银行相信他本人正在请求转账于是执行了转账请求。

如何防止 CSRF 攻击

谨慎选择网站框架

使用内置了防护 CSRF 的框架，例如 .NET。 正确的配置很重要。如果你使用的框架没有保护，可以使用 Anti-CSRF 令牌添加保护。

使用 Anti-CSRF 令牌

令牌（也称为令牌同步模式）是一种服务器端的保护方式，服务器向用户的浏览器提供唯一的、随机生成的令牌，并检查每个请求来查看浏览器是否在执行请求之前将其发回。

这个令牌通过隐藏字段发送，应该是一个会在很短的时间内失效的不可预测的随机数，且不能重复使用。

根据不同页面的信息敏感程度，可以针对每个请求使用不同的令牌，或者仅针对不同的表单。令牌应该以安全的方式进行对比验证（例如比较哈希值），并且不应在 HTTP GET 请求中发送，防止作为 URL 的一部分或者 Referrer 泄漏。

在 Cookie 中使用 SameSite 标记

SameSite 标记的 cookie，只能发送来自同域名的请求。

基本上，www.bank.com 可以被允许向www.bank.com/updatepassword 提交 request 请求。 但www.maliciousdomain.com向 www.bank.com/updatepassword 发出请求时不能发送会话 cookie，因此无法进行攻击。

现在大多数浏览器都支持这个标志，但不是全部。它应该是综合防御战略的一部分。

深入练习防御

你可以进行许多其他的控制措施并配合其他措施使用，可以提供针对 CSRF 的保护。

例如，你可以采取以下一些其他保护措施

• 使用标准头文件验证来源（确定请求的来源和目标位置是否匹配）
• 使用自定义的请求头文件（站点将不接受没有相应的头文件的请求）
• 双重提交 cookie（尤其是一秒钟随机生成且未知的 cookie；对于攻击者来说，必须提交该参数才能正常请求）。

让用户参与交易流程

对于转账或密码更改等敏感操作，要求用户行为（如 CAPTCHA、一次性令牌或重新身份验证）。

无效的措施示例：

• 多步骤交易： 只要攻击者可以预测/确定每个步骤，有多少步骤并不重要。
• HTTPS： 总是一个好的安全措施，但对于 CSRF 无效
• URL 改写： 这可以防止攻击者在 CSRF 攻击期间猜测受害者的会话 ID，但随后攻击者可以在 URL 中看到它。用一个缺陷替换另一个缺陷并不是一个好主意。
• 使用私密（Secret）Cookie： 私密 cookie 同样是作为请求的一部分提交，也就是仍然可以被攻击者利用。
• 只接受 POST 请求/避免 GET 请求： 伪造的 POST 请求仍可用于执行 CSRF 攻击。

CSRF的其他称呼

CSRF 也被称作 XSRF，Sea Surf（CSRF 发音），会话叠置（Session Riding），跨站点引用伪造（Cross-Site Reference Forgery），恶意连接（Hostile Linking），一键攻击（One-Click Attack）。

资料来源/扩展阅读

• OWASP CSRF
• OWASP CSRF Prevention
• CSRF Attacks
• Anti-CSRF Tokens
• CSRF Basics
• PortSwigger CSRF

原文：Cross Site Request Forgery – What is a CSRF Attack and How to Prevent It，作者：Megan Kaczanowski