跨站脚本攻击（XSS）与跨站请求伪造（CSRF）的介绍、区别和预防
概念
跨站脚本攻击（XSS）
攻击者通过在网页中注入恶意脚本（如 JavaScript），当用户访问该页面时，脚本会在用户浏览器中执行，从而窃取数据、劫持会话或控制用户行为。
“我偷你的数据”（脚本注入，用户受害）。
事件：
2011 年索尼 PSN 被黑事件，用户数据泄露，其中就涉及 XSS 漏洞。这个案例展示了 XSS 如何被用来窃取用户会话，进而访问敏感信息。
核心机制：
- 注入脚本：攻击者利用网页对用户输入的信任，将恶意代码插入评论区、搜索框等可输入区域。
示例：在论坛评论中输入<script>alert('XSS');</script>。 - 用户触发：用户访问被注入脚本的页面时，浏览器会执行恶意代码。
- 攻击目标：直接针对用户，窃取其数据或会话信息。
常见类型：
- 存储型 XSS：脚本被永久存储在服务器（如数据库），所有访问该页面的用户都会触发。
- 反射型 XSS：脚本存在于 URL 参数中，需诱骗用户点击特定链接。
- DOM 型 XSS：通过修改页面 DOM 结构触发，不依赖服务器响应。
跨站请求伪造（CSRF）
攻击者伪造用户身份，在用户不知情的情况下，利用其已登录的会话向目标网站发送恶意请求，执行敏感操作（如转账、修改密码）
“我用你的身份搞破坏”（伪造请求，网站受害）。
事件：
2014 年的 WordPress 插件漏洞导致管理员账户被劫持，攻击者利用 CSRF 伪造请求，执行恶意操作。这个案例说明 CSRF 在实际应用中的威胁。
核心机制：
- 会话劫持：用户已登录目标网站，Cookie 中包含会话凭证。
- 伪造请求：攻击者构造包含合法请求参数的页面（如自动提交的表单），诱骗用户访问。
示例：钓鱼网站的<form action="https://bank.com/transfer" method="POST">...</form>。 - 服务器误判：服务器验证请求时，因 Cookie 合法而认为是用户的正常操作。
攻击目标：
间接攻击网站，利用用户权限执行非法操作，而非直接窃取用户数据。
xss与csrf的相同和不同
相同点
- 攻击媒介：
均通过用户浏览器执行恶意操作，依赖浏览器与服务器的交互。 - 利用用户身份：
攻击者均需借助用户已登录的会话（如 Cookie）实施攻击。 - 潜在危害：
可能导致用户数据泄露、账户被盗或网站功能滥用。
不同点
| 对比维度 | 跨站脚本攻击（XSS） | 跨站请求伪造（CSRF） |
|---|---|---|
| 核心机制 | 注入恶意脚本到网页中执行 | 伪造用户请求欺骗服务器 |
| 攻击目标 | 用户（窃取数据或会话） | 网站（执行用户权限操作） |
| 数据流向 | 攻击者→用户→服务器 | 攻击者→服务器（冒用用户身份） |
| 触发条件 | 用户主动访问含恶意脚本的页面 | 用户已登录且未退出的情况下访问恶意页面 |
| 常见场景 | 评论区、搜索框注入脚本 | 钓鱼链接诱导点击 |
防范措施
跨站脚本攻击（XSS）的防护
- 输入过滤：
对用户输入的数据进行严格验证，禁止 HTML/JavaScript 等危险字符（如<script>）。// 示例：过滤<script>标签 function sanitizeInput(input) { return input.replace(/<script\b[^<]*(?:(?!<\/script>)<[^<]*)*<\/script>/gi, ''); } - 输出编码：
在 HTML、JavaScript、URL 等上下文中对输出内容进行编码，防止脚本执行。<!-- 示例：对用户输入的name进行HTML编码 --> <p>欢迎用户：<%= encodeForHTML(user.name) %></p> - 内容安全策略（CSP）：
通过 HTTP 头或 meta 标签限制可执行脚本的来源。<meta http-equiv="Content-Security-Policy" content="default-src 'self'"> - HttpOnly Cookie：
设置 Cookie 的HttpOnly属性，防止 XSS 窃取会话。
跨站请求伪造（CSRF）的防护
- CSRF 令牌（Token）：
在表单或请求中嵌入随机生成的令牌，服务器验证令牌合法性。<!-- 示例：表单中添加CSRF令牌 --> <input type="hidden" name="csrf_token" value="随机字符串"> - 验证 Referer 头：
检查请求来源是否为可信域名，但存在绕过风险（如浏览器不发送 Referer）。 - SameSite Cookie 属性：
设置 Cookie 的SameSite=Strict/Lax，防止第三方网站发起请求。 - 双因素认证（2FA）：
对敏感操作（如转账、修改密码）强制使用 2FA，降低 CSRF 危害。
总结
- XSS：重点在于防止脚本注入，通过输入过滤、输出编码和 CSP 实现。
- CSRF：核心是验证请求的合法性，依赖令牌机制和 Cookie 安全属性。
- 组合防护：两者可结合使用，如
HttpOnly+SameSiteCookie 同时增强对 XSS 和 CSRF 的防御。
在实际开发中，需根据具体场景选择防护策略，并定期进行安全测试，如使用库博静态代码分析工具进行安全检测，及时发现代码中存在的各类XSS和CSRF漏洞，及时发现及时修复，防止软件投入使用后，造成更大的损失。
