有用的审计不是 80 页 PDF，也不是工具界面上一片绿色。它要找出可能击垮应用或泄露数据的问题，用证据证明，并决定先修什么。
这套48 小时方法论适用于 PHP/Laravel、Node.js 和 WordPress 应用（多站点、Elementor、带支付的店铺）。涉及电商或本地网关时，包括结账和 webhook —— 正是常引发真实事故的攻击面。
为什么重要（不只是“合规”）
把安全想成店铺门锁：它不能替代生意，但没有它谁都能进来。早期发现通常只花一个 sprint；一次事故则消耗客户、声誉和数日救火。
- 资金：可篡改支付或未签名 webhook。
- 数据：通过 IDOR 可见的订单或用户。
- 运营：无 MFA 的后台、废弃插件、公开的
.env。 - 优先级：没有 P0/P1/P2，一切都像紧急，却什么都关不掉。
通俗关键概念
- 攻击面：陌生人能触达的一切（表单、API、上传、后台）。
- 认证 vs 授权：“你是谁” vs “你能做什么”。失败点不同。
- IDOR：把
/orders/100改成/orders/101就看到别人的订单。 - 注入：让系统把数据当成指令执行（SQL、XSS、路径遍历）。
- 依赖项：含已知漏洞的第三方代码；更新也是安全工作。
48 小时分配
第 0–4 小时：攻击面测绘
- 公开路由清单（web + API）。
- 表单、上传、支付 webhook、cron 端点。
- 当前 headers、cookie、重定向。
- WordPress：版本、子主题、活跃插件、administrator 用户。
- 多站点：站点、超级管理员和网络插件。
第 4–16 小时：认证与会话
- 密码重置、用户枚举、速率限制。
Secure/HttpOnly/SameSitecookie。- 状态变更表单的 CSRF。
- JWT：
exp、轮换、在localStorage中不安全存储。 - WordPress 管理后台或 Filament/Horizon 无 MFA 暴露。
第 16–32 小时：注入与业务逻辑
- SQL / ORM 误用、存储型 XSS、路径遍历。
- Laravel 中的 mass assignment（
$fillable/$guarded）。 - IDOR：能否查看订单
#id+1？ - 支付：确认金额不信任客户端。
- 上传：验证真实文件类型，而非仅扩展名。
第 32–48 小时：依赖项与交付物
- 有判断地使用
composer/npm audit（噪音 vs 真实风险）。 - 已废弃或有已知 advisory 的 WordPress 插件。
- 仓库中的密钥、暴露的
.env、公开备份。 - P0/P1/P2 报告 + 按 sprint 的修复计划。
Laravel：审查要点
- 所有 API 输入使用 Form Requests 验证。
- 授权：show/update/destroy 使用 Policies/Gates。
- Mass assignment：模型
$guarded = []或危险的 fillables。 - 文件：私有
Storage磁盘；签名 URL。 - 带 backoff 和 dead-letter 的队列；payload 不含不必要 PII。
- 生产环境
APP_DEBUG=false；Telescope/Horizon 不公开。
WordPress：审查要点
- 删除通用
admin用户；审查角色；特权账户启用 2FA。 - XML-RPC：无合法应用需要时禁用。
- REST：泄露信息的用户端点。
- 上传：在
uploads中阻止执行。 - WooCommerce：网关插件已更新；webhook 权限最小化。
“审计”时的常见错误
- 只信任自动扫描器，而不人工验证发现。
- 忽略业务逻辑（金额、订单 ID、角色权限）。
- 交付 CVE 列表，却不按本产品影响排序。
- 不审查部署：同一密钥或旧插件会在下一版本回来。
- 把一切标为严重：团队饱和，却修不掉今天可利用的问题。
实用检查清单
.env、.git或备份是否可通过 URL 访问？- 登录、重置和敏感 API 是否有速率限制？
- 会话 cookie 在 HTTPS 上是否有正确标志？
- 状态变更表单是否启用 CSRF？
- Policies/capabilities 是否存在并在每条路由上调用？
- 上传是否验证真实 MIME？
- 支付 webhook 是否验证签名/来源并保证幂等？
- 安全 headers（CSP、HSTS）是否存在且不破坏前端？
- 关键依赖项是否有更新负责人？
- 部署是否会重新引入相同密钥或旧插件？
交付物格式
| 优先级 | 标准 | 示例 |
|---|---|---|
| P0 | 已可利用 / 高影响 | RCE、SQLi、可篡改支付、公开 .env |
| P1 | 高风险 | 存储型 XSS、订单 IDOR、敏感操作 CSRF |
| P2 | 加固 | headers 不完整、尚未暴露的旧插件 |
每个发现包括：位置、复现方式、风险、建议修复和相对工作量。与以下主题相关： DevOps 和 Coolify和网络安全 .