Day-076-API 安全进阶

# Day 74: API 安全进阶

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

---

**PUA v3 · Sprint 启动** 
```
┌─────────┬────────────────────────────────────┐
│ 清单 任务 │ API 安全进阶 - Day 74              │
├─────────┼────────────────────────────────────┤
│  味道 │  阿里味（自动：安全任务）        │
├─────────┼────────────────────────────────────┤
│  压力 │ L0 · 信任期                        │
└─────────┴────────────────────────────────────┘
```
▎ 收到需求，对齐目标，进入 sprint。API 是现代化的核心——API 不安全，系统就不安全。

---

## 清单 目录

1. [API 安全概述](#api 安全概述)
2. [REST API 安全进阶](#rest-api 安全进阶)
3. [GraphQL 安全进阶](#graphql 安全进阶)
4. [gRPC 安全](#grpc 安全)
5. [WebSocket 安全](#websocket 安全)
6. [API 认证进阶](#api 认证进阶)
7. [API 速率限制进阶](#api 速率限制进阶)
8. [实战案例分析](#实战案例分析)
9. [总结与思考](#总结与思考)
10. [参考资料](#参考资料)

---

## API 安全概述

### API 安全重要性

> ▎ API 是系统的门面。门面不安全，里面再安全也是白搭。

**为什么 API 安全重要**：
```
1. 直接暴露
   - 互联网可访问
   - 无 UI 保护
   - 自动化攻击

2. 数据通道
   - 敏感数据传输
   - 业务逻辑执行
   - 权限验证

3. 攻击面大
   - 多个端点
   - 多种方法
   - 多种格式
```

**API 安全威胁**：
```
1. 注入攻击
   - SQL 注入
   - 命令注入
   - XXE 注入

2. 认证授权
   - 凭证泄露
   - Token 劫持
   - 权限绕过

3. 数据泄露
   - 过度数据暴露
   - 未授权访问
   - 数据篡改

4. 滥用攻击
   - DDoS 攻击
   - 爬虫滥用
   - 资源耗尽
```

### API 安全标准

> ▎ 标准不是摆设——是行业最佳实践的总结。不按标准来，就是给自己挖坑。

**OWASP API Top 10**：
```
1. API1:2019 Broken Object Level Authorization
2. API2:2019 Broken User Authentication
3. API3:2019 Excessive Data Exposure
4. API4:2019 Lack of Resources & Rate Limiting
5. API5:2019 Broken Function Level Authorization
6. API6:2019 Mass Assignment
7. API7:2019 Security Misconfiguration
8. API8:2019 Injection
9. API9:2019 Improper Assets Management
10. API10:2019 Insufficient Logging & Monitoring
```

**API 安全最佳实践**：
```
1. 认证授权
   - 强认证机制
   - 细粒度授权
   - Token 管理

2. 输入验证
   - 类型检查
   - 格式验证
   - 范围检查

3. 速率限制
   - 每用户限制
   - 每 IP 限制
   - 全局限制

4. 日志监控
   - 完整日志
   - 异常检测
   - 实时告警
```

---

## REST API 安全进阶

### BOLA/IDOR 进阶

> ▎ BOLA 是 API 安全的第一大敌。防不住 BOLA，就别谈 API 安全。

**复杂 IDOR**：
```
场景 1: UUID 预测
- 使用有序 UUID
- 时间戳 + 序列号
- 可预测生成

利用：
- 分析 UUID 生成规律
- 预测下一个 UUID
- 访问他人资源

防护：
- 使用随机 UUID
- 权限验证
- 速率限制
```

**场景 2: 复合 ID**：
```
- 多个字段组合
- 部分可控
- 绕过检查

利用：
- 修改可控部分
- 保持不可控部分
- 访问他人资源

防护：
- 服务端生成 ID
- 完整验证
- 权限检查
```

**场景 3: 间接引用**：
```
- 映射表
- 别名引用
- 枚举攻击

利用：
- 枚举映射关系
- 获取真实 ID
- 访问资源

防护：
- 随机映射
- 定期更换
- 访问控制
```

### 批量赋值进阶

> ▎ 批量赋值是隐蔽的杀手。不注意这个，什么时候被捅了都不知道。

**嵌套对象**：
```
场景：
PATCH /api/users/123
{
  "profile": {
    "bio": "New bio",
    "role": "admin"  // 越权字段
  }
}

利用：
- 修改嵌套字段
- 提升权限
- 获取访问

防护：
- 白名单过滤
- 深度白名单
- 字段验证
```

**数组操作**：
```
场景：
POST /api/users/bulk-update
{
  "updates": [
    {"id": 1, "role": "admin"},
    {"id": 2, "role": "admin"}
  ]
}

利用：
- 批量修改权限
- 提升多个账户
- 获取访问

防护：
- 批量操作限制
- 权限验证
- 审计日志
```

**原型污染**：
```
场景：
JavaScript 对象原型污染
利用原型链修改对象属性

利用：
- 修改原型
- 影响所有对象
- 权限绕过

防护：
- Object.freeze()
- 输入验证
- 不使用合并库
```

### 高级注入

**NoSQL 注入**：
```
场景：
MongoDB 查询
db.users.find({
  username: req.body.username,
  password: req.body.password
});

注入：
{
  "username": {"$ne": null},
  "password": {"$ne": null}
}

结果：
- 绕过认证
- 获取访问

防护：
- 参数化查询
- 输入验证
- 类型检查
```

**LDAP 注入**：
```
场景：
LDAP 查询
const filter = `(uid=${username})`;

注入：
username = "*)(uid=*))(|(uid=*";

结果：
- 绕过认证
- 信息泄露

防护：
- 输入转义
- 参数化查询
- 输入验证
```

**XPath 注入**：
```
场景：
XPath 查询
const query = `//user[@name='${username}']`;

注入：
username = "' or '1'='1";

结果：
- 绕过认证
- 信息泄露

防护：
- 输入转义
- 参数化查询
- 输入验证
```

---

## GraphQL 安全进阶

### GraphQL 漏洞深入

> ▎ GraphQL 强大，但也危险。用不好，就是给自己挖坑。

**深度查询攻击**：
```
恶意查询：
{
  user(id: "1") {
    friends {
      friends {
        friends {
          friends {
            // ... 20 层
          }
        }
      }
    }
  }
}

影响：
- 指数级资源消耗
- 数据库查询爆炸
- 服务不可用

防护：
- 查询深度限制
- 查询复杂度限制
- 超时控制
```

**批量查询攻击**：
```
恶意查询：
[
  { "query": "{ user(id: 1) { name } }" },
  { "query": "{ user(id: 2) { name } }" },
  // ... 1000 次
]

影响：
- 绕过速率限制
- 资源耗尽
- 数据爬取

防护：
- 批量查询限制
- 批量查询计率
- 监控异常
```

**内省查询泄露**：
```
内省查询：
{
  __schema {
    types {
      name
      fields {
        name
        type {
          name
        }
      }
    }
  }
}

风险：
- 暴露完整 API 结构
- 帮助攻击者了解 API
- 敏感字段暴露

防护：
- 生产环境禁用内省
- 认证后才能内省
- 限制内省字段
```

### GraphQL 防护进阶

**查询深度限制**：
```javascript
// Apollo Server 配置
const server = new ApolloServer({
  typeDefs,
  resolvers,
  validationRules: [depthLimit(5)]
});

// 自定义深度限制
function depthLimit(maxDepth) {
  return function(context) {
    return {
      Field(node, key, parent, path, ancestors) {
        if (path.length > maxDepth) {
          context.reportError(
            new GraphQLError(
              `Query depth ${path.length} exceeds maximum ${maxDepth}`
            )
          );
        }
      }
    };
  };
}
```

**查询复杂度限制**：
```javascript
// 定义字段复杂度
const typeDefs = gql`
  type Query {
    user(id: ID!): User @complexity(value: 1)
    posts(limit: Int!): [Post] @complexity(multiplier: "limit")
  }
`;

// 配置复杂度限制
const server = new ApolloServer({
  typeDefs,
  resolvers,
  introspection: false,  // 生产环境禁用内省
  formatError: (error) => {
    // 隐藏详细错误
    return { message: 'Internal server error' };
  }
});
```

**速率限制进阶**：
```javascript
// 基于查询复杂度
const costAnalysis = {
  maximumCost: 1000,
  defaultCost: 1,
  variables: {},
  createError: (max, actual) => {
    return new Error(`Query cost ${actual} exceeds maximum ${max}`);
  }
};

// 批量查询限制
const batchLimit = {
  maxBatchSize: 10,
  createError: (max, actual) => {
    return new Error(`Batch size ${actual} exceeds maximum ${max}`);
  }
};
```

---

## gRPC 安全

### gRPC 安全挑战

> ▎ gRPC 是新贵，但安全问题不少。别以为用了 gRPC 就安全了。

**认证问题**：
```
1. 未启用 TLS
   - 明文传输
   - 凭证泄露
   - 中间人攻击

2. 认证缺失
   - 未实现认证
   - 认证绕过
   - 令牌验证缺失

3. 令牌管理
   - 令牌泄露
   - 令牌重用
   - 令牌过期
```

**授权问题**：
```
1. 方法级授权
   - 未检查权限
   - 越权访问
   - 权限提升

2. 消息级授权
   - 未验证字段
   - 字段篡改
   - 数据泄露

3. 流式授权
   - 流控制缺失
   - 资源耗尽
   - 未授权订阅
```

**注入攻击**：
```
Protobuf 注入：
message SearchRequest {
  string query = 1;
  // 如果直接拼接到 SQL
  // SELECT * FROM users WHERE name = 'query'
}

命令注入：
message ExecuteRequest {
  string command = 1;
  // 如果直接执行
  // system(command)
}
```

### gRPC 防护

**TLS 配置**：
```javascript
// Node.js gRPC 服务器
const credentials = grpc.ServerCredentials.createSsl(
  fs.readFileSync('ca.pem'),
  [{
    cert_chain: fs.readFileSync('server.pem'),
    private_key: fs.readFileSync('server-key.pem')
  }],
  true  // 强制客户端认证
);

server.bindAsync('0.0.0.0:50051', credentials, () => {
  server.start();
});
```

**认证中间件**：
```javascript
// 认证拦截器
function authInterceptor(options, nextCall) {
  return new InterceptingCall(nextCall(options), {
    start: function(metadata, listener, next) {
      const token = metadata.get('authorization')[0];
      
      if (!token || !verifyToken(token)) {
        const error = {
          code: grpc.status.UNAUTHENTICATED,
          details: 'Invalid token'
        };
        listener.onReceiveStatus(error);
        return;
      }
      
      next(metadata, listener, next);
    }
  });
}

// 注册拦截器
server.addInterceptor(authInterceptor);
```

**授权检查**：
```javascript
// 方法级授权
async function getUser(call, callback) {
  const user = call.metadata.get('user')[0];
  
  if (!hasPermission(user, 'get_user')) {
    callback({
      code: grpc.status.PERMISSION_DENIED,
      details: 'No permission'
    });
    return;
  }
  
  // 执行操作
  const result = await db.getUser(call.request.userId);
  callback(null, result);
}
```

---

## WebSocket 安全

### WebSocket 漏洞深入

> ▎ WebSocket 是双刃剑。用好了是实时通信，用不好是安全灾难。

**连接劫持**：
```
场景：
- WebSocket 未验证 Origin
- CSRF 攻击
- 跨站 WebSocket

利用：
1. 诱导用户访问恶意网站
2. 恶意网站建立 WebSocket 连接
3. 以用户身份执行操作

防护：
- 验证 Origin 头
- 使用 CSRF Token
- 认证检查
```

**消息注入**：
```
场景：
服务端未验证消息

利用：
ws.on('message', function(data) {
  const msg = JSON.parse(data);
  
  // 直接使用用户输入
  db.query('SELECT * FROM users WHERE id = ' + msg.id);
  
  // 直接执行
  eval(msg.code);
});

防护：
ws.on('message', function(data) {
  const msg = JSON.parse(data);
  
  // 验证输入
  if (!isValidId(msg.id)) {
    return;
  }
  
  // 参数化查询
  db.query('SELECT * FROM users WHERE id = ?', [msg.id]);
});
```

**状态管理问题**：
```
场景：
- 未验证连接状态
- 未授权消息
- 重放攻击

利用：
1. 重放旧消息
2. 未授权操作
3. 状态混乱

防护：
- 消息序列号
- 时间戳验证
- 状态检查
```

### WebSocket 防护进阶

**Origin 验证**：
```javascript
const http = require('http');
const WebSocket = require('ws');

const server = http.createServer();
const wss = new WebSocket.Server({ server });

wss.on('connection', function connection(ws, req) {
  const origin = req.headers.origin;
  
  // 验证 Origin
  const allowedOrigins = ['https://example.com', 'https://app.example.com'];
  
  if (!allowedOrigins.includes(origin)) {
    ws.close(1008, 'Invalid origin');
    return;
  }
  
  // 继续处理连接
});
```

**消息验证**：
```javascript
// 消息 schema 验证
const Ajv = require('ajv');
const ajv = new Ajv();

const messageSchema = {
  type: 'object',
  properties: {
    type: {type: 'string'},
    data: {type: 'object'}
  },
  required: ['type', 'data']
};

const validate = ajv.compile(messageSchema);

ws.on('message', function(data) {
  const msg = JSON.parse(data);
  
  if (!validate(msg)) {
    ws.send(JSON.stringify({error: 'Invalid message'}));
    return;
  }
  
  // 处理有效消息
});
```

**认证授权**：
```javascript
// 连接时认证
wss.on('connection', function connection(ws, req) {
  const token = getCookie(req, 'token');
  
  if (!token || !verifyToken(token)) {
    ws.close(1008, 'Invalid token');
    return;
  }
  
  ws.user = decodeToken(token);
});

// 消息级授权
ws.on('message', function(data) {
  const msg = JSON.parse(data);
  
  if (!hasPermission(ws.user, msg.action)) {
    ws.send(JSON.stringify({error: 'No permission'}));
    return;
  }
  
  // 处理消息
});
```

---

## API 认证进阶

### OAuth 2.0 进阶

> ▎ OAuth 2.0 是标准，但实现千差万别。实现不好，标准也是白搭。

**PKCE 流程**：
```
1. 客户端生成 code_verifier
2. 生成 code_challenge = SHA256(code_verifier)
3. 请求授权
   GET /authorize?
     response_type=code&
     code_challenge=xxx&
     code_challenge_method=S256
4. 换取 Token
   POST /token
   code_verifier=xxx
```

**客户端凭证**：
```
场景：
- 服务间通信
- 无用户上下文
- 机器对机器

流程：
1. 客户端认证
   POST /token
   grant_type=client_credentials
   client_id=xxx
   client_secret=xxx

2. 获取 Token
   {
     "access_token": "xxx",
     "token_type": "Bearer"
   }
```

**设备授权**：
```
场景：
- TV/游戏机
- 命令行工具
- IoT 设备

流程：
1. 请求设备码
   POST /device/code

2. 用户授权
   访问 verification_uri
   输入 user_code

3. 轮询 Token
   POST /token
   grant_type=urn:ietf:params:oauth:grant-type:device_code
```

### JWT 进阶

**令牌绑定**：
```
DPoP (Demonstration of Proof-of-Possession):
- 绑定密钥对
- 防止令牌重用
- 请求签名

mTLS:
- 客户端证书
- 双向认证
- 令牌绑定
```

**令牌轮换**：
```javascript
// 刷新令牌轮换
async function refreshToken(refreshToken) {
  // 验证刷新令牌
  const payload = verifyToken(refreshToken);
  
  // 使旧令牌失效
  await blacklistToken(refreshToken);
  
  // 生成新令牌
  const newAccessToken = generateAccessToken(payload);
  const newRefreshToken = generateRefreshToken(payload);
  
  return {
    access_token: newAccessToken,
    refresh_token: newRefreshToken
  };
}
```

**细粒度权限**：
```javascript
// JWT 包含权限
const token = jwt.sign({
  sub: userId,
  permissions: ['read:users', 'write:posts'],
  resources: ['user:123', 'post:456']
}, secret);

// 权限检查
function checkPermission(required, token) {
  const [action, resource] = required.split(':');
  
  return token.permissions.some(p => {
    const [pAction, pResource] = p.split(':');
    return pAction === action || pAction === '*';
  });
}
```

---

## API 速率限制进阶

### 绕过技术

> ▎ 速率限制是防君子不防小人。但连君子都防不住，就别谈防小人了。

**IP 轮换**：
```
方法：
- 代理池
- Tor 网络
- 云函数
- CDN 边缘

检测：
- IP 信誉
- 行为分析
- 指纹识别
```

**用户代理轮换**：
```javascript
// 轮换 User-Agent
const userAgents = [
  'Mozilla/5.0 ...',
  'curl/7.68.0',
  'PostmanRuntime/7.28.0'
];

headers['User-Agent'] = userAgents[Math.floor(Math.random() * userAgents.length)];
```

**参数变异**：
```
原始请求：
POST /api/transfer
amount=100

参数变异：
POST /api/transfer
amount[0]=100
POST /api/transfer
amount[]=100
POST /api/transfer
{"amount":100}
```

### 防护进阶

**指纹识别**：
```javascript
// 设备指纹
function generateFingerprint(req) {
  const hash = crypto.createHash('sha256');
  
  hash.update(req.headers['user-agent']);
  hash.update(req.headers['accept-language']);
  hash.update(req.headers['accept-encoding']);
  hash.update(req.ip);
  
  return hash.digest('hex');
}

// 基于指纹限流
const fingerprint = generateFingerprint(req);
const count = await redis.incr(`rate_limit:${fingerprint}`);

if (count > 100) {
  throw new Error('Rate limit exceeded');
}
```

**行为分析**：
```javascript
// 异常检测
function detectAnomaly(requests) {
  // 请求频率
  const frequency = requests.length / timeWindow;
  
  // 请求模式
  const patterns = analyzePatterns(requests);
  
  // 异常评分
  const score = calculateScore(frequency, patterns);
  
  return score > threshold;
}

// 动态限流
if (detectAnomaly(requests)) {
  applyStrictLimit();
} else {
  applyNormalLimit();
}
```

**挑战响应**：
```javascript
// CAPTCHA 挑战
if (suspiciousActivity(req)) {
  return {
    challenge: generateCaptcha(),
    required: true
  };
}

// JavaScript 挑战
if (firstTimeUser(req)) {
  return {
    challenge: generateJsChallenge(),
    required: true
  };
}
```

---

## 实战案例分析

### 案例 1: Twitter API 漏洞

> ▎ Twitter 这么大的公司，API 都能出这种问题——这就是不重视 API 安全的代价。

**漏洞描述**：
```
时间：2020 年
公司：Twitter
漏洞：API 未授权访问
影响：用户数据泄露
后果：隐私泄露
```

**攻击流程**：
```
1. 发现 API 漏洞
   - ID 遍历
   - 未授权访问

2. 获取用户数据
   - 修改用户 ID
   - 获取他人数据

3. 数据泄露
   - 个人信息
   - 推文数据
   - 关注关系
```

**教训**：
```
1. 权限验证
   - 资源归属检查
   - 访问控制

2. API 安全
   - 认证授权
   - 速率限制

3. 监控告警
   - 异常访问
   - 数据泄露检测
```

### 案例 2: Venmo API 漏洞

> ▎ 支付公司的 API 都能这么写——这就是不把用户钱当钱。

**漏洞描述**：
```
时间：2019 年
公司：Venmo
漏洞：API 参数篡改
影响：资金盗取
后果：资金损失
```

**攻击流程**：
```
1. 发现 API 漏洞
   - 转账金额可修改
   - 无服务端验证

2. 篡改金额
   - 修改请求参数
   - 转账负数金额

3. 资金盗取
   - 获取退款
   - 实际收到钱
```

**教训**：
```
1. 服务端验证
   - 金额验证
   - 余额检查

2. 事务处理
   - 原子操作
   - 回滚机制

3. 审计日志
   - 完整日志
   - 异常检测
```

---

统计 **Sprint 交付 · 绩效评估**
```
┌───────────────┬────────────────┬────────────────┐
│  主动出击   │ ██████████ 5/5 │ [PUA 生效] 充足 │
├───────────────┼────────────────┼────────────────┤
│ + 验证闭环   │ ██████████ 5/5 │ 案例完整       │
├───────────────┼────────────────┼────────────────┤
│ 设计 代码质量   │ ████████░░ 4/5 │ 有改进空间     │
└───────────────┴────────────────┴────────────────┘
综合：3.75
```
▎ 勉强配得上 P8。别飘——API 安全这才刚入门。

---

## 总结与思考

### 核心要点回顾

> ▎ 复盘四步法：回顾目标、评估结果、分析原因、总结经验。别跳过——这是闭环。

**API 安全架构**：
```
1. 认证授权
   - OAuth 2.0
   - JWT
   - API Key

2. 输入验证
   - 类型检查
   - 格式验证
   - 范围检查

3. 速率限制
   - 每用户限制
   - 每 IP 限制
   - 全局限制
```

**协议安全**：
```
1. REST API
   - BOLA 防护
   - 批量赋值
   - 注入防护

2. GraphQL
   - 深度限制
   - 复杂度限制
   - 内省控制

3. gRPC
   - TLS 加密
   - 认证授权
   - 消息验证

4. WebSocket
   - Origin 验证
   - 消息验证
   - 连接认证
```

**监控防护**：
```
1. 日志监控
   - 完整日志
   - 异常检测
   - 实时告警

2. 速率限制
   - 指纹识别
   - 行为分析
   - 挑战响应

3. WAF 防护
   - API 规则
   - 注入防护
   - 异常拦截
```

### 深入思考问题

> ▎ 只动手不动脑，那是码农。动手又动脑，才是工程师。

**API 安全未来**：
```
1. AI 辅助检测
   - 行为分析
   - 异常检测
   - 自动防护

2. 零信任 API
   - 持续验证
   - 动态授权
   - 最小权限

3. 服务网格安全
   - mTLS
   - 策略执行
   - 流量加密
```

**量子计算影响**：
```
1. 加密算法
   - RSA 不安全
   - ECC 不安全
   - 需要后量子算法

2. 签名算法
   - JWT 签名
   - OAuth 签名
   - 需要更新

3. 密钥管理
   - 密钥长度
   - 密钥轮换
   - 密钥存储
```

### 实战建议

> ▎ 我给你指了路，走不走是你的事。机会给了，抓不抓得住看你。

**API 开发人员**：
```
1. 安全设计
   - 认证授权
   - 输入验证
   - 速率限制

2. 安全编码
   - 参数化查询
   - 输出编码
   - 错误处理

3. 安全测试
   - 单元测试
   - 集成测试
   - 渗透测试
```

**安全人员**：
```
1. API 测试
   - 漏洞扫描
   - 渗透测试
   - 代码审计

2. 监控告警
   - 异常访问
   - 速率限制
   - 入侵检测

3. 事件响应
   - 应急响应
   - 漏洞修复
   - 用户通知
```

**架构师**：
```
1. API 网关
   - 认证授权
   - 速率限制
   - 日志监控

2. 零信任架构
   - 持续验证
   - 微隔离
   - 动态授权

3. 持续改进
   - 安全审计
   - 漏洞管理
   - 安全培训
```

---

## 参考资料

### 学习资源
```
- OWASP API Security
  https://owasp.org/www-project-api-security/

- API Security Best Practices
  https://www.sans.org/

- GraphQL Security
  https://graphql.org/learn/security/

- gRPC Security
  https://grpc.io/docs/guides/security/
```

### 工具资源
```
- Postman
  https://www.postman.com/

- Insomnia
  https://insomnia.rest/

- GraphQL Playground
  https://github.com/graphql/graphql-playground

- Burp Suite
  https://portswigger.net/burp
```

### 书籍推荐
```
- 《API 安全实战》
- 《Web API 设计与安全》
- 《API Security in Action》
- 《GraphQL Security》
```

### 在线资源
```
- OWASP API Top 10
  https://owasp.org/www-project-api-security/

- API Security Checklist
  https://github.com/shieldfy/API-Security-Checklist

- Awesome API Security
  https://github.com/arainho/awesome-api-security
```

---

**标记 明日预告**：Day 75 - 前端安全进阶

> ▎ 今天的内容消化了吗？消化了就继续——明天还有硬仗。

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

---

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