requestValidationMode=“2.0”表示什么意思？
requestValidationMode 有两个值：
1.2.0 仅对网页启用请求验证。是启用还是关闭取决于 validateRequest。
2.4.0 默认值。任何 HTTP 请求都会启用请求验证，也就是说不光是网页，还包括 Cookie 等。此时强制启用，不管 validateRequest 为何值。
3.由于 requestValidationMode="4.0" 是强制启用，所以我们会发现在 .NET Framework 4.0 中仅靠设置 validateRequest 是关闭不了请求验证的，还得将 requestValidationMode 设置为 2.0。
ASP.NET中的请求验证特性提供了某一等级的保护措施防止XSS攻击，之前版本的ASP.NET的请求验证是默认启动的,但是他仅仅应用于ASP.NET页面中(.aspx文件和.aspx.cs文件。
如果以上回答没有解决你的问题请看下面回答：
2.0的意思就是说是以前旧版本的升级版，有过之无不及的意思
入侵aspx站要用什么 *** 呢?
1.无论什么站，无论什么语言，我要渗透，之一件事就是扫目录，更好一下扫出个上传点，直接上传shell，诸位不要笑，有时候你花很久搞一个站，最后发现有个现成的上传点，而且很容易猜到，不过这种情况发生在asp居多！
2.asp（aspx）+MSSQL先考虑注入，一般的注入都有DBowner权限可以直接写shell；如果写不了，或者web与数据库分离，那就猜数据，从后台下手了，后台可以上传或者改配置文件；
3.asp（aspx）+ACCESS拿shell一般只有3种 *** ，一是前台上传或者注入进后台上传；二是注入进后台改配置文件；三是注入进后台备份数据库或者暴库后知道是asp或者asa数据库于是直接写一句话；
4.php+MYSQL一般是注入进后台上传，偶尔运气好些权限够高可以注入select into outfile；然后包含，分本地与远程，远程包含在高版本php是不支持的，于是想办法本地上传图片文件或者写到log里；然后php程序某某未公开的漏洞，运气好可以直接写shell。
5.jsp+MYSQL利用数据库拿权限方面基本同php，而且jsp的上传基本很少检查文件后缀，于是只要有注入点与后台，拿shell相当的容易。jsp+ORACLE的站我碰到的不多，碰到的也是猜出用户名与密码从后台下手的。
6.无论什么大站，主站一般都很安全（不然早被人玩了），于是一般从二级域名下手，猜出主站的某些用户名与密码或者搞到主站的源代码，或者旁注得到同网段服务器后cain或arp。
7.一般的大站很少有用现成的CMS的，于是如果你有幸找到源码，那你就发了，注入漏洞啊，上传漏洞啊，写文件漏洞啊，都掌握在你手里。多看看那些大站新出来的测试分站点，那些站还在测试中，可以很轻松拿下。
8.上传有个文件名截断，这包括2个方面，一是00截断，二是长文件名截断（曾经利用这个搞下hw）；然后很多写文件的地方，都可以00，屡试不爽。上传别忘了.asp（当然.asa，.cer，.cdx都可以啦）目录的妙用。
9.php站无论windows还是linux，都有magic_quotes_gpc的问题，magic_quotes_gpc为on的时候，在server变量注入的时候还是可以select into outfile，今年我搞过某未开源cms就是这个情况，一般情况下为on就别考虑写文件了，不过有这个权限别忘了读文件源码，因为load_file的参数是可以编码的。
10.猜路径或者文件在入侵中非常必要，猜不到路径的时候别忘了google（baidu太烂，google很全），于是你可以考虑看站点下的robot.txt或者robots.txt，会有惊喜。
11.工具的使用很重要，入侵之前用WVS扫扫会有助入侵；注入工具虽然很多，但不见得都好使，现在的软硬防火墙、防注入越来越厉害，那时候你就别偷懒，多手工有助你成长。
12.遇到过一流监控么，遇到其他防post的防火墙么，有时候一句话进去了都无法传大马，那时候，你先学学编码，学学变换绕过。
13.想搞一般的小站，记得查看这个小站的版权，找做这个站的公司，然后从这个公司做的其他站下手，得到源码再回头搞，我曾经通过这个 *** 拿下某知名制药的公司站。
14.旁注的思路永远不过时，遇到dbowner的注入，可以很舒服写shell到你需要的站，省得麻烦的提权了；运气不好，按部就班拿shell提权得到你所需。
15.永远别忘记社会工程学，利用社工把自己当成一个什么也不会的人，从某某站长的qq，身份证，邮箱等等下手，也许有时可能会有意外；另外别忘记admin,admin；test,test；123456,123456这种简单的尝试，当然，你也可以暴力破解。
16.别忽视XSS，别忽视cookie，XSS可以偷cookie，更有若干妙用，自己学会领悟；cookie可以伪造登陆，cookie可以注入，cookie注入可以绕绝大多数的防火墙。
17.平时搞站多多搜集路径啊，源码啊，工具啊，充实自己的“武器”库；更好把自己的入侵步骤记录下来，或者事后反思下，我一般都是记在txt里，另外要做到举一反三。
18.多学习，多看源码，多看公布出来的0day，脚本是入侵的前提，而不是工具，会用工具会装B你还没入门。
最后奉劝诸位有事没事改人家首页的装B者，出来混，迟早是要还的，别等进了局子再后悔。还有一点，就是我搞N多站，没挂过一个马，至于很多挂马的人，我不知道该说什么，因为大家都喜欢钱，但是还是少为之吧。
如何防止xss攻击
1. XSS攻击原理
XSS原称为CSS(Cross-Site Scripting)，因为和层叠样式表(Cascading Style Sheets)重名，所以改称为XSS(X一般有未知的含义，还有扩展的含义)。XSS攻击涉及到三方：攻击者，用户，web server。用户是通过浏览器来访问web server上的网页，XSS攻击就是攻击者通过各种办法，在用户访问的网页中插入自己的脚本，让其在用户访问网页时在其浏览器中进行执行。攻击者通过插入的脚本的执行，来获得用户的信息，比如cookie，发送到攻击者自己的网站(跨站了)。所以称为跨站脚本攻击。XSS可以分为反射型XSS和持久性XSS，还有DOM Based XSS。(一句话，XSS就是在用户的浏览器中执行攻击者自己定制的脚本。)
1.1 反射型XSS
反射性XSS，也就是非持久性XSS。用户点击攻击链接，服务器解析后响应，在返回的响应内容中出现攻击者的XSS代码，被浏览器执行。一来一去，XSS攻击脚本被web server反射回来给浏览器执行，所以称为反射型XSS。
特点：
1 XSS攻击代码非持久性，也就是没有保存在web server中，而是出现在URL地址中；
2 非持久性，那么攻击方式就不同了。一般是攻击者通过邮件，聊天软件等等方式发送攻击URL，然后用户点击来达到攻击的；
1.2 持久型XSS
区别就是XSS恶意代码存储在web server中，这样，每一个访问特定网页的用户，都会被攻击。
特点：
1 XSS攻击代码存储于web server上；
2 攻击者，一般是通过网站的留言、评论、博客、日志等等功能(所有能够向web server输入内容的地方)，将攻击代码存储到web server上的；
有时持久性XSS和反射型XSS是同时使用的，比如先通过对一个攻击url进行编码(来绕过xss filter)，然后提交该web server(存储在web server中), 然后用户在浏览页面时，如果点击该url，就会触发一个XSS攻击。当然用户点击该url时，也可能会触发一个CSRF(Cross site request forgery)攻击。
1.3 DOM based XSS
基于DOM的XSS，也就是web server不参与，仅仅涉及到浏览器的XSS。比如根据用户的输入来动态构造一个DOM节点，如果没有对用户的输入进行过滤，那么也就导致XSS攻击的产生。过滤可以考虑采用esapi4js。
asp项目中如何防止xss攻击
asp中防止xss攻击的 *** 如下：
确保所有输出内容都经过 HTML 编码。
禁止用户提供的文本进入任何 HTML 元素属性字符串。
根据 msdn.microsoft.com/library/3yekbd5b 中的概述，检查 Request.Browser，以阻止应用程序使用 Internet Explorer 6。
了解控件的行为以及其输出是否经过 HTML 编码。如果未经过 HTML 编码，则对进入控件的数据进行编码。
使用 Microsoft 防跨站点脚本库 (AntiXSS) 并将其设置为您的默认 HTML 编码器。
在将 HTML 数据保存到数据库之前，使用 AntiXSS Sanitizer 对象（该库是一个单独的下载文件，将在下文中介绍）调用 GetSafeHtml 或 GetSafeHtmlFragment；不要在保存数据之前对数据进行编码。
对于 Web 窗体，不要在网页中设置 EnableRequestValidation=false。遗憾的是，Web 上的大多数用户组文章都建议在出现错误时禁用该设置。该设置的存在是有原因的，例如，如果向服务器发送回“X”之类的字符组合，该设置将阻止请求。如果您的控件将 HTML 发送回服务器并收到图 5 所示的错误，那么理想情况下，您应该在将数据发布到服务器之前对数据进行编码。这是 WYSIWYG 控件的常见情形，现今的大多数版本都会在将其 HTML 数据发布回服务器之前对该数据进行正确编码。
对于 ASP.NET MVC 3 应用程序，当您需要将 HTML 发布回模型时，不要使用 ValidateInput(false) 来关闭请求验证。只需向模型属性中添加 [AllowHtml] 即可，如下所示：
public class BlogEntry
{
public int UserId {get;set;}
[AllowHtml]
public string BlogText {get;set;}
}
如何正确防御xss攻击
传统防御技术
2.1.1基于特征的防御
传统XSS防御多采用特征匹配方式，在所有提交的信息中都进行匹配检查。对于这种类型的XSS攻击，采用的模式匹配 *** 一般会需要对“javascript”这个关键字进行检索，一旦发现提交信息中包含“javascript”，就认定为XSS攻击。
2.1.2 基于代码修改的防御
和SQL注入防御一样，XSS攻击也是利用了Web页面的编写疏忽，所以还有一种 *** 就是从Web应用开发的角度来避免：
1、对所有用户提交内容进行可靠的输入验证，包括对URL、查询关键字、HTTP头、POST数据等，仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交，对其他的一律过滤。
2、实现Session标记(session tokens)、CAPTCHA系统或者HTTP引用头检查，以防功能被第三方网站所执行。
3、确认接收的的内容被妥善的规范化，仅包含最小的、安全的Tag(没有javascript)，去掉任何对远程内容的引用(尤其是样式表和javascript)，使用HTTP only的cookie。
当然，如上 *** 将会降低Web业务系统的可用性，用户仅能输入少量的制定字符，人与系统间的交互被降到极致，仅适用于信息发布型站点。
并且考虑到很少有Web编码人员受过正规的安全培训，很难做到完全避免页面中的XSS漏洞。
扩展资料：
XSS攻击的危害包括
1、盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
2、控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
3、盗窃企业重要的具有商业价值的资料
4、非法转账
5、强制发送电子邮件
6、网站挂马
7、控制受害者机器向其它网站发起攻击
受攻击事件
新浪微博XSS受攻击事件
2011年6月28日晚，新浪微博出现了一次比较大的XSS攻击事件。
大量用户自动发送诸如：
“郭美美事件的一些未注意到的细节”，“建党大业中穿帮地方”，“让女人心动的100句诗歌”，“这是传说中的神仙眷侣啊”等等微博和私信，并自动关注一位名为hellosamy的用户。
事件的经过线索如下：
20:14，开始有大量带V的认证用户中招转发蠕虫
20:30，某网站中的病毒页面无法访问
20:32，新浪微博中hellosamy用户无法访问
21:02，新浪漏洞修补完毕
百度贴吧xss攻击事件
2014年3月9晚，六安吧等几十个贴吧出现点击推广贴会自动转发等。并且吧友所关注的每个关注的贴吧都会转一遍，病毒循环发帖。并且导致吧务人员，和吧友被封禁。
参考资料：
XSS攻击-百度百科
如何正确防御xss攻击?
1、基于特征的防御。XSS漏洞和著名的SQL注入漏洞一样，都是利用了Web页面的编写不完善，所以每一个漏洞所利用和针对的弱点都不尽相同，这就是给XSS漏洞防御带来的困难，不可能以单一特征来概括所有XSS攻击。
传统的XSS防御在进行攻击鉴别时多采用特征匹配方式，主要是针对JavaScript这个关键词进行检索，但是这种鉴别不够灵活，凡是提交的信息中各有JavaScript时，就被硬性的判定为XSS攻击。
2、基于代码修改的防御。Web页面开发者在编写程序时往往会出现一些失误或漏洞，XSS攻击正是利用了失误和漏洞，因此一种比较理想的 *** 就是通过优化Web应用开发来减少漏洞，避免被攻击：
①用户向服务器上提交的信息要对URL和附带的HTTP头、POST数据等进行查询，对不是规定格式、长度的内容进行过滤。
②实现Session标记、CAPTCHA系统或者HTTP引用头检查，以防功能被第三方网站所执行。
③确认接收的内容被妥善的规范化，仅包含最小的、安全的Tag，去掉任何对远程内容的引用，使用HTTP only的cookie。
3、客户端分层防御策略。客户端跨站脚本攻击的分层防御策略是基于独立分配线程和分层防御策略的安全模型。它建立在客户端，这是它与其他模型更大的区别。之所以客户端安全性如此重要，客户端在接受服务器信息，选择性的执行相关内容。这样就可以使防御XSS攻击变得容易，该模型主要由三大部分组成：
①对每一个网页分配独立线程且分析资源消耗的网页线程分析模块;
②包含分层防御策略四个规则的用户输入分析模块;
③保存互联网上有关XSS恶意网站信息的XSS信息数据库。
版权声明
本文仅代表作者观点，不代表本站立场。
本文系作者授权发表，未经许可，不得转载。
