谈谈asp.net cookie注入和跨站攻击和防范(一年没上CSDN)

上高三时，语文老师不限体裁,让我们写作文，自由发挥反而同学们都不知怎么写了。我记得老师说过，把你们放到广场你们不会走了，条条道路通罗马，给个宰牛刀倒不会杀鸡了。生活中这种事何常又不发生呢？
.net 如此强大，类多，看起来也很累！若对有些有些细节性的东西不去不关注。以至于写的程序安全性很脆弱，不要出现自己写的程序有漏洞,就说微软.net 有问题。这种说法我不认同。绝大多数还是我们程序写的有问题。
大学时对网络安全很喜欢，也很喜欢脚本注入，当第一次看asp.net书籍时，与asp相比，被那些配置吸引了。如：每个页面的ErrorPage设置，web.config <customErrors mode="Off"/> HttpUtility.UrlEncode,Server.UrlDecode,Server.HtmlEncode ,正则表达式 ......的确很强大.当然还有datagrid了，那时就喜欢上了.net。为什么现在还是出现注入....是我们没有用对方法。以至于出现像asp方式的处理方法。

   inputString=inputString.Replace("'", "''");//单引号替换成两个单引号替换

   inputString=inputString.Replace("&","&"); //过滤字符&

   inputString=inputString.Replace("\"","""); //过滤字符\

   inputString=inputString.Replace("<","<"); //过滤字符<

   inputString=inputString.Replace(">",">"); //过滤字符>

   inputString=inputString.Replace(" "," "); //过滤字符空格" "

   inputString=inputString.Replace("  ","  "); //过滤字符" "" "

   inputString=inputString.Replace("\t","  ");//过滤字符\t

   inputString=inputString.Replace("\r", "<br>");//过滤字符\r<br>

只要有Sqlparameter 设置参数与数据列关联。如：select * from table where keyword=@keyword 这儿出现keyword='"+@keyword+"' 用这种方式写，不管你放在那儿都有注入的可能。换句话，不要产生拼接字符就ok，数据库当中什么都可以插了。“'”只不过是了个字符而已，不会出现语句不闭合的现象。以前看黑防杂志时，有人写的文章说不要把所有罪过归于“'”,现在看样子，这问题已经解决了。
以前的小逗点就如现在的“三鹿奶粉”了。
前段时间给一个asp.net的政府网站补sql注入漏洞时,攻防的思路我又重新整理了下,以前经常也论坛给别人解答.net安全这方面的问题,很多情况有些相似。但安全方面关注面太广,不光光是程序的问题。软硬件都是一个整体。某一处设置不当，就会被别人攻击。
今天我谈谈asp.net cookie注入和跨站攻击和防范的一看法。希望能抛砖引玉！
cookie 注入我认为是sql注入的前奏，有cookie注入的不一定会有sql注入。我们常见的注入一般是QueryString进行注入的，地址栏当中如有aspx?ID=，cookie注入目的跟它一样，只是我们看起来不透明罢了。对于asp.net 对URL重写或者生成静态的html文件,我们是没办法进行注入的。
cookie注入是在当前的会话下进行的。在地址栏当中提交
如：

javascript:alert(document.cookie="ID="+escape("2 and 1=1"))

就在当页中生成一个名为ID，值为:2 and 1=1 的cookie。
数据包如下：
[code=INIFile]GET /WebSite/Default.aspx HTTP/1.1
Accept: */*
Accept-Language: zh-cn
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; CIBA; .NET CLR 2.0.40607)
Host: localhost:1580
Connection: Keep-Alive
Cookie: ID=2%20and%201%3D1[/code]


也可以用程序来显示:

  protected void Page_Load(object sender, EventArgs e)

    {

        try

        {

            int ID = Convert.ToInt32(Request["ID"]);  //ID 取整数的话，就Convert.ToInt32

            //string ID = Request["ID"];           //能用整型就不要转成字符串

            //Response.Write(Server.UrlEncode(ID));

            if (Request.Cookies["ID"] != null)

            {

                ID = Convert.ToInt32(Request.Cookies["ID"].Value);

                Response.Write("Cookie Value:" + ID + "<br />");

            }

            else

            {

                Response.Write("当前浏览器进程的无会话Cookie!<br />");

            }

            if (ID == 2)

            {

                Response.Write("参数为：");

                Response.Write(ID);

            }

            else

            {

                Response.Write("没有参数传过来");

            }

        }

        catch(Exception ex)

        {

            Response.Write(ex.Message);

        }

    }  

asp.net 取值的方法也get ,post 两种,组合起来也就三种。web服务器取数据时先取get中的数据，没有再取post中的数据,还会去取Cookies中的数据,Request从集合取数据是有顺序的，先是QueryString、其次Form、接下来才是Cookies、最后是ServerVariables。Request对象按照这样的顺序依次搜索这几个集合中的变量，到找到第一个符合条件的集合停止。
产生cookie注入的原因是在取值是用Request["ID"],所以写程序时明确从那儿取值是比较好的习惯
Request.QueryString["ID"]、还是Request.Form["ID"]. 现在cookie注入不像以前那样手动，它有个中转程序。这个程序可以自己建个web服务器。从这儿构造sql注入程序去渗透web服务器。若是黑客攻破了这个防线，也没事，它还要进行我们常说的sql注入。你若写的程序不是字符串拼接的话，它只能也停留在这个门槛上了. 表现层与业务逻辑层要交互，对表现层接口提供的数据进行一下验证，是比较保险的。用户传来的未必是业务逻辑层想要的。就如上面的Request["ID"] 取得的ID,业务逻辑层想要ID类是整型。那我们Convert.ToInt32(Request["ID"])，攻击者即使使用URL编码也不会出现什么注入。若ID是string 类型，那就比较麻烦了，因为这种情况会出现攻击者对sql 语句的构造，这也没什么，Sqlparameter类来参数设置，也不会出现什么sql注入，而不必自己构造什么过滤函数。到头写的不对头，照样被攻击。刚学注入时，我想用Replace去过滤就可能了，后来才知道有限去对无限是错误的。如：过滤and这个词，若攻击者构造aandnd 1=1 , replace不是成了and 1=1、 an/*注释*/d 1=1 方法太多了，发现sql注入和溢出的人真天才.
XSS攻击以前asp当中是过滤

   inputString=inputString.Replace("<","<"); //过滤字符<

   inputString=inputString.Replace(">",">"); //过滤字符>

在asp.net 当中传输的字符串敏感的话，asp.net 提示遇到“从客户端检测到有潜在危险的Request.Form 或Request.Cookie值”错误提示很多人不管安全性就在web.config文档<system.web>后面加入这一句： <pages validaterequest="false"/> 程序是安全了，但它是页面级的设置，每个页面都可以输入有htmt javascript 有语句，不进行HtmlEncode转义，就直接输出。这样做不好的做法有机会构成xss攻击。有些用户不是有意有提交一些javascrpt脚本，服务器解析成javascript脚本，若被攻击者利用，它可构造一个网页木马，当每个用户去访问注入脚本的网站，木马就ie后台暗暗的自动装到使用者电脑，那就你中彩了，小心你的各种帐户。现在的都木马反弹性的，服务端去自动连接客户端。最好防的方法还是更新高版本的IE，及时更新病毒库吧。一般的马杀毒软件还是认知的。经过加变态的壳那就不好说了，我们都帮不了你，那就悄悄当别人肉鸡吧！
.net 当中方法对Html进行转义，Server.HtmlEncode()所以对客户提交的文本进行一下转义是比较保险的做法，当然对富文本转义是必不可少了。当然，文本输入也可以进行正则表达式的过滤，后台的过滤是必不可少的。asp.net2.0当中gridview列属性设置当中有个HtmlEncode对数据库数据进行转义，DataList,repeater 当中没有这个属性。

            <asp:DataList ID="DataList1" runat="server" DataSourceID="SqlDataSource1">

            <ItemTemplate>

                不解析的HTML，原样输出:

                <asp:Label ID="idLabel" runat="server" Text='<%# Server.HtmlEncode(Eval("含有HTML标签的字符串").ToString())%>'></asp:Label><br />

            </ItemTemplate>

        </asp:DataList>

这样的好处时有时可以在存储过程当中设置html标签，对字体加粗加红<strong><font color="red">显示字段</strong>，不说这种写法不利于重构，耦合太高。但是微软既然给了这种方法，认为比较合适时就用罢。但是这种方法打开了xxs攻击的目的。它可以解析html标签，若攻击者在加入<iframe src=本马地址 width=0 height=0></iframe>,用户是看不见的。框架挂马只是网页挂马当中的一种。所以我们对数据是否要 <pages validaterequest="false"/> 和输入数据是否htmlEncode.输入的数据当中也包括cookie.value过滤了，因为cookie.value即使加密码了，还是可以修改的。cookie使用不好又会给攻击者提供xss攻击。
最后，我有一句话结束我的漫谈吧！给用户最小的入口，同时不要相信用户给你提供的数据总是可靠的。想起说一下cookie方面的安全。但是好长时间没有关注这一块，有机地再和大家讨论吧！