探索ASP.NETForms验证的相关安全性问题

ASP.NET Forms验证主要是为了防止Forms被破解危害网站的安全，今天我们将从简单的Forms开始讲述，最后讲解危机将带来什么后果。

专业领域包括网站制作、网站设计、商城网站建设、微信营销、系统平台开发， 与其他网站设计及系统开发公司不同，成都创新互联公司的整合解决方案结合了帮做网络品牌建设经验和互联网整合营销的理念，并将策略和执行紧密结合，为客户提供全网互联网整合方案。

ASP.NET提供了内置的登录验证，最为常用的就是Forms验证。讲解如何配置的文章非常多，这里就不再讲如何配置使用这个验证的方式了。下面讲讲其在安全性上存在的一些被忽视的问题。其实它本身没有问题，而使用的方式上会附带出来一些问题。

本文将分三部分讲实际应用中将会遇到的安全性问题，并且加以研究，并尝试提出解决方案。

一、简单的Forms被破解危机

二、垂直划分站点的Forms被破解危机

三、危机将带来什么后果

一、简单的Forms被破解危机

最简单的一个ASP.NET Forms验证，在web.config下配置节点：

 
 
 

  
  
  
 mode="Forms">

  
  
  
     name=".MyCookies">

  
  
  

 
 
 

编写一个帮助类：

 
 
 

  
  
  
CookieHelper类 
  
  
  
    public static class CookieHelper { 
  
  
  
        public static string Encrypt(string name, string value) { 
  
  
  
            FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(1, name, DateTime.Now, DateTime.Now.AddDays(1), true, value, "/"); 
  
  
  
            string authTicket = FormsAuthentication.Encrypt(ticket); 
  
  
  
            return authTicket; 
  
  
  
        } 
  
  
  

  
  
  
        public static void Set(string name, string value) { 
  
  
  
            HttpCookie cookie = new HttpCookie(FormsAuthentication.FormsCookieName, Encrypt(name, value)); 
  
  
  
            cookie.Expires = DateTime.Now.AddDays(1); 
  
  
  
            if (HttpContext.Current.Response.Cookies[FormsAuthentication.FormsCookieName] == null) 
  
  
  
                HttpContext.Current.Response.Cookies.Add(cookie); 
  
  
  
            else
  
  
  
                HttpContext.Current.Response.Cookies.Set(cookie); 
  
  
  
        } 
  
  
  

  
  
  
        public static string Get() { 
  
  
  
            if (HttpContext.Current.Request.Cookies[FormsAuthentication.FormsCookieName] == null) 
  
  
  
                return null; 
  
  
  
            else { 
  
  
  
                return HttpContext.Current.Request.Cookies[FormsAuthentication.FormsCookieName].Value; 
  
  
  
            } 
  
  
  
        } 
  
  
  

  
  
  
        public static FormsAuthenticationTicket Decrypt(string value) { 
  
  
  
            return FormsAuthentication.Decrypt(value); 
  
  
  
        } 
  
  
  
    }
 
 
 

建立站点SiteA

建立站点SiteB

在SiteA的页面设置Cookie:

CookieHelper.Set("yurow", "123123");

OK!这样，就在SiteA建立了一份Cookie，这个本身并没有任何问题。但是我们往往忽视了一些问题，大家看到，我在CookieHelper类里提供了Decrypt方法，这个方法可以解密Cookie。问题就在于这里！怎么？不知道？那就让贫道来跟施主解释。在这样的网站下，我进行以下的操作步骤：

1、我注册一个帐号；

2、我用这个帐号登录（方便起见，我使用Firefox）;

3、打开Firebug,并且启用该网站的网络监视；

4、刷新登录后的页面；

5、在该页面被监视的HTTP头中可以看到一段Cookie密文。例如：

.MyCookie=32DDE0B4E858248037E4D082EF7E9C9BC607B7AA878F8DD
7DE7C13630A5A38FD9A9DA89B709E79F97D05DEEFC9D55A45D29051D
66955439055D01476E8659E34ABDB42FA0018020194F26618FE74E11B
 这样的字符串。

OK，在该网站的操作到此为止。现在在SiteB中建立一个页面，中间加上一个输入框，一个按钮，并且编写以下事件：

解密代码

 
 
 

  
  
  
protected void Button1_Click(object sender, EventArgs e) { 
  
  
  
    string text = TextBox1.Text; 
  
  
  
    if (!string.IsNullOrEmpty(text)) { 
  
  
  
        FormsAuthenticationTicket ticket = CookieHelper.Decrypt(text); 
  
  
  
        Type type = ticket.GetType(); 
  
  
  
        PropertyInfo[] properties = type.GetProperties(); 
  
  
  
        StringBuilder sb = new StringBuilder(); 
  
  
  
        foreach (PropertyInfo propertie in properties) { 
  
  
  
            string name = propertie.Name; 
  
  
  
            string val = propertie.GetValue(ticket, null).ToString(); 
  
  
  
            sb.Append(name); 
  
  
  
            sb.Append(":"); 
  
  
  
            sb.Append(val); 
  
  
  
            sb.Append("\r\n"); 
  
  
  
        } 
  
  
  
        //textBox2.Text = sb.ToString(); 
  
  
  
        Response.Write(sb.ToString()); 
  
  
  
    } 
  
  
  
}
 
 
 

把上面的Cookie密文，等于后面的部分复制到SiteB页面中，点解密按钮，看到了什么？

Version:1 Name:yurow Expiration:2009-9-23 19:12:44 IssueDate:2009-9-22 19:12:44 IsPersistent:True Expired:False UserData:123123 CookiePath:/

怎么样？所有的信息都被解密了！不过好像高兴地太早了，解密了自己的数据有啥用啊，又拿不到别人的Cookie密文。暂且打住，接下来先讲垂直划分站点安全隐患。

二、垂直划分站点的Forms被破解危机

垂直划分站点其外在表现一般是多域名的N多站点。比如博客园的space.cnblogs.com,news.cnblogs.com等等。而上面第一部分的描述中，贫道似乎漏掉了关于设置machineKey的问题，那是因为要留到这里来讲，要是上面都说了，现在讲啥？

是的，我们是可以在web.config中设置

这样的节点。如果在A站点设置了这个，除非B站点也设置相同KEY的节点,否则SiteB将无法正确解密SiteA产生的Cookie密文。似乎一般的网站都设置了这个，好像我们不需要为此而担心了嘛！

是的，一般情况是这样的。但是，很多公司的人员流动性是较大的，而且垂直分割的站点中，可以接触到web.config的人我相信是非常多的。这就能让某些人，（当然，不包括贫道，嘿嘿）就可以比较容易地拿到这个关键的数据。这个数据能干啥？那还用说啊？我在SiteB我自己建立的站点的Web.config也配置上这个节点，那就可以轻易解开目标网站的Cookie密文。为了保证这方面的安全性不得不把Cookie加密解密部分做成服务，不但容易更新，而且让尽可能少的人接触，防止安全性上的问题被放大。要不然，有个人离职啊，或者电脑中毒啊，最好还是要改动改动machineKey，否则呢？否则就有可能出问题。出什么问题呢？这就是下面要讲的。

三、危机将带来什么后果

加密的Key泄露，会带来什么后果？后果很严重。从上面的例子可以看到这个站点Cookie密文包含的关键信息。而是要CookieHelper类，根据这些关键信息，我们就可以轻易地制造出一个Cookies密文。而拿这个Cookies密文写入目标网站的Coookies中，那么就会认为你已经登录。并且这个（这里我们用的验证可能是Cookie保持的用户名或者ID一类的东西。）用户名可以随意伪造，也就是可以用不存在的用户进行发帖！如果你每次在发帖等操作进行验证无疑是增加了服务器的负担，而最好的办法当然是不外泄加密KEY了。这种方式不当可以伪造用户（几个月前我专门试过一些站点是可以的，而伪造用户发帖会造成该论坛的某个版面甚至首页无法访问），而且可以伪造成管理员的帐号。不难想象，如果用其它用户的帐号或者管理员的帐号进行随意发帖，会造成怎么样的恶劣影响了吧？

OK，意识到问题了吧？

本文来自Birdshover的博客园文章《ASP.NET Forms验证的安全性问题研究——为什么加密代码需要配置为服务》