Day002_Web应用

1. 架构形态与战术调整 (Architecture Mode)

战术指导：在输入 URL 后的第一反应，必须判断目标的“骨架”是什么。

核心问题：这是一个动态网站、纯静态页，还是基于 API 的前后端分离应用？

实战意义：不同的架构决定了漏洞的高发区是完全不同的（例如静态页面就不存在 SQL注入）。

明确 Web 应用与用户交互的方式，直接决定了测试重点：

套用模版型 (SaaS/CMS)
- 例子：CSDN, cnblog, GitHub Pages, 第三方建站系统。
- 安全测试思路：核心系统通常经过严密测试，基本无通用漏洞。攻击重心应转向业务逻辑漏洞（如越权访问）、用户管理权限、钓鱼攻击或社工，而非试图挖掘系统本身的 RCE。
前后端分离 (Frontend-Backend Separation)
- 例子：https://www.rxthink.cn/
- 参考：分离架构安全思路
- 安全测试思路：重心转移至 API 接口测试与前端安全。
  - 前端：重点关注 JS 中的敏感信息泄露（Key/Token）、XSS、Vue.js/Node.js 组件漏洞。
  - 后端：攻击入口隐蔽，需重点测试 API 的鉴权（JWT/OAuth）、未授权访问及参数逻辑。
纯静态页面 (Static)
- 例子：纯 HTML + CSS + JS 组成的宣传页。
- 安全测试思路： 无后端交互，因此不存在常规 Web 漏洞（如 SQLi, RCE, 上传）。
  - 找线索：立即停止 Web 攻击，转为 资产发现 (OSINT)，寻找同一域名下的其他子域、API 接口或后台管理入口。

战术指导：应用跑在什么载体上？

核心问题：是集成环境、原生系统还是容器？

实战意义：决定了获取 Shell 后的权限级别（Root/System 还是受限用户）以及防御体系的强度。

集成软件包
- 例子：宝塔面板 (Bt), PhpStudy, XAMPP。
- 安全测试思路：主要关注 默认配置不当 与 权限差异。这类环境常存在默认端口（如 8888）、默认数据库密码或过于宽松的目录权限。
自主/云镜像环境
- 例子：云服务器自行搭建或使用厂商公共镜像。
- 安全测试思路：重点在于管理员的人为配置失误。防护体系很大程度上取决于云厂商的安全组策略。
容器化部署
- 例子：Docker, K8s。
- 安全测试思路：引入了 虚拟化隔离 难题。如果成功 GetShell，通常只是拿到了容器内的权限。后续必须考虑 容器逃逸 (Escape) 提权，才能触达到宿主机核心数据。

战术指导：当你有机会接触到源码（开源下载或泄露）时，源码的形态决定了审计的成本与工具。

核心问题：代码是人能看懂的，还是机器编译过的？

实战意义：决定了是直接白盒审计，还是需要反编译/解密。

可以直接阅读逻辑，适合白盒审计：

单纯简易源码 结构简单，逻辑直白，容易出现“面条代码”，易读易挖。
MVC 框架源码 引入了 MVC (Model-View-Controller) 结构。
- 难点：需要先理清 路由 (Route) 关系，找到 URL 对应的 Controller 文件，否则无法定位漏洞点。
前后端分离源码
- 参考：前后端分离架构详解
- 难点：源码通常分为两个仓库（前端包 + 后端 API 代码），审计时需重点关注后端 API 的参数处理与跨域配置 (CORS)。

无法直接阅读逻辑，需要反编译或解密工具：

编译封装源码
- 例子：.NET (DLL 封装), Java (JAR/WAR 打包)。
- 应对：必须使用 反编译工具（如 dnSpy, JD-GUI, CFR）将二进制文件还原为伪代码，才能进行逻辑分析。
加密型源码
- 例子：使用了 IonCube, Zend Guard 加密的 PHP 代码，或 通达OA 等商业源码。
- 应对：
  1. 尝试寻找特定的 解密脚本。
  2. 若无法解密，只能将其视为 黑盒测试，通过 Fuzzing 测试其输入输出逻辑，无法查看内部实现。