网站漏洞防护之信息泄露与错误页面安全配置

网站信息泄露最隐蔽的出口往往不在数据库查询接口，而在那些被运维人员忽略的HTTP错误页面和默认配置里。攻击者通过触发404、403或500错误，就能从看似无害的报错页面中提取出服务器版本、框架指纹、物理路径甚至内网架构信息。Apache Tomcat的默认404页面会直接暴露版本号，Nginx在没有自定义错误页时会把后端地址和响应头一并返回，这些碎片化信息经过组合，就能拼凑出一张完整的攻击地图。

第一种是应用服务器自带的管理后台错误页。WebLogic的404页面默认会显示“From RFC 2068 Hypertext Transfer Protocol”，同时附带Server头信息，攻击者用搜索引擎搜索这段特征字符串，就能批量定位暴露在公网的WebLogic节点。第二种是框架调试模式未关闭，Spring Boot应用如果在生产环境开启了debug=true，请求一个不存在的路由会返回Whitelabel Error Page，页面里详细列出了请求路径、时间戳和堆栈跟踪，其中堆栈信息直接暴露了包名和类结构。第三种是CDN回源错误，当CDN节点无法连接到源站时，默认错误页可能会显示源站IP地址，这个IP一旦暴露，攻击者就能绕过CDN直接对源站发动DDoS攻击或漏洞扫描。

针对Web服务器的错误页配置，核心原则是统一拦截、最小化输出。Nginx层面需要在server块中定义error_page指令，把常见的4xx和5xx状态码都指向同一个静态HTML文件，同时关闭server_tokens，禁止在响应头中显示版本号。具体配置可以这样写：

server {
    listen 443 ssl;
    server_name example.com;
    server_tokens off;
    
    error_page 400 401 403 404 405 408 413 414 500 502 503 504 /error.html;
    location = /error.html {
        root /usr/share/nginx/html;
        internal;
    }
    
    proxy_intercept_errors on;
    proxy_pass http://backend;
}

这里有个容易遗漏的细节，proxy_intercept_errors必须设置为on，否则当后端返回错误状态码时，Nginx不会用本地错误页替换，而是直接把后端的原始错误响应透传给客户端。Apache的配置逻辑类似，需要在httpd.conf中设置ErrorDocument指令，同时用ServerSignature Off和ServerTokens Prod来抑制版本信息输出。IIS则需要通过web.config中的httpErrors节点来配置，关键属性是errorMode要设为“Custom”，existingResponse要设为“Replace”，确保完全替换掉底层应用抛出的错误信息。

Web服务器层面的错误页配置只能拦截未到达应用的请求错误，对于应用内部抛出的异常，必须在代码层做统一异常处理。以Java的Spring Boot为例，全局异常处理器需要捕获所有未被Controller层处理的异常，返回一个不包含任何技术细节的通用错误响应。实现方式是用@ControllerAdvice注解配合@ExceptionHandler，在处理器中记录详细日志供内部排查，但给客户端只返回一个业务状态码和通用提示信息。关键是要把异常堆栈、SQL语句、接口调用参数这些敏感信息全部过滤掉，绝不能像默认的500错误那样原样输出。

很多人只关注响应体里的错误内容，却忽略了响应头本身就是信息泄露的重灾区。Server头会暴露Web服务器类型和版本，X-Powered-By头会暴露后端语言和框架，X-AspNet-Version头在ASP.NET应用中默认开启，Set-Cookie头里的JSESSIONID或PHPSESSID会暴露会话机制类型。更隐蔽的是，某些中间件会在响应头中添加自定义字段，比如某WAF产品会在X-Cache头里返回命中状态和节点信息，攻击者可以据此判断WAF规则是否存在绕过可能。消除这些头信息需要在反向代理层做统一处理，Nginx可以用more_clear_headers模块批量清除，或者在proxy_pass时用proxy_hide_header逐条屏蔽。如果不想引入第三方模块，也可以在应用代码中通过框架配置来禁用，比如Spring Boot在application.properties中设置server.server-header=none。

Web服务器默认开启的目录浏览功能是信息泄露的重灾区。Apache的mod_autoindex模块如果未被禁用，访问一个没有索引文件的目录就会列出所有文件和子目录，攻击者可以直接浏览网站目录结构，下载备份文件、日志文件或配置文件。Nginx默认没有开启目录浏览，但如果配置了autoindex on，同样会产生这个问题。封堵方法很简单，在Nginx的location块中明确设置autoindex off，在Apache的Directory指令中设置Options -Indexes。但光关闭目录浏览还不够，还需要防止攻击者通过猜解常见文件名来探测敏感文件。.git目录、.svn目录、.DS_Store文件、备份文件后缀如.bak和.swp，这些都应该在Web服务器层面直接禁止访问，Nginx可以用location ~ /\.来匹配所有以点开头的隐藏文件和目录，返回403或404。

现代Web应用大量使用前端框架，JavaScript源码中经常硬编码着API接口地址、第三方服务密钥、内网测试环境的URL甚至数据库连接配置。Webpack打包时如果没有做代码混淆和压缩，这些信息会以明文形式暴露在浏览器开发者工具中。更严重的是sourcemap文件，如果生产环境错误地部署了.js.map文件，攻击者可以直接还原出完整的源代码结构，找到业务逻辑漏洞和未授权的API端点。构建流程中必须确保生产构建不包含sourcemap，或者在Nginx层对.map后缀的请求直接返回404。对于必须暴露在前端的配置信息，应该通过环境变量注入，而不是直接写在代码里。

SQL注入攻击之所以能成功，很大程度上依赖数据库抛出的详细错误信息。MySQL的语法错误会返回“You have an error in your SQL syntax”，附带出错的SQL语句片段，攻击者利用这些反馈不断调整注入载荷，直到绕过验证逻辑。PostgreSQL的错误信息更加详细，会返回表名、列名和数据类型。防御的关键不是阻止SQL注入本身，而是在数据库连接层和ORM层做双重静默处理。数据库连接字符串中要关闭详细错误输出，PHP的PDO要设置PDO::ATTR_ERRMODE为PDO::ERRMODE_SILENT，Java的JDBC连接要避免使用printStackTrace直接输出异常。ORM框架层面，MyBatis和Hibernate都需要配置全局异常拦截器，把数据库层抛出的异常转换成通用错误码后再返回。

文件上传功能如果处理不当，错误提示会直接暴露服务器的物理路径。PHP应用在上传失败时，move_uploaded_file函数返回false，如果开发者直接用die或echo输出错误信息，就会把临时目录路径、目标目录路径全部显示出来。Java的MultipartFile上传在抛出IOException时，异常消息里也常常包含文件存储的绝对路径。正确的做法是捕获所有文件操作异常，记录到日志系统，给用户只返回“上传失败，请重试”这样的通用提示。上传目录本身也要配置为不可执行脚本，Nginx中对该目录的location块设置fastcgi_pass off或者直接禁止PHP解析。

RESTful API的错误响应如果不做标准化处理，不同模块抛出的异常格式各异，有的返回JSON，有的返回HTML，有的直接返回字符串，攻击者能从格式差异中推断出后端技术栈的边界和模块划分。应该建立统一的API错误响应格式，包含标准的HTTP状态码、业务错误码和人类可读的错误消息，不包含任何调试信息。对于GraphQL接口，即使查询语法错误，也不应该在errors字段中返回堆栈跟踪，production环境必须关闭debug模式。API网关层可以统一处理所有后端服务的错误响应，把不同服务的错误格式转换成一致的外部格式。

把所有错误信息都对用户隐藏之后，内部排查问题就完全依赖日志系统。日志中需要记录完整的请求上下文、异常堆栈、用户身份标识和时间戳，但日志本身的安全也不能忽视。日志文件如果存储在Web可访问的目录下，或者通过一个未授权的API接口就能查询，那就等于把隐藏的信息又暴露了出来。集中式日志系统应该部署在内网，通过VPN或专线访问，日志内容中如果包含敏感数据要做脱敏处理。同时要建立错误频率监控，某个IP短时间内触发大量404或500错误，很可能是攻击者在进行信息探测，应该自动触发告警或临时封禁。

信息泄露防护不是单一环节的工作，需要在Web服务器、应用框架、代码逻辑、日志系统和监控告警五个层面形成纵深防御。Web服务器层负责拦截目录浏览、隐藏版本信息、统一错误页；应用框架层负责全局异常捕获和响应头清理；代码逻辑层负责文件操作、数据库操作的静默处理；日志系统层负责安全存储和脱敏；监控告警层负责发现探测行为并及时响应。每一层都要假设外层可能已经被绕过，独立做好自己的防护。定期用自动化扫描工具对生产环境做信息泄露检测，重点检查HTTP响应头、错误页面内容、JavaScript源码和robots.txt中是否暴露了敏感路径，把信息泄露的排查纳入每次版本上线的安全检查清单里。