外部触发入口的安全审计要点

接手一个旧项目时，最容易让人心里发毛的往往不是代码写得乱，而是你根本不知道哪些地方能被外部直接"摸到"。一个看似藏在后台的接口，可能因为路由配置失误暴露在公网；一个三年前为了快速对接写的回调入口，可能至今没有做任何请求验证。这些外部触发入口才是安全审计时最该优先盯紧的地方。

聊到这个，有几个位置是怎么都绕不开的。

首先是所有接收用户输入的地方。别管是表单提交、URL 参数还是 API 请求体，只要数据最终会进入数据库查询、拼进命令行、写进文件路径或者原样输出到页面，就必须当不可信数据处理。旧项目里经常能看到直接用字符串拼接 SQL 的写法，这种地方一旦被注入，整个数据库就相当于敞开了门。改成预处理语句并绑定参数是最低限度的修复，但审计时更要关注那些"看起来不会出问题"的间接拼接，比如动态表名、排序字段、WHERE 条件里的 IN 子句拼接，这些往往是扫描工具容易漏掉、但手工审计一眼就能看出不对劲的位置。

文件上传是另一个重灾区。很多旧系统只在前端限制了文件类型，后端几乎不做校验，或者只检查了扩展名。更危险的是，上传目录如果还保留了脚本执行权限，攻击者传一个伪装的 PHP 文件上去，就能直接在服务器上执行任意代码。审计时要检查的不只是有没有做类型校验，还包括上传后的存储路径是否在 Web 可访问目录之外、文件名是否做了随机化处理、文件大小有没有上限。

第三方回调入口是最容易被忽视的。支付通知、消息推送、Webhook 这些接口，当年为了快速上线，常常只实现了业务逻辑，没做请求来源验证。攻击者如果摸清了回调地址和数据格式，完全可以伪造请求，篡改订单状态或者触发不该执行的操作。审计这类入口时，签名验证、时间戳防重放、回调地址白名单这三样至少要检查一遍。如果发现什么都没做，这个漏洞的优先级应该排在最前面。

还有个容易被忽略的点是配置泄露。数据库密码、第三方密钥、加密盐值这些敏感信息，如果硬编码在代码里又随 Git 仓库一起公开了，那前面的所有安全加固都可能白做。旧项目里常见的情况是，配置文件一开始被随手放在项目根目录，后来虽然移到了外部，但 Git 历史里还完整保留着。审计时不仅要看当前代码，还得翻一遍提交记录。

说到底，外部触发入口的安全审计，核心原则就一条：凡是能从外部触发的路径，默认都不安全。按这个思路去排查，优先级自然会清晰起来。