form 验证 - 管宇

公告

转载http://blog.sina.com.cn/s/blog_553852910100fuaa.html

ASP.NET安全问题－－Froms验证的具体介绍(上篇)

前言：在ASP.NET中，常用的就是Forms验证，最重要的原因就是灵活。因为Forms验证细细的谈起来也确实不少，而且我也不想草草的说完了事，那对大家和自己都不负责任的。

       本篇的话题如下：
       Forms验证的工作原理
       Forms验证中的API

       Forms验证的工作原理
       我们知道，Forms验证主要是基于cookie的，说白一点就是：把用户信息保存在cookie中，然后发送到客户端；再就是解析客户端的发送了的cookie信息，进行解析，然后进行验证。关于cookieless的工作原理和方法，我这里不赘述，大家可以参看我的另外的一片文章：浅谈ASP.NET内部机制(一)。

       当匿名用户请求一个需要验证后才能访问的资源和页面的时候，那么如果采用了Forms验证，那么URL授权模块就会把用户重定向到登录页面。而之前请求的URL就会被保存起来，等到用户正确的登录后，就再次转向之前要请求的页面。我想这点，大家应该都用过。

       下面我们就看看登录的时候发生了什么，看看登录的具体的流程？也请大家注意我使用的一些术语，因为这些术语再Forms中都有特定的对象，大家之后就可以看到的，很重要。

       1.再浏览器中有个登录窗体，要输入用户名和密码等凭证，通过提交给服务器的ASP.NET网站来审核，检查凭证是否正确。
       2.如果凭证正确，那么就会再服务器端就会创建一个"身份验证票据"。身份验证票据中含有了经过加密的用户信息。
       3.这个票据再服务器端被写入cookie中，然后发送到客户端。
       4.然后用户就被重定向到他们最初请求的URL中。

       注：大家可能会有疑问：最初请求的URL到底保存在哪里？不要担心，现在只要明白上面的流程就OK。

        5.上面第4步就是要转向最初请求的URL，假设最初的请求页面是Default.aspx,那么现在就是从登录的页面Login.aspx转向到Default.aspx 页面，此时因为身份验证的票据cookie已经存在于客户端的浏览器中了，此时的转向Default.aspx页面时，实际是再次向服务器端发起了请求，所以正如我们之前所谈到的：每个请求都要从ASP.NET管道中一级级的向后传，要经历ASP.NET的的生命周期：Application_BeginRequest,Application_AuthenticateRequest.....。(希望大家明白)

       但是这次的请求就和第一次我们发起的请求步同了，为什么？
       第一次我们请求Default.aspx页面的时候，我们根本就没有提供任何的表明我们身份的票据，但是这次我们已经登录了，而且我们的浏览器中已经有了我们的身份验证的票据的cookie，此时在Application_AuthenticateRequest事件中，Forms验证模块就获取表明我们身份cookie，然后就利用cookie中信息填充Context.User。
       验证模块处理完之后就是授权模块起作用了。其实URL授权模块就会利用我们之前填充在Context.User中的信息来验证用户是否被批准访问所请求的资源或者页面。


       Forms验证中的API
       实现Forms身份验证之前，我们看看组成Forms验证的API以及相关的类：
       FormsAuthenticationModule:对每个请求进行验证的HTTP模块
       FormsAuthentication:包含在Forms验证中我们常用的方法和属性(很重要的)
       FormsIdentity：Forms验证标识。
       FormsAuthenticationTicket：身份验证的票据，对用户的信息进行加密后的产物，我们一般把它写如cookie中，之前我们谈过了的。
       上面的类在System.Web.Security下。

       下面我们来一一介绍.

       FormsAuthenticationModule
       它是一个实现了IHttpModule接口的类。它可以用来处理每个请求的Application_AuthenticateRequest事件。如果发送了的请求中已经包含了cookie信息，那么这个模块就对cookie信息进行解密和解析，然后构造一个GenericPrincipal的类实例填充Context.User,并且也创建一个FormsIdentity的实例。
       注意：当我们在web.config中配置了Forms验证后，那么我们在Application_AuthenticateRequest事件写的代码要是和Forms相关的API。上篇文章谈过了。

       FormsAuthentication类
       这个类很重要。

还有一点注意的就是：因为FormsAuthentication和FormsAuthenticationModule名称很相似，很容易混淆。

      它们之前的区别在于，FormsAuthenticationModule是一个HTTP模块；而FormsAuthenticate是一个类，它有很多的方法和属性。更加直白的说就是：它们之前没有什么关联，只是在Application_AuthenticateRequest事件中我们常常要调用FormsAuthenticate类的一些方法和属性。而且FormsAuthenticate的很多方法都是静态的方法，我们不会创建FormsAuthenticate类的实例。

       还有一点要特别注意的就是FormsAuthenticate的Authenticate方法。
       我们之前说过了，我们一般是在登录窗体中提交用户信息，然后服务器端验证提交的信息，我们在服务器端常常是去数据库中检查这些信息的正确性，但是去数据库或者其他的数据存储(如文件，活动目录)中去检查只是一种情况。
       还有另外的情况。不知道大家是否记得web.config 中的一个配置的节点：
<authentication mode="Forms">
        <forms>
          <credentials>
            <user name="xiaoyang" password="xiaoyang"/>
            <user name="panyan" password="panyan"/>
          </credentials>
        </forms>
    </authentication>

       如果我们在配置文件配置了上述的信息，那么我们就可以用Authenticate方法来检查提供了用户信息(用户名和密码)是否正确，如果我们没有在web.config配置用户的信息，也就是说我们是把信息保存在数据库等其他的地方，那么我们就不能Authenticate这个方法。当然我们很少用Authenticate这个方法，因为我们不可能把所有用户信息硬编码到配置文件中，但是还是要清楚这个方法。

       另外我简单的介绍一些常用的方法，具体的使用我以后会讲述。
       在FormsAuthenticate中使用频繁的是RedirectFromLoginPage方法。每当验证了用户的凭证后就会使用到这个方法，也就是我们之前说过的：跳转到我们最初请求的页面。
       这个方法就这么简单的一"跳"，但是其实在内部做了很多的事情：
       1.为用户创建一个身份验证的票据
       2.对身份验证的票据进行加密
       3.创建一个cookie，把加密的票据保存在cookie中
       4.向HTTP响应添加cookie，并且发送给客户端。
       5.跳转，并且把用户重定向到最初请求的页面

       另外FormsAuthenticate类还有很多的其他方法和属性：

       FormsAuthenticate中涉及到客户端保存cookie的两个属性就是：
       FormsCookieName:获取或者设设置cookie的名称
       FormsCookiePath:获取或者设置cookie的url路径

       其中FormsCookiePath属性有一点要注意:大多数的浏览器会在判断cookie是否要和请求一起发送时，用到cookie路径。(我们一般在配置文件配置path="/"),如果我们配置的path不是"/"，那么这个cookie就不会和请求发送到服务器端.

       FormsAuthenticate中和cookie操作相关的方法有：
       Decrypt:提取身份验证cookie的加密信息，创建FormsAuthenticationTicket,也就是解密。
       Encrypt:加密。从FormsAuthenticationTicket中获取信息，并且加密。以备我们之后把加密的信息写入cookie
       GetAuthCookie:创建身份验证cookie，但是并不把它立即添加到HTTP响应中
       SetAuthCookie:创建身份验证cookie，并且把它添加到Response.Cookie中。
       RenewTicketIfOld：刷新身份验证cookie的生命周期

GetRedirectUrl:把用户重定向到他们最初请求的页面。

SignOut:使得当前的身份验证cookie过期。我们常用的注销功能。

       FormsIdentity
       大家现在应该知道什么是标识 Identity,它包含了用户名和ID标识信息，可以参看我前面的文章。

       FormsAuthenticationTicket 票据
       通过上面的讲解，大家已经对它不陌生了，FormsAuthenticationTicket实际上就包含用户信息的一个类的实例。

       注意：FormsAuthenticationTicket和cookie之间的区别：
       cookie其实就是一个载体，容器，它包含了加密后的FormsAuthenticationTicket。

       FormsAuthenticationTicket类的UserName属性就是用户的用户名，我们可以根据这个属性识别不同的用户。

       由于身份验证是基于cookie的，所以要考虑到cookie的过期的问题。比如我们在登录时有个"记住我"的checkbox，如果勾上，那么就创建了一个永不过期的cookie，处于安全，我不提倡这样。

       所以在FormsAuthenticationTicket也提供了关于设置cookie属性：

       Expiration:获取一个表示cookie期满的DateTime对象
       Expired：判断cookie是否过期
       IsPersistent:是否在用户关闭浏览器后继续保存cookie
       IssueDate:返回最初设置cookie的时间

还有就是CookiePath：设置cookie的保存路径，前面谈论过了，一般设置为"/"。

另外FormsAuthenticationTicket身份验证票据目的是识别用户。同时，我们也可以利用FormsAuthenticationTicket的UserData属性添加额外的信息，如角色等，然后这额外的信息就可以保存在cookie中。

今天就谈这里。大家先有个总体的认识，具体的代码部分，我们后面谈。谢谢各位！！！

ASP.NET安全问题－－Froms验证的具体介绍(中篇)

前言：今天是端午节，大家节日快乐！别忘了过我们的传统节日！！！因为前一篇文章已经谈论了与Forms验证有关的一些理论的知识，所以本篇主要讲述Forms验证一般的使用方法，也给出一些代码。可能有些话题之前园子里有朋友谈论过，如果有重复，那么就权当是复习也行！

本篇的话题如下：

       启用Forms身份验证
       用户信息的存储
       web.config配置的一些用法
       Forms验证简单的功能介绍
       Forms验证中的Cookie问题

       启用Forms身份验证
       相信大家对很清楚如何启用 Forms验证，但是这里我还是罗嗦一下。
       我们只要在 web.config文件中配置如下就行了：

        这样之后，ASP.NET运行时就知道我们启用了Forms验证，在生命周期的验证阶段就激活FormsAuthenticationModule模块。

       还有一点要特别注意：<authentication/>元素节点只能在应用程序的根文件夹中的 web.config中配置。如果在子文件夹中使用这个节点就会报错。这也说明了每个应用程序只能定义一个身份验证类型。

       而且在<authentication/>节点中，我们还可以进行更多的设置。如下：

我们下面就看看<forms>节点中的属性的含义和用途：
name：定义身份验证cookie的名称。因为我们把身份验证的票据是存放在cookie中的，而且我们必须给身份验证cookie取具有唯一性的名称，防止和其他的应用程序中的cookie冲突。

loginUrl：从英文名字就可以知道是关于登录的。实际上就是标明把用户重定向到哪个页面取登录。

timeout:设置身份验证cookie持续的时间，以分钟为单位的。而且这个时间是一个相对的时间，就是说每次对用户进行验证时，cookie的期限就会被重新设置。如果在60分钟内用户再没有向服务器发起请求，那么cookie就过期，之后如果用户再次发起请求，那么就要重新输入用户名和密码等信息。

       path：设置cookie的保存的路径，一般是设置为"/"，我们不要轻易的改变。

       我们之前也说过，我们的身份验证的票据是加密以后再存放如cookie中的，然后再把cookie发送到客户端。当客户端再次请求的时候，再服务器端就会解析客户端发送来的cookie信息，我们必须要确认：客户端发送来的cookie信息就是我们之前从服务器端发送过去的，也就是说，我们要判断，我们的cookie在客户端是否被篡改了。

       所以，这就是<forms/>中属性protection的用途。protection的值有四个：
       Encryption:对cookie的内容信息进行加密。
       Validation:向cookie中的内容添加MAC(消息验证代码),以便服务器判断cookie是否被篡改了。
       None：禁用加密和篡改检查
       All:同时启用加密和篡改检查。

       默认情况下是"All"，因为它可以把数据加密放入cookie中，而且对返回到服务器端的cookie进行验证。

       用户信息的存储

       我们一般把用户的信息，如用户名和密码存放在数据库中。如之前一篇文章说的，我们也可以把用户的用户名和密码信息直接放在web.config文件中。

       Forms验证其实对把用户凭证信息放在哪里提供了很大的灵活性。默认情况下是放在web.config中的。如下代码：

见上面的 <credentials>节点，就是我们存放的用户信息。上面的信息是以明文(没有加密)的形式存放。我们也采用加密的方式存放，只要配置如下：<credentials passwordFormat="MD5">，配置 passwordFormat的加密方式就行了。那么用户在传输之前就会被加密。

还有就是把用户信息存储在数据库中，我们后面会讲述的，也是最常用的方式。

       web.config配置的一些用法
       1.在web.config中添加用户凭证
       我们之前说过了，ASP.NET的身份验证中，对于如何存储用户凭证提供了很大的灵活性。默认情况下是把凭证存储在web.config中的。
       我们还是来看看之前配置的一些节点信息：

       在<credentials>中就是我们存储的用户的一些信息。不知道大家是否还记得我们之前已经说过了的Authenticate方法:只有把用户信息存放在了配置文件中，我们才可以使用这个方法，代码如下(判断提交的用户信息是否合法)：
bool IsAuthenticate= FormsAuthentication.Authenticate(userName, userPassword);

       2.拒绝匿名用户访问
       其实这是与用户授权的问题现关联的，关于授权问题，我们以后谈，这里只是简单的提下，算是预热吧！
       我们可以拒绝匿名用户访问我们的网站，只要配置如下：

谈起这个节点，还是有一些话题的，这个我们在专门讲述授权的时候具体谈。现在我们的重点是验证！

Forms验证一些简单的使用

其实对于任何一种验证来说，无非就是提供输入用户信息的界面，也就是常见的登录页面。登录页面可以很简单：只要提供输入用户名和密码的输入框就行了，而登录页面的功能就是验证输入信息是否正确，如果正确就创建身份验证的票据并且保存在cookie中。
下面就看看一个简单的页面以及代码的实现：

注：界面很简单，大家可能会想到ASP.NET现有的Login控件，但是Login是基于MemberShip的。现在谈MemberShip还过早，因为我们后面文章专门的讲解从Forms验证到MemberShip的自然过渡，那样大家就可以很清楚的知道MemberShip到时怎么回事。

代码部分，其实主要是"登录"按钮背后的代码：

protected void  btnLogin_Click(object sender, EventArgs e)
{

     if (FormsAuthentication.Authenticate(txtUserName.Text, txtUserPasswork.Text))
        {
             FormsAuthentication.RedirectFromLoginPage(txtUserName.Text, false);
        }
     else
        {
             throw new Exception("登录失败！！！");
        }
}

        代码的前提是：我们把用户的信息存放在了web.config文件中，因为我们用了Authenticate方法。
       首先代码就判断提供的用户名和密码是否正确，如果正确，那么就通过了验证，那么我们就调用RedirectFromLoginPage就把用户定位了他们最初请求的页面。
       注意：当我们调用RedirectFromLoginPage方法时，RedirectFromLoginPage就创建一个身份验证的票据，即把用户的信息写入票据中，并且加密，并把票据写入cookie，然后就把用户定位了他们最初请求的页面。我们只是写了一行代码就实现了很多的功能。

还有一点就是RedirectFromLoginPage方法的第二个参数指出了是否应该创建一个持久性的cookie，即用户关闭浏览器后依然保留cookie。我们常常实现"记住我"的功能就是传入了true.

当我们登录了之后，要注销也只要一行代码：

protected void btnloginOut_Click(object sender, EventArgs e)
        {
                FormsAuthentication.SignOut();
        }

Forms验证中的Cookie问题

之前我们所见到的示例都是利用非持久性的身份验证cookie来维持请求之前的身份验证。这就意味着：如果用户关闭浏览器，cookie就期满失效，下次还需要在此登录。从安全的方面还说，这是个好事。

身份验证cookie中保存的身份验证票据是ASP.NET应用程序识别用户的工具。例如，如果一个用户拥有一个管理员的有效验证票据，那么我们的ASP.NET网站就会认为这个用户就是管理员。

尽管使用持久化的身份验证cookie风险很大，但是还是有很多的用处的。例如，如果我们只是仅仅为了区别不同的用户，而不是对受限资源的访问进行限制，那么我们就不要求用户在每次访问站点时都登录，这样我们就可以利用持久化的cookie，而且创建持久化的cookie也很简单，如我们之前用的RedirectFromLoginPage，只要把方法的第二个参数设置为true就行了。

除此之外，创建持久化的身份cookie，我们还可以使用SetAuthCookie,并且把第二个参数设置为true。如下：
FormsAuthentication.SetAuthCookie(txtUserName.Text, true);

持久化的cookie只有在调用了FormsAuthentication.SignOut();方法之后才会过期。并且持久化的cookie不会受到web.config中的<forms>节点中设置的超时的影响。如果我们希望持久化的cookie超时，我们就要调用FormsAuthentication类的GetAuthCookie方法，设置cookie的期满日期和时间，并且我们自己手动的把它写入HTTP响应。

如下面的代码，我们创建一个时间为一周的持久化的cookie(代码加了注释)：

protected void  btnLogin_Click(object sender, EventArgs e)
        {
                //判断用户提供的验证信息是否正确
                if (FormsAuthentication.Authenticate(txtUserName.Text, txtUserPasswork.Text))
                {
                        //创建一个持久化的身份验证cookie
                        HttpCookie cookie = FormsAuthentication.GetAuthCookie(txtUserName.Text, true);

                        //设置cookie的有效时间
                        cookie.Expires = DateTime.Now.AddDays(7);

                        //手动添加到HTTP响应中
                        Response.Cookies.Add(cookie);

                        //跳转到最初请求的页面
                         Response.Redirect(FormsAuthentication.GetRedirectUrl(txtUserName.Text, true));
                }
                else
                {
                        throw new Exception("登录失败！！！");
                }
        }

其中GetRedirectUrl获取用户最初请求的URL

今天的就写到这里，下一篇比较深入讲述 Forms验证的一些知识！
谢谢大家的支持！！！

2. 前言:通过之前的几篇文章，相信大家对Forms验证有了一定的了解，也清楚了Identity,IPrincipal,票据等概念。之前的文站一直没有把验证和数据库联系起来，本篇就从这方面讲解，用代码来演示！而且代码中也涉及到一些角色授权的问题，为之后的文章伏笔!

今天话题如下：

       验证流程讲述
       数据库准备
       代码编写

       验证流程讲述

       我们首先假设一个场景：用户现在已经打开了我们的首页Default.aspx，但是有些资源只能是登录用户才可以看到的，那么如果这个用户想要查看这些资源，那么他就要登录。而且这个用户已经有了一个帐号。(我们本篇主要的话题是身份验证，至于创建用户账户是怎么创建的，我们不关心，方法很多，如直接一个数据库插入就行了!)

       我们现在就把我们的一些流程说下:
       1.用户登录，在输入框中输入用户名和密码信息
       2.点击登录按钮后，到数据库中查询该用户是否存在
       3 如果存在，服务器端代码就创建一个身份验证的票据，保存在cookie中，然后发送到客户端的浏览器
       4.用户已经有了验证的cookie，那么就页面就跳转到用户之前请求的页面

数据库准备

       那么下面我们就开始详细讲述:
       首先，我们我们肯定要先得创建一个数据库，我们就取名为Login表，创建一个用户信息表，我们在在表中建立三个字段UserName,UserPassword，UserRole(大家可以创建更多字段,我这里只是演示，大家可以扩展的). 至于表中的数据，大家自己随便插入几条！

       代码编写
       因为我们常常要验证用户，所以我们把验证用户的代码写成一个方法放在App_Code目录下的Helpers.cs类中
       代码如下：

public static bool ValidateUser(string username, string password)
{

然后我们就创建一个登录的页面Login.aspx,在页面上面放入两个TextBox，分别用来供用户输入用户名和密码。

放上一个按钮，用来登录。

回到Helpers.cs中，我再添加一个方法，来获取用户的角色：

public static string  GetRoleForUser(string username )
{
        //创建链接
    SqlConnection con = new SqlConnection();
    con.ConnectionString =
        ConfigurationManager.ConnectionStrings[“MyConnectionString”].ConnectionString;

    SqlCommand com = new SqlCommand();
    com.Connection = con;

        //执行命令
    com.CommandText = “Select UseRole m Users Where Username=@Username;
    com.Parameters.AddWithValue(“@Username”, username);

    con.Open();

        //返回结果
    string userRole= (string)com.ExecuteScalar();

    con.Close();

}

为了启动Forms验证，我们还得到web.config文件中配置，如下：

并且不允许匿名用户访问我们的网站：

然后我们就开始在Login.aspx的登录按钮下面写代码了：

基本思想如下：

1.验证用户是否存在，

2.如果存在，同时获取用户的角色

3.创建身份验证票据和cookie，并且发送到客户端的浏览器中

代码都加了注释，通过之前的基础，相信大家可以对下面的代码没有问题。

Code
protected void LoginCallback(object sender, EventArgs e)
{
    if (Helpers.ValidateUser(UserName.Text, Password.Text))
    {
                //获取用户的角色
        string     rolenames = Helpers.GetRolesForUser(UserName.Text);

                //创建身份验证票据
        FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(1,
                UserName.Text, DateTime.Now, DateTime.Now.AddSeconds(40), false, roles);

                //加密票据
        string encryptedTicket = FormsAuthentication.Encrypt(ticket);

                //创建新的cookie
        HttpCookie cookie = new HttpCookie(FormsAuthentication.FormsCookieName);

                //把加密后的票据信息放入cookie
        cookie.Value = encryptedTicket;

                //把cookie添加到响应流中
        Response.Cookies.Add(cookie);

                //把cookie发送到客户端
        Response.Redirect(FormsAuthentication.GetRedirectUrl(UserName.Text,false),true);

    }
}

好了，现在如果我们正确的输入用户名和密码，那么我们的浏览器中就有了身份验证的cookie了，现在我们的页面就要马上从原来的Login.aspx转向到Default.aspx页面了，我们现在把这个转向的过程在头脑中把它慢速化，因为我们要分析这个过程。

在Login.aspx转向到Default.aspx页面跳转的过程中，其实我们在请求Default.aspx页面，这个我们之前请求的过程没有任何的区别，也是一样要经历ASP.NET的一些生命周期，但是这次我们的浏览器中已经有了身份验证的cookie，ASP.NET运行时在处理，在处理Application_AuthenticateRequest事件时就要解析我们的cookie了。其实在之前我们登录之前，在这个事件代码中也解析了cookie的，只是那时候没有找到cookie而以。

Application_AuthenticateRequest事件的代码中，其实就是解析cookie，然后把用户的身份标识，并且把用户的身份信息保存起来：

Code
Code
void Application_AuthenticateRequest(object sender, EventArgs e)
{
    HttpApplication app = (HttpApplication)sender;

        //获取身份验证的cookie
    HttpCookie cookie = Request.Cookies[FormsAuthentication.FormsCookieName];

    if (cookie != null)
    {
        string encryptedTicket = cookie.Value;

                //解密cookie中的票据信息
        FormsAuthenticationTicket ticket =
            FormsAuthentication.Decrypt(encryptedTicket);

                //获取用户角色信息
        string[] roles = new string[]{ticket.UserData.toString()};

               //创建用户标识
        FormsIdentity identity = new FormsIdentity(ticket);

                //创建用户的主体信息
        System.Security.Principal.GenericPrincipal user =
        new System.Security.Principal.GenericPrincipal(identity, roles);
        app.Context.User = user;
    }
}

我们看到最后一行代码：app.Context.User = user;，把用户的身份以及角色信息保存在了User属性中。

我们就可以在页面中通过如下方法判断用户是否登录了：

if (Page.User.Identity.IsAuthenticated)
{
//

}

用下面的方法判断用户是否属于某个角色：

if (Page.User.IsInRole("Admin")
{
//

}

其实这个我们之前讲过了的Identity,IPrincipal概念有关，不清楚的可以看看之前的文章！

代码到这里，今天也写完了，有关身份验证的问题就要讲完了，还差一个问题没有讲述：自定义身份验证以及开发自定义的HttpModule.

之后的的文章将讲述授权的问题。

谢谢大家的支持！

posted on 2010-04-26 15:21 管宇阅读(298) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

小管

公告