从客户端检测到有潜在危险的Request.Form值的asp.net代码

1、web.config文档<system.web>后面加入这一句：


代码如下:

<pages validaterequest="false"/>

示例：
XML/HTML


代码如下:

<?xml version="1.0" encoding="gb2312" ?>
<configuration>
<system.web>
<pages validaterequest="false"/>
</system.web>
</configuration>

2、在*.aspx文档头的page中加入validaterequest="false",示例如下：


代码如下:

<%@ page validaterequest="false" language="c#" codebehind="index.aspx.cs" autoeventwireup="false" inherits="mybbs.webform1" %>

其实这样做是不正确的，会给程序安全带来风险。
　　ASP.Net 1.1后引入了对提交表单自动检查是否存在XSS(跨站脚本攻击)的能力。当用户试图用之类的输入影响页面返回结果的时候，ASP.Net的引擎会引发一个 HttpRequestValidationExceptioin。这是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 (HttpContext.Current.Server.GetLastError() is HttpRequestValidationException)
{
HttpContext.Current.Response.Write("请输入合法的字符串【<a href=\"javascript:history.back(0);\">返回</a>】");
HttpContext.Current.Server.ClearError();
}
}

这样这个程序就可以截获 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>", "</b>");
sb.Replace("<i>", "<i>");
sb.Replace("</i>", "</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');">

赞 (0)

相关推荐

  • ASP.NET中Request.Form中文乱码的解决方法

    背景 涉及到两个网站的通信,网站A有一页面a,用提交表单的方式,传值到网站B的页面b.网站A统一用UTF-8编码,网站B统一用GB2312编码. web.config中编码的设置 网站A:<globalization requestEncoding="UTF-8" responseEncoding="UTF-8" /> 网站B:<globalization requestEncoding="gb2312" responseEnc

  • ASP.NET从客户端中检测到有潜在危险的request.form值的3种解决方法

    ASP.NET从客户端中检测到有潜在危险的request.form值的3种解决方法

    当页面编辑或运行提交时,出现"从客户端中检测到有潜在危险的request.form值"问题,该怎么办呢?如下图所示: 下面博主汇总出现这种错误的几种解决方法: 问题原因:由于在asp.net中,Request提交时出现有html代码或javascript等字符串时,程序系统会认为其具有潜在危险的值.环境配置会报出"从客户端 中检测到有潜在危险的Request.Form值"这样的Error. 1.当前提交页面,添加代码 打开当前.aspx页面,页头加上代码:valid

  • asp下request.querystring("id")与request("id")区别

    Request从几个集合取数据是有顺序的,从前到后的顺序依次是 QueryString,Form,最后是ServerVariables.Request对象按照这样的顺序依次搜索这几个集合中的变量,如果有符合的就中止,后面的就不管了. 现在我们来分析下你得问题.  假设有个页面 test.asp?id=111  这里我们的页面是用GET的方法.这时用request.querystring("id")与request("id")是一样得,应该如果不指定REQUEST得集

  • ASP读取Request.QueryString编码的函数代码

    1. 支持参数纯汉字 ?a=深山老熊 2. 支持参数gb2312 Urlencode编码: ?a=%C9%EE%C9%BD%C0%CF%D0%DC 3. 支持参数UTF-8 Urlencode编码: ?a=%E6%B7%B1%E5%B1%B1%E8%80%81%E7%86%8A 复制代码 代码如下: <%@LANGUAGE="VBSCRIPT" CODEPAGE="65001"%> <% Option Explicit Const YXCMS_CH

  • 循环取值Request.QueryString的用法

    当页面上的FORM以GET方式向页面发送请[/url]求数据(如数据含有不安全字符,则浏览器先将其转换成16进制的字符再传送,如空格被转成%20)时,WEB   SERVER   将请求数据放入一名为QUERY_STRING的环境变量中,QueryString   方法是从这一环境变量中取出相应的值,并将被转成16进制的字符还原(如   %20   被还原成空格). 如表单上有一   name为username的文本框及一   name为password的文本框   ,   当表单提交时,会产生

  • Jquery中request和request.form和request.querystring的区别

    Request.Form是获取以POST方式提交的表单数据: Request.QueryString主要是获取地址栏参数或者以Get方式提交的数据 而Request则包含以上两种方式,会在Request.QueryString和Request.Form中都查询一遍变量.但是优先获取GET方式提交的数据,即Request.QueryString Request:包含以上两种方式(优先获取GET方式提交的数据),它会在QueryString.Form.ServerVariable中都搜寻一遍. 而且

  • asp.net 从客户端中检测到有潜在危险的 Request.Form 值错误解

    从客户端(ftbContent="<P><A href="http://l...")中检测到有潜在危险的 Request.Form 值. 说明: 请求验证过程检测到有潜在危险的客户端输入值,对请求的处理已经中止.该值可能指示危及应用程序安全的尝试,如跨站点的脚本攻击.通过在 Page 指令或 配置节中设置 validateRequest=false 可以禁用请求验证.但是,在这种情况下,强烈建议应用程序显式检查所有输入. 异常详细信息: System.Web

  • Request.QueryString与一般NameValueCollection的区别

    Request.QueryString与一般NameValueCollection的区别

    查看了QueryString的定义类型是NameValueCollection,就误以为这是NameValueCollection的重写了ToString()的方法,于是放心地将代码转移到了业务逻辑层.因为还要重构查询参数,因此重新构建了一个NameValueCollection,并想当然地用ToString()的结果作为Key.但实际运行之后发现,每次的结果都一样的,都是第一次的查询结果.经调试,发现NameValueCollection的ToString()方法并没有重新,还是返回的是"Sy

  • asp.net下Request.QueryString取不到值的解决方法

    今天做新的ppc weather服务器的时候竟然碰到QueryString取不到值的问题 查了下网上,应该是编码的问题,tq121用的是utf-8,而我希望用gb2132输入~ 因此,改一下~哈哈 打开web.config把 <!-- <globalization              requestEncoding="utf-8"              responseEncoding="utf-8"     /> 改成 <glob

  • asp.net中Request.QueryString与Request.Param的区别分析

    request.params其实是一个集合,它依次包括request.querystring.request.form.request.cookies和request.servervariables. 如果要在两个页面传递数据的话,只能用request.querystring.request.form.request.cookies Request.Params 是在 QueryString.Form.Server Variable 以及 Cookies 找数据, 他首先在 QueryStrin

  • ASP.NET检测到不安全 Request.Form 值解决方案汇总

    ASP.NET检测到不安全 Request.Form 值解决方案汇总

    当我们在网站中使用CKEditor等富文本编辑器时,大多都会遇到这样的到警告 这是因为ASP.NET默认开启对页面提交内容的验证(不仅是ASP.NET MVC,WebForms也默认启用对页面提交的内容进行验证),解决这个问题的关键就在于在有富文本编辑器的页面或者会有提交html代码的页面关闭验证,可大致分为以下三种情况: 基于Framework2.0 webForm的网站 这种情况相比之下算是最好解决的,直接在需要的页面顶部的 Page 指令中设置 ValidateRequest="false

  • 有潜在危险的 Request.Form 值避免方法

    个人感觉在 .net framework 4.0中 最好的解决" 有潜在危险的 Request.Form 值" 这个问题的方法是 在 system.web 中加上 <httpRuntime requestValidationMode="2.0"/> 这句话 因为4.0的验证在HTTP的BeginRequest前启用 复制代码 代码如下: <system.web> <httpRuntime requestValidationMode=&q

随机推荐