Web安全加固

去年冬天，全加一个做跨境电商的全加朋友半夜给我打电话，说网站被挂马了。全加后台多出十几个管理员账号，全加支付页面被注入了窃取信用卡信息的全加脚本。他问我：“服务器防火墙不是全加开着吗？”我登进去一看，数据库端口直接暴露在公网，全加密码还是全加`admin123`。防火墙？全加形同虚设。

Web安全加固这件事，全加很多人理解成装个WAF、全加开个HTTPS就完事了。全加实际情况远没那么简单。全加攻击者不会正面硬刚你的全加防护设备，他们专挑你忽略的全加角落下手。

输入验证是最容易被跳过的环节

SQL注入到今天依然是重灾区。原因很朴素：开发图省事，直接把用户输入拼进查询语句。`SELECT * FROM users WHERE id = ' + request.getParameter("id")`，这种代码在老旧系统里一抓一大把。加固的手段不复杂，参数化查询能解决绝大部分问题。但麻烦在于，遗留系统改造成本高，很多团队选择“先上线再说”。

XSS同理。用户提交的评论、昵称、个人简介，如果输出时不做转义，一段`<script>`就能让所有访问者中招。我见过一个论坛，攻击者在签名里植入挖矿脚本，整整跑了三个月才被发现。防御方式无非是输出编码加CSP策略，但关键在于每一条输出路径都要覆盖，漏一个就等于没做。

会话管理里的坑比想象中多

Session ID放在URL里传递，这操作现在听起来离谱，但某些老框架默认就这么干。一旦用户把链接分享出去，会话就被劫持了。Cookie必须设置`HttpOnly`和`Secure`，`SameSite`属性也得根据业务场景选对值。CSRF token不能省，尤其是涉及转账、改密码这类操作。

还有个细节：Session过期时间。见过一个后台管理系统，登录后session永不过期。运维人员嫌反复登录麻烦，主动把超时设成了负数。方便是方便了，风险也拉满了。

文件上传是另一个高频入口

限制扩展名？不够。攻击者可以把`.php`改成`.php5`、`.phtml`，甚至利用解析漏洞上传图片马。正确做法是白名单校验扩展名、重命名文件、把上传目录放在Web根目录之外，再配合服务器配置禁止该目录执行脚本。四层防护缺一不可。

文件包含漏洞也值得提一句。`include($_GET['page'])`这种写法，攻击者通过路径穿越能读取服务器上的任意文件，甚至执行远程代码。加固方式很直接：不要用用户输入拼接文件路径，用白名单映射。

安全响应头经常被遗忘

`X-Content-Type-Options: nosniff`防止MIME类型嗅探，`X-Frame-Options: DENY`挡住点击劫持，`Strict-Transport-Security`强制HTTPS。这些配置加在Nginx或Apache层面，几行代码的事，但很多项目上线时压根没检查过。

我自己的习惯是，每次新项目部署前跑一遍OWASP ZAP的基线扫描，再手动过一遍上面这些点。工具能查出六成问题，剩下的四成靠经验和耐心。安全加固没有一劳永逸的方案，它更像是一个持续修补的过程。你今天忽略的那个参数，可能就是明天入侵者的入口。