ASP.NET WebForms站点根目录下危险Request.Path问题排查求助

老兄，我懂这种卡在“本该早就搞定”问题上的烦躁——渗透测试报告收尾阶段卡这种小节点，简直比挖到高危漏洞还闹心😅。先说说你用global.asax拦截HttpExceptions这个操作：确实能生效，但这种“事后拦截”的方式其实存在不少潜在问题，咱们一步步捋清楚，再给你更稳妥的方案。

先聊聊当前拦截方式的局限 #

• 覆盖不全：HttpException只是ASP.NET抛出的异常类型之一，还有路由错误、请求解析异常（像你举的那个恶意URL，可能触发的是请求路径解析时的异常，未必都会包装成HttpException），这些场景可能绕开你的拦截。
• 不够优雅：在global.asax里直接拦截相当于全局“兜底”，但没有从根源上控制错误输出，万一后续代码有遗漏，还是可能泄露敏感信息。
• 调试不便：开发环境下如果一直开着拦截，排查问题会很麻烦，得频繁切换开关。

针对你的场景，更规范的替代方案 #

1. 用ASP.NET自定义错误页（Web.config配置） #

这是官方推荐的方式，比global.asax拦截更全面，能覆盖大部分异常场景：

<configuration>
  <system.web>
    <customErrors mode="RemoteOnly" defaultRedirect="~/Error/General">
      <error statusCode="404" redirect="~/Error/NotFound"/>
      <error statusCode="500" redirect="~/Error/ServerError"/>
    </customErrors>
  </system.web>
  <!-- ASP.NET MVC/.NET Framework后期版本需补充此配置 -->
  <system.webServer>
    <httpErrors errorMode="Custom" existingResponse="Replace">
      <remove statusCode="404"/>
      <remove statusCode="500"/>
      <error statusCode="404" path="/Error/NotFound" responseMode="ExecuteURL"/>
      <error statusCode="500" path="/Error/ServerError" responseMode="ExecuteURL"/>
    </httpErrors>
  </system.webServer>
</configuration>

• mode="RemoteOnly"：本地开发环境显示详细错误方便调试，远程访问自动跳自定义错误页，兼顾安全与开发效率。
• existingResponse="Replace"：确保服务器自带的错误响应被完全替换，不会泄露默认错误信息。

2. 针对恶意URL的前置处理 #

你举的那个包含编码后<script>的URL，本质是路径注入/XSS探测，除了拦截异常，更应该在请求到达业务逻辑前就处理：

• 路由约束：在路由配置里添加正则约束，限制路径只能包含合法字符，比如：

routes.MapRoute(
    name: "Default",
    url: "{controller}/{action}/{id}",
    defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional },
    constraints: new { id = @"^[a-zA-Z0-9-_]*$" } // 限制id仅允许字母、数字、下划线、短横线
);

• 请求前置校验：在Global.asax的Application_BeginRequest里提前检查请求路径，发现可疑字符直接返回403：

protected void Application_BeginRequest(object sender, EventArgs e)
{
    var rawUrl = Request.RawUrl;
    // 检测编码后的危险字符或脚本关键字
    if (rawUrl.Contains("%3cscript%3e") || rawUrl.Contains("%3c/script%3e") || rawUrl.Contains("eval("))
    {
        Response.StatusCode = 403;
        Response.End();
        return;
    }
}

这种前置拦截比事后处理异常更高效，也能减少服务器不必要的异常抛出。

3. 补充：全局异常过滤器（针对MVC项目） #

如果是ASP.NET MVC项目，用全局异常过滤器比global.asax更贴合框架设计：

public class CustomExceptionFilter : IExceptionFilter
{
    public void OnException(ExceptionContext filterContext)
    {
        if (!filterContext.ExceptionHandled)
        {
            // 记录异常日志（注意不要写入敏感信息！）
            // Logger.Log(filterContext.Exception.Message);
            
            // 根据异常类型返回对应错误页
            if (filterContext.Exception is HttpException httpEx)
            {
                filterContext.Result = new RedirectResult($"~/Error/HttpError/{httpEx.GetHttpCode()}");
            }
            else
            {
                filterContext.Result = new RedirectResult("~/Error/General");
            }
            filterContext.ExceptionHandled = true;
        }
    }
}

然后在Global.asax的Application_Start里注册：

GlobalFilters.Filters.Add(new CustomExceptionFilter());

最后提个小建议 #

渗透测试里这种“本该前期解决”的问题，大多是因为前期只关注功能开发，没做基础的安全边界控制。这次修复后，可以把请求合法性校验、错误信息管控加到团队的编码规范里，避免下次再踩同样的坑。

内容的提问来源于stack exchange，提问作者DrMistry