48 小时 Web 安全审计：Laravel、Node.js 和 WordPress

有用的审计不是一片绿色的工具界面表演。它要找出可能击垮应用或泄露数据的问题，用证据记录，并优先确定先修什么。

本方法论适用于 PHP/Laravel、Node.js 和 WordPress 应用（多站点、Elementor、带支付的店铺）。涉及电商或本地网关时，包括结账和 webhook —— 与在线支付覆盖的同一攻击面。

48 小时分配

第 0–4 小时：攻击面测绘

• 公开路由清单（web + API）。
• 表单、上传、支付 webhook、cron 端点。
• 当前 headers、cookie、重定向。
• WordPress：版本、子主题、活跃插件、administrator 用户。
• 多站点：站点、超级管理员和网络插件。

第 4–16 小时：认证与会话

• 密码重置、用户枚举、速率限制。
• Secure / HttpOnly / SameSite cookie。
• 状态变更表单的 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。
• 已废弃或有已知 advisory 的 WordPress 插件。
• 仓库中的密钥、暴露的 .env、公开备份。
• P0/P1/P2 报告 + 按 sprint 的修复计划。

实用检查清单

1. .env、.git 或备份是否可通过 URL 访问？
2. 登录、重置和敏感 API 是否有速率限制？
3. 会话 cookie 在 HTTPS 上是否有正确标志？
4. 状态变更表单是否启用 CSRF？
5. Policies/capabilities 是否存在并在每条路由上调用？
6. 上传是否验证真实 MIME？
7. 支付 webhook 是否验证签名/来源并保证幂等？
8. 安全 headers（CSP、HSTS）是否存在且不破坏前端？
9. 关键依赖项是否有更新负责人？
10. 部署是否会重新引入相同密钥或旧插件？

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 权限最小化。

交付物格式

每个发现包括：位置、复现方式、风险、建议修复和相对工作量。与以下主题相关： DevOps 和 Coolify和网络安全 .