02 道具清单：Web应用架构与常见组件

02 道具清单：Web 应用架构与常见组件

典型 Web 应用从浏览器到数据库通常隔着客户端、反向代理、应用服务器、数据库与第三方服务五层；每一层都有自己的输入入口，也就各自开着一扇攻击门。要定位漏洞在哪一层，先得有一张“道具清单”，把组件和它们各自的暴露面摆上桌。

上一节我们有了术语和坐标，但安全最终落在具体的软件上。这一节切一个最常见的 Web 部署结构，逐层标注“哪一层会接收不信任输入、最容易被挖出什么”。目的不是背架构图，而是让你在埋防线时知道该守哪个层。

一、一张典型的部署地形

从前到后，一次请求通常依次经过：客户端浏览器 → CDN/负载均衡/反向代理 → 应用服务器（框架 + 业务代码）→ 数据库/缓存/消息队列 → 第三方外部服务（支付、短信、邮件、日志）。这五层里，第 1 层和第 5 层往往最容易被新手忽略：浏览器会执行页面里的脚本（XSS 的现场），第三方回调是信任边界上的薄弱点（SSRF、回调劫持的现场）。

二、每一层最容易开的那扇门

客户端层问题集中在“浏览器相信了页面里不该有的脚本”。应用服务器层的问题最密集，因为它同时握着参数绑定、数据库访问、认证授权三套逻辑——SQL 注入、越权、XSS 的反射点大多堆在这附近。数据层最容易被人忽略的是“数据库账户权限过大”和“明文存储敏感数据”，两者往往不在代码层面，而在连接配置和建表规范上。

理解这五层还有个实际价值：排查复现顺序。看到一条“某接口返回了别人订单”的报告，第一反应不是改 SQL，而是先确认参数是否经过授权校验、路由层有没有做归属判定——绝大多数访问控制问题出在应用层少了那一次“这是不是当前用户自己的资源”的判断。

三、为什么“组件”值得单列

“常见组件”四个字在安全语境里指两块：一是第三方库与框架（登录 SDK、图片处理器、序列化包），二是基础设施组件（防火墙、负载均衡、缓存集群）。前者的坑是版本滞后和依赖链放大，后者的坑是默认配置和过度暴露。这两类问题在第四幕的“使用含漏洞组件”一节会展开，这里先埋下结论：你把多少第三方代码放进系统，就相当于把多少份别人的代码审计压力背到自己身上。

四、一次动手的架构盘点

找线上一个最熟悉的服务，按五层画一张现有拓扑图，然后对每一层回答同一个问题：这个输入我可以不信任到什么程度？举例——登录接口的表单参数可以被任何人构造，绝不能信任；内部管理页的 Cookie 理论上可信但也要校验是否失效。把答案写进注释，就得到了一张带“信任标注”的架构图。下一次改任何一层，先看它旁边标注的可信度再动手，会少踩一半坑。

⚠️ 常见坑：只在新功能接口上做权限校验，漏了“历史接口”。攻击者最爱扫的是老接口——它们往往参数更原始、校验更粗糙。盘点攻击面时，把存量接口和新增接口一起纳入，别只盯着当期代码。

五、五层之外的“横向组件”

上面五层是按“一次请求的纵向路径”画的，但现实系统里还横着一批不直接参与请求、却一样开门的组件：任务调度器、定时脚本、队列消费端、后台批处理。它们的共同特征是“没有浏览器入口”，反而更容易被当成不需要防护的角落。一旦被拉了横向移动，攻击者从一台跳板机爬到能触发批处理的机器，能拿到的往往是数据库全量权限。

所以做架构盘点时，把“请求路径”和“管控路径”分开各画一张图。请求路径回答“每次访问会经过哪几层”，管控路径回答“谁有权限去动哪些调度和批处理”。大多数数据泄露不是从公网入口一路打穿，而是先打进一个低风险组件，再沿内部信任横向爬到核心库。

六、给“不信任度”打分而不是只贴标签

第四节让每一层标注可信度，实操里更进一步：别只标“可信/不可信”两级，改成四分——完全不可信（任意匿名触达）、半可信（登录后即可触达）、受约束可信（需特殊权限）、内部可信（仅内网或受控调用）。登录接口的表单属于第一档，内部管理页属于第三档，数据库连接属于第四档。

这样打分的价值在于排修复顺序：两个同样“不可信”的入口，一个碰得到敏感数据、一个只能读到验证码，风险天差地别。评分能让“全部攻面”从一排等高的墙，变成一条按暴露程度降序的河流。加固时就顺着河流上游往下游做，先把最湍急的首段堵住。

七、把五层地图用进一次真实排查

把抽象地形拉回一次真实过程：一个普通用户打开个人中心，浏览器发出请求，经 CDN 与反向代理进入应用服务器，应用再查数据库、调第三方存储取头像。某天安全组收到告警，说“登录后能看到别人的订单号”。拿到这条报告，顺着道具清单往下走比乱翻代码快得多：先确认请求携带的会话是否归属当前用户，再查应用层那一次“订单属于谁”的归属校验存不存在，最后才轮到怀疑 SQL。判断权限归属的最前一道门就设在应用层；路由和服务层漏了校验，后面数据库写得再严谨也挡不住。地形图当排查索引的意义正在于此——每层标注的可信度，就是告诉你该先怀疑谁、后怀疑谁。

同一张图还能用来预判“这轮改动会殃及哪几层”。改了一个字段的长度，看似只落在数据库层，实际上传路径上第三方校验、应用层映射都可能被牵动。动手前先看这个字段跨了几层、每层挂着多少校验与编码逻辑，能少踩“改一处、炸一串”的联动事故。五层地形不只是静态概念，更是一张常更新的排查地图。

本节要点回顾

• 横向组件不可漏：调度器、批处理、队列消费端没有浏览器入口，却常握有数据库全量权限，要单独画管控路径图。
• 纵向与横向两张图：请求路径看每层暴露，管控路径看谁能动调度与批处理，数据泄露多走横向爬升。
• 不信任度四级打分：匿名、半可信、受约束、内部可信，让攻击面从等高墙变成降序河流。
• 按暴露度排修复：同样不可信的入口，碰不碰到敏感数据决定优先级，先堵上游首段。
• 五层地形：客户端、代理网关、应用服务器、数据层、第三方服务，每层都有独立攻击面。
• 应用服务器层是注入、越权、XSS 反射点最密集的一层，优先级最高。
• 第三方回调是信任边界的薄弱环节，验签不严易出 SSRF 与回调伪造。
• 组件依赖把第三方审计压力背到自己身上，版本滞后会放大漏洞。
• 架构盘点时给每层输入标注可信度，形成带信任标注的地图，改层先看标注。