ASP.NET Forms驗證的安全性問題研究——為什麼加密代碼需要配置為服務

申明：這個文章不是要你去幹啥壞事，就是提醒一下你可能會遇到的安全性問題。

ASP.Net提供了內建的登入驗證，最為常用的就是Forms驗證。講解如何配置的文章非常多，這裡就不再講如何配置使用這個驗證的方式了。下面講講其在安全性上存在的一些被忽視的問題。其實它本身沒有問題，而使用的方式上會附帶出來一些問題。

本文將分三部分講實際應用中將會遇到的安全性問題，並且加以研究，並嘗試提出解決方案。

一、簡單的Forms被破解危機
二、垂直劃分網站的Forms被破解危機
三、危機將帶來什麼後果

 

 一、簡單的Forms被破解危機

最簡單的一個Forms驗證，在web.config下配置節點：

 

        <authentication mode="Forms">

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

        </authentication>

編寫一個協助類：

 

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中設定

<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，意識到問題了吧？那貧道就不再多說了。