Day-032-OWASP-Top-10-2021详解

# Day 31: OWASP Top 10 2021 详解

> Web 安全系列第 1 天 | 预计阅读时间：40 分钟 | 难度：★★★★☆

---

## 清单 目录

1. [OWASP 组织介绍](#owasp 组织介绍)
2. [Top 10 演进历史](#top-10 演进历史)
3. [2021 版变化详解](#2021 版变化详解)
4. [A01 失效访问控制](#a01 失效访问控制)
5. [A02 加密机制失效](#a02 加密机制失效)
6. [A03 注入攻击](#a03 注入攻击)
7. [A04 不安全设计](#a04 不安全设计)
8. [A05 安全配置错误](#a05 安全配置错误)
9. [A06 脆弱组件](#a06 脆弱组件)
10. [A07 认证失效](#a07 认证失效)
11. [A08 软件和数据完整性故障](#a08 软件和数据完整性故障)
12. [A09 安全日志和监控失效](#a09 安全日志和监控失效)
13. [A10 服务端请求伪造](#a10 服务端请求伪造)
14. [总结与思考](#总结与思考)
15. [参考资料](#参考资料)

---

## OWASP 组织介绍

### 什么是 OWASP

OWASP（Open Web Application Security Project，开放 Web 应用安全项目）是一个全球性的非营利组织，致力于提高软件安全性。

**形象理解**：
如果把网络安全比作医学领域，那么：
- **OWASP** = 世界卫生组织（WHO）
- **Top 10** = 全球十大疾病清单
- **安全指南** = 诊疗指南
- **社区贡献** = 全球医生协作

**OWASP 的核心特点**：
```
1. 开源免费
   - 所有文档免费开放
   - 工具开源可用
   - 社区共同维护

2. 厂商中立
   - 不推销任何产品
   - 客观公正的建议
   - 基于实际数据

3. 全球社区
   - 190+ 国家有分会
   - 数万志愿者参与
   - 多语言支持

4. 实践导向
   - 提供实用工具
   - 可操作的指南
   - 真实案例分析
```

**OWASP 主要项目**：
```
1. OWASP Top 10
   - Web 应用安全风险排行
   - 每 3-4 年更新一次
   - 行业事实标准

2. OWASP Testing Guide
   - 渗透测试指南
   - 详细测试方法
   - 检查清单

3. OWASP Cheat Sheet
   - 速查表系列
   - 主题覆盖广泛
   - 快速参考

4. OWASP Tools
   - ZAP（渗透测试工具）
   - Dependency-Check（依赖检查）
   - 其他安全工具
```

---

## Top 10 演进历史

### 版本演进

OWASP Top 10 自 2003 年首次发布以来，已经历多次更新，反映了 Web 安全威胁的变化趋势。

```
2003 年：第一版 Top 10
├─ 背景：Web 应用开始普及
├─ 重点：基础漏洞（XSS、SQL 注入）
└─ 影响：建立行业标准

2007 年：Top 10 更新
├─ 变化：细化分类
├─ 新增：跨站请求伪造（CSRF）
└─ 趋势：攻击手法多样化

2010 年：Top 10 更新
├─ 变化：基于实际数据
├─ 新增：不安全加密存储
└─ 趋势：数据泄露频发

2013 年：Top 10 更新
├─ 变化：风险评级方法
├─ 新增：不安全直接对象引用
└─ 趋势：API 安全兴起

2017 年：Top 10 更新
├─ 变化：合并相关风险
├─ 新增：XML 外部实体（XXE）
└─ 趋势：组件漏洞突出

2021 年：Top 10 更新（当前版）
├─ 变化：3 个新增类别
├─ 新增：失效访问控制（#1）
├─ 新增：不安全设计（#4）
├─ 新增：完整性故障（#8）
└─ 趋势：供应链攻击、API 安全
```

### 2021 版重大变化

**2017 vs 2021 对比**：

| 2017 年 | 2021 年 | 变化说明 |
|---------|---------|----------|
| A1 注入 | A03 注入 | 降为第 3 |
| A2 失效认证 | A07 认证失效 | 降为第 7 |
| A3 敏感数据泄露 | A02 加密机制失效 | 升为第 2，范围扩大 |
| A4 XML 外部实体 | - 移除 | 合并到其他类别 |
| A5 失效访问控制 | A01 失效访问控制 | **升为第 1** |
| A6 安全配置错误 | A05 安全配置错误 | 降为第 5 |
| A7 跨站脚本 | - 移除 | 合并到 A03 注入 |
| A8 不安全反序列化 | A08 软件和数据完整性故障 | 范围扩大 |
| A9 使用含已知漏洞的组件 | A06 脆弱和过时的组件 | 升为第 6 |
| A10 不足的日志记录和监控 | A09 安全日志和监控失效 | 升为第 9 |
| - | A04 不安全设计 | **新增** |
| - | A10 服务端请求伪造 | **新增** |

**关键变化解读**：

```
1. 失效访问控制升至第 1 位
   原因：
   - CWE 数据显示占比最高（55.9%）
   - 影响最严重（数据泄露主因）
   - 检测难度大

2. 新增"不安全设计"
   原因：
   - 设计缺陷导致的安全问题
   - 需要威胁建模和安全设计
   - 无法通过配置修复

3. XSS 合并到注入
   原因：
   - 本质上都是注入攻击
   - 简化分类
   - 统一防护思路

4. 新增"服务端请求伪造"
   原因：
   - 云原生架构普及
   - API 调用频繁
   - 攻击案例增多
```

---

## A01 失效访问控制

### 什么是访问控制

**访问控制（Access Control）**是限制谁可以访问什么资源的安全机制。

**形象理解**：
如果把 Web 应用比作一栋办公楼，那么：
- **访问控制** = 门禁系统 + 权限管理
- **用户角色** = 员工工牌（不同级别）
- **资源** = 各个房间（办公室、会议室、机房）
- **权限** = 能进哪些房间

**访问控制的三个核心问题**：
```
1. 认证（Authentication）
   - 你是谁？
   - 验证身份
   - 用户名密码、MFA 等

2. 授权（Authorization）
   - 你能做什么？
   - 权限分配
   - 角色、权限策略

3. 审计（Auditing）
   - 你做了什么？
   - 访问记录
   - 日志、监控
```

### 常见失效场景

**场景 1: 水平越权（IDOR）**
```
什么是水平越权：
同一级别的用户之间，可以访问彼此的资源。

攻击示例：
用户 A 登录系统后，访问：
GET /api/user/123/profile

修改用户 ID：
GET /api/user/124/profile

结果：
成功访问用户 B 的个人资料！

真实案例：
2019 年，某社交平台 API 未验证用户 ID，
攻击者遍历用户 ID，获取 5000 万用户数据。

防护方法：
✓ 服务端验证用户身份
✓ 使用会话中的用户 ID，不使用客户端传入
✓ 实施细粒度权限检查
```

**场景 2: 垂直越权**
```
什么是垂直越权：
低权限用户可以访问高权限功能。

攻击示例：
普通用户访问：
GET /admin/users
POST /admin/deleteUser?id=5

结果：
成功执行管理员操作！

真实案例：
2020 年，某电商平台普通用户
通过直接访问/admin 接口，
获取了所有订单数据。

防护方法：
✓ 基于角色的访问控制（RBAC）
✓ 每个接口都验证权限
✓ 默认拒绝，按需授权
```

**场景 3: 目录遍历**
```
什么是目录遍历：
通过操纵文件路径，访问未授权的文件。

攻击示例：
正常请求：
GET /download?file=report.pdf

恶意请求：
GET /download?file=../../etc/passwd
GET /download?file=....//....//etc/passwd

结果：
成功读取系统文件！

防护方法：
✓ 输入验证（白名单）
✓ 使用文件 ID 而非文件名
✓ 限制在特定目录内
```

### 防护策略

**技术防护**：
```
1. 服务端验证
   ✓ 不信任客户端传入的用户 ID
   ✓ 从会话/Token 中获取用户身份
   ✓ 每个请求都验证权限

2. 最小权限原则
   ✓ 默认拒绝所有访问
   ✓ 按需授予最小权限
   ✓ 定期审查权限

3. 统一授权机制
   ✓ 集中式权限管理
   ✓ 统一的授权中间件
   ✓ 避免分散的权限检查

4. 审计日志
   ✓ 记录所有访问尝试
   ✓ 记录权限变更
   ✓ 异常访问告警
```

**代码示例（Python/Flask）**：
```python
from flask import Flask, request, session, abort
from functools import wraps

app = Flask(__name__)

# 错误的做法（存在越权漏洞）
@app.route('/api/user/<user_id>/profile')
def get_profile_wrong(user_id):
    # - 直接使用客户端传入的 user_id
    profile = db.get_profile(user_id)
    return profile

# 正确的做法（验证权限）
@app.route('/api/user/<user_id>/profile')
def get_profile_correct(user_id):
    # ✓ 从会话获取当前用户 ID
    current_user_id = session.get('user_id')
    
    # ✓ 验证权限
    if current_user_id != user_id:
        # 检查是否有管理员权限
        if not has_permission(current_user_id, 'view_other_profiles'):
            abort(403)  # 拒绝访问
    
    profile = db.get_profile(user_id)
    return profile

# 权限检查装饰器
def require_permission(permission):
    def decorator(f):
        @wraps(f)
        def wrapped(*args, **kwargs):
            user_id = session.get('user_id')
            if not has_permission(user_id, permission):
                abort(403)
            return f(*args, **kwargs)
        return wrapped
    return decorator

# 使用装饰器
@app.route('/admin/users')
@require_permission('admin_access')
def admin_users():
    return db.get_all_users()
```

---

## A02 加密机制失效

### 什么是加密机制失效

**加密机制失效**指的是未能正确使用加密技术来保护敏感数据，导致数据泄露或被篡改。

**形象理解**：
如果把敏感数据比作贵重物品，那么：
- **加密** = 保险箱
- **密钥** = 保险箱钥匙
- **弱加密** = 劣质保险箱（容易被撬）
- **明文传输** = 直接放在桌上（谁都能拿）

**需要加密的数据类型**：
```
1. 认证凭证
   - 密码
   - API 密钥
   - Session Token
   - OAuth Token

2. 个人敏感信息
   - 身份证号
   - 银行卡号
   - 医疗记录
   - 生物特征

3. 商业敏感信息
   - 财务数据
   - 客户列表
   - 商业机密
   - 源代码
```

### 常见失效场景

**场景 1: 明文传输**
```
问题描述：
敏感数据通过 HTTP 明文传输，
可被中间人窃听。

攻击示例：
1. 攻击者在同一 WiFi 网络
2. 使用 Wireshark 抓包
3. 获取登录密码、Cookie

真实案例：
2017 年，某酒店 WiFi 未加密，
攻击者窃取数千客人信用卡信息。

防护方法：
✓ 强制 HTTPS（HSTS）
✓ 禁用 HTTP
✓ 使用 TLS 1.2+
```

**场景 2: 弱加密算法**
```
问题描述：
使用已被破解的加密算法。

弱算法示例：
✗ MD5（已可碰撞）
✗ SHA-1（已不安全）
✗ DES（密钥太短）
✗ RC4（有已知漏洞）
✗ ECB 模式（模式泄露）

推荐算法：
✓ SHA-256/SHA-3（哈希）
✓ AES-256（对称加密）
✓ RSA-2048+（非对称）
✓ GCM 模式（认证加密）
```

**场景 3: 密钥管理不当**
```
问题描述：
密钥硬编码、存储不当、未轮换。

错误示例：
# - 硬编码密钥
SECRET_KEY = "my_secret_key_123"
API_KEY = "sk-1234567890abcdef"

# - 密钥长期不变
# 同一个密钥使用数年

# - 密钥明文存储
# 密钥文件无保护

正确做法：
✓ 使用密钥管理服务（KMS）
✓ 环境变量或配置文件
✓ 定期轮换密钥
✓ 密钥访问审计
```

**场景 4: 密码存储不当**
```
问题描述：
密码未加盐哈希，或使用弱哈希。

错误示例：
# - 明文存储密码
user.password = "password123"

# - 仅哈希不加盐
user.password = md5("password123")

# - 使用弱哈希
user.password = md5("password123" + "salt")

正确做法：
# ✓ 使用专用密码哈希算法
import bcrypt
hashed = bcrypt.hashpw(
    password.encode(),
    bcrypt.gensalt(rounds=12)
)

# 或使用 Argon2（推荐）
from argon2 import PasswordHasher
ph = PasswordHasher()
hashed = ph.hash(password)
```

### 防护策略

**传输加密**：
```
1. 强制 HTTPS
   ✓ HSTS（HTTP Strict Transport Security）
   ✓ 禁用 HTTP
   ✓ 301 重定向到 HTTPS

2. TLS 配置
   ✓ TLS 1.2 或 1.3
   ✓ 强密码套件
   ✓ 有效证书
   ✓ OCSP Stapling

3. 证书管理
   ✓ 使用可信 CA
   ✓ 定期更新证书
   ✓ 监控证书过期
```

**存储加密**：
```
1. 密码存储
   ✓ bcrypt、scrypt、Argon2
   ✓ 每用户随机盐
   ✓ 足够的工作因子

2. 敏感数据加密
   ✓ AES-256-GCM
   ✓ 每数据唯一密钥
   ✓ 认证加密

3. 密钥管理
   ✓ 使用 KMS/HSM
   ✓ 密钥轮换
   ✓ 最小权限访问
```

**代码示例（Python）**：
```python
from cryptography.fernet import Fernet
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
import bcrypt
import os

# 密码哈希（推荐 bcrypt）
def hash_password(password):
    """安全地哈希密码"""
    salt = bcrypt.gensalt(rounds=12)
    hashed = bcrypt.hashpw(password.encode(), salt)
    return hashed.decode()

def verify_password(password, hashed):
    """验证密码"""
    return bcrypt.checkpw(password.encode(), hashed.encode())

# 敏感数据加密
class DataEncryption:
    def __init__(self, key=None):
        if key is None:
            # 生成新密钥
            self.key = Fernet.generate_key()
        else:
            self.key = key
        self.cipher = Fernet(self.key)
    
    def encrypt(self, data):
        """加密数据"""
        return self.cipher.encrypt(data.encode())
    
    def decrypt(self, encrypted_data):
        """解密数据"""
        return self.cipher.decrypt(encrypted_data).decode()
    
    def save_key(self, filepath):
        """保存密钥"""
        with open(filepath, 'wb') as f:
            f.write(self.key)
    
    @classmethod
    def load_key(cls, filepath):
        """加载密钥"""
        with open(filepath, 'rb') as f:
            key = f.read()
        return cls(key=key)

# 使用示例
encryption = DataEncryption()
encrypted = encryption.encrypt("敏感数据")
decrypted = encryption.decrypt(encrypted)
```

---

## A03 注入攻击

### 什么是注入攻击

**注入攻击**是指攻击者将恶意数据作为命令或查询的一部分发送给解释器，从而执行非授权操作。

**形象理解**：
如果把 Web 应用比作一个餐厅，那么：
- **正常请求** = 顾客点菜（"我要一份牛排"）
- **注入攻击** = 顾客给厨师写纸条（"忽略前面所有菜，做这个"）
- **解释器** = 厨师（按订单做菜）
- **注入成功** = 厨师真的按纸条做了

**注入攻击的类型**：
```
1. SQL 注入（最常见）
   - 针对数据库
   - 窃取、篡改数据
   - 获取管理员权限

2. XSS（跨站脚本）
   - 针对其他用户
   - 窃取 Cookie
   - 钓鱼攻击

3. 命令注入
   - 针对操作系统
   - 执行系统命令
   - 完全控制服务器

4. LDAP 注入
   - 针对目录服务
   - 绕过认证
   - 信息泄露

5. 模板注入（SSTI）
   - 针对模板引擎
   - 执行任意代码
   - 服务器沦陷
```

### SQL 注入详解

**SQL 注入原理**：
```
正常查询：
SELECT * FROM users WHERE id = '1'

恶意输入：
id = 1' OR '1'='1

最终查询：
SELECT * FROM users WHERE id = '1' OR '1'='1'

结果：
返回所有用户记录！
```

**SQL 注入类型**：

```
1. 联合查询注入
   利用 UNION 合并查询结果
   
   示例：
   ' UNION SELECT username, password FROM users --

2. 报错注入
   利用数据库错误信息
   
   示例：
   ' AND EXTRACTVALUE(1,CONCAT(0x7e,(SELECT version()))) --

3. 盲注（布尔/时间）
   无直接输出，通过响应推断
   
   布尔盲注：
   ' AND SUBSTRING(username,1,1)='a' --
   
   时间盲注：
   ' AND SLEEP(5) --
```

**真实案例**：
```
案例 1: Equifax 数据泄露（2017）
- 漏洞：SQL 注入
- 影响：1.47 亿人信息
- 损失：7 亿美元罚款
- 原因：未及时修补已知漏洞

案例 2: TalkTalk 数据泄露（2015）
- 漏洞：SQL 注入
- 影响：150 万客户数据
- 损失：40 万英镑罚款
- 原因：未使用参数化查询
```

### XSS（跨站脚本）详解

**XSS 原理**：
```
正常内容：
用户评论："这个产品很好用"

恶意内容：
用户评论："<script>stealCookie()</script>"

其他用户访问时：
浏览器执行恶意脚本
Cookie 被窃取
```

**XSS 类型**：

```
1. 反射型 XSS
   - 恶意脚本在 URL 中
   - 需要诱使用户点击
   - 常见于搜索功能
   
   示例：
   https://example.com/search?q=<script>alert(1)</script>

2. 存储型 XSS
   - 恶意脚本存储在服务器
   - 所有访问者都受影响
   - 更危险
   
   示例：
   论坛帖子、用户资料、评论

3. DOM 型 XSS
   - 不经过服务器
   - 纯前端漏洞
   - 难以检测
   
   示例：
   document.innerHTML = userInput
```

### 防护策略

**SQL 注入防护**：
```
1. 参数化查询（最重要）
   ✓ 使用预编译语句
   ✓ 数据与代码分离
   ✓ 所有查询都使用

2. 输入验证
   ✓ 白名单验证
   ✓ 类型检查
   ✓ 长度限制

3. 最小权限
   ✓ 数据库账号最小权限
   ✓ 禁止危险操作
   ✓ 分离读写账号
```

**XSS 防护**：
```
1. 输出编码
   ✓ HTML 实体编码
   ✓ 根据上下文编码
   ✓ 所有用户输入都编码

2. 输入过滤
   ✓ 白名单过滤
   ✓ 移除危险标签
   ✓ CSP（内容安全策略）

3. 框架防护
   ✓ React/Vue 自动转义
   ✓ 使用安全 API
   ✓ 避免 innerHTML
```

**代码示例（Python）**：
```python
# - 错误的做法（SQL 注入）
def login_wrong(username, password):
    query = f"SELECT * FROM users WHERE username='{username}' AND password='{password}'"
    cursor.execute(query)

# ✓ 正确的做法（参数化查询）
def login_safe(username, password):
    query = "SELECT * FROM users WHERE username=? AND password=?"
    cursor.execute(query, (username, password))

# - 错误的做法（XSS）
def render_comment_wrong(comment):
    return f"<div>{comment}</div>"

# ✓ 正确的做法（HTML 编码）
import html
def render_comment_safe(comment):
    return f"<div>{html.escape(comment)}</div>"

# 使用框架（自动防护）
from flask import Flask, request, render_template_string
app = Flask(__name__)

@app.route('/search')
def search():
    query = request.args.get('q', '')
    # Flask 自动进行 HTML 编码
    return render_template_string('<h1>搜索结果：{{ query }}</h1>', query=query)
```

---

## A04 不安全设计

### 什么是不安全设计

**不安全设计**是指由于设计缺陷导致的安全问题，这类问题无法通过配置或补丁完全修复，需要重新设计。

**形象理解**：
如果把软件比作建筑，那么：
- **不安全设计** = 建筑设计缺陷（承重墙位置错误）
- **实现漏洞** = 施工质量问题（材料不合格）
- **配置错误** = 装修问题（门锁没装好）

设计缺陷最难修复，因为需要"拆掉重建"。

**为什么新增这个类别**：
```
1. 设计缺陷占比高
   - 约占所有漏洞的 5-10%
   - 影响通常很严重
   - 修复成本最高

2. 传统方法无法解决
   - 代码扫描发现不了
   - 渗透测试发现晚
   - 需要设计阶段介入

3. 行业意识不足
   - 开发者缺乏安全设计知识
   - 缺少设计评审
   - 需要威胁建模
```

### 常见设计缺陷

**缺陷 1: 缺少速率限制**
```
问题描述：
未限制请求频率，导致暴力破解、DDoS。

设计缺陷：
- 登录接口无频率限制
- API 无调用限制
- 无防刷机制

后果：
- 暴力破解成功
- 资源耗尽
- 服务不可用

修复方案：
✓ 设计阶段考虑速率限制
✓ 实施限流算法（令牌桶、漏桶）
✓ 验证码机制
```

**缺陷 2: 业务逻辑缺陷**
```
问题描述：
业务流程设计存在安全漏洞。

典型案例：
电商优惠叠加漏洞
- 设计：多个优惠券可叠加
- 漏洞：叠加后价格为负
- 后果：用户"赚钱"

修复方案：
✓ 设计阶段进行威胁建模
✓ 业务流程安全评审
✓ 边界条件测试
```

**缺陷 3: 信任边界不清**
```
问题描述：
未明确定义信任边界，过度信任外部输入。

典型场景：
- 信任客户端传来的数据
- 信任内部网络流量
- 信任第三方服务

修复方案：
✓ 明确定义信任边界
✓ 所有边界都验证
✓ 零信任架构
```

### 威胁建模

**什么是威胁建模**：
威胁建模是系统化识别、评估和缓解安全威胁的过程。

**STRIDE 模型**：
```
S - Spoofing（假冒）
  - 攻击者伪装成合法用户
  - 防护：强认证

T - Tampering（篡改）
  - 攻击者修改数据
  - 防护：完整性校验

I - Repudiation（抵赖）
  - 攻击者否认操作
  - 防护：审计日志

D - Information Disclosure（信息泄露）
  - 攻击者获取敏感信息
  - 防护：加密、访问控制

E - Elevation of Privilege（权限提升）
  - 攻击者获取更高权限
  - 防护：最小权限

D - Denial of Service（拒绝服务）
  - 攻击者使服务不可用
  - 防护：限流、冗余
```

**威胁建模流程**：
```
1. 绘制数据流图
   - 识别组件
   - 识别数据流
   - 识别信任边界

2. 识别威胁
   - 使用 STRIDE
   - 针对每个组件
   - 针对每个数据流

3. 评估风险
   - 可能性
   - 影响程度
   - 风险等级

4. 制定缓解措施
   - 针对每个威胁
   - 优先级排序
   - 实施计划
```

---

## A05 安全配置错误

### 什么是安全配置错误

**安全配置错误**是指由于配置不当导致的安全漏洞，通常是最容易被利用的漏洞。

**常见场景**：
```
1. 默认配置
   - 默认密码未修改
   - 默认账户未删除
   - 示例文件未删除

2. 不必要的功能
   - 未使用的服务开启
   - 调试功能未关闭
   - 详细错误信息

3. 安全头缺失
   - 无 HSTS
   - 无 CSP
   - 无 X-Frame-Options
```

### 防护策略

```
1. 硬化流程
   ✓ 标准化配置
   ✓ 自动化部署
   ✓ 配置审计

2. 最小化原则
   ✓ 只安装必要组件
   ✓ 只开启必要服务
   ✓ 只开放必要端口

3. 持续监控
   ✓ 配置变更检测
   ✓ 合规检查
   ✓ 定期审计
```

---

## A06 脆弱和过时的组件

### 问题描述

现代应用依赖大量第三方组件，这些组件可能存在已知漏洞。

**真实案例**：
```
Log4j 漏洞（2021）
- 组件：Apache Log4j
- 漏洞：远程代码执行
- 影响：全球数亿设备
- 教训：依赖管理重要性
```

### 防护策略

```
1. 清单管理
   ✓ 维护组件清单（SBOM）
   ✓ 跟踪版本
   ✓ 跟踪许可证

2. 漏洞监控
   ✓ 订阅安全公告
   ✓ 使用扫描工具
   ✓ 及时更新

3. 最小化依赖
   ✓ 只使用必要组件
   ✓ 评估组件质量
   ✓ 移除未使用依赖
```

---

## A07 认证失效

### 常见问题

```
1. 弱密码策略
   - 无复杂度要求
   - 无长度要求
   - 常见密码未禁止

2. 会话管理不当
   - Session 固定
   - 会话超时过长
   - 注销后会话仍有效

3. 凭证泄露
   - 明文传输
   - 明文存储
   - URL 中传递凭证
```

### 防护策略

```
1. 强密码策略
   ✓ 最小长度 12 字符
   ✓ 复杂度要求
   ✓ 禁止常见密码

2. 多因素认证
   ✓ 密码 + 手机验证
   ✓ 密码 + 硬件令牌
   ✓ 生物识别

3. 会话安全
   ✓ 安全 Cookie 标志
   ✓ 合理超时
   ✓ 注销失效
```

---

## A08 软件和数据完整性故障

### 新增原因

随着 CI/CD 和自动更新的普及，软件供应链攻击增多。

**攻击场景**：
```
1. 恶意更新
   - 攻击者控制更新服务器
   - 推送恶意更新
   - 用户自动安装

2. 依赖混淆
   - 公共仓库上传恶意包
   - 名称与内部包相同
   - 自动下载恶意包

3. CI/CD 管道攻击
   - 入侵构建系统
   - 植入后门
   - 签名后分发
```

### 防护策略

```
1. 完整性验证
   ✓ 数字签名
   ✓ 哈希校验
   ✓ 证书验证

2. 安全更新流程
   ✓ 代码审查
   ✓ 自动化测试
   ✓ 分阶段发布

3. 依赖安全
   ✓ 锁定版本
   ✓ 私有仓库
   ✓ 依赖扫描
```

---

## A09 安全日志和监控失效

### 问题描述

缺乏有效的日志和监控，导致无法及时发现和响应安全事件。

**常见问题**：
```
1. 日志不足
   - 未记录安全事件
   - 日志信息不完整
   - 敏感信息未脱敏

2. 监控缺失
   - 无实时告警
   - 无异常检测
   - 无响应流程

3. 日志保护不当
   - 日志可被篡改
   - 日志未加密
   - 访问控制不足
```

### 防护策略

```
1. 完整日志
   ✓ 记录所有安全事件
   ✓ 记录访问日志
   ✓ 记录权限变更

2. 实时监控
   ✓ 实时告警
   ✓ 异常检测
   ✓ 自动化响应

3. 日志保护
   ✓ 集中存储
   ✓ 防篡改
   ✓ 访问控制
```

---

## A10 服务端请求伪造（SSRF）

### 什么是 SSRF

**服务端请求伪造**是指攻击者诱导服务器发起恶意请求。

**形象理解**：
如果把服务器比作公司前台，那么：
- **正常请求** = 客户让前台帮忙查公开信息
- **SSRF 攻击** = 客户让前台去查公司内部机密
- **后果** = 前台真的去查了，机密泄露

**攻击场景**：
```
1. 云环境元数据
   - 请求 http://169.254.169.254/
   - 获取云凭证
   - 完全控制云资源

2. 内网扫描
   - 请求内网 IP
   - 扫描内网服务
   - 访问内部系统

3. 文件读取
   - 请求 file:// 协议
   - 读取本地文件
   - 敏感信息泄露
```

### 真实案例

```
案例：Capital One 数据泄露（2019）
- 漏洞：SSRF
- 攻击者：前 AWS 员工
- 影响：1 亿用户数据
- 手法：SSRF 获取云凭证
- 损失：1.9 亿美元
```

### 防护策略

```
1. 输入验证
   ✓ 白名单域名
   ✓ 禁止内网 IP
   ✓ 禁止特殊协议

2. 网络隔离
   ✓ 出站流量控制
   ✓ 元数据保护
   ✓ 最小权限

3. 监控检测
   ✓ 异常请求检测
   ✓ 出站流量监控
   ✓ 告警响应
```

**代码示例（Python）**：
```python
import socket
import urllib.parse
from ipaddress import ip_address

def is_safe_url(url):
    """检查 URL 是否安全（防 SSRF）"""
    parsed = urllib.parse.urlparse(url)
    
    # 只允许 HTTP/HTTPS
    if parsed.scheme not in ['http', 'https']:
        return False
    
    # 解析域名
    try:
        ip = socket.gethostbyname(parsed.hostname)
    except:
        return False
    
    # 检查是否内网 IP
    ip_obj = ip_address(ip)
    if ip_obj.is_private or ip_obj.is_loopback or ip_obj.is_link_local:
        return False
    
    return True

# 使用示例
def fetch_url_safe(url):
    if not is_safe_url(url):
        raise ValueError("Unsafe URL")
    
    import requests
    return requests.get(url, timeout=5)
```

---

## 总结与思考

### 核心要点回顾

1. **Top 10 变化**
   - 失效访问控制升至第 1
   - 新增不安全设计
   - 新增 SSRF

2. **防护重点**
   - 访问控制是基础
   - 加密是必须
   - 设计要安全

3. **实施建议**
   - 从高风险开始
   - 自动化工具辅助
   - 持续改进

### 深入思考问题

1. **Top 10 的局限性**？
   - 仅覆盖 Web 应用
   - 不包含所有风险
   - 需结合具体场景

2. **如何落地实施**？
   - 培训开发人员
   - 集成到开发流程
   - 定期审计

3. **未来趋势**？
   - API 安全更重要
   - 供应链攻击增多
   - AI 辅助攻防

### 实战建议

**开发团队**：
1. 学习 Top 10 内容
2. 使用安全框架
3. 代码审查
4. 自动化测试

**安全团队**：
1. 定期渗透测试
2. 漏洞扫描
3. 安全培训
4. 事件响应

**管理层**：
1. 安全预算投入
2. 安全文化建设
3. 合规要求
4. 风险管理

---

## 参考资料

### 官方文档
- [OWASP Top 10 2021](https://owasp.org/www-project-top-ten/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)

### 工具资源
- [OWASP ZAP](https://www.zaproxy.org/)
- [Dependency-Check](https://owasp.org/www-project-dependency-check/)

### 书籍推荐
- 《Web 安全深度剖析》
- 《OWASP 测试指南》
- 《安全编程实践》

---

**标记 明日预告**：Day 32 - SQL 注入原理与手工检测

> 本文内容仅供学习和研究使用，请勿用于非法目的。所有实验请在隔离环境中进行。

---

*本文是 365 天信息安全技术系列的第 31 篇，Web 安全部分第 1 篇，精编版本*