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

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

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

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

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

 

 一、简单的Forms被破解危机

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

 

        <authentication mode="Forms">

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

        </authentication>

编写一个帮助类:

 

CookieHelper类

建立站点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中建立一个页面,中间加上一个输入框,一个按钮,并且编写以下事件:

解密代码

把上面的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,意识到问题了吧?那贫道就不再多说了。

posted @ 2009-09-22 20:19 Birdshover 阅读(...) 评论(...) 编辑 收藏