以下哪些是防止网站存在漏洞的防护措施

上周帮朋友看一个刚上线的电商站，后台登录框没做频率限制，止网站存我拿 Burp 跑了一百个弱密码，漏洞三分钟就进去了。护措他一脸懵：“我用了 HTTPS 啊，下防怎么还能被爆破？止网站存” 这事挺典型——很多人把“加密传输”和“防漏洞”画等号。那到底哪些操作才算真正在堵漏洞？漏洞我按实际踩过的坑来筛一遍。

输入验证和参数化查询，护措这两个得捆在一起说。下防SQL 注入能活到今天，止网站存就是漏洞因为有人还在拼 SQL 字符串。我见过一个老系统，护措搜索框输入 ' OR 1=1 -- 直接吐出了整张用户表。下防参数化查询（Prepared Statement）把数据和指令分开，止网站存数据库不会把用户输入当代码执行。漏洞输入验证则是第一道筛子，比如手机号字段只允许数字，长度固定 11 位，多余字符直接拒掉。别指望前端 JS 校验，那玩意儿关掉浏览器就废了。

输出编码经常被忽略。XSS 攻击不一定要你“存”恶意脚本，反射型也能弹窗。有个论坛把用户昵称直接 innerHTML 到页面，结果昵称改成 <img src=x onerror=alert(1)> 就中招。正确做法是输出到 HTML 上下文用 HTML 实体编码，输出到 JS 里用 \x 转义，别一套编码走天下。

身份认证和会话管理这块，漏洞往往出在“省事”上。见过一个后台，登录后 session ID 直接放在 URL 里 ?sid=abc123，分享链接就把自己卖了。还有 cookie 不设 HttpOnly 和 Secure，XSS 一打一个准。密码存储用 MD5 加盐？现在显卡跑 MD5 每秒几十亿次，得用 bcrypt 或 argon2 这种慢哈希。另外，登录失败次数限制、验证码、多因素认证，这些不是可选项——我那个朋友的后台，加上失败锁定后，爆破成本直接从三分钟变成三年。

访问控制得细到每个接口。有个 API 设计成 /api/user/123/orders，我把 123 改成 124 就能看别人的订单。这叫 IDOR（不安全的直接对象引用）。修复方法不是把 ID 换成 UUID 就完事——UUID 可预测照样能猜。关键是在服务端每次请求都校验：当前登录用户有没有权限访问这个资源？别信前端传过来的 user_id，那玩意儿随便改。

安全配置错误排 OWASP 前十好多年了。默认口令、目录列表、错误堆栈直接回显、不必要的端口开放……我扫过一个站，/.git/config 能直接下载，里面数据库密码明文躺着。还有 phpinfo() 页面没删，攻击者连你 PHP 版本、扩展、环境变量全知道了。生产环境关掉 display_errors，删掉测试文件，改掉默认管理员路径，这些是基本功。

依赖组件漏洞现在越来越要命。Log4j2 那次，多少站半夜爬起来打补丁。你代码写得再干净，引用的第三方库有 RCE，照样完蛋。得用 npm audit、OWASP Dependency-Check 这类工具定期扫，别等 CVE 爆出来才慌。我习惯在 CI 里加一步依赖检查，有高危直接构建失败。

日志和监控不是事后诸葛亮。有次一个站被传了 webshell，翻日志发现半年前就有异常 POST 请求，但没人看。日志要记关键操作——登录、改密码、文件上传、权限变更，并且集中存储，别放本地让攻击者顺手删了。监控告警设阈值，比如一分钟内 50 次 404，可能是目录扫描。

最后说个反直觉的：安全培训比买设备管用。开发图省事写个 eval($_POST['code'])，你上十个 WAF 也拦不住。让团队知道常见漏洞怎么产生的，比堆产品有效。我见过一个前端，把 API 密钥硬编码在 JS 里，还说“反正压缩了看不见”——压缩又不是加密。

所以回到标题，哪些是防护措施？输入验证、参数化查询、输出编码、强认证、细粒度访问控制、安全配置、依赖管理、日志监控、人员培训——这些都得做，缺一个就是木桶短板。HTTPS 只是其中一块板，别拿它当全部。