漏洞名称：未自定义统一错误页面导致信息泄露，抛出异常信息泄露，错误详情信息泄漏，AWVS漏洞名称如下：
Application error message
Error message on page
ASP.NET error message

漏洞描述：攻击者可通过构造恶意请求包触发Web应用程序报错，提取报错信息泄露的敏感信息，如Web中间件的版本信息、数据库连接信息。

检测条件：1、 被测网站web业务正常运行

检测方法：

1、 通过web扫描工具对网站扫描可得到结果。
2、 或者通过手工，去尝试打开一些不存在的网站路径，或者文件，以及在url中输入一些敏感的字符，看其页面是否会抛出异常或者报错，导致错误消息中包含一些网站架构，版本，等敏感信息。

修复方案：

1、 对于tomcat的中间件下，常用修复方式如下：找到配置文件web.xml,修改内容如下：

配置一个统一的静态页面，将400、403、404、500等常见报错重定向到该静态页面，而不是抛出异常（报错信息导致代码信息泄漏）。

<error-page>
<exception-type>java.lang.Throwable</exception-type>
<location>/jsp/common/error.html</location>
</error-page>
<error-page>
<error-code>500</error-code>
<location>/jsp/common/error.html</location>
</error-page>
<error-page>
<error-code>404</error-code>
<location>/jsp/common/error.html</location>
</error-page>
<error-page>
<error-code>403</error-code>
<location>/jsp/common/error.hrml</location>
</error-page>

2、 对于常用的jsp语言开发的网站，可在业务流程中，加入异常捕获过程中预定义的错误编码，将异常输出到错误日志中，并在前台页面返回相应的错误编码，以便应用系统运维人员进行异常排查。代码参考：

try {
//某业务处理流程
……
} catch (Exception e) {
e.printStackTrace();
logger.error(e.getMessage());
resultMessage = getText("业务处理发生异常，错误编码A-04221!");
return "errorJsp";
}

3、 对于IIS/ASP.net下设置404错误页面：这样，便可以保证IIS能够正确地返回‚404‛状态码：首先，修改应用程序根目录的设置，打开 ‚web.config‛ 文件编辑，在其中加入如下内容：

＜configuration＞
＜system.web＞
＜customErrors mode=‛On‛ defaultRedirect=‛error.asp‛＞
＜error statusCode=‛404″ redirect=‛notfound.asp‛ /＞
＜/customErrors＞
＜/system.web＞
＜/configuration＞

注：上文例中‚error.asp‛为系统默认的404页面，‚notfound.asp‛为自定义的404页面，使用时请修改相应文件名。然后，在自定义的404页面‚notfound.asp‛中加入将显示的代码页面，如‚not found‛。

4、 对于apache服务器的设置：修改 httpd.conf，找到如下：

#ErrorDocument 500 "The server made a boo boo."
#ErrorDocument 404 /missing.html
#ErrorDocument 404 "/cgi-bin/missing_handler.pl"
#ErrorDocument 402 http://www.example.com/subscription_info.html
httpd.conf中的这一部分,#ErrorDocument 404 /missing.html 是显示错误
页信息的,去掉前面的#，修改为：ErrorDocument 404 /404.jsp

5、 对于PHP中间件的使用者，可通过修改php.ini文件来实现如果关闭与开启错误信息，关闭错误显示后，php函数执行错误的信息将不会再显示给用户，这样能在一定程度上防止攻击者从错误信息得知脚本的物理位置，以及一些其它有用的信息，起码给攻击者的黑箱检测造成一定的障碍。这些错误信息可能对我们自己有用，可以让它写到指定文件中去，那么修改以下

log_errors = Off
改为：
log_errors = On
以及指定文件，找到下面这行：
;error_log = filename
去 掉 前 面 的 ; 注 释 ， 把 filename 改 为 指 定 文 件 ， 如
/usr/local/xxx/logs/php_error.log
error_log = /usr/local/xxx/logs/php_error.log
这样所有的错误都会写到php_error.log文件里。

6、 对于J2EE项目开发的网站，如果想通过捕获抛出的异常信息的方式来修复，可以使用Spring MVC统一异常处理的方法来进行修复， Spring MVC处理异常有3种方式：

6.1、 使用Spring MVC提供的简单异常处理器SimpleMappingExceptionResolver：

<bean class="org.springframework.web.servlet.handler.SimpleMapping
ExceptionResolver">
<!-- 定义默认的异常处理页面，当该异常类型的注册时使用 -->
<property name="defaultErrorView" value="error"></property>
<!-- 定义异常处理页面用来获取异常信息的变量名，默认为exception --〉
<property name="exceptionAttribute" value="ex"></property>
<!-- 定义需要特殊处理的异常，用类名或完全路径名作为key，异常也页名作为值
-->
<property name="exceptionMappings">
<props>
<prop
key="cn.basttg.core.exception.BusinessException">error-business</prop>
<prop
key="cn.basttg.core.exception.ParameterException">error-parameter</prop>
<!-- 这里还可以继续扩展对不同异常类型的处理 -->
</props>
</property>
</bean>

启动测试项目，经验证，各种层面所抛出的异常（业务异常BusinessException、参数异常ParameterException和其它的异常Exception）都能准确显示定义的异常处理页面，达到了统一异常处理的目标。使用SimpleMappingExceptionResolver进行异常处理，具有集成简单、有良好的扩展性、对已有代码没有入侵性等优点，但该方法仅能获取到异常信息，若在出现异常时，对需要获取除异常以外的数据的情况不适用。

6.2、 实现Spring的异常处理接口HandlerExceptionResolver 自定义自己的异常处理器； 增加HandlerExceptionResolver 接口的实现类MyExceptionHandler，代码如下：

1..public class MyExceptionHandler implements
HandlerExceptionResolver {
2.
3. public ModelAndView resolveException(HttpServletRequest
request, HttpServletResponse response, Object handler,
4. Exception ex) {
5. Map<String, Object> model = new HashMap<String, Object>();
6. model.put("ex", ex);
7.
8. // 根据不同错误转向不同页面
9. if(ex instanceof BusinessException) {
10. return new ModelAndView("error-business", model);
11. }else if(ex instanceof ParameterException) {
12. return new ModelAndView("error-parameter", model);
13. } else {
14. return new ModelAndView("error", model);
15. }
16. }
17.}
在Spring的配置文件applicationContext.xml中增加以下内容：
<bean
id="exceptionHandler"
class="cn.basttg.core.exception.MyExceptionHandler"/>

启动测试项目，经验证各种层抛出的异常（业务异常BusinessException、参数异常ParameterException和其它的异常Exception）都能准确显示定义的异常 处 理 页 面 ， 达 到 了 统 一 异 常 处 理 的 目 标 ， 使 用 实 现HandlerExceptionResolver接口的异常处理器进行异常处理，具有集成简单、有良好的扩展性、对已有代码没有入侵性等优点，同时，在异常处理时能获取
导致出现异常的对象，有利于提供更详细的异常处理信息。

6.3、 使用@ExceptionHandler注解实现异常处理；增加BaseController类，并在类中使用@ExceptionHandler注解声明异常处理，代码如下：

1.public class BaseController {
2. /** 基于@ExceptionHandler异常处理 */
3. @ExceptionHandler
4. public String exp(HttpServletRequest request, Exception ex) {
5.
6. request.setAttribute("ex", ex);
7.
8. // 根据不同错误转向不同页面
9. if(ex instanceof BusinessException) {
10. return "error-business";
11. }else if(ex instanceof ParameterException) {
12. return "error-parameter";
13. } else {
14. return "error";
15. }
16. }
17.}

修改代码，使所有需要异常处理的Controller都继承该类，如下所示，修改后的TestController类继承于BaseController：public class TestController extends BaseController使用@ExceptionHandler注解实现异常处理，具有集成简单、有扩展性好（只需要将要异常处理的Controller类继承于BaseController即可）、不需要附加Spring配置等优点，但该方法对已有代码存在入侵性（需要修改已有代码，使相关类继承于BaseController），在异常处理时不能获取除异常以外的数据。