|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
你觉得学习.NET怎么样,我懂的少,问的可能很幼稚,见笑了啊:)ASP.Net1.1后引进了对提交表单主动反省是不是存在XSS(跨站剧本打击)的才能。当用户试图用之类的输出影响页面前往了局的时分,ASP.Net的引擎会激发一个HttpRequestValidationExceptioin。默许情形下会前往以下笔墨的页面:以下是援用片断:
ServerErrorin/YourApplicationPathApplication
ApotentiallydangerousRequest.Formvaluewasdetectedfromtheclient
(txtName="<b>").
Description:RequestValidationhasdetectedapotentiallydangerousclientinputvalue,andprocessingoftherequesthasbeenaborted.Thisvaluemayindicateanattempttocompromisethesecurityofyourapplication,suchasacross-sitescriptingattack.YoucandisablerequestvalidationbysettingvalidateRequest=falseinthePagedirectiveorintheconfigurationsection.However,itisstronglyrecommendedthatyourapplicationexplicitlycheckallinputsinthiscase.
ExceptionDetails:System.Web.HttpRequestValidationException:ApotentiallydangerousRequest.Formvaluewasdetectedfromtheclient(txtName="<b>").
....
这是ASP.Net供应的一个很主要的平安特征。由于良多程序员对平安没有观点,乃至都不晓得XSS这类打击的存在,晓得自动往防护的就更少了。ASP.Net在这一点上做到默许平安。如许让对平安不是很懂得的程序员仍旧能够写出有必定平安防护才能的网站。
可是,当我Google搜刮HttpRequestValidationException大概"ApotentiallydangerousRequest.Formvaluewasdetectedfromtheclient"的时分,惊异的发明年夜部分人给出的办理计划居然是在ASP.Net页面形貌中经由过程设置validateRequest=false来禁用这个特征,而不往体贴谁人程序员的网站是不是真的不必要这个特征。看得我这叫一个人心惶惶。平安认识应当每时每刻在每个程序员的内心,不论你对平安的观点懂得几,一个自动的认识在头脑里,你的站点就会平安良多。
为何良多程序员想要克制validateRequest呢?有一部分是真的必要用户输出""之类的字符。这就不用说了。另有一部分实在并非用户同意输出那些简单引发XSS的字符,而是厌恶这类报错的情势,究竟一年夜段英文加上一个ASP.Net典范非常毛病信息,显得这个站点堕落了,而不是用户输出了不法的字符,但是本人又不晓得怎样不让它报错,本人来处置报错。
关于但愿很好的处置这个毛病信息,而不利用默许ASP.Net非常报错信息的程序员们,你们不要禁用validateRequest=false。
准确的做法是在你以后页面增加Page_Error()函数,来捕捉一切页面处置过程当中产生的而没有处置的非常。然后给用户一个正当的报错信息。假如以后页面没有Page_Error(),这个非常将会送到Global.asax的Application_Error()来处置,你也能够在那边写通用的非常报错处置函数。假如两个中央都没有写非常处置函数,才会显现这个默许的报错页面呢。
举例而言,处置这个非常实在只必要很冗长的一小段代码就够了。
在页面的Code-behind页面中到场这么一段代码:protectedvoidPage_Error(objectsender,EventArgse)
{
Exceptionex=Server.GetLastError();
if(exisHttpRequestValidationException)
{
Response.Write("请您输出正当字符串。");
Server.ClearError();//假如不ClearError()这个非常会持续传到Application_Error()。
}
}
如许这个程序就能够截获HttpRequestValidationException非常,并且能够依照程序员的志愿前往一个公道的报错信息。
这段代码很复杂,以是我但愿一切不是真的要同意用户输出之类字符的伴侣,万万不要随便的克制这个平安特征,假如只是必要非常处置,那末请用相似于下面的代码来处置便可。
而关于那些经由过程明白克制了这个特征的程序员,本人必定要分明本人在做甚么,并且必定要本人手动的反省必需过滤的字符串,不然你的站点很简单激发跨站剧本打击。
关于存在RichTextEditor的页面应当怎样处置?
假如页面有富文本编纂器的控件的,那末一定会招致有类的HTML标签提交返来。在这类情形下,我们不能不将validateRequest="false"。那末平安性怎样处置?怎样在这类情形下最年夜限制的防备跨站剧本打击呢?
依据微软的倡议,我们应当接纳平安上称为“默许克制,显式同意”的战略。
·起首,我们将输出字符串用HttpUtility.HtmlEncode()来编码,将个中的HTML标签完全克制。
·然后,我们再对我们所感乐趣的、而且是平安标签,经由过程Replace()举行交换。好比,我们但愿有""标签,那末我们就将""显式的交换回""。
示例代码以下:
voidsubmitBtn_Click(objectsender,EventArgse)
{
//将输出字符串编码,如许一切的HTML标签都生效了。
StringBuildersb=newStringBuilder(
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>标签是有大概招致javascript实行的,如许打击者就能够做他想假装的任何事变。
关于<style>也是一样:
<styletype="text/javascript">...
alert(hello);
</style>
不思索平安间接作废报警的办法:
办理计划一:
在.aspx文件头中到场这句:
<%@PagevalidateRequest="false"%>
办理计划二:
修正web.config文件:
<configuration>
<system.web>
<pagesvalidateRequest="false"/>
</system.web>
</configuration>
由于validateRequest默许值为true。只需设为false便可。
我认为,可以通过更加简单的首次编译,而增加第二次编译的负担,来提高java的运行效率。只是将java源代码进行简单的等价转换,而不假设编译成某种虚拟机器的目标格式,而由本地编译器针对性的二次编译。 |
|