读书笔记_图解HTTP(五) 确认访问用户身份的认证以及基于HT

2019-05-24  本文已影响0人  我是李小米

读《图解HTTP》记录

上一篇 读书笔记_图解HTTP(四) HTTPS

1、确认访问用户身份的认证

某些Web页面只想让特定的人浏览，必不可少的就是认证功能。

1.1、何为认证

计算机本身无法判断客户端的身份，为了弄清楚是谁在访问服务器，就得要让客户端自报家门。可是，就算是对方声称自己是a,身份是否属实这点也无从谈起。位了确认a本人是否真的具有访问权限，就需要核对“登陆者本人才知道的信息”、“登陆者本人才会有的信息”。核对信息通常指一下：

HTTP使用的认证方式

HTTP/1.1使用的认证方式如下

1.2、BASIC认证

BASIC认证是从HTTP/1.0就定义的认证方式。即便是现在仍有一部分网站会使用这种认证方式。是Web服务器与通信客户端之间进行的认证方式。

BASIC认证的步骤
BASIC认证概要

BASIC认证采用的虽然是Base64编码，方这不是加密处理。不需要任何附带信息就能解码。在HTTP等非加密通信的线路上如果被 窃听，被盗的可能性极高。
另外，如果想再进行一次BASIC认证，一般的浏览器却无法实现认证注销操作，这也是问题。
BASIC认证使用上不够便捷灵活，且达不到多数Web网站期望的安全性等级，因此它并不常用。

1.3 DIGEST认证

为弥补BASIC认证存在的弱点，从HTTP/1.1起就有了DIGEST认证。DIGEST认证同样使用质询/响应的方式，但是不会像BASIC认证那样直接发送明文密码。
所谓质询响应方式是指，一开始一方会先发送认证要求给另一方，接着使用从另一方那接收到的质询码计算生成响应码。最后将向响应码返回给对方进行认证的方式。



因为发送给对方的只是响应摘要及由质询码产生的计算结果，所以比起BASIC认证，密码泄露的可能性就降低了。

DIGEST认证的认证步骤
DIGEST认真概要

username是realm现顶范围内可进行认证的用户名。
uri(digest-uri)即Request-URI的值，但考虑到经代理转发后Request-URI的值可能被修改，因此事先会赋值一份副本保存在uri内。
response也可叫做Request-Digest，存放经过MD5运算后的密码字符串，形成响应码。

1.4 SSL客户端认证

从使用用户ID和密码的认证方面来讲，只要二者的内容正确，就可以认证是本人的行为。但是如果用户ID和密码被盗，就很有可能被第三者冒充。利用SSL客户端认证则可以避免该情况的发生。

SSL客户端认证是由HTTPS的客户端证书完成认证的方式。凭借客户端证书认证，服务器可以确认访问是否来自已登录的客户端。

1.4.1 SSL客户端认证的步骤

为了达到SSL客户端认证的目的，需要事先将客户端证书分发给客户端，且客户端必须安装此证书。

1.4.2 SSL客户端认证采用双因素认证

在多数情况下，SSL客户端认证不仅依靠证书完成认证，一般会和基于表单认证组成形成一种双因素认证来使用。所谓双因素认证就是指，认证过程中不仅需要密码这一因素，还需要申请认证者提供其他持有信息，从而作为另一个因素，与其组合使用的认证方式。

就是说，第一个认证因素的SSL客户端证书用来认证客户端计算机，另一个认证因素的密码则用来确定这是用户本人的行为。

通过双因素认证之后，就可以确认是用户本人正在使用匹配正确的计算机访问服务器。

1.4.3 SSL客户端认证必要的费用

使用SSL客户端认证需要用到客户端证书。而客户端证书需要支付一定费用才能使用。
这里的费用是，从认证机构购买客户端证书的费用，以及服务器运营者为保证自己搭建的认证机构安全运营所产生的费用。

1.5 基于表单认证

基于保单的认真方法并不是在HTTP协议中定义的。客户端会向服务器上的Web应用程序发送登录信息,按登录信息的验证结果认证。
多数情况下，客户端把事前登录好的用户ID和密码等登录信息发送给Web程序，基于认证结果来决定认证是否成功。

1.5.1、认证多为基于表单认证

由于使用上的便利性以及安全性问题，HTTP协议标准提供的BASIC认证和DIGEST认证几乎不怎么使用。另外，SSL客户端认证虽然安全，但有成本，现在还未普及。
比如SSH和FTP协议，服务器和客户端之间的认证是合乎标准规范的，并且满足了最基本的功能需求上的安全级别，因此这些协议的认证可以拿来直接使用。但对于Web网站的认证功能，能够满足其安全使用级别的标准规范并不存在，所以只好使用由Web应用程序各自实现基于表单的认证方式。
不具备共同标准规范的表单认证，在每个Web网站上都会有各自不同的实现方式。如果是全面考虑过安全性能而事先的表单认证，那么就能具备高度的安全等级。但在表单认证的实现中存在问题的Web网站也很多见。

1.5.2、Session管理和Cookie应用

基于表单认证的标准规范尚未有定论，一般会使用Cookie来管理Session。
基于表单认真本身是通过服务器端的Web应用，将客户端发送过来的用户ID和密码与之前登录过的信息做匹配来进行认证的。
但鉴于HTTP是无状态协议，之前已认证成功的用户状态无法通过协议层保存下来。即，无法实现状态管理，因此即使当该用户下一次继续访问，也无法区分他与其他用户。于是我们用Cookie来管理Session,以弥补HTTP协议中病不存在的状态管理功能。


Session管理以及Cookie状态管理

除了以上介绍的应用实例，还有应用其他不同方案的案例。

另外，不仅基于表单认证的登录信息以及认证过程都无标准化的方法，服务器端因如何让保存用户提交的密码信息等登录信息也没办法标准化。
通常，一种安全的保存方法是，先利用给密码加盐(salt)的方式增加额外信息，再使用散列函数计算出散列值后保存。但是我们也经常看到直接保存明文密码的做法，而这样的做法具有导致密码泄露的风险。
加盐(salt)其实是由服务器随机生成一个字符串，但是要保证长度足够长，并且是真正随机生成的。然后把它和密码字符串连接(前后都可以)生成散列值。当两个用户使用同一个密码时，由于随机生成的salt不同,对应的散列值也是不同的。这样一来，很大程度上减少了名密码特征，攻击者也就很难利用自己手中的密码特征进行破解。

2、基于HTTP的功能追加协议

虽然HTTP协议既简单又简捷，但随着时代的发展，其功能使用上已经不满足现阶段了。下面就要讲基于HTTP新增加的功能的协议。

2.1、基于HTTP的协议

在建立HTTP标准规范时，制定者主要是想把HTTP当作传输HTML文档的协议。随着时代的发展，Web的用途根据多样性，比如演化成在线购物网站、社交网络服务、企业内部的管理工具等等。

而这些网站所追求的功能可通过Web应用和脚本程序实现。即使这些功能已经满足需求，在性能上却未必最优，这是因为HTTP协议上的限制以及自身性能有限。

HTTP功能的不足可通过创建一套全新的协议来弥补。可是目前基于HTTP的Web浏览器的使用环境已遍布全球，因此无法完全抛弃HTTP。有一些行协议的规则也是基于HTTP的，并在此基础上添加了新的功能。

2.2 消除HTTP瓶颈的SPDY

Google在2010年发布了SPDY,其开发目标是为了解决HTTP的性能平静，缩短Web页面加载时间(50%)。

2.2.1 HTTP瓶颈

在Facebook和Teitter等社交网站上，几乎能够实时观察到海量用户公开发布的内容，这也是一种乐趣。当几百、几千万的用户发布内容时，Web网站位了保存这些新增的内容，在短时间内就会发生大量内容更新。
为了尽可能实时地显示这些更新的内容，服务器上一有内容更新，就需要直接把那些内容反馈到客户端的页面上，虽然看起来挺简单，但HTTP却无法妥善的处理好这项任务。
使用HTTP协议探知服务器上是否有内容更新，就必须频繁从客户端到服务器进行确认。如果服务器上没有内容更新，那么就会产生很多徒劳的通信。
若想在所有Web实现所需的功能，以下这些HTTP标准就会成为瓶颈。

Ajax的解决方法

Ajax(Asynchronous JavaScript and XML,异步JavaScript与XML技术)是一种有效利用JavaScript的DOM(Document Object Model，文档对象模型)的操作，以达到局部Web页面替换加载的而异步通信手段。和之前的同步通信相比，由于它只更新一部分页面，响应中传输的数据量会因此而减少，这一优点是显而易见的。
Ajax的核心技术是名为XMLHttpRequest的API，通过JavaScript脚本语岩的调用就能和服务器进行HTTP通信。借由这种手段，就能从已加载完毕的Web页面发起请求，只更新局部页面。
而利用Ajax实时得从服务器获取内容，有可能会导致大量请求产生。另外Ajax仍未解决HTTP协议本身存在的问题。


Ajax通信
Comet的解决方法

一旦服务器端有内容更新了，Comet不会让请求等待，而是直接给客户端响应。这是一种通过延迟应答，模拟实现服务器端先客户端图送(Server Push)的功能。
通常，服务器收到请求，会在处理完毕之后就立即返回响应，单位了实现推送功能，Comet会先将响应置于挂起状态，但服务器端有内容更新时，再返回该响应。因此，服务器一旦有更新，就可以立即反馈给客户端。
内容上虽然可以左到实时更新，但位了保留相应，一次连接的持续时间也边长了。期间为了维持连接会消耗更多的资源。另外，Comet也仍未解决HTTP协议本身存在的问题。


Comet通信
SPDY的目标

陆续出现的Ajax和Comet等提高易用性的技术，一定程度上使HTTP得到了改善，当HTTP协议本身的限制也令人无奈。为了进行根本性的改善，需要有一些协议层面上的改动。
处于持续开发状态中的SPDY协议，真是为了在协议级别消除HTTP所遭遇的瓶颈。

2.2.2 SPDY的设计与功能

SPDY没有完全改写HTTP协议，而是在TCP/IP的应用层和运输层之间通过新加会话层的形式运作。同时，考虑到安全性问题，SPDY规定通信使用SSL。
SPDY以会话层的形式加入，控制对数据的流动，但还是采用HTTP建立通信连接。因此，可以照常使用HTTP的GET/POST等方法以及Cookie和HTTP报文等。


SPDY的设计

使用SPDY后，HTTP协议额外获得了一下功能。

2.2.3 SPDY消除Web瓶颈了吗？

希望使用SPDY时，Web的内容端不必做什么特别改动，而Web浏览器及Web服务器都要为对应SPDY做出一定程度上的改动。有好几家Web浏览器已经针对SPDY做出了相应的调整。另外，Web服务器也进行了实验性质的应用，但把该技术导入实际的Web网站却进展不佳。
因为SPDY基本上只是讲单个域名(IP地址)的通信多路复用，所以当一个Web网站上使用多个域名下的资源，改善效果就会受到限制。
SPDY的确是一种可有效消除HTTP瓶颈的技术，但很多Web网站存在的问题并非仅仅是由HTTP瓶颈所导致。对Web本身的速度提升，还应该从其他可细致钻研的地方入手，比如改善Web内容夫人编写方式等。

2.3 使用浏览器进行双工通信的WebSocket

一旦Web服务器与客户端之间建立起WebSocket协议的通信连接，之后所有的通信都依靠这个专用协议进行。通信过程中可互相发送JSON、XML、HTML或图片等任意格式的数据。
由于是建立在HTTP基础上的协议，因此连接的发起方仍然是客户端，而一旦确立WebSocket通信连接，不论服务器还是客户端，任意以放都可直接向对方发送报文。
一下是WebSocket协议的主要特点：

为了实现WebSocket通信，在HTTP连接建立之后，需要完成一次"握手"(Handshaking)的步骤。

GET /chat HTTP/1.1 
Host: server.example.com 
Upgrade: websocket 
Connection: Upgrade 
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 
Origin: http://example.com 
Sec-WebSocket-Protocol: chat, superchat 
Sec-WebSocket-Version: 13

Sec-WebSocket-Key字段内记录着握手过程中必不可少的键值。
Sec-WebSocket-Protocol字段内记录使用的子协议。
子协议按WebSocket协议标准在连接分开使用时，定义那些连接的名称。

HTTP/1.1 101 Switching Protocols 
Upgrade: websocket 
Connection: Upgrade 
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: cha

Sec-WebSocket-Accept的字段值是由握手请求中的Sec-WebSocket-Key的字段值生成的。
成功握手确立WebSocket连接之后，通信时不再使用HTTP的数据帧，而采用WebSocket独立的数据帧。

WebSocket通信 
var socket = new WebSocket('ws://game.example.com:12010/updates');
socket.onopen = function () {
   setInterval(function() {
      if (socket.bufferedAmount == 0)
          socket.send(getUpdateData());
      }, 50);
};

下一篇 读书笔记_图解HTTP(六)Web攻击技术

上一篇 下一篇

猜你喜欢

热点阅读