企业官网建设流程全解析

Anthropic-Cybersecurity-Skills 实战：基于 SIEM 与 WAF 日志的 API 枚举攻击检测（BOLA/IDOR）

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

导读

本文围绕 Anthropic-Cybersecurity-Skills 仓库中的detecting-api-enumeration-attacks技能展开，系统讲解如何基于 API 网关与 WAF 日志检测 API 枚举攻击——包括顺序 ID 遍历、UUID/GUID 枚举、参数篡改探测以及 BOLA/IDOR 等对象级授权绕过行为（OWASP API1:2023）。读完本文，你将掌握一整套从「攻击模式识别 → 检测指标提炼 → Splunk/Elastic SIEM 检测规则编写 → Python 检测脚本落地」的完整检测方案，并了解如何在数据层强制授权、使用不可预测标识符与端点级限流等预防控制。

什么是 API 枚举攻击

API 枚举攻击是指攻击者利用顺序或可预测的标识符，系统性地探测 API 端点，以发现并访问未授权资源的攻击行为。其典型场景是Broken Object Level Authorization（BOLA，对象级授权缺陷），它被 OWASP API Security Top 10 列为 API1:2023 最高危 API 漏洞。攻击者通过篡改请求中的对象标识符（用户 ID、订单号、账户引用等），绕过授权检查访问其他用户的数据。此类攻击本质上是访问控制失效，因此日志层面的核心检测思路是：监控快速连续访问、授权失败以及异常 API 使用行为三种模式的组合。

从 MITRE ATT&CK 视角看，本技能覆盖了 Active Scanning (T1595) 及子技术 T1595.002、Network Service Discovery (T1046)、Exploit Public-Facing Application (T1190) 与 Account Discovery (T1087) 等技战术映射，同时在 NIST CSF 2.0 上对应 PR.PS-01、ID.RA-01、PR.DS-10、DE.CM-01 等功能区（见 SKILL.md 元数据）。

适用场景

• 调查安全事件时需要对 API 枚举攻击进行检测与取证；
• 编写该领域的检测规则或威胁狩猎查询；
• SOC 分析师需要结构化的分析流程；
• 验证相关攻击技术对应的安全监控覆盖度。

前置条件

• 启用日志记录的 API 网关或反向代理（Kong、AWS API Gateway、Apigee 等）；
• SIEM 平台（Splunk、Elastic SIEM 或 Microsoft Sentinel）；
• 包含请求细节的 API 服务端日志；
• 具备 API 防护能力的 Web 应用防火墙（WAF）；
• 理解 API 的授权模型与对象标识符方案。

检测技术与严重性速查

api-reference.md 给出了五大核心检测技术及对应的严重性分级，这是整个检测体系的「雷达表」，任何检测规则都应至少覆盖以下五种行为：

这些技术之间存在明显的攻击链递进关系：攻击者往往先通过路径发现摸清 API 结构，再以端点模糊测试或顺序 ID 枚举批量试探资源，最后在BOLA/IDOR 探测阶段真正触达越权数据；而速率滥用则贯穿始终，是所有自动化枚举行为的共性特征。

数据源：NGINX Combined Log Format

所有检测的前提是拥有结构完整的访问日志。api-reference.md 明确了检测所依赖的 NGINX Combined Log Format：

$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"

字段语义：$remote_addr为客户端 IP，$remote_user为认证用户（未认证为-），$time_local为请求时间，$request包含 HTTP 方法与请求路径，$status为响应状态码，$body_bytes_sent为响应体字节数，后随 Referer 与 User-Agent。

这条格式是 agent.py 解析器 的直接输入。parse_access_log()用正则(\S+) \S+ \S+ \[([^\]]+)\] "(\S+) (\S+) \S+" (\d+) \d+从每行日志中提取 IP、时间戳、方法、路径与状态码，并封装为结构化条目供后续检测函数使用。如果你的网关/代理日志字段与 Combined 格式存在差异（如 AWS API Gateway 的 JSON 格式、Apigee 的 JSON 格式），需要先做字段映射/ETL 归一化再喂给检测逻辑。

常见枚举路径

攻击者的路径选择高度有规律可循。api-reference.md 归纳了最常被枚举的路径模式：

在 agent.py 中，这些模式被固化为ENUMERATION_PATTERNS正则列表，包括/api/v\d+/users/\d+、/api/v\d+/accounts/[a-f0-9-]+、/api/v\d+/orders/\d+、/graphql.*introspection以及/admin|internal|debug|swagger|api-docs等。当同一 IP 对任一模式匹配到的路径数超过 5 个时，detect_path_enumeration()即输出 HIGH 级别的路径枚举告警（agent.py L111-L129）。

三大攻击模式详解

1. 顺序 ID 枚举（Sequential ID Enumeration）

攻击者遍历数值型或可预测的标识符：

GET /api/v1/users/1001 -> 200 OK GET /api/v1/users/1002 -> 200 OK GET /api/v1/users/1003 -> 403 Forbidden GET /api/v1/users/1004 -> 200 OK GET /api/v1/users/1005 -> 200 OK ...

检测指标：

• 对同一端点快速发起 ID 递增的连续请求；
• 同一来源出现 200/403/401 混合响应；
• 请求速率超出正常用户行为基线；
• 访问了认证用户作用域之外的资源。

注意：200 与 403 混存恰恰是最危险的信号——说明授权检查是「事后」的或按资源粒度生效，攻击者已能分辨哪些对象存在、哪些对象不可见，从而绘制资源清单。

2. UUID/GUID 枚举

即使使用非顺序标识符，只要 UUID 能通过其他端点泄露，仍可被枚举利用：

# 攻击者先从列表端点批量收割 UUID GET /api/v1/posts?page=1 -> Returns post objects with author UUIDs # 再利用收割的 UUID 访问受限用户数据 GET /api/v1/users/a3f2c1e4-... -> Private user profile GET /api/v1/users/b7d9e8f1-... -> Private user profile

3. 参数篡改枚举（Parameter Tampering）

认证用户通过篡改请求参数越权访问他人资源：

# 以 user_id=100 认证，尝试访问其他用户的订单 GET /api/v1/orders?user_id=101 GET /api/v1/orders?user_id=102 GET /api/v1/orders?user_id=103

这一模式对应 OWASPAPI3:2023 Broken Object Property Level Authorization（对象属性级授权缺陷）的前兆行为，检测时可针对?user_id=、?account=等易被篡改的查询参数建立专门的参数监控维度。

SIEM 检测规则实战

Splunk 检测查询

Splunk 查询 从uri_path中提取端点和对象 ID，按src_ip + endpoint + user_session聚合统计：

# 检测 API 端点上的顺序 ID 枚举 index=api_logs sourcetype=api_access | rex field=uri_path "(?<endpoint>/api/v\d+/\w+/)(?<object_id>\d+)" | stats count as request_count, dc(object_id) as unique_ids, values(status_code) as status_codes, min(_time) as first_seen, max(_time) as last_seen by src_ip, endpoint, user_session | eval time_span = last_seen - first_seen | eval requests_per_second = request_count / max(time_span, 1) | where unique_ids > 20 AND requests_per_second > 2 | eval severity = case( unique_ids > 100, "critical", unique_ids > 50, "high", unique_ids > 20, "medium", 1==1, "low" ) | sort - unique_ids | table src_ip, endpoint, unique_ids, request_count, requests_per_second, status_codes, severity

要点解析：dc(object_id)统计去重后的独立对象数（比原始请求数更能反映「遍历」性质）；requests_per_second > 2过滤正常用户偶发访问；阈值unique_ids > 20与三级 severity 分级（20/50/100）与 agent.py 的EnumerationDetector分级逻辑 保持一致——这是本技能跨语言规则统一的一个设计细节。

第二条查询聚焦 BOLA 的授权失败模式：

# 通过授权失败模式检测 BOLA index=api_logs sourcetype=api_access status_code IN (401, 403) | bin _time span=5m | stats count as failure_count, dc(uri_path) as unique_paths, values(uri_path) as attempted_paths by _time, src_ip, user_id | where failure_count > 10 | eval attack_type = if(unique_paths > 5, "enumeration", "brute_force")

这里用unique_paths > 5区分枚举（探多路径、多对象）与暴力破解（集中攻击少数路径）两种攻击类型，是 SOC 分析师可直接照搬的分类判据。

Elastic SIEM 检测规则

对应 Elastic 侧的 threshold 规则（SKILL.md）：

{ "rule": { "name": "API Object Enumeration Detection", "description": "Detects rapid sequential access to API objects with mixed authorization results", "type": "threshold", "index": ["api-access-*"], "query": { "bool": { "must": [ { "regexp": { "url.path": "/api/v[0-9]+/[a-z]+/[0-9]+" } } ], "should": [ { "term": { "http.response.status_code": 200 } }, { "term": { "http.response.status_code": 403 } }, { "term": { "http.response.status_code": 401 } } ] } }, "threshold": { "field": ["source.ip"], "value": 50, "cardinality": [ { "field": "url.path", "value": 20 } ] }, "schedule": { "interval": "5m" }, "severity": "high", "risk_score": 73, "tags": ["OWASP-API1", "BOLA", "Enumeration"] } }

规则逻辑：匹配/api/v{version}/{resource}/{id}形态的路径，should子句让混合授权结果（200/401/403）都能命中；threshold 按source.ip聚合，5 分钟内触发 50 次请求且去重路径数 ≥20 时告警。risk_score: 73与severity: high对应本技能的 HIGH 分级。

Python 检测脚本与源码级实现

SKILL.md 提供了一个完整的EnumerationDetector实现，其核心设计可直接对接前面介绍的 SIEM 规则，且仓库配套的 scripts/agent.py 提供了可直接运行的命令行版本。两者共享同一套检测哲学：按源 IP 分组 → 时间窗分析 → 去重对象数 + 每秒请求数 + 授权失败率联合判定 → 分级告警。

对象 ID 提取正则（EnumerationDetector.ID_PATTERNS）

ID_PATTERNS = [ re.compile(r'/api/v\d+/(\w+)/(\d+)'), # Numeric IDs re.compile(r'/api/v\d+/(\w+)/([a-f0-9\-]{36})'), # UUIDs re.compile(r'/api/v\d+/(\w+)/([a-zA-Z0-9]{20,})'), # Long alphanumeric IDs ]

三种模式分别覆盖数值 ID、UUID（36 位十六进制加连字符）和长字母数字 ID（如 Stripe 风格sk_live_...或 YouTube 风格 ID），保证不同 ID 方案都能被提取出来参与计数。

端点归一化

endpoint = re.sub(r'/[a-f0-9\-]{36}', '/{id}', re.sub(r'/\d+', '/{id}', record.path))

将具体 ID 替换为{id}占位符，使/users/1001与/users/1002归并为同一端点模式，这是「按端点聚合统计」的关键步骤。

顺序性判定（_check_sequential）

numeric_ids = sorted(int(i) for i in ids) sequential_count = sum( 1 for i in range(1, len(numeric_ids)) if numeric_ids[i] - numeric_ids[i-1] <= 2 ) return sequential_count / len(numeric_ids) > 0.7

间隔 ≤2 视为「连续步进」，当连续占比 >70% 时判定为顺序枚举（sequential_enumeration），否则为随机枚举（random_enumeration）。阈值参数可在初始化时调节：time_window_minutes=5、min_unique_ids=15、max_requests_per_second=5.0。

命令行审计脚本（agent.py）

agent.py 实现了与 SKILL.md 检测器互补的三大检测器，并支持 WAF 联动：

# 解析访问日志并输出三份检测报告 python3 scripts/agent.py --log-file /var/log/api/access.log # 将报告保存为 JSON python3 scripts/agent.py --log-file /var/log/api/access.log --output report.json # 查询 WAF 的 api-abuse 规则事件（需 requests 库） pip install requests python3 scripts/agent.py --waf-url https://waf.example.com --waf-key YOUR_API_KEY

三大检测器及其在源码中的位置：

其中detect_rate_anomalies中>50 requests与>20 个 404的阈值分别对应 api-reference 中「Rate abuse >50 API requests/minute」与「Endpoint fuzzing 高 404 率」两条检测技术；query_waf_logs则演示了如何用requests库拉取 WAF 的rule_category=api-abuse事件做二次确认（agent.py L132-L142），这正是 api-reference.md 中requests库「WAF and SIEM API queries」用途的落地实现。

WAF 规则类别

WAF 侧可针对不同行为配置独立的规则类别（见 api-reference.md），以便于在 SIEM 中按类别聚合统计：

例如 agent.py 的query_waf_logs默认查询rule_category=api-abuse，与上述分类一一对应；SIEM 侧可将 WAF 事件与网关日志关联，用 WAF 拦截记录反哺调优检测阈值。

预防控制：检测之外的三道防线

检测只能「看见」，根治 BOLA 必须从架构层修复（SKILL.md 预防控制章节）：

1. 服务端强制授权（数据层兜底）

# 始终在数据层校验对象归属 def get_user_order(request, order_id): order = Order.objects.get(id=order_id) if order.user_id != request.user.id: raise PermissionDenied("Not authorized to access this order") return order

关键原则：授权检查不能只做在 Controller/中间件层，必须在数据访问层基于对象归属强制执行，因为枚举攻击的本质是授权逻辑缺失而非路径隐藏。

2. 使用不可预测标识符

import uuid # 用 UUID 替代顺序整数 class Order(Model): id = UUIDField(default=uuid.uuid4, primary_key=True)

UUID 虽非绝对安全（如「UUID 枚举」章节所示，泄露即可被利用），但能大幅提高批量猜测成本，与端点级鉴权配合使用效果最佳。

3. 按端点实施限流

# Kong 按 API 路由限流 plugins: - name: rate-limiting config: minute: 30 policy: redis limit_by: credential

按凭据（而非 IP）限流可规避攻击者轮换 IP 绕过；policy: redis适用于多实例分布式网关。生产环境建议按端点资源敏感度设置差异化阈值（如/users/{id}30 次/分钟、公开列表端点 120 次/分钟）。

与 OWASP API Security Top 10 的对应关系

本技能覆盖的威胁面可映射到 OWASP API Security Top 10 的前五位：

仓库资源导航

• 技能主体文档：skills/detecting-api-enumeration-attacks/SKILL.md
• API 参考速查：skills/detecting-api-enumeration-attacks/references/api-reference.md
• 可执行检测脚本：skills/detecting-api-enumeration-attacks/scripts/agent.py
• 技能许可：skills/detecting-api-enumeration-attacks/LICENSE
• MITRE ATT&CK 覆盖总览：mappings/mitre-attack/coverage-summary.md

落地建议

1. 数据先行：确保网关/WAF 输出 Combined Log Format 或可归一化的结构化日志，字段至少包含客户端 IP、认证用户、时间、完整路径、状态码。
2. 分层检测：SIEM 规则负责全局聚合（Splunk/Elastic），agent.py 负责离线审计与样本取证，WAF 规则（rate-limit/api-abuse/bola/scanner）负责实时拦截，三层互补。
3. 阈值调优：min_unique_ids、requests_per_second、404 阈值等需基于各自 API 的正常访问基线校准，避免大量误报淹没真实告警；可用 WAF 已确认的api-abuse事件作为调优参照。
4. 闭环修复：检出 BOLA 类告警后，优先按「数据层强制授权 + UUID 化 + 端点级凭据限流」三项预防控制整改，而不是仅靠规则封禁 IP。

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills