HTTP的识别,认证与安全——《HTTP权威指南》系列

WilsonLiu's blog 首发地址

识别,认证与安全

第三部分的4章提供了一系列的技术和机器，可用来跟踪身份，进行安全性检测，控制对内容的访问。

客户端识别与cookie机制 第十一章

HTTP最初是一个匿名，无状态的请求/响应协议。服务器处理来自客户端的请求，而后向客户端回送一条响应。web服务器几乎没有什么信息能够用来断定是哪一个用户发送的请求，也没法记录来访用户的请求序列。

用户识别机制

• 承载用户身份信息的HTTP首部

• 客户端IP地址跟踪，经过用户的IP地址对其进行识别

• 用户登陆，用认证方式来识别用户

• 胖URL，一种在URL中嵌入识别信息的技术

• cookie，一种功能强大且高效的持久身份识别技术

HTTP首部

下表给出了7种常见的用来承载用户相关信息的HTTP请求首部。后面3个首部是扩展类型的请求首部。

首部名称	描述
From	用户的E-mail地址
User-Agent	用户的浏览器软件
Referer	用户是从这个页面上依照连接跳转过来的
Authorization	用户名和密码
Client-IP	客户端的IP地址
X-Forwarded-For	客户端的IP地址
Cookie	服务器产生的ID标签

用户登陆

为了使web站点的登陆更加简便，HTTP中包含了一种内建机制，能够用WWW-Authenticate首部和Authorization首部向web站点传送用户的相关信息。一旦登陆，浏览器就能够不断地在每条发往这个站点的请求中发送这个登陆信息了。

缺点：保密性不强，不能跨站点，不一样的站点须要从新输入帐户密码。

胖URL

能够经过胖URL将服务器上若干个独立的HTTP事务捆绑成一个"会话"或"访问"。用户首次访问这个web站点时，会生成一个惟一的ID，用服务器能够识别的方式将这个ID添加到URL中，而后服务器就会将客户端从新导向这个胖URL。

问题：

• 丑陋的URL

• 没法共享URL

• 破坏缓存

• 额外的服务器负荷

• 逃逸口

• 在会话间是非持久的

cookie

cookie是当前识别用户，实现持久会话的最好方式。最初由网景公司开发，但如今全部的主要浏览器都支持他。

cookie的类型

能够笼统的分为:会话cookie和持久cookie。会话cookie和持久cookie的惟一区别就是他们的过时时间。 若是设置了Discard参数，或者没有设置Expires或Max-Age参数来讲明扩展的过时时间，这个cookie就是一个会话cookie。

不一样的站点使用不一样的cookie

cookie的域属性
产生cookie的服务器能够向Set-Cookie响应首部添加一个Domain属性来控制哪些站点开业看到那个cookie。

Set-cookie: user="wilson";domain="wilsonliu.cn"

则用户访问的任何以wilsonliu.cn结尾的站点都会讲此cookie发布出去。

cookie的路径属性
cookie规范甚至容许用户将cookie与部分web站点关联起来。能够经过Path属性来实现这一功能。

Set-cookie: year="21";domain="wilsonliu.cn";path=/year/

则只会在/year/下的站点时才会发布此cookie。

cookie成分

cookie版本0 (Netscape)

Set-Cookie首部

• Name=Value

• Expires

• domain

• Path

• Secure

cookie首部
客户端发送请求时，会将全部与域，路径，安全过滤器匹配的未过时的cookie都发送给这个站点。

cookie版本1 (RFC 2965)

Set-Cookie2

• Name = Value

• Version

• Comment

• CommentURL

• Discard

• domain

• Max-Age

• Path

• Port

• Secure

cookie首部
版本1的cookie会带回与传输的每一个cookie相关的附加信息，用来描述每一个cookie途径的过滤器。每一个匹配的cookie都必须包含来自相应的Set-Cookie2首部的全部Domain,Port和Path属性。

基本认证机制 第十二章

基本认证质询首部

HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm=quoted-realm

响应首部(经过base64编码传输)

Authorization:Basic base64-username-and-password

摘要认证 第十三章

基本认证便捷灵活，但极不安全。用户名与密码明文传输，也没有采起任何措施防止对报文的篡改。安全使用基本认证的惟一方式就是将其与SSL配合使用。

摘要认证与基本认证兼容。但却更为安全。

摘要认证的改进

• 永远不会以明文的方式在网络上发送密码

• 能够防止恶意用户捕获并重放认证的握手过程

• 能够有选择地防止对报文内容的篡改

• 防范其余几种常见的攻击方式

用摘要保护密码

摘要认证遵循的箴言是"毫不经过网络发送密码"。客户端不会发送密码，而是会发送一个“指纹”或密码的"摘要"，这是密码的不可逆扰码。

单向摘要

摘要是"对信息主体的浓缩"。摘要是一种单向函数，主要用于将无限的输入值转换为有限的浓缩输出值。常见的摘要函数MD5，会将任意长度的字节序列转换为一个128位的摘要。
有时也将摘要函数称为加密的校验和，单向散列函数或指纹函数。

用随机数防止重放攻击

使用单向摘要就无需以明文形式发送密码，没有哪一个而已用户可以轻易地从摘要中解码出原始密码。

可是仅仅隐藏密码并不能避免危险，由于即使不知道密码，也能够截获摘要，并重放给服务器。摘要和密码同样好用。

为防止此类重放攻击的发生服务器能够向客户端发送一个称为随机数(nonce)的特殊令牌，这个数会常常发生变化(多是每毫秒，或者是每次认证都变化)。客户端在计算摘要以前要先将这个随机数令牌附加到密码上去。

摘要的计算

摘要认证的核心就是对公共信息，保密信息和有时限的随机值这个组合的单项摘要。

数据

1. 与安全性相关的数据(A1) ——包含有用户名，密码，保护域和随机数等内容

2. 与报文有关的数据(A2) ——好比URL，请求方法和报文实体，A2有助于防止方法，资源或报文被篡改

预受权

在普通的认证方式中，事务结束以前，每条请求都要有一次请求/质询的循环。
若是客户端事先知道下一个随机数是什么，就能够取消这个请求/质询循环。

• 服务器预先在Authentication-Info成功首部中发送下一个随机数

• 服务器容许在一小段时间内使用同一个随机数

• 客户端和服务器使用同步的，可预测的随机数生成算法

应该考虑的实际问题

• 多重质询

• 差错处理

• 保护空间

• 重写URI

• 缓存

安全性考虑

• 首部篡改

• 重放攻击

• 多重认证机制

• 词典攻击

• 恶意代理攻击和中间人攻击

• 选择明文攻击

• 存储密码

安全HTTP 第十四章

保护HTTP的安全

• 服务器认证

• 客户端认证

• 完整性

• 加密

• 效率

• 普适性

• 管理的可扩展性

• 适应性

• 在社会的可行性

HTTPS

HTTPS是最流行的HTTP安全形式，它是由网景公司独创，全部主要的浏览器和服务器都支持此协议。
使用HTTPS时，全部的HTTP请求和响应数据在发送到网络以前，都要进行加密。HTTPS在HTTP下面提供了一个传输级的密码安全层——可使用SSL，也可使用其后继者，传输层安全(Transport Layer Security,TLS)。

大部分困难的编码及解码工做都是在SSL库中完成的，因此web客户端和服务器在使用安全HTTP时无需过多地修改器协议处理逻辑。在大多数状况下，只须要用SSL的输入/输出调用取代TCP的调用，再增长其余几个调用来配置和管理安全信息就好了。

数字加密

• 密码 对文本进行编码，使偷窥者没法识别的算法

• 密钥 改变密码行为的数字化参数

• 对称密钥加密系统 编/解码使用相同密钥的算法

• 不对称密钥加密系统 编/解码使用不一样密钥的算法

• 公开密钥加密系统 一种可以使数百万计算机便捷地发送机密报文的系统

• 数字签名 用来验证报文未被伪造或篡改的校验和

• 数字证书 由一个可信的组织验证和签发的识别信息

密码

密码学基于一种名为密码(cipher)的秘密代码。密码是一套编码方案——一种特殊的报文编码方式和一种稍后使用的相应解码方式的结合体。加密以前的原始报文一般被称为明文(plaintext或cleartext)。使用了密码以后的编码报文一般被称做密文(ciphertext)。

使用密钥的密码

编码算法和编码机器均可能落入敌人手中，因此大部分机器上都有一些盘号，能够将其设置为大量不一样的值以改变密码的工做方式。这些密码参数被称为密钥(key)，要在密码机中输入正确的密钥，解密过程才能正确进行。

对称密钥加密技术

编码时使用的密钥值和解码时同样，这就是对称密钥(symmetric-key)。

保持密钥的机密状态是很重要的，在不少状况下，编/解码算法都是众所周知的，所以密钥就是惟一保密的东西了。好的加密算法会迫使攻击者试遍每个可能的密钥，才能破解代码。用暴力去尝试全部的密钥值称为枚举攻击(enumeration attack)。可用密钥的数量取决于密钥中的位数，以及可能的密钥中有多少是有效的。

对称密钥加密技术的缺点之一就是发送者和接受者在互相对话以前，必定要有一个共享的保密密钥。每对通讯实体都须要本身的私有密钥。若是有N个节点，每一个节点都要和其余全部的N-1个节点进行安全对话，总共须要N的平方个保密密钥，这将是一个管理噩梦。

公开密钥加密技术

公开密钥使用了2个非对称密钥:一个用来对主机报文编码，另一个用来对主机报文解码。编码密钥是众所周知的，但只要主机才知道私有的解密密钥。
全部的公开密钥非对称加密系统所面临的共同挑战是，要确保即使有人拥有了下面全部的线索，也没法计算出保密的私有密钥:

• 公开密钥

• 一小片拦截下来的密文(可经过对网络的嗅探获取)

• 一条报文及与之相关的密文(对任意一段文本运行加密器就能够获得)

混合加密系统和会话密钥

两节点间经过便捷的公开密钥加密技术创建起安全通讯，而后再用那条安全的通道产生并发送临时的随即对称密钥，经过更快的对称加密技术对其他的数据进行加密。

数字签名

除了加/解密报文以外，还能够用加密系统对报文进行签名(sign)，以说明是谁编写的报文，同时证实报文未被篡改过。这种技术被称为数字签名(digital signing)。

1. 客户端将变长报文提取为定长的摘要

2. 客户端对摘要应用了一个"签名"函数，这个函数会将用户的私有密钥做为参数。由于只有用户才知道私有密钥，因此正确的签名函数会说明签名者就是其全部者。

3. 一旦计算出签名，客户端就将其附加在报文的末尾，并将报文和签名都发送给对方。

4. 在接收端，会用公开密钥对签名进行检查，若是不匹配则表示已被篡改。

使用数字签名的好处

1. 签名能够验证是做者编写了这条报文，只有做者才会有最机密的私有密钥，所以，只有做者才能计算出这些校验和。校验和就像来自做者的我的“签名”同样。

2. 签名能够防止报文被篡改，若是有恶意攻击者在报文传输过程当中对其进行了修改，校验和就再也不匹配了。因为校验和只有做者保密的私有密钥才能产生，因此攻击者没法为篡改了的报文伪造出正确的校验码。

数字证书

数字证书中包含了由某个受信任组织担保的用户或公司的相关信息。数字证书都是由官方的"证书颁发机构"以数字方式签发的。
经过HTTPS创建了一个安全web事务以后，现代浏览器都会自动获取所链接服务器的数字证书。若是服务器没有证书，安全链接就会失败。浏览器收到证书的时候会对签名颁发机构进行检查。

HTTPS——细节介绍

HTTPS将HTTP协议与一组强大的对称，非对称和基于证书的加密技术结合在一块儿，使得HTTPS不只很安全，并且很灵活，很容易在处于无序状态的，分散的全球互联网上进行管理。

客户端会对web资源执行某事务时，他会去检查URL的方案，若是URL的方案是https，客户端就会打开一条到服务器端口443(而不是传统的http默认的80端口)的链接，而后与服务器进行SSL"握手"，以二进制格式与服务器交换一些SSL安全参数，附加上加密的HTTP命令。

站点证书的有效性

1. 日期检测

2. 签名颁发者可信度检测

3. 签名检测

4. 站点身份检测

经过代理以隧道形式传输安全流量

客户端一般会用web代理服务器表明它们来访问web服务器。但只要客户端开始用服务器的公开密钥对发往服务器的数据进行加密，代理就不再能读取HTTP首部了！就没法知道应该将请求转向何处了。为了使HTTPS与代理配合工做，能够用HTTPS SSL隧道协议。使用HTTPS隧道协议，客户端首先告诉代理，它想要链接的安全主机和端口。这是在开始加密以前，以明文形式告知的。