ASP.Net 1.1后引入了对提交表单自动检查是否存在XSS(跨站脚本攻击)的能力。当用户试图用之类的输入影响页面返回结果的时候,ASP.Net的引擎会引发一 个 HttpRequestValidationExceptioin。默认情况下会返回如下文字的页面:
以下是引用片段:
Server Error in '/YourApplicationPath' Application
A potentially dangerous Request.Form value was detected from the client
(txtName="<b>").
Description: Request Validation has detected a potentially dangerous client input value, and processing of the request has been aborted. This value may indicate an attempt to compromise the security of your application, such as a cross-site scripting attack. You can disable request validation by setting validateRequest=false in the Page directive or in the configuration section. However, it is strongly recommended that your application explicitly check all inputs in this case.
Exception Details: System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client (txtName="<b>").
....
这是ASP.Net提供的一个很重要的安全特性。因为很多程序员对安全没有概念,甚至都不知道XSS这种攻击的存在,知道主动去防护的就更少了。ASP.Net在这一点上做到默认安全。这样让对安全不是很了解的程序员依旧可以写出有一定安全防护能力的网站。
但是,当我Google搜索 HttpRequestValidationException 或者 "A potentially dangerous Request.Form value was detected from the client"的时候,惊奇的发现大部分人给出的解决方案竟然是在ASP.Net页面描述中通过设置 validateRequest=false 来禁用这个特性,而不去关心那个程序员的网站是否真的不需要这个特性。看得我这叫一个胆战心惊。安全意识应该时时刻刻在每一个程序员的心里,不管你对安全的概念了解多少,一个主动的意识在脑子里,你的站点就会安全很多。
为什么很多程序员想要禁止 validateRequest 呢?有一部分是真的需要用户输入"<>"之类的字符。这就不必说了。还有一部分其实并不是用户允许输入那些容易引起XSS的字符,而是讨厌这 种报错的形式,毕竟一大段英文加上一个ASP.Net典型异常错误信息,显得这个站点出错了,而不是用户输入了非法的字符,可是自己又不知道怎么不让它报错,自己来处理报错。
对于希望很好的处理这个错误信息,而不使用默认ASP.Net异常报错信息的程序员们,你们不要禁用validateRequest=false。
正确的做法是在你当前页面添加Page_Error()函数,来捕获所有页面处理过程中发生的而没有处理的异常。然后给用户一个合法的报错信 息。如果当前页面没有Page_Error(),这个异常将会送到Global.asax的Application_Error()来处理,你也可以在那 里写通用的异常报错处理函数。如果两个地方都没有写异常处理函数,才会显示这个默认的报错页面呢。
举例而言,处理这个异常其实只需要很简短的一小段代码就够了。在页面的Code-behind页面中加入这么一段代码:
以下是引用片段:
protected void Page_Error(object sender, EventArgs e)
{
Exception ex = Server.GetLastError();
if (ex is HttpRequestValidationException)
{
Response.Write("请您输入合法字符串。");
Server.ClearError(); // 如果不ClearError()这个异常会继续传到Application_Error()。
}
}
这样这个程序就可以截获 HttpRequestValidationException 异常,而且可以按照程序员的意愿返回一个合理的报错信息。
这段代码很简单,所以我希望所有不是真的要允许用户输入之类字符的朋友,千万不要随意的禁止这个安全特性,如果只是需要异常处理,那么请用类似于上面的代码来处理即可。
而对于那些通过 明确禁止了这个特性的程序员,自己一定要明白自己在做什么,而且一定要自己手动的检查必须过滤的字符串,否则你的站点很容易引发跨站脚本攻击。
关于存在Rich Text Editor的页面应该如何处理?
如果页面有富文本编辑器的控件的,那么必然会导致有类的HTML标签提交回来。在这种情况下,我们不得不将validateRequest="false"。那么安全性怎么处理?如何在这种情况下最大限度的预防跨站脚本攻击呢?
根据微软的建议,我们应该采取安全上称为“默认禁止,显式允许”的策略。
首先,我们将输入字符串用 HttpUtility.HtmlEncode()来编码,将其中的HTML标签彻底禁止。
然后,我们再对我们所感兴趣的、并且是安全标签,通过Replace()进行替换。比如,我们希望有""标签,那么我们就将""显式的替换回""。
示例代码如下:
以下是引用片段:
void submitBtn_Click(object sender, EventArgs e)
...{
// 将输入字符串编码,这样所有的HTML标签都失效了。
StringBuilder sb = new StringBuilder(
HttpUtility.HtmlEncode(htmlInputTxt.Text));
// 然后我们选择性的允许<b> 和 <i>
sb.Replace("<b>", "<b>");
sb.Replace("</b>", "");
sb.Replace("<i>", "<i>");
sb.Replace("</i>", "");
Response.Write(sb.ToString());
}
这样我们即允许了部分HTML标签,又禁止了危险的标签。
根据微软提供的建议,我们要慎重允许下列HTML标签,因为这些HTML标签都是有可能导致跨站脚本攻击的。
以下是引用片段:
# <applet>
# <body>
# <embed>
# <frame>
# <script>
# <frameset>
# <html>
# <iframe>
# <img>
# <style>
# <layer>
# <link>
# <ilayer>
# <meta>
# <object>
可能这里最让人不能理解的是<img>。但是,看过下列代码后,就应该明白其危险性了。
以下是引用片段:
<img src="javascript:alert('hello');">
<img src="java script:alert('hello');">
<img src="java script:alert('hello');">
通过<img>标签是有可能导致javascript执行的,这样攻击者就可以做他想伪装的任何事情。
关于<style>也是一样:
以下是引用片段:
<style TYPE="text/javascript">...
alert('hello');
</style>
从客户端中检测到有潜在危险的 Request.Form 值
由于在.net中,Request时出现有HTML或Javascript等字符串时,系统会认为是危险性值。立马报错上面的错误。
解决办法:
解决方案一:
在.aspx文件头中加入这句:
<%@ Page validateRequest="false" %>
解决方案二:
修改web.config文件:
<configuration>
<system.web>
<pages validateRequest="false" />
</system.web>
</configuration>
因为validateRequest默认值为true。只要设为false即可。
当然,这样只能是让界面好看一些,要想抵制注入,还得从过滤上做足功夫
然后,还是有不禁用validateRequest的方法的,如下
不禁用validateRequest=false。
正确的做法是在你当前页面添加Page_Error()函数,来捕获所有页面处理过程中发生的而没有处理的异常。然后给用户一个合法的报错信息。如果当前页面没有Page_Error(),这个异常将会送到Global.asax的Application_Error()来处理,你也可以在那里写通用的异常报错处理函数。如果两个地方都没有写异常处理函数,才会显示这个默认的报错页面呢。
举例而言,处理这个异常其实只需要很简短的一小段代码就够了。在页面的Code-behind页面中加入这么一段代码:
以下是引用片段:
protected void Page_Error(object sender, EventArgs e)
{
Exception ex = Server.GetLastError();
if (ex is HttpRequestValidationException)
{
Response.Write("请您输入合法字符串。");
Server.ClearError(); // 如果不ClearError()这个异常会继续传到Application_Error()。
}
}
分享到:
相关推荐
当页面编辑或运行提交时,出现“从客户端中检测到有潜在危险的request.form值”问题,该怎么办呢?如下图所示: 下面博主汇总出现这种错误的几种解决方法: 问题原因:由于在asp.net中,Request提交时出现有html...
在***中,提交表单时系统可能会提示“从客户端中检测到有潜在危险的Request.Form值”的错误,这通常意味着***的请求验证特性检测到可能的跨站脚本攻击(XSS)。为了解决这个问题,我们需要理解***的请求验证机制,并...
### 潜在危险的 Request.Form 值:深入解析与解决方案 在现代Web开发中,尤其是使用ASP.NET框架时,安全性和数据验证是至关重要的环节。本文将深入探讨一个常见的安全问题:“潜在危险的Request.Form值”,并提供...
总之,在***开发中处理“从客户端检测到有潜在危险的Request.Form值”时,必须要有强烈的安全意识,不建议关闭请求验证功能,而应该采用合适的方法来处理可能的XSS威胁,确保网站的安全性。对于异常的处理,应当根据...
ASP.NET 检测到不安全 Request.Form 值的问题通常是由于框架的安全机制在尝试防止跨站脚本攻击(XSS)和SQL注入等安全威胁。ASP.NET 自动执行请求验证,检查用户提交的数据是否包含可能有害的HTML标签或脚本。在某些...
***程序运行时可能会遇到各种错误,其中之一就是由于请求验证过程发现客户端输入值存在潜在危险而导致的错误。这种错误是***安全功能的一部分,其目的是防止跨站脚本攻击(XSS)等安全漏洞。 在*** 1.1版本中,默认...
在探讨Request、Request.Form和Request.QueryString的区别之前,我们先来明确一下它们在Web开发中的基本概念和作用。在Web应用程序中,服务器与客户端之间通过HTTP协议进行数据交换,这一过程涉及到了请求(Request)...
在这种情况下,它会检查Request.Form中的值是否包含潜在的危险数据,例如脚本标记()或其他非安全字符。 为了解决这个问题,有几种方法可以关闭验证机制。最简单的情况是在使用富文本编辑器的页面顶部Page指令中...
总之,通过在`web.config`文件中进行简单配置,可以大幅提升.NET Framework 4.0应用的安全性,特别是在处理`Request.Form`值时。通过这种方式,可以有效避免潜在危险的数据对Web应用构成的威胁,从而构建更加安全...
在 C# 中,获取请求参数可以使用 Request.Params、Request、Request.QueryString、Request.Form、Request.Cookies 和 Request.ServerVariables 等对象。每个对象都有其特点和用途,了解它们的区别和用法是非常重要的...
在探讨“解决当FORM的ENCTYPE='multipart/form-data'时request.getParameter()获取不到值的方法”这一主题时,我们首先需要理解为什么在特定情况下,传统的`request.getParameter()`方法无法正常工作,以及如何通过...
asp.net下Request.QueryString取不到值的解决方法
通过上述分析,我们可以清楚地看到`request.getParameter()`与`request.getAttribute()`在功能、用途及使用场景上的区别,这将有助于开发者在实际项目中更加合理地选择和应用这些方法,提高代码的效率和可维护性。
标题中的“ASP.NET中Request.Form中文乱码的解决方法”直指一个常见的编程难题:当用户通过表单提交包含中文字符的数据时,服务器端接收到的数据可能会出现乱码。这种情况通常发生在不同的网页编码格式之间交互时,...
具体参考:从客户端检测到有潜在危险的Request.Form值,禁止提交html标记(<>等被转义成<) 3、上传漏洞 解决办法:禁止上传目录的运行权限。只给读取权限。另外要禁止上传非法类型文件。不仅仅是aspx类型,...