攻防演练安全体系设计（三）：Web、API与应用安全
原创
闲聊三号
闲聊三号
闲聊知识铺
2026年10月19日 08:35
河南
去阅读
前两层解决的是：
- 第一层：攻击者能看到什么；
- 第二层：哪些流量可以进入网络。
第三层需要解决的是：
当攻击流量已经通过HTTP/HTTPS等合法业务端口进入系统后，如何识别其中的恶意请求。
这就是Web、API与应用安全。
传统边界设备擅长控制“谁能访问、访问什么端口”，但对于大量基于HTTP/HTTPS的攻击，仅靠防火墙往往不够。
因为攻击者和正常用户访问的，可能都是：
TCP/443 HTTPS
真正的区别在于：
请求内容 参数 调用逻辑 身份状态 业务行为
因此，第三层的核心是：理解应用
一、为什么Web是重保中的重点入口
绝大多数互联网业务最终都会暴露Web或API接口。典型入口包括：
- 门户网站
- OA
- 统一认证
- 管理后台
- 移动端接口
- 小程序接口
- 开放API
- 文件上传接口
- 第三方业务接口
这些系统长期暴露在互联网，容易成为攻击者重点关注的入口。
典型攻击路径可能是：
发现Web系统 ↓ 识别技术栈 ↓ 寻找漏洞 ↓ 构造恶意请求 ↓ 执行命令 ↓ 控制服务器
因此应用层是从访问进入入侵的关键位置。
二、WAF解决什么问题
WAF，即Web Application Firewall。
它关注的不是IP和端口，而是HTTP/HTTPS请求本身。主要检测：
SQL注入 XSS 命令注入 路径遍历 文件包含 恶意文件上传 异常请求 已知Web漏洞利用 Web扫描
典型部署：
Internet │ ▼ NGFW │ ▼ WAF │ ▼ 负载均衡器 │ ▼ Web服务
或者：
Internet │ ▼ CDN │ ▼ WAF │ ▼ 应用系统
它的作用可以概括为：
允许正常HTTP请求进入，阻断恶意HTTP请求。
三、WAF不是“部署了就有效”
WAF和IPS一样，真正的难点不是安装，而是策略质量。常见问题包括：
只开检测，不阻断 规则长期不更新 大量误报无人处理 业务上线后没有重新调优 所有系统使用相同策略 白名单过度放宽
最终可能出现两个极端：
规则太严 → 正常业务被误封规则太松 → 攻击可以通过
因此，重保前WAF应该重点完成：
规则更新 ↓ 历史告警分析 ↓ 误报确认 ↓ 业务白名单梳理 ↓ 高危规则阻断 ↓ 特殊接口单独加固
四、不同业务不应该使用同一套策略
一个门户网站和一个文件上传接口，风险完全不同。例如：
门户首页主要是：
- GET
- 静态内容
- 普通查询
而上传接口可能包含如下这些，风险更高。
- POST
- 文件上传
- 复杂参数
- 认证逻辑
因此WAF策略应该根据具体情况，做差异化控制。而不是简单全站套同一策略。
业务类型 URL HTTP方法 参数类型 访问来源 用户身份
五、为什么API越来越重要
现代业务已经不再只是传统网页。大量系统采用：
Web前端 + 移动App + 小程序 + API
甚至采用：
微服务 + API Gateway
因此，攻击面逐渐从“页面”转向“接口”。例如：
/api/login /api/user /api/order /api/admin /api/upload
API安全面临的问题和传统Web攻击并不完全相同。
六、API最常见的问题不是传统漏洞，而是业务逻辑
传统WAF擅长发现：
SQL注入 XSS 命令执行
但API攻击中大量问题属于：
未授权访问 水平越权 垂直越权 接口枚举 参数篡改 Token滥用 敏感数据泄露 接口滥用
例如：正常请求：
GET /api/order/10001
攻击者修改：
GET /api/order/10002
如果系统没有正确校验当前用户是否有权限访问10002订单，就可能产生越权。从HTTP协议角度看：
请求完全合法
传统WAF可能不会认为这是攻击。因此API安全需要理解：
谁在调用接口，以及这个用户是否有权执行这个操作。
七、API安全首先要解决“有哪些API”
和外部攻击面类似，API管理也存在一个现实问题：企业自己未必知道所有API。
可能存在：
正式API 历史API 测试API 旧版本API 内部API公网暴露 第三方接口 开发临时接口
因此API安全第一步应该是：
API发现 ↓ API分类 ↓ 敏感接口识别 ↓ 风险分析
而不是直接配置拦截规则。
八、重点接口应该单独保护
重保期间可以把API按照风险分类。例如高风险接口：
登录 注册 密码重置 文件上传 订单 支付 用户信息 管理员接口 数据导出
这些接口可以增加：
身份校验 权限检查 访问频率限制 来源限制 行为分析 验证码 二次认证
尤其是：管理接口，原则上不应该直接暴露在互联网。
九、文件上传接口要重点关注
文件上传是攻防演练中的典型高风险入口之一。攻击者可能尝试上传：
WebShell 恶意脚本 可执行文件 畸形文件
因此应同时考虑：
文件类型校验 扩展名限制 MIME校验 文件内容检测 上传目录隔离 禁止执行权限 随机文件名 恶意文件检测
仅靠：禁止后缀并不可靠。文件上传安全必须同时由：应用自身控制 + WAF检测 + 服务器权限控制 + EDR检测共同完成。
十、管理后台应该尽量从公网消失
很多攻击来自：
/admin /manage /console
如果管理后台并不需要公网访问，最好的防护不是：再加一条WAF规则。而是直接：取消公网访问
改为：
管理员 │ ▼ VPN │ ▼ 堡垒机 │ ▼ 管理后台
这和第一层攻击面收敛的原则一致：
能从攻击面移除的资产，不要依赖检测设备长期保护。
十一、HTTPS会带来检测问题
现在绝大多数Web业务都使用HTTPS。这意味着：
HTTP请求 ↓ TLS加密 ↓ 网络传输
如果安全设备无法解密TLS，就无法看到：
URL参数 POST内容 Payload 文件内容
因此WAF一般需要位于能够看到明文HTTP的位置。例如：
Internet │ ▼ WAF │ TLS终止 ▼ Web Server
或者与负载均衡、反向代理配合完成TLS解密。架构设计时必须明确：
到底由谁解密HTTPS
否则可能出现设备已经部署，但实际上看不到有效应用层内容。
十二、真实源IP必须保留下来
在实际网络中，Web请求经常经过：
CDN ↓ WAF ↓ 负载均衡 ↓ Web服务
如果配置不正确，后端看到的源IP可能全部变成：WAF地址，或者：负载均衡地址
这样会影响：
安全分析 攻击溯源 SIEM关联 访问控制 日志审计
因此需要正确处理：
X-Forwarded-For X-Real-IP
同时必须防止攻击者伪造这些字段。正确原则应该是：
只信任由受控代理设备写入的真实源IP字段。
十三、WAF不能替代应用安全
这是一个非常重要的原则。WAF可以阻断很多攻击，但不能解决所有应用问题。例如：
越权访问 业务逻辑漏洞 错误权限设计 敏感信息泄露 不安全的接口流程
这些问题必须在应用本身解决。因此真正有效的应用安全应该是：
安全开发 + 代码审计 + 漏洞测试 + WAF + 运行时检测
而不是：
应用有漏洞 ↓ 全部交给WAF
十四、RASP解决什么问题
RASP，即Runtime Application Self-Protection。它与WAF的区别在于位置不同。WAF在应用之外：
攻击请求 ↓ WAF ↓ 应用
RASP则运行在应用内部：
应用进程 │ ├── SQL调用 ├── 文件操作 ├── 命令执行 └── 网络连接
因此它可以看到更接近真实执行结果的信息。例如攻击者发送一个请求后：
HTTP请求 ↓ 应用代码 ↓ Runtime.exec() ↓ 执行系统命令
RASP可以直接观察到：应用正在执行危险命令
这类能力对于高价值Web系统有一定意义。
十五、但RASP不是所有环境都适合
因为RASP通常需要：
Agent 应用插件 运行时Hook
因此需要考虑：
应用兼容性 性能影响 开发配合 运行稳定性
所以实际项目中，RASP更适合作为关键应用的增强防护，而不是简单替代WAF。
十六、WebShell是应用层和主机层的交界点
Web攻击成功后，一个非常典型的结果就是WebShell，这时攻击已经从应用层进入主机层，例如：
漏洞利用 ↓ 写入WebShell ↓ HTTP访问WebShell ↓ 执行系统命令
因此WebShell检测不能只依赖WAF。应该形成：
WAF 检测异常请求 + EDR/HIDS 检测异常文件和进程
例如：
WAF 发现上传可疑文件 ↓ EDR发现Web目录新增脚本 ↓ Web进程启动cmd/bash
这三个事件如果同时出现，风险等级应该立即提升。
十七、应用层必须和EDR联动
一个非常重要的攻击信号是：Web进程 → 启动系统命令例如：
java → cmd.exenginx → bashphp-fpm → curl
这种行为并不一定绝对恶意，但在大多数Web服务器环境下值得高度关注。因此第三层和第四层之间必须建立关联：
WAF攻击 ↓ EDR异常进程
比单独一个WAF告警更有价值。
十八、应用安全还要关注认证入口
登录接口是攻击者重点关注的位置。常见攻击包括：
弱口令 密码喷洒 撞库 暴力破解 验证码绕过 Token窃取 Session滥用
因此应考虑：
MFA 登录频率限制 异常IP识别 失败次数限制 设备识别 异常地域登录检测
这部分实际上也是第三层和第五层“身份安全”的交界位置。
十九、重保期间应用层应该做什么
重保前建议重点完成以下工作。
资产确认
确认所有公网Web系统 确认所有API 确认管理后台 确认测试环境
漏洞治理
高危漏洞修复 历史漏洞复测 组件版本检查 Web框架检查
WAF调优
规则库更新 高危规则阻断 误报处理 URL级策略 上传接口加强
API治理
关闭废弃API 限制管理接口 检查越权 限制高风险接口访问频率
认证加固
关闭弱口令 启用MFA 限制暴力破解 清理无效账号
日志接入
WAF日志 Web访问日志 应用日志 API网关日志
统一进入SOC。
二十、不要只关注“已知漏洞”
重保中一个常见误区是：漏洞扫描没有高危漏洞 = Web系统安全，实际上并不是。应用攻击还可能来自：
业务逻辑缺陷 权限设计错误 配置错误 接口暴露 弱口令 默认账号 文件上传问题
因此漏洞扫描只是应用安全的一部分。更完整的能力应该包括：
漏洞扫描 + 人工渗透测试 + 代码安全 + WAF + API安全 + 运行时检测
二十一、第三层真正要解决的问题
Web、API与应用层最终需要回答：
当前请求是不是攻击？ 调用者有没有权限？ 接口行为是否异常？ 攻击是否已经进入应用执行阶段？ 攻击是否已经影响服务器？
这一层实际上是整个攻击链非常关键的转折点。在此之前攻击者还在网络外部，一旦应用漏洞利用成功攻击者开始获得服务器执行能力。
防御重点也随之发生变化。从请求检测转向:
进程 文件 命令 网络连接 主机行为
这就是下一层：终端与服务器安全
如果第三层解决的是：
阻止恶意请求变成一次成功利用。
那么第四层需要解决的是：
> 一旦攻击已经进入主机，我们还能不能及时发现和阻断。
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论