一、介绍：
存储型 XSS（Cross-Site Scripting）攻击是一种 Web 应用程序中常见的安全漏洞，攻击者通过将恶意脚本注入到服务器端，使得这些脚本被存储在数据库中，进而在用户浏览器中执行。下面是对存储型 XSS 攻击的解释和分析：
- 攻击过程：
- 攻击者将恶意脚本注入到 Web 应用程序的输入字段或用户提交的内容中。
- 这些恶意脚本被存储在服务器端，通常是在数据库中，以便后续用户访问时被提取和执行。
- 当用户浏览包含恶意脚本的页面时，浏览器执行这些脚本，导致攻击者可以在用户环境中执行恶意操作。
- 危害：
- 存储型 XSS 攻击可能导致用户受到各种危害，包括但不限于：
- 窃取用户的敏感信息，如登录凭据、会话标识等。
- 在用户账户下执行未经授权的操作。
- 劫持用户的会话。
- 在受害用户的浏览器上执行恶意操作，如下载恶意软件或进行网络攻击。
防御措施：
- 输入验证：对于用户输入的数据，进行有效的输入验证，确保只接受合法和预期的输入。
- 输出转义：在将用户输入嵌入到 HTML 页面之前，对其进行适当的输出编码，以防止执行恶意脚本。
- Content Security Policy（CSP）：通过在HTTP响应头中设置 CSP 策略，限制浏览器执行外部脚本的能力，从而减少 XSS 攻击的风险。
- 定期安全审计：定期审查和测试应用程序的代码，以发现潜在的 XSS 漏洞，并及时修复。
总体而言，存储型 XSS 攻击是一种危险的安全漏洞，要防范这种攻击，开发者需要采取多层次的防御策略，包括验证输入、转义输出、使用 CSP 等
二、实操演示：
环境准备：
测试：
打开咱们已经安装好了的 Pikachu 靶场，找到存储型 xss 这一页面
尝试在输入框中输入一些值，然后点击 submit 提交
它输出在了留言列表下面，咱们再尝试输入一些奇怪的值
<script></script>
可以看到多了个删除，这是因为咱们输入的 JavaScript 代码被执行了，说明没有做任何过滤处理
攻击：
输入以下代码到输入框中
<script>alert(/XSS 代码执行成功/)</script>
代码立马执行了，接下来咱们试试重进靶场
明显可以看到在咱们切换页面时代码就已经执行，现在咱们就来分析
分析：
网站的执行顺序涉及到前端和后端的不同阶段，以及浏览器和服务器的协同工作。下面是一个典型的网站加载和执行的顺序：
1. 服务器端执行阶段：
- 接收请求：
- 当用户在浏览器中输入网址或点击链接时，浏览器向服务器发送HTTP请求。
- 服务器处理请求：
- 服务器接收到请求后，执行相应的处理，可能涉及到路由解析、数据库查询、业务逻辑处理等。
- 生成动态内容：
- 对于动态网页，服务器生成HTML内容，并将其返回给浏览器。这可能包括从数据库检索数据，动态生成页面。
- 发送响应：
- 服务器将生成的HTML、CSS、JavaScript等资源作为HTTP响应返回给浏览器。
2. 浏览器端执行阶段：
- HTML解析：
- 浏览器接收到服务器返回的HTML响应后，开始解析HTML文档构建DOM树。
- CSS解析：
- 同时，浏览器解析CSS样式表构建CSSOM树。
- 渲染树构建：
- 浏览器将DOM树和CSSOM树结合构建渲染树，该树用于布局和绘制页面。
- 页面渲染：
- 浏览器根据渲染树进行页面布局和绘制，显示最终的页面内容。
- JavaScript执行：
- 浏览器执行HTML中的内联JavaScript代码，或者加载并执行外部JavaScript文件。
- JavaScript执行期间可能会修改DOM树，触发重新渲染。
3. 交互阶段：
- 用户交互：
- 用户与页面交互，触发事件，如点击按钮、输入表单等。
- 事件处理：
- 与JavaScript相关的事件处理器（event handlers）被触发，执行相应的JavaScript代码。
- 动态更新：
- JavaScript代码可能会动态地修改页面内容、样式，或者进行异步请求获取数据。
这个整体的过程构成了从用户发起请求到最终页面显示的完整生命周期。需要注意的是，前端和后端的执行是并行的，并且整个过程是一个不断循环的交互过程，以响应用户的操作
由此可知，因为服务器在查询数据库中的留言时，返回到了浏览器中被其执行，所以先弹框
如果读者觉得对您有帮助，麻烦动动小手评论点点赞或者收藏关注博主，谢谢支持！！
