目录
4. 总结浏览器解析机制，若不能理解，解释《漏洞利用之XSS注入》中15条中，至少5条执行成功或不成功的原因。
1. 总结反射型、存储型、DOM型XSS特点和区别
反射型XSS的特点
GET XSS
- 数据提交方式：GET XSS通过URL的查询字符串（query string）提交恶意脚本。攻击者会构造一个包含恶意脚本的URL，并诱导用户点击该链接。当用户点击链接时，恶意脚本会被发送到服务器，并在服务器响应时返回给用户的浏览器执行。
- 易于利用：由于GET请求中的数据直接显示在URL中，因此GET XSS相对容易被攻击者利用。攻击者可以很容易地通过伪造链接或嵌入到合法网站中的链接来发动攻击。
- 非持久性：GET XSS攻击是即时的，不会将恶意脚本存储在服务器上。一旦用户关闭包含恶意脚本的页面或清除浏览器缓存，攻击就会停止。
POST XSS
- 数据提交方式：POST XSS通过HTTP POST请求体提交恶意脚本。这种攻击方式通常发生在用户提交表单时，恶意脚本被嵌入到表单数据中。由于POST请求不会在URL中显示数据，因此POST XSS相对难以直接通过URL进行攻击。
- 隐蔽性：POST XSS的攻击过程相对隐蔽，因为恶意脚本不会出现在URL中。攻击者需要构造一个恶意的表单页面，并诱导用户在该页面上输入数据或提交表单。
- 可能的持久性：虽然POST XSS本身不直接涉及服务器端的存储，但如果服务器在处理POST请求时没有进行充分的验证和过滤，恶意脚本可能会被存储在数据库中。在这种情况下，每当其他用户访问受影响的页面时，恶意脚本都可能会被执行，从而构成类似存储型XSS的攻击效果。然而，这种持久性并不是POST XSS的固有特性，而是取决于服务器端的安全措施。
二者的区别
| GET XSS | POST XSS | |
| 数据提交方式 | 通过URL的查询字符串提交恶意脚本 | 通过HTTP POST请求体提交恶意脚本 |
| 易于利用性 | 由于URL中直接显示数据，相对容易被攻击者利用 | 攻击过程相对隐蔽，不易直接通过URL进行攻击 |
| 非持久性/持久性 | 通常是非持久的，依赖于用户的即时点击 | 可能是非持久的（直接攻击），但也可能因服务器端的处理不当而变为持久的（类似存储型XSS） |
| 攻击场景 | 常见于诱导用户点击恶意链接的场景 | 常见于用户提交表单的场景 |
存储型XSS的特点
-
持久性：存储型XSS的核心特点是其持久性。恶意脚本被注入到目标网站的数据库中，并存储在服务器上。这意味着一旦攻击成功，恶意脚本就会持续存在，并在每次用户访问受影响的页面时自动执行。这种持久性使得攻击者能够长期影响大量用户，而无需每次都进行新的攻击尝试。
-
隐蔽性：由于恶意脚本存储在服务器上，并且通常不会直接显示在URL或页面源代码中，因此存储型XSS攻击相对隐蔽。攻击者可以精心构造恶意脚本，使其难以被用户或网站管理员察觉。此外，由于攻击是自动触发的，用户可能根本不会意识到他们的浏览器正在执行恶意代码。
-
广泛影响：由于恶意脚本会在每次用户访问页面时执行，因此存储型XSS攻击可以影响大量用户。这取决于受影响的页面在网站中的受欢迎程度和访问频率。在极端情况下，恶意脚本可能会传播到整个网站，甚至通过用户之间的交互（如论坛帖子、评论等）传播到其他网站。
-
难以清除：一旦恶意脚本被注入到数据库中，清除起来可能非常困难。攻击者可能会使用各种技术来绕过网站的安全措施，如加密、混淆或分散存储恶意脚本。此外，即使网站管理员能够识别并删除恶意脚本，攻击者也可能已经找到了重新注入恶意脚本的方法。
-
多种攻击方式：存储型XSS攻击可以用于多种恶意目的，包括但不限于窃取用户数据（如登录凭据、信用卡信息等）、会话劫持、传播恶意软件、进行网络钓鱼攻击等。攻击者可以根据他们的目标和资源选择最合适的攻击方式。
DOM型XSS的特点
-
客户端执行：与反射型XSS和存储型XSS不同，DOM型XSS的恶意脚本直接在受害者的浏览器上执行，而不涉及服务器端的响应。这意味着攻击者不需要控制服务器或修改服务器上的数据，只需要控制或影响发送到浏览器的数据即可。
-
隐蔽性强：由于DOM型XSS的攻击发生在客户端，服务器端的日志通常不会记录任何异常，这使得检测和追踪DOM型XSS攻击变得更加困难。此外，由于恶意脚本可能隐藏在看似合法的JavaScript代码中，因此很难通过简单的代码审查来发现。
-
依赖动态内容：DOM型XSS通常与网页的动态生成内容有关。攻击者可能会利用JavaScript来读取URL参数、cookie、localStorage等客户端数据，并根据这些数据动态地修改DOM元素，从而插入恶意脚本。
-
绕过传统防御措施：由于DOM型XSS不依赖于服务器端的响应，因此它可以绕过一些传统的XSS防御措施，如输入验证和输出编码。这些措施通常只能保护服务器免受攻击，但无法阻止客户端的JavaScript代码被恶意修改。
-
多样化的攻击方式：DOM型XSS的攻击方式非常多样化，攻击者可以通过各种方式触发恶意脚本的执行，如通过JavaScript事件（如onclick、onmouseover等）、通过修改CSS样式来触发JavaScript代码的执行、或者通过利用浏览器的某些特性（如HTML5的WebSockets）来绕过同源策略等。
各类XSS的区别
被攻击对象的不同
反射型XSS的被攻击对象一般是攻击者去寻找的，就比如说：一个攻击者想盗取A的QQ号，那么攻击者就可以将一个含有反射型XSS的URL链接给A，此时我们可以看出，需要将特定的URL，注意是特定的URL给A，当A点击进入链接时，就受到XSS攻击，所以这种攻击范围不是特别的广。
而存储型XSS是广撒网的方式或者指定的方式，就是攻击者将存储型XSS放在一些有XSS漏洞的网站上，只要有用户访问这个链接就会中招，而攻击者也可以寻找被攻击对象，比如说上面的例子，所以我们可以看出，存储型XSS的危害性更大，范围更广，可以不需要寻找被攻击对象，只要存储型XSS在服务器上就能实施攻击。
DOM型XSS的被攻击对象其实和反射型XSS被攻击对象差不多，就是给攻击对象放送URL。
解析位置不同
反射型XSS的脚本被解析的地方是浏览器，而存储型XSS的脚本被解析的地方是服务器，DOM型XSS也是浏览器，所以DOM型又叫DOM反射型XSS。但是反射型XSS需要联网，而DOM型不需要！
存储时间不同
反射型XSS是既有即用，没有持久性，而存储型XSS是存储在服务器上，只要服务器不挂机或者是被干掉，就一直会有，DOM型XSS和反射型差不多，但是用人就扯淡了，那反射型只要不改变源代码不就是一直存在吗？不是的，反射型XSS是必须得特定的URL才能使得被攻击对象中招，如果是单单官方网页，就没有了咯，存储型就不同，只要服务器里面有存储型XSS，不论是不是官网，被攻击对象都会被攻击。
XSS靶机实测
环境准备
启动Apache/Mysql/Burpsuite代理
反射型XSS（get）
输入<script>alert('1')</script>，发现url存在变化，显示了递交的变量信息
确认返回，显示 who is, I don't care!
在输入的时候可能会遇到输入框长度限制的问题，可以根据url指向位置来修改对应文件：
在Buprsuite查看抓包内容，发送到Repeater
send查看详细信息
反射型XSS（post）
使用admin/123456进行登录，获取cookie
输入<script>alert('1')</script>，点击submit，发现url没有显示递交信息，这便是get和post的一大区别：
在Buprsuite查看抓包内容，发送到Repeater
send查看详细信息
存储型XSS
输入<script>alert('1')</script>
在消息记录中显示了出来（显示在最下方），但因为是<script>的特殊性，这里显示是空
但其实可以在数据库中查看
在Buprsuite查看抓包内容，发送到Repeater
send查看详细信息
2. 上网搜索一份XSS 的fuzz字典或字典生成工具
来源：https://github.com/oldboot/FuzzDicts
3. 到XSS挑战靶场打靶。
链接：https://xss.tesla-space.com/
第一关
观察url，发现有参数传递“?name=test”，推测是反射型XSS(get)
尝试将传递的内容改为payload：
<script>alert('1')</script>
第二关
有搜索框，输入内容<script>alert('1')</script>并搜索
看来并没那么简单，查看网页源代码，发现有猫腻，在15行我们的引号被实体转义了，为了避免这个情况，考虑提前闭合>
尝试使用 > 提前闭合value后边的内容再输入新的内容使其逃逸，payload：
111"><script>alert('1')</script>
第三关
仍然是有搜索框的，输入1上一关的payload，点击搜索
查看网页源代码寻找突破口
发现搜索处在value变量的地方，输入的用于闭合的双引号被实体化了，但单引号没有，修改payload为：111'><script>alert('1')</script>,查看源码还是不行，因为>也被实体化了。
既然这样，我们只能考虑不使用>进行闭合，而是在input标签内进行XSS，学习到有一函数满足我们的需求，即onclick，设置的变量随着我们点击输入框后即刻触发，payload为：
'onclick='alert(1)
搜索后再点击输入框，即可成功过关
第四关
输入123点击搜索
查看源代码查找突破口，使用了双引号闭合：
尝试使用第二关的payload：
原来是把我们输入的<>过滤掉了，那就把第三关的payload中的单引号改成双引号就行了呗，payload如下：
"onclick="alert(1)
搜索后再点击输入框，即可成功过关
第五关
仍然是有输入框的，输入123点击搜索
查看网页源码：
使用的是双引号，继续用第二关的payload尝试：
好家伙，篡改了我的第一个script，没错，他只改了，第一个，那么我可不可以把第一个script放到闭合前和他同归于尽呢。
尝试使用payload：script"><script>alert('1')</script>， 还是我想得太简单了，并不行。他应该是按照标签识别并进行篡改的。
那使用第四关的payload试一下：
好吧他给我的alert加了双引号，变成字符串了,后面尝试onclick也被改了。好吧，不让我用script，我用a标签搭配javascript:alert总行了吧~
payload如下：
"><a href="javascript:alert(1)">点击>，就过关了~
注意这里的a标签使用全貌应该是这样的
<a href="javascript:alert(1)"XXXXXXX</a>XXXXXXX是a标签的主题内容，可以理解为超链接显示的文本，而它的作用就是前面双引号括起来的alert，payload中的</a>其实是被省略的，末尾的>是这里的XXXXXX对应的内容。
4. 总结浏览器解析机制，若不能理解，解释《漏洞利用之XSS注入》中15条中，至少5条执行成功或不成功的原因。
类型1：url不解析编码内容
<a href="%6a%61%76%61%73%63%72%69%70%74:%61%6c%65%72%74%28%31%29"></a>类型2：标签功能误用
2 执行
<div><img src=x onerror=alert(4)></div>结果：不执行
解释：从HTML解析机制看，在读取 <div> 之后进⼊数据状态， < 会被HTML解码，但不会进⼊标签开始状态，当然也就不会创建 img 元素，也就不会执⾏。
类型3：textarea只打印
<textarea><script>alert(5)</script></textarea>结果：不执行
解释：<textarea> 是 RCDATA 元素（RCDATA elements），可以容纳⽂本和字符引⽤，注意不能 容纳其他元素，HTML解码得到 <textarea><script>alert(5)</script></textarea> 于是直接显示，类似于print函数。
类型4：javascript中的unicode
<button onclick="confirm('8\u0027);">Button</button>结果：不执行
解释：onclick 中的值会交给JS处理，在JS中只有字符串和标识符能⽤Unicode表示， ' 显然不⾏， JS执⾏失败
类型5：script只容纳文本
<script>alert(9);</script>结果：不执行
解释：script 属于原始⽂本元素(Raw text elements)，只可以容纳⽂本，注意没有字符引⽤，于是直接由JS处理，JS也认不出来，执⾏失败 原始⽂本元素(Raw text elements)有 <script> 和 <style>
622
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
