“检测到有潜在危险的 Request.Form 值”非关闭验证的解决办法

22 篇文章 0 订阅
16 篇文章 1 订阅

最常发生此错误的场景:服务端接收富文本编辑器带格式的内容。


(不推荐)网络上通常对于《.net会报出“检测到有潜在危险的 Request.Form 值。”》异常的解决办法是

“ValidateRequest="false"” 

和 

web.config中添加“<httpRuntime requestValidationMode="2.0" />


但这种关闭验证机制的办法总感觉心里不踏实,危险重重,下面我说一种我的解决办法,使风险变的可控。

其实也很简单:

ajax我使用的较多,取值都会在js中,那么我决定将值取出后使用js进行加工和判断。

首先,导致报错的一般是<p>这样的格式标记,那么我们对照“Server.HtmlEncode”编码格式进行一下转换。

这里要使用js的replace(a,b)替换方法进行全部替换,而方法默认只会替换第一个,所以我们要使用第一个参数的正则格式来替换全部的:


str.replace(/</g, '&lt;') //将 < 替换为 &lt;

str.replace(/>/g, '&gt;') //将 > 替换为 &gt;

第一个参数正则格式,两个/之间为要替换的内容,最后的g为全文匹配标示符


这样就会吧所有的<>都替换掉,此时将不会报错,同样你可以继续增加一些其它的判断来防止一些攻击。

在数据展示时,将这些内容直接展示在界面上,代码将不会被执行,而是展示出来。

如果需要代码执行,那么在服务端可以使用 Server.HtmlDecode() 方法将数据解码,再将数据输出到界面,代码就会被执行。


虽然不会绝对的安全,但是你已经可以对风险做到心中有数,比起关闭验证机制要好的多,也更灵活。


根据提供的引用内容,无法直接回答你的问题。引用和引用提供了一些关于字段类型和动态字段的信息,但与从客户端检测潜在危险Request.Form无关。 要从客户端检测潜在危险Request.Form,你可以使用一些安全性工具和技术来帮助你识别和处理潜在的安全问题。以下是一些常见的方法: 1. 输入验证:对于从客户端接收到的所有输入数据,包括Request.Form,都应该进行验证验证可以包括检查输入的长度、格式、类型和特殊字符等。你可以使用正则表达式或内置的验证函数来实现输入验证。 2. 输出编码:在将从Request.Form获取的输出到响应时,确保对进行适当的编码,以防止跨站点脚本攻击(XSS)。常见的编码方法包括HTML编码和URL编码。 3. 防范SQL注入:如果你将Request.Form用于构建SQL查询,确保使用参数化查询或预编译语句来防止SQL注入攻击。不要直接将Request.Form拼接到SQL查询字符串。 4. 防范跨站点请求伪造(CSRF):对于涉及敏感操作的请求,例如更改密码或删除数据,确保使用CSRF令牌来验证请求的合法性。CSRF令牌可以防止恶意网站利用用户的身份进行伪造请求。 5. 安全审计日志:记录所有与Request.Form相关的操作,包括输入验证失败、异常请求和安全事件。这些日志可以帮助你追踪和调查潜在的安全问题。 请注意,以上方法只是一些常见的安全措施,具体的实施方法可能因你使用的编程语言和框架而有所不同。建议你查阅相关的安全文档和指南,以了解更多关于保护Web应用程序安全的最佳实践。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值