发现漏洞别慌，先搞清楚类型
前几天朋友老李急匆匆找我，说公司网站突然打不开，后台还跳出一堆奇怪的提示。一看日志，是被人通过一个旧版本的CMS漏洞上传了恶意脚本。这种情况其实很常见，关键是怎么修。
漏洞不是单一问题，得先分清是系统层、应用层还是配置类的问题。比如服务器用的是Linux，长期没更新内核，可能有提权漏洞；网站用的WordPress插件老旧，可能被SQL注入；防火墙规则放开了不必要的端口，也可能成为突破口。
及时更新是基础操作
很多漏洞其实在官方发布补丁时就已经能解决。像Apache、Nginx、PHP这些常用组件，一旦爆出高危漏洞，开发团队通常会快速推出修复版本。定期执行系统更新命令，能挡住大部分低级攻击。
yum update -y && apt-get upgrade -y这行命令看着简单，但不少运维人员因为怕影响业务就一直拖着，结果给了黑客可乘之机。建议在测试环境先验证更新兼容性，再推到生产环境。
针对Web应用漏洞的处理方式
如果你跑的是网站，常见的XSS、SQL注入、文件包含这类问题，光靠更新不一定够。比如某个PHP页面直接拼接用户输入：
$sql = "SELECT * FROM users WHERE id = " . $_GET['id'];<br>$result = mysqli_query($conn, $sql);这种写法很容易被构造恶意参数绕过验证。修复方法是改用预处理语句：
$stmt = $conn->prepare("SELECT * FROM users WHERE id = ?");<br>$stmt->bind_param("i", $user_id);<br>$stmt->execute();哪怕用户传进来的是' OR 1=1--，也不会破坏查询逻辑。
权限和配置也不能忽视
有些“漏洞”其实是配置不当。比如数据库账号用了root，网站目录权限设成777，或者php.ini里allow_url_include没关。这些都不是程序本身的缺陷，但同样危险。
正确的做法是遵循最小权限原则：Web服务运行用户不要有root权限，数据库连接用专用账号并限制IP访问，敏感文件如配置文件放到web根目录之外。
还有个容易被忽略的地方——日志。出事之后翻不到记录，等于瞎子摸象。确保关键服务开启日志，并定期检查异常请求，比如频繁404、大量POST到不存在的接口，都可能是扫描或攻击前兆。
修补之后还要验证
改完代码、打完补丁，别以为就万事大吉。可以用工具简单测一下，比如用curl模拟攻击请求，看是否还能复现问题。
curl 'http://yoursite.com/search.php?q=<script>alert(1)</script>'如果页面正常输出内容而不执行脚本，说明XSS修复有效。也可以用开源扫描器如OpenVAS做一轮基础检测。
最后提醒一句，别迷信“一劳永逸”的解决方案。新漏洞每天都在冒出来，保持警惕，定期巡检，才是长久之计。