Rest安全(一)

REST安全（一）

　　## 1.身份认证 ##

　　HTTP认证规范定义了两种HTTP身份认证方式：HTTP Basic(基本认证)和Http Digest（摘要认证）。HTTP认证是一种无状态的认证方式，服务器容器不会为这样的登录匹配Session,身份信息随浏览器关闭而消失。Java平台包含了HTTP的两种身份认证，此外还定义了HTTP+HTML form-based authentication(表单认证)和证书认证。

　　基本认证，摘要认证和表单认证都是基于“用户名-密码”的认证机制，而证书认证是基于证书的认证机制。基本认证和表单认证的请求过程需要提交用户的密码信息，而且对服务器的合法性缺乏判断依据，摘要认证和证书认证的请求过程将对服务器的合法性进行验证而且不直接提交用户的密码。下面我们来讨论着4种认证方式：

　　１.１基本认证

HTTP的基本认证最初定义在HTTP1.0规范（RFC 1945）中，后续最新的定义包含于HTTP1.1规范和HTTP认证规范。HTTP的基本认证是指通过Web浏览器或其他客户端在发送请求时，提供用户名和密码作为身份凭证的一种登录验证方式。在请求发送之前，用户名和密码字符串通过一个冒号合并，形如：Username:Password,合并后的字符串经过Base64算法进行编码。

　　浏览器或客户端最终将经过Base64编码的字符串提交给服务器。Base64编码的目的并不是实习安全和隐私，而是为了将用户名和密码中的HTTP不兼容的字符转换为兼容的字符集。

　　HTTTP基本认证的请求过程是一个质询/回应的对话流程，即客户端请求一个需要身份认证的资源路径，但是没有提供用户名和密码。服务器端响应HTTP401（未授权）的应答，并提供一个认证域（Basic realm）。客户端增加认证消息头，内容为前述的Base64加密字符串，形式为Authorization:Basic base64encode(Username:Password),并再次发起请求。服务器接受请求并处理，如果用户凭据非法或无效，服务器可能再次返回HTTP状态码401，客户端可以再次提示用户输入密码。质询/回应回话流程是可以省略，即可以在客户端第一次请求中就发送认证消息头。

　　基本认证的安全缺陷

1.基本认证通过网络发送用户名和密码，虽然进行base-64编码可以隐藏用户名和密码，但是很容易通过反向编码过程进行解码。

2.即使密码以更加难以解码的方式加密，第三方用户仍然可以捕获被修改过的用户名和密码，并通过重放攻击获取服务器的访问权限。

3.很多用户会将不同的服务使用相同的用户名和密码，基本认证直接发送用户名和密码，会对一些重要的服务(比如在线银行网站)造成威胁。

4.基本认证没有提供任何针对代理和中间人节点的防护措施，他们没有修改认证首部，但却修改了报文的其余部分，这样就严重的改变了事务的本质。

5.假冒服务器很容易骗过基本认证。如果在用户实际链接到一台恶意服务器或者网关的时候，能够让用户相信他链接的是一个受基本认证保护的合法主机，攻击者就可以请求用户输入密码。

6.IIS中站点默认开启匿名身份验证，并可以直接访问。

１.２摘要认证

　　摘要认证最初定义在RFC 2069中，以服务器生成的随机数来维护安全性。RFC 2069中定义的认证响应由HA1，HA2，A1及A2组成。其中，nonce是服务器端随机数。RFC 2617引入了一系列安全增强的选项，包括QoP(保护质量)，请求技数器nc(nonceCount)和cnonce(clientNonce,客户端随机数)。这些增强项有效的防止了通信过程中的明文攻击，随机数的时间戳增加可以防止重放攻击。

1.3表单认证
　　　

　　表单认证是基于HTTP，使用HTML的Form标签提交表单的认证形式。用户登录页面定义在web.xml文件的form-login-page字段中，在没有被认证前，访问者对资源地址的访问会被引导到该页面。访问者提交身份信息后，服务器接受并处理请求，如果认证通过，将重定向到welcome-file字段定义的页面，如果失败，将重定向到form-error-page字段定义的页面。相对于HTTP认证，表单认证允许开发者指定并设计具有良好用户体验的登录页面，登录成功页面和登录失败页面。

　　java平台处理表单认证的实现实在客户端页面（例如HTML+AJAX,JSP,JSF等）中。

1.4证书认证

　　证书认证是通过数字证书认证身份对的方式。这一方式从技术角度可以拆分为证书管理和通信协议两个环节。证书是静态的文件，为基于SSL/TLS协议通信过程所用。

　　１）证书

　　证书是包含公钥和密钥属主信息的文件。加密是为了将信息保密且完整地传递出去，加密算法是实现这一工程的手段。持有加密算法的文件就是密钥，密钥分为公钥和私钥，在加密，解密环节，公钥用于加密，私钥用于解密。

　　当甲有乙的证书后，甲就可以从该证书中获取乙的公钥。使用该公钥对数据进行加密，然后发送给乙，乙使用私有的私钥将数据解密。在这一过程中，信息的保密性和完整性得到了保障。这里就和之前的三个不同了，之前的所有端点认证中，甲都无法确认接受者是乙。

　　证书认证解决了端点认证的两个问题：

　　第一个问题时验证接受者是乙。在签名环节，私钥用于签名，公钥用于检验。乙的公钥就像乙手写签名的快照一样，只有乙本人的签名才与之能相匹配。

　　第二个问题时验证证书的合法性。通信过程中，对方提交的证书说他是乙，那么甲如何相信证书及其所言呢？这需要使用或间接使用另一个权威证书来鉴定该证书的合法性，需要证书链模型。该模型最简单的版本为甲乙互相信任，这种情况下无需ＣＡ证书参与进来.最复杂的版本就是甲乙只相信最权威的CA认证机构，而他们持有的认证证书却都不是直接来自那个机构签发的。通过证书链逐级上溯，最终，甲通过信任CA来认可当前证书是为乙颁发的，这样一来只要乙的私钥签名在经过证书公钥校验后结构一致，甲就可以相信接受者是乙。

　　证书的签发格式遵循X.509标准