实习Day4

目录

一、反射型、存储型、DOM型XSS特点和区别

 反射型XSS（Reflected XSS）                

 存储型XSS（Stored XSS）

DOM型XSS（DOM-based XSS）

区别

二、XSS 的fuzz字典、字典生成工具

GitHub - TheKingOfDuck/fuzzDicts: Web Pentesting Fuzz 字典,一个就够了。https://github.com/TheKingOfDuck/fuzzDicts

三、XSS靶场（https://xss.tesla-space.com/）

第一关

第二关

第三关

第四关

第五关

四、总结浏览器解析机制

HTML解析

URL解析

JavaScript解析

解析流

一、反射型、存储型、DOM型XSS特点和区别

 反射型XSS（Reflected XSS）                

        即时性：反射型XSS的攻击效果是即时的，用户需要点击或访问一个包含恶意脚本的链接，该链接中的恶意脚本会立即在用户的浏览器中执行。

        依赖服务器：攻击者构造的恶意脚本需要通过HTTP请求发送到服务器，并在服务器的响应中反射回客户端执行。

        非持久性：恶意脚本不会存储在服务器上，因此一旦攻击链接被删除或失效，攻击就无法继续。

 存储型XSS（Stored XSS）

        持久性：存储型XSS的恶意脚本被永久存储在服务器上，如博客留言、论坛帖子或用户资料等位置。一旦存储，每次用户访问包含该恶意脚本的页面时，脚本都会自动执行。

        隐蔽性：由于恶意脚本存储在服务器上，攻击者可以隐蔽地实施攻击，无需每次都发送恶意链接。

        危害性大：由于攻击具有持久性，且隐蔽性高，存储型XSS的危害性通常比反射型XSS更大。

DOM型XSS（DOM-based XSS）

        不依赖服务器：DOM型XSS的恶意脚本直接在客户端（浏览器）中通过JavaScript动态生成和执行，不经过服务器。

        灵活性高：由于恶意脚本在客户端执行，攻击者可以利用JavaScript的强大功能进行各种复杂的攻击。

        难以检测：由于攻击发生在客户端，且可能不涉及服务器端的日志记录，因此DOM型XSS往往难以被检测和防御。

区别

        持久性：反射型XSS是非持久的，而存储型XSS是持久的。

        攻击方式：反射型XSS通过诱导用户点击恶意链接来触发攻击，存储型XSS则通过用户访问被污染的页面来触发攻击，基于DOM的XSS则通过修改DOM结构来注入恶意代码。

        危害程度：存储型XSS由于恶意代码存储在服务器上，因此可以长期影响多个用户，其危害程度通常高于反射型XSS和基于DOM的XSS。

二、XSS 的fuzz字典、字典生成工具

GitHub - TheKingOfDuck/fuzzDicts: Web Pentesting Fuzz 字典,一个就够了。https://github.com/TheKingOfDuck/fuzzDicts

三、XSS靶场（https://xss.tesla-space.com/）

第一关

        没有任何的输入点，而页面上有一个test（用户名），url中也有一个name参数，猜测是将url中的name获取到的值，直接放入页面导致了xss，试一下，看看页面上的值会不会根据name参数得到的值而改变

         尝试输入一个payload，把 name 传入的参数替换为

<script>alert(1)</script>

第二关

        改变唯一输入点的时候，页面有两处随之改变,提交内容为 input 标签的 value

        构造 payload 时闭合引号，尖括号即可成功 

"><script>alert(1)</script>

第三关

        尝试同样的payload进行测试

        出现问题：" 无法闭合      ’ 变成了"，且后面的被编码了 

         htmlspecialchars ()该函数会将特殊字符进行转义，因此这里无法采用标签，因为标签都是带有”<“的，但该函数不会转义单引号 ，所以可以采用事件闭合标签

' onclick='alert(1) 

        点击输入框触发 

第四关

        尝试<script>alert(1)</script>，发现 <> 均被替换为空

         构造onclick事件，并用双引号闭合标签

" onclick="alert(1)

第五关

        尝试"><script>alert(1)</script>,发现 script替换为 scr_pt 

        尝试" οnclick="alert(1) ,发现 on 替换为 o_n

        使用 a 标签的 href 导入 js 代码进行注入 

"><a href=javascript:alert(1)>1

四、总结浏览器解析机制

HTML解析

        在解析过程中，任何时候它只要遇到⼀个'<'符号（后面没有跟'/'符号）就会进入“标签开始状态(Tag open state)”。然后转变到“标签名状态(Tag name state)”，“前属性名状态(beforeattribute name state)”......最后进入“数据状态(Data state)”并释放当前标签的token。当解析器处于“数据状态(Data state)”时，它会继续解析，每当发现⼀个完整的标签，就会释放出⼀个token。

        这里有三种情况可以容纳字符实体，“数据状态中的字符引用”，“RCDATA状态中的字符引用”和“属性值状态中的字符引用”，在这些状态中HTML字符实体将会从“&#...;”形式解码，对应的解码字符会被放入数据缓冲区中。

URL解析

        URL解析器也是⼀个状态机模型，从输入流中进来的字符可以引导URL解析器转换到不同的状态。

        URL资源类型必须是ASCII字母（U+0041-U+005A || U+0061-U+007A），不然就会进入“无类型”状态。例如，你不能对协议类型进行任何的编码操作，不然URL解析器会认为它无类型。

JavaScript解析

        所有的“script”块都属于“原始文本”元素。“script”块有个有趣的属性：在块中的字符引用并不会被解析和解码【协议无法识别（即被编码的javascript:）】

        Unicode转义序列只有在标识符名称里不被当作字符串，也只有在标识符名称里的编码字符能够被正常的解析

解析流

        当浏览器从网络堆栈中获得一段内容后，触发HTML解析器来对这篇文档进行词法解析。在这一步中字符引用被解码。在词法解析完成后，DOM树就被创建好了，JavaScript解析器会介入来对内联脚本进行解析。在这⼀步中Unicode转义序列和Hex转义序列被解码。同时，如果浏览器遇到需要URL的上下文，URL解析器也会介入来解码URL内容。在这一步中URL解码操作被完成。由于URL位置不同，URL解析器可能会在JavaScript解析器之前或之后进行解析。