目录
一、XSS概念简述
1、XSS简介：
2、XSS基本原理：
3、XSS攻击流程：
4、XSS漏洞危害：
二、XSS类型：
1、反射型XSS：
2、存储型XSS：
3、DOM型XSS：
三、靶场漏洞复现(pikachu)：
1、靶场来源：
2、反射型XSS(get)复现：
3、反射型XSS(post)复现：
4、存储型XSS复现：
5、DOM型XSS复现：
四、总结：
一、XSS概念简述
1、XSS简介：
XSS（Cross Site Scripting），译做：跨站脚本攻击。
2、XSS基本原理：
XSS漏洞的基本原理是恶意攻击者将一段恶意代码，通常是客户端脚本如JavaScript，注入到Web页面中。当其他用户浏览这个被篡改的网页时，这段脚本会在他们的浏览器上执行，从而可能导致各种安全事件。
XSS常常存在于评论区功能处，攻击者往往会在评论区编写恶意代码，通过评论功能将恶意代码发往后台，从而与后台代码形成某种程度上的闭合，导致后台代码中被植入恶意代码。
3、XSS攻击流程：
攻击者从评论区上传恶意代码 ---> 注入代码的网页代码部分过滤不完全或无过滤操作 ---> 恶意代码植入网页代码 ---> 某用户A对网页此处进行了访问操作 ---> 用户A的浏览器对网页注入的恶意代码进行解析 ---> 用户A遭到攻击。
4、XSS漏洞危害：
（1）盗取各种用户账号；
（2）窃取用户Cookie资料，冒充用户身份进入网站；
（3）劫持用户会话，执行任意操作；指操作用户浏览器；
（4）刷流量，执行弹窗广告；传播蠕虫病毒。
二、XSS类型：
1、反射型XSS：
（1）攻击流程：
当攻击者将带有恶意脚本的URL发送给用户时，如果用户点击了这个URL，恶意脚本就会被发送到服务器，然后服务器会将这个脚本作为响应的一部分返回给用户的浏览器。浏览器在收到响应后会执行这段脚本，从而可能导致敏感信息如cookies被窃取。
这种攻击之所以被称为“反射型”，是因为恶意脚本是通过用户的浏览器“反射”回服务器，然后再由服务器“反射”回更多用户的浏览器来传播的。这种攻击方式通常是一次性的，因为恶意脚本不会存储在服务器上，而是通过URL参数直接传递给服务器。
（2）流程图：
2、存储型XSS：
（1）攻击流程：
攻击者通过 评论区、论坛等功能将 XSS代码上传，服务器接收并进行存储，XSS代码就成功植入了网页代码中，当其他用户对包含XSS代码的网页时，XSS代码就会被用户的浏览器进行解析并执行。
（2）流程图：
3、DOM型XSS：
DOM型XSS漏洞是一种基于文档对象模型（Document Object Model，简称DOM）的漏洞，它允许攻击者通过修改DOM元素的属性来注入并执行恶意脚本。
这种攻击方式不需要通过URL传递恶意代码，而是直接在用户的浏览器端执行。攻击者可能会利用JavaScript代码，通过改变页面的DOM结构，插入恶意脚本。由于这个过程是在客户端完成的，因此DOM型XSS攻击更加隐蔽，与传统的反射型XSS相比，它不依赖于服务器的响应，使得检测和防御更加困难。
简单来说：DOM型XSS漏洞地原理是利用前端代码漏洞。
三、靶场漏洞复现(pikachu)：
1、靶场来源：
BUUCTF -- pikachu靶场 -- Cross--Site Scripting 模块。
跳转BUUCTF -- pikachu 靶场
2、反射型XSS(get)复现：
页面如图所示：
我们首先输入kobe，观察页面和URL的变化：
发现页面内容显示正常，URL中出现 message=kobe，我们已知 反射型XSS 是针对URL来进行操作的，我们修改URL中的 message 的值：
message = <script>alert(document.cookie)</script>修改后提交，显示如下：
页面成功显示 cookie信息，复现成功。
3、反射型XSS(post)复现：
（1）get 和 post 型的XSS反射型漏洞的区别：
---数据提交方式不同：
反射型XSS(GET)：攻击载荷（payload）直接附加在URL中，用户通过点击含有恶意代码的链接即可触发攻击。这种方式下，恶意脚本会随着URL传递，不需要用户进行任何提交动作。
反射型XSS(POST)：攻击载荷通常不会直接出现在URL中，而是通过表单提交的方式发送到服务器。在这种情况下，攻击者可能需要诱使用户点击一个按钮或提交一个表单，使得恶意数据作为POST请求的一部分发送出去。
（2）漏洞复现：
进入靶场，页面如图所示：
我们利用 F12 中的查看器，查看当前页面源代码：
观察到表单<form>的数据提交方式为 POST，这就是XSS反射型(post)的特点。
我们在输入栏中同样尝试输入kobe，页面如下：
页面显示内容正常，但是发现，post提交与get提交的不同之处在于，post的message=消失了，这就是post提交中攻击载荷(payload)通常不会出现在URL中的特点。
我们尝试在输入栏中输入XSS代码并进行提交：
<script>alert(document.cookie)</script>提交后页面如下：
页面中显示了cookie、账号和密码，漏洞复现成功。
4、存储型XSS复现：
进入靶场，页面如图所示：
前面已经介绍过存储型XSS的特性，在这里不做赘述。
查看评论区页面源代码：
可以发现明显存在XSS漏洞，可以在<p>标签中插入javascript代码并一直存储在那里。
我们在评论区写入XSS代码，并提交：
<script>alert(document.cookie)</script>提交后页面如下：
cookie值显示，漏洞复现成功。
5、DOM型XSS复现：
进入靶场，页面如图所示：
我们依然尝试输入 kobe，发现页面回显一段英文 what do you see? ，其他无内容显示。我们查看页面源代码，内容如下：
观察源代码，发现kobe在<a>标签中的 href 处显示，想要进行XSS攻击，我们需要构造一段合适的payload，来将此处的 html 语句闭合并且执行我们自己的 javascript语句。
我们构造以下payload:
#' onclick="alert(document.cookie)">提交后，源代码的html语句变成了这样，如下图：
我们发现payload提交后，与源代码中的旧html语句联合构造出了一个新的html语句，代码意为：点击 '>what do you see? 就会执行 onclick中的语句，即执行我们注入的XSS语句。
注入XSS语句后，页面如下：
我们点击 '>what do you see? ，显示如下：
cookie值正常显示，漏洞复现成功。
四、总结：
XSS漏洞通常要结合检查页面源代码来进行注入。
