一、过期没打的组件，等于把门虚掩着
企业网站很少从零写起，多半架在现成的建站程序、框架和一堆插件上。问题也出在这：装完就没人管了。插件作者发了安全更新，站点管理员不知道；框架出了高危漏洞，补丁在服务器上躺了半年。公开的漏洞利用代码很容易获取，攻击者用自动化扫描工具在 互联网上找到版本号对得上的站点就直接打，拼的是谁动作快，不需要多高深的技术。
对策是把"定期更新"写进运维流程，订阅安全公告，建立更新台账，一有补丁就安排测试更新。插件只留正在用的，停用的删掉而不是禁用。更新前先在测试环境过一遍，避免插件冲突把站点搞挂——但"怕出问题就不更新"不是办法，是拖时间。
二、弱口令和默认账号，最老也最好用
后台管理员密码设成"admin123"，数据库账号和网站账号共用一个密码，设备装好之后默认口令从来没改过，后台登录地址默认不变，还没有登录次数限制。这类问题年年说，年年有。攻击者用撞库、暴力破解、泄露密码库批量试，自动化工具一晚上能试几万个组合，几分钟就能扫出一堆弱口令，直接进后台改页面、挂木马。这个漏洞不需要任何技术含量，纯靠管理员懒。
对策是后台登录加失败次数限制和验证码，管理账号开双因素认证。不同系统用不同密码，别一套走天下。不同人员分配独立账号，离职人员及时回收权限。默认账号要么改要么删，尤其是那些安装完就忘了的测试账号。
三、注入类漏洞，输入框就是入口
用户输入的地方没做过滤，攻击者往表单、URL参数里塞构造好的语句，轻则拖走数据库，重则拿到服务器权限。SQL注入喊了二十年，老系统里还是能碰到。搜索框、登录框、翻页参数、留言输入框都是常见入口，有回显的直接读数据，没回显的盲注慢慢猜。
对策是参数化查询或使用ORM框架，别把用户输入直接拼进语句。输入校验做在服务端，前端校验只是体验优化，挡不住人。数据库账号按最小权限配，网站用的账号别给删库建表的权限。培训时要让开发明白，任何用户输入都可能是恶意载荷，不能信任。
四、文件上传口子没管住，后门直接送上楼
需要上传图片、附件的功能很常见，但上传目录如果没限制类型、没改文件名、还能被当脚本执行，攻击者传一个脚本文件上去，就等于在服务器上开了个门，这也是勒索病毒植入、页面挂黑链的常见入口。常见手法包括改扩展名绕过黑名单、伪造文件头骗过类型检测、利用解析漏洞让图片里藏的代码被执行，上传成功后访问那个文件，后门就跑起来了。
对策是白名单限定允许的扩展名，上传后重命名并去掉执行权限，上传目录单独存放、禁止脚本执行，别和程序目录混在一起。文件内容做二次检测，光看后缀不够，有条件用杀毒引擎扫描。非必要的上传功能直接关闭。
五、权限配得松，越权访问防不住
后台功能做了登录校验，但没校验"这个用户有没有权限看这条数据"。改一下URL里的ID就能看到别人的订单、别人的资料，水平越权和垂直越权都算这一类。这类漏洞最容易被忽视，因为扫描器扫不出来，靠的是开发时没做好权限校验和逻辑判断。
对策是每个请求都在服务端做权限判断，别信前端传上来的身份标识。接口返回字段按需给，敏感信息脱敏，前端藏起来没用，抓包就看见了。上线前做一轮越权测试，比事后补救便宜得多。教育重点放在代码审查环节，每个涉及数据的请求都必须验证当前用户是否有权操作。
这五类漏洞有个共同点：都不是什么新鲜攻击手法，靠的都是基础工作没做到位。很多企业觉得网站只放宣传内容、没有交易功能，风险不大，运维投入很少；外包建站交付后服务商不再跟进，内部人员不懂维护、不敢升级，风险持续累积。安全培训如果只让员工背概念，不如把这几条落到具体岗位上——谁负责更新组件、谁管账号策略、开发提交代码前有没有做输入校验和权限检查。用真实案例代替抽象说教，把漏洞检查变成日常动作：运维定期扫描漏洞、查看插件版本、检查后台登录日志，重点盯上传入口、搜索和留言模块；开发上线前自己先试一遍常见套路。概念背得再熟，补丁不打、密码不改，攻击者该进还是进。
