Web安全性措施

一、理解验证机制

           Web应用的安全性措施主要包含下面4个方面：

        1、身份验证

           对安全性的第一个基本要求是验证用户。验证是识别一个人或一个系统以及检验其资格的过程。在Internet领域，验证一个用户的基本方法是用户名和口令。

        2、授权

           一旦用户通过验证，还必须给它授权，授权是确定用户是否被允许访问它所请求的资源的过程。例如，在银行系统中，你只能访问你的银行账户，不能访问别人的银行账户。授权通常是通过一个访问控制列表(Access Control List,ACL)而强制实施的，该列表制订了用户和他所访问额度资源类型。

        3、数据完整性

          数据完整性是指从发送者传输到接受者的过程数据不被破坏。例如，你发送一个请求要从一个账户转1000到另一个账户，那么银行得到的请求是转账1000而不是2000.数据的完整性是通过数据一起发送一个哈希码或签名保证的。在接收端需要验证数据或哈希码。

        4、数据保密性

          数据保密性是保证除了应该访问它的用户外，别人不能访问敏感信息。例如，当你发送用户名/口令登录某个Web站点，如果Internet上是以普通文本形式传输的，黑客就可以通过分析HTTP包来获得这些信息。在这种情况下，数据就不具有保密性了。保密性通常是通过对信息的加密来实现的，这样只有应该获得信息的用户才能解密。目前，大多数Web站点使用HTTPS协议来对信息加密，这样，即使黑客分析数据，也不能对他解密，所以也不能使用它。

          授权与保密的区别是二者对信息保护的方式不同。授权是首先防止信息到达无权访问的用户，而保密是保证即使信息被非法获得，也不能被使用。

二、验证的类型

         在Servlet规范中定义了如下四种用户验证机制：①HTTP Basic验证；②HTTP Digest验证；③HTTPS Client验证；④HTTP FORM-based验证。

         这些验证机制都是基于用户名/口令的机制，在该机制中，服务器维护一个所有用户名和口令的列表以及需要保护的资源列表。

      1、HTTP Basic验证

          这种验证成为HTTP基本验证，它是由HTTP1.1规范定义的，这是一种保护资源的最简单和最常用的验证机制。当浏览器请求任何受保护资源时，服务器都要求一个用户名和口令。如果用户输入了一个合法的用户名和口令，服务器才发送资源。

          HTTP基本验证的优点是：实现较容易，所有的浏览器都支持。缺点是：因为用户名和口令没有被加密，而是采用Base64编码，所以是不安全的；不能自定义对话框的外观。

      2、HTTP Digest验证

         这种验证称为HTTP摘要验证，它除了口令是以加密的方式发送，其他与基本验证都一样，但比基本验证全。

         HTTP摘要验证的优点有：比基本验证安全；缺点：只能被IE5以上版本支持；许多Servlet容器不支持，因为规范并没有强制要求。

      3、FORM-based验证

          这种验证称为基本表单的验证，它类似于基本验证，但它使用用户自定义的表单来获得用户名和口令而不是使用浏览器的弹出对话框。开发人员必须创建表单的HTTP页面，对表单外观可以定制。

          基本验证表单的优点是：所有的浏览器都支持，而容易实现。客观可以定制登录页面的外观。缺点是：它不是安全的，用户名/口令没有加密。

      4、HTTPS Client验证

          这种验证称为客户证书验证。它采用HTTPS传输信息。HTTPS是在安全套接层（Secure Socket Layer,SSL）之上的HTTP,SSL可以保证Internet上敏感数据传输的保密性。在这样机制中，当浏览器和服务器之间建立起SSL连接后，所有数据都以加密的形式传输。

         优点：它是4中验证类型中最安全的，所有常用浏览器都支持；缺点：它需要一个证书授权机构（如VeriSign）的证书；它的实现和维护的成本较高。

三、基本验证的过程

            现在来详细看一下客户请求一个受保护资源时，浏览器和Web容器之间是怎么样实现身份验证的。

      （1）浏览器向某个受保护的资源发送请求，此时浏览器并不知道资源是受保护的，所以它发送的一个请求是一般的HTTP请求，例如：

        GET/login.do/1.1

      （2）当服务器接受对资源的请求后，首先在访问控制列表ACL中查看该资源是否受保护的，若不是，服务器将资源发送给用户。若发现该资源是受保护的，它并不直接发送资源，而是向客户发送一个401 Unauthorized(非授权)消息。在该消息中包含一个响应头告诉浏览器访问该资源需要验证。响应消息中还包括验证方法安全域名称以及请求内容的长度和类型。下面是服务器发送的一个响应案例：

       HTTP/1.1 401 Unauthorized

       Server:Tomcat/7.0.39

       WWW - Authenticate:Basec realm = "Security Test"

       Content - Length = 500

       Content - Type = text/html

      (3) 当浏览器收到上面的响应，打开一个对话框提示用户输入用户名和密码。

      (4) 用户一旦输入了用户名和密码并单击“确定”按钮，浏览器再次发送并在名为Authorization的请求头中传递用户名和密码的值，如：

           GET/account.do HTTP/1.1

           Authorization:Basic bWFyeTptbW0 = 

         上面请求头中包含用户名和密码串的Base 64编码值。注意，Base64 编码不是一种加密的方法。使用sun.misc.Base64Encoder和sun.misc.Base64Decoder类可以对任何字符串编码和解码。

       (5) 当服务器接受该请求，它将在访问控制列表ACL检验用户名和密码，如果是合法的用户而且该用户可以访问该资源，它将发送资源并在浏览器中显示出来，否则将再一次发送401 Unauthorized消息，浏览器再次显示用户名/密码对话框。