ASP.NET MVC应用安全性(一)——自定义错误处理
程序员文章站
2022-04-06 13:05:17
很多 ASP.NET MVC 开发者都会写出高性能的代码,很好地交付软件,等等。但是却并没有安全性方面的计划。 有一种攻击是攻击者截获最终用户提交的表单数据,将其改变再将修改后的数据发送到服务器。 对于这种情况,开发者需要进行适当的验证,不过验证显示的大量错误信息中可能会泄漏服务器信息。 如常见的4 ......
很多 ASP.NET MVC 开发者都会写出高性能的代码,很好地交付软件,等等。但是却并没有安全性方面的计划。
有一种攻击是攻击者截获最终用户提交的表单数据,将其改变再将修改后的数据发送到服务器。
对于这种情况,开发者需要进行适当的验证,不过验证显示的大量错误信息中可能会泄漏服务器信息。
如常见的404页面和500页面(俗称黄页):
解决方法:
- 先关闭自定义错误,将Web.config配置文件中customErrors节点的mode设置为Off
1 <system.web> 2 <customErrors mode="Off"></customErrors> 3 <compilation debug="true" targetFramework="4.5"/> 4 <httpRuntime targetFramework="4.5"/> 5 </system.web>
- 在GlobalFilter全局过滤器中取消HandleErrorAttribute的注册
1 public class FilterConfig 2 { 3 public static void RegisterGlobalFilters(GlobalFilterCollection filters) 4 { 5 //filters.Add(new HandleErrorAttribute()); 6 } 7 8 }
- Global.asax文件并添加Application_Error事件代码
1 protected void Application_Error(Object sender, EventArgs e) 2 { 3 Exception exception = Server.GetLastError(); 4 if (exception != null) 5 { 6 HttpException httpException = exception as HttpException; 7 if (httpException != null) 8 { 9 int errorCode = httpException.GetHttpCode(); 10 if (errorCode == 400 || errorCode == 404) 11 { 12 Response.StatusCode = 404; 13 Response.Redirect(string.Format("~/Error/Error404"), true); 14 Server.ClearError(); 15 return; 16 } 17 } 18 19 var postData = string.Empty; 20 try 21 { 22 using (System.IO.Stream stream = Request.InputStream) 23 { 24 using (System.IO.StreamReader streamReader = new System.IO.StreamReader(stream, System.Text.Encoding.UTF8)) 25 { 26 postData = streamReader.ReadToEnd(); 27 } 28 } 29 } 30 catch { } 31 32 //该方法为写错误日志和发送错误邮件给开发者的方法(可忽略) 33 LogCache.Instance.saveToLog(Request, AppDomain.CurrentDomain.BaseDirectory + @"\privateFolder\SysLog\Error\", DateTime.Now.ToString("yyyyMMddHH") + ".log", postData, exception.ToString()); 34 35 Response.StatusCode = 500; 36 Response.Redirect(string.Format("~/Error/Error500"), true); 37 Server.ClearError(); 38 } 39 }
- 添加自定义的404、500页面
最终实现效果:
使用应用程序全局错误的一些优势:
第一点就是兼容性好,Web Form和MVC中都可以通用,如果旧的Web Form项目中是使用Application_Error处理全局异常,那么在新的MVC项目就可以很容易移植过来!此外灵活性也比较高,相比ASP.NET自带的自定义错误以及MVC的HandleError特性,可以更加*的编写灵活的业务代码。
另外可以根据需求设定HTTP错误码,这方面也是考虑到一个SEO的问题,毕竟ASP.NET的自定义错误机智是使用302重写跳转,并不有利于SEO。虽然customErrors节点的redirectMode属性可以设置为"ResponseRewrite"(重写),但是如果在跳转的页面上不设置HTTP错误码,则HTTP状态码为200。
Application_Error处理网站异常的局限性:
Application_Error事件无法处理已经被处理的异常,比如在try-catch捕捉的异常。此外由于是应用程序级别的事件,所以无法处理操作方法或者控制器级别的异常,暂时我也只想到这些局限,一般来说只要项目没有什么特殊要求都可以使用此事件处理自定义异常。
推荐阅读
-
2.第一个ASP.NET MVC 5.0应用程序
-
2.第一个ASP.NET MVC 5.0应用程序
-
ASP.NET Core Web 应用程序系列(一)- 使用ASP.NET Core内置的IoC容器DI进行批量依赖注入(MVC当中应用)
-
ASP.NET MVC4.0 控件的应用(一)
-
ASP.NET Core Web 应用程序系列(一)- 使用ASP.NET Core内置的IoC容器DI进行批量依赖注入(MVC当中应用)
-
ASP.NET MVC应用安全性(一)——自定义错误处理
-
ASP.NET MVC+LINQ开发一个图书销售站点(4):创建一个ASP.NET MVC应用的原型
-
Pro ASP.NET Core MVC(二)【第一个MVC 应用程序】