Web服务器防范敏感信息泄露的服防范方式有

一次渗透测试中，我随手在目标站点的敏感响应头里看到了X-Powered-By: PHP/7.0.3，紧接着顺着报错页面暴露的信息泄露绝对路径，直接拖出了/var/www/html/config.php的服防范备份文件。这不是敏感什么高深攻击，纯粹是信息泄露服务器自己把底裤亮了出来——敏感信息泄露，九成以上是服防范配置和习惯问题，而非漏洞本身。敏感

最直接的信息泄露防线是收敛响应头。默认的服防范Server头会精确到版本号，等于告诉攻击者“来打这个已知CVE”。敏感用Nginx就把server_tokens off;写上，信息泄露Apache则改ServerTokens Prod。服防范顺手把X-Powered-By、敏感X-AspNet-Version这类框架指纹全剥掉。信息泄露别小看这点信息，去年某国企内网被日穿，起因就是对方从响应头识别出老版本Tomcat，直接打了一个五年前的反序列化漏洞。

错误页面是另一个重灾区。默认的404、500页面会吐出物理路径、SQL语句片段甚至堆栈跟踪。我见过一个金融系统，数据库连接串直接打印在报错页面里——因为开发图省事，把display_errors开到了生产环境。正确做法是全局关闭调试输出，同时准备一套统一的友好错误页，把真实异常写入服务器日志而不是返回给客户端。记住，日志是给运维看的，不是给攻击者看的。

目录遍历和备份文件泄露往往被忽略。很多团队把.bak、.swp、.git目录留在web根目录下，以为删了入口文件就安全。实际上，只要autoindex开着，或者路径可预测，攻击者就能直接下载源码压缩包。我在一次众测里，就是靠猜/www.zip路径，把整个站点源码拷走了——里面躺着数据库密码和支付回调密钥。所以，务必关闭目录列表，对敏感扩展名做白名单拦截，同时确保.git这类目录无法通过web访问。

再说说配置文件的权限管理。web进程通常以www-data运行，但很多运维图省事把整个项目目录设成777。这等于让攻击者一旦getshell，就能直接改写配置或植入后门。正确做法是：代码目录只读，上传目录单独隔离并禁止执行脚本，配置文件放在web根目录之外。比如Laravel项目，.env文件默认就在上级目录，但总有人手动把它挪到public下面——那就别怪扫描器扫到它。

最后提一个容易翻车的地方：第三方组件的默认页面。比如安装完phpMyAdmin不删setup目录，或者Redis没设密码还暴露在公网。这类问题不产生日志，但危害极大。我碰到过一个案例，对方服务器上开着Jenkins默认端口，未登录就能查看构建日志，里面硬编码了云厂商的AccessKey。结果整个OSS桶被拖空，数据被勒索。

敏感信息泄露的根子在于“信任默认值”——信任框架的默认配置，信任开发环境的调试模式，信任内网不会出问题。但web服务器天生就是暴露在恶意流量下的，你每多藏一份信息，攻击者就得多花十倍的探测时间。把上述几点落实了，至少能挡住九成脚本小子的随机扫描。剩下的，靠日志监控和及时补丁去兜底。

(责任编辑：综合)