ASP.NET Forms验证的安全性问题研究——为什么加密代码需要配置为服务

申明：这个帖子不是要你去干啥坏事，就是提醒一下你可能会遇到的安全性问题。

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

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

一、简单的Forms被破解危机
二、垂直划分站点的Forms被破解危机
三、危机将带来什么后果

 

 一、简单的Forms被破解危机

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

 

        <authentication mode="Forms">

            <forms name=".MyCookies"></forms>

        </authentication>

编写一个帮助类：

 

    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中设置

<machineKey validationKey="*********" decryptionKey="********" validation="SHA1" decryption="3DES"/>

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

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

三、危机将带来什么后果

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

OK，意识到问题了吧？那贫道就不再多说了。