关于dwr的ArequesthasbeendeniedasapotentialCSRFattack.错误和dwrerror的问题就给大家分享到这里，感谢你花时间阅读本站内容，更多关于Apotentia
关于dwr的A request has been denied as a potential CSRF attack.错误和dwr error的问题就给大家分享到这里，感谢你花时间阅读本站内容，更多关于A potentially dangerous Request.Form value was ...、A potentially dangerous Request.Form value was detected from the client、A potentially dangerous Request.Form value was detected from the client 的解决方法、A request has been denied as a potential csrf attack的解决方案等相关知识的信息别忘了在本站进行查找喔。
本文目录一览：- dwr的A request has been denied as a potential CSRF attack.错误（dwr error）
- A potentially dangerous Request.Form value was ...
- A potentially dangerous Request.Form value was detected from the client
- A potentially dangerous Request.Form value was detected from the client 的解决方法
- A request has been denied as a potential csrf attack的解决方案
dwr的A request has been denied as a potential CSRF attack.错误（dwr error）
原文地址：http://persevere.iteye.com/blog/550004
dwr的A request has been denied as a potential CSRF attack.错误
虽然DWR是个很早就出现的Ajax框架，但一直都没去使用过，今天正好没事就看了一下并参照文档照做了个demo，
在其中碰到一个问题：
后台打印出错误信息：“严重: A request has been denied as a potential CSRF attack.” 在网上google一把
之后，出现此错误的原因大都是说“请求被拒绝，可能存在csrf(cross-site request forgeries,跨站请求伪造)攻击、
页面URL可能被跨站了的服务所调用之类的”，但是我这里只有一个简单的测试页面，是根本不存在什么所谓的跨站请求的，
但不知道为什么？希望有知道的朋友告诉一下我，万谢！
不过最后还是通过网上搜索给解决了，得到以下两种解决方案：
1、在web.xml配置文件中修改dwr的配置：
- <servlet>
- servlet-name>dwr-invoker</servlet-class>org.directwebremoting.servlet.DwrServletinit-paramparam-name>debugparam-value>true <!--新加coRSSDomainSessionSecurity参数-->
- >crossDomainSessionSecurity>false>
据说参数coRSSDomainSessionSecurity是在dwr版本2.0才有的.默认值为true,也就是禁止其他域发送请求.若设置成false后，就能够从其他域进行请求但这样做会在安全性上有一些冒险.
2、将JSP文件中所引用的js文件engine.js的方式，由<script type="text/javascript" src="js/engine.js"></script>更改成:<script type="text/javascript" src="dwr/engine.js"></script>。不知道为什么这样就可以啦，而
引用js目录下就会报错。希望有知道朋友，不吝赐教，在下感激不尽！
A potentially dangerous Request.Form value was ...
A potentially dangerous Request.Form value was detected from the client
针对这个问题,以前在.net Framework2.0里,只要修改
<pages validateRequest="false" />
就可以
但是现在在4.0里,需要修改
The request validation feature in ASP.NET provides a certain level of default protection against cross-site scripting (XSS) attacks. In previous versions of ASP.NET, request validation was enabled by default. However, it applied only to ASP.NET pages (.aspx files and their class files) and only when those pages were executing.
In ASP.NET 4, by default, request validation is enabled for all requests, because it is enabled before the BeginRequest phase of an HTTP request. As a result, request validation applies to requests for all ASP.NET resources, not just .aspx page requests. This includes requests such as Web service calls and custom HTTP handlers. Request validation is also active when custom HTTP modules are reading the contents of an HTTP request.
As a result, request validation errors might now occur for requests that previously did not trigger errors. To revert to the behavior of the ASP.NET 2.0 request validation feature, add the following setting in the Web.config file:
<httpRuntime requestValidationMode="2.0" />
However, we recommend that you analyze any request validation errors to determine whether existing handlers, modules, or other custom code accesses potentially unsafe HTTP inputs that could be XSS attack vectors.
这样才对
A potentially dangerous Request.Form value was detected from the client
A potentially dangerous Request.Form value was detected from the client
解决方案一：
在.aspx文件头中加入这句：
<%@ Page validateRequest="false" %>
解决方案二：
修改web.config文件: <configuration> <system.web> <pages validateRequest="false" /> </system.web> </configuration> 因为validateRequest默认值 为true。只要设为false即可。
A potentially dangerous Request.Form value was detected from the client 的解决方法
System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client
方法一：通过在 Page 指令或 配置节中设置 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标签都是有可能导致跨站脚本攻击的。
可能这里最让人不能理解的是<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>
A request has been denied as a potential csrf attack的解决方案
crossDomainSessionSecurity 设置为false
今天关于dwr的A request has been denied as a potential CSRF attack.错误和dwr error的分享就到这里，希望大家有所收获，若想了解更多关于A potentially dangerous Request.Form value was ...、A potentially dangerous Request.Form value was detected from the client、A potentially dangerous Request.Form value was detected from the client 的解决方法、A request has been denied as a potential csrf attack的解决方案等相关知识，可以在本站进行查询。
本文标签：
