读书笔记——《图解HTTP》（四）

第八章 确认访问用户身份的认证

为何认证：

计算机本身无法判断坐在显示器前的使用者的身份、进一步说，也无法确认网络的那头究竟有谁。可见，为了弄清究竟是谁在访问服务器，就得让对方的客户端自报家门。可是，就算正在访问服务器的对方声称自己是ueno，身份是否属实这点却也无从谈起。为确认ueno本人是否真的具有访问系统的权限，就需要核对“登录者本人才知道的信息”、“登录者本人才会有的信息”。   

• 核对的信息通常是指以下这些。

  • 密码：只有本人才会知道的字符串信息。
  • 动态令牌：仅限本人持有的设备内显示的一次性密码。
  • 数字证书：仅限本人（终端）持有的信息。
  • 生物认证：指纹和虹膜等本人的生理信息。
  • IC卡等：仅限本人持有的信息。

• HTTP使用的认证方式
  HTTP/1.1使用的认证方式如下所示。

  • BASIC 认证（基本认证）
  • DIGEST认证（摘要认证）
  • SSL客户端认证
  • FormBase认证（基于表单认证）
    此外，还有Windows统一认证（Keberos认证、NTLM认证）。

BASIC认证：

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

认证步骤：

1. 步骤1：
   当请求的资源需要BASIC认证时，服务器会随状态码401 Authorization Required，返回带 WWW-Authenticate首部字段的响应。该字段内包含认证的方式（BASIC）及Request-URI 安全域字符串（realm）。

2. 步骤2：
   接收到状态码401的客户端为了通过BASIC认证，需要将用户ID及密码发送给服务器。发送的字符串内容是由用户ID和密码构成，两者中间以冒号(:)连接后，再经过Base64编码处理。把这串字符串写入首部字段Authorization后，发送请求。
   当用户代理为浏览器时，用户仅需输入用户ID和密码即可，之后，浏览器会自动完成到Base64编码的转换工作。

3. 步骤3：
   接收到包含首部字段Authorization 请求的服务器，会对认证信息的正确性进行验证。如验证通过，则返回一条包含Request-URI资源的响应。

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

DIGEST认证

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

认证步骤：

1. 步骤1：
   请求需认证的资源时，服务器会随着状态码401 Authorization Required，返回带WWW-Authenticate首部字段的响应。该字段内包含质问响应方式认证所需的临时质询码（随机数，nonce）。首部字段wWW-Authenticate内必须包含realm和nonce这两个字段的信息。客户端就是依靠向服务器回送这两个值进行认证的。
   nonce是一种每次随返回的401响应生成的任意随机字符串。该字符串通常推荐由Base64编码的十六进制数的组成形式，但实际内容依赖服务器的具体实现。

2. 步骤2：
   接收到401状态码的客户端，返回的响应中包含DIGEST认证必须的首部字段Authorization信息。首部字段Authorization内必须包含username、 realm、 nonce、 uri和response的字段信息。其中，realm和nonce就是之前从服务器接收到的响应中的字段。username是realm限定范围内可进行认证的用户名。uri （digest-uri） 即Request-URI的值，但考虑到经代理转发后Request-URI的值可能被修改，因此事先会复制一份副本保存在uri内。response也可叫做Request-Digest，存放经过MD5运算后的密码字符串，形成响应码。响应中其他的实体请参见第6章的请求首部字段Authorization。

3. 步骤3：
   接收到包含首部字段Authorization 请求的服务器，会确认认证信息的正确性。认证通过后则返回包含Request-URI资源的响应。并且这时会在首部字段Authentication-Info写入一些认证成功的相关信息。DIGEST认证提供了高于BASIC认证的安全等级，但是和HTTPS的客户端认证相比仍旧很弱。DIGEST认证提供防止密码被窃听的保护机制，但并不存在防止用户伪装的保护机制。DIGEST认证和BASIC认证一样，使用上不那么便捷灵活，且仍达不到多数Web网站对高度安全等级的追求标准。因此它的适用范围也有所受限。

SSL客户端认证

从使用用户ID和密码的认证方式方面来讲，只要二者的内容正确，即可认证是本人的行为。但如果用户ID和密码被盗，就很有可能被第三者冒充。利用SSL客户端认证则可以避免该情况的发生。       
SSL客户端认证是借由HTTPS的客户端证书完成认证的方式。凭借客户端证书认证，服务器可确认访问是否来自已登录的客户端。为达到SSL客户端认证的目的，需要事先将客户端证书分发给客户端，且客户端必须安装此证书。     

1. 步骤1：
   接收到需要认证资源的请求，服务器会发送Certificate Request报文，要求客户端提供客户端证书。
2. 步骤2：
   用户选择将发送的客户端证书后，客户端会把客户端证书信息以Client Certificate 报文方式发送给服务器。
3. 步骤3：
   服务器验证客户端证书验证通过后方可领取证书内客户端的公开密钥，然后开始HTTPS加密通信。

基于表单认证

基于表单的认证方法并不是在HTTP协议中定义的。客户端会向服务器上的Web应用程序发送登录信息（Credential），按登录信息的验证结果认证。根据Web应用程序的实际安装，提供的用户界面及认证方式也各不相同。     

• 认证多半为基于表单认证
  由于使用上的便利性及安全性问题，HTTP协议标准提供的BASIC认证和DIGEST认证几乎不怎么使用。另外，SL客户端认证虽然具有高度的安全等级，但因为导入及维持费用等问题，还尚未普及。

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

1. 步骤1：
   客户端把用户ID和密码等登录信息放入报文的实体部分，通常是以POST方法把请求发送给服务器。而这时，会使用HTTPS通信来进行HTML表单画面的显示和用户输入数据的发送。
2. 步骤2：
   服务器会发放用以识别用户的Session ID。通过验证从客户端发送过来的登录信息进行身份认证，然后把用户的认证状态与Session ID绑定后记录在服务器端。
   向客户端返回响应时，会在首部字段Set-Cookie内写入Session ID（如PHPSESSID=028a8c…）。你可以把Session ID想象成一种用以区分不同用户的等位号。然而，如果Session ID被第三方盗走，对方就可以伪装成你的身份进行恶意操作了。因此必须防止Session ID被盗，或被猜出。为了做到这点，Session ID应使用难以推测的字符串，且服务器端也需要进行有效期的管理，保证其安全性。
   另外，为减轻跨站脚本攻击（XSS）造成的损失，建议事先在Cookie内加上htponly属性。
3. 步骤3：
   客户端接收到从服务器端发来的SessionID后，会将其作为Cookie保存在本地。下次向服务器发送请求时，浏览器会自动发送Cookie，所以SessionID也随之发送到服务器。服务器端可通过验证接收到的Session ID识别用户和其认证状态。

第九章 基于HTTP的功能追加协议

消除HTTP瓶颈的SPDY

Google在2010年发布了SPDY（取自SPeeDY，发音同speedy），其开发目标旨在解决HTTP的性能瓶颈，缩短Web页面的加载时间（50%）。

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

  • 一条连接上只可发送一个请求。
  • 请求只能从客户端开始。客户端不可以接收除响应以外的指令。
  • 请求/响应首部未经压缩就发送。首部信息越多延迟越大。
  • 发送冗长的首部。每次互相发送相同的首部造成的浪费较多。
  • 可任意选择数据压缩格式。非强制压缩发送。

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

使用SPDY后，HTTP协议额外获得以下功能：

• 多路复用流
  通过单一的TCP连接，可以无限制处理多个HTTP请求。所有请求的处理都在一条TCP连接上完成，因此TCP的处理效率得到提高。

• 赋予请求优先级
  SPDY不仅可以无限制地并发处理请求，还可以给请求逐个分配优先级顺序。这样主要是为了在发送多个请求时，解决因带宽低而导致响应变慢的问题。

• 压缩HTTP首部
  压缩HTTP请求和响应的首部。这样一来，通信产生的数据包数量和发送的字节数就更少了。

• 推送功能
  支持服务器主动向客户端推送数据的功能。这样，服务器可直接发送数据，而不必等待客户端的请求。

• 服务器提示功能
  服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源之前就可以获知资源的存在，因此在资源已缓存等情况下，可以避免发送不必要的请求。

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

利用Ajax和Comet技术进行通信可以提升web的浏览速度。但问题在于通信若使用HTTP协议，就无法彻底解决瓶颈问题。WebSocket网络技术正是为解决这些问题而实现的一套新协议及API。

• *WebSocket的设计与功能
  WebSocket，即web浏览器与web服务器之间全双工通信标准。其中，WebSocket协议由IETF定为标准，WebSocketAPI由W3C定为标准。仍在开发中的技术主要是为了解决Ajax和Comet里XMLHttpRequest附带的缺陷所引起的问题。

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

下面我们列举一下WebSocket协议的主要特点。

• 推送功能
  支持由服务器向客户端推送数据的推送功能。这样，服务器可直接发送数据，而不必等待客户端的请求。

• 减少通信量
  只要建立起WebSocket连接，就希望一直保持连接状态。和HTTP相比，不但每次连接时的总开销减少，而且由于WebSocket的首部信息很小，通信量也相应减少了。

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

期盼已久的HTTP/2.0

目前主流的HTTP/1.1标准，自1999年发布的RFC2616之后再未进行过改订。SPDY和WebSocket等技术纷纷出现，很难断言HTTP/1.1仍是适用于当下的Web的协议。

负责互联网技术标准的IETF（Internet Engineering Task Force，互联网工程任务组）创立httpbis工作组，其目标是推进下一代HTTP——HTTP/2.0在2014年11月实现标准化。

• HTTP/2.0的特点
  HTTP/2.0的目标是改善用户在使用Web时的速度体验。由于基本上都会先通过HTTP/1.1与TCP连接，现在我们以下面的这些协议为基础，探讨一下它们的实现方法。

  • SPDY
  • HTTP Speed+Mobility
  • Network-Friendly HTTP Upgrade

http2.0技术讨论：

第十章 构建Web内容的技术

HTML

HTML（HyperText Markup Language，超文本标记语言）是为了发送Web上的超文本（Hypertext）而开发的标记语言。超文本是一种文档系统，可将文档中任意位置的信息与其他信息（文本或图片等）建立关联，即超链接文本。标记语言是指通过在文档的某部分穿插特别的字符串标签，用来修饰文档的语言。我们把出现在HTML文档内的这种特殊字符串叫做HTML标签（Tag）。

设计应用CSS

CSS（Cascading Style Sheets，层叠样式表）可以指定如何展现HTML内的各种元素，属于样式表标准之一。即使是相同的HTML文档，通过改变应用的CSS，用浏览器看到的页面外观也会随之改变。CSS的理念就是让文档的结构和设计分离，达到解耦的目的。

动态HTML

所谓动态HTML（Dynamic HTML），是指使用客户端脚本语言将静态的HTML内容变成动态的技术的总称。鼠标单击点开的新闻、Google Maps等可滚动的地图就用到了动态HTML。

动态HTML技术是通过调用客户端脚本语言JavaScript，实现对HTML的Web页面的动态改造。利用DOM（Document Object Model，文档对象模型）可指定欲发生动态变化的HTML元素。

Web应用

Web应用是指通过Web功能提供的应用程序。比如购物网站、网上银行、SNS、BBS、搜索引擎和e-learning等。互联网（Internet）或企业内网（Intranet）上遍布各式各样的Web应用。

原本应用HTTP协议的Web的机制就是对客户端发来的请求，返回事前准备好的内容。可随着Web越来越普及，仅靠这样的做法已不足以应对所有的需求，更需要引入由程序创建HTML内容的做法。类似这种由程序创建的内容称为动态内容，而事先准备好的内容称为静态内容。Web应用则作用于动态内容之上。

数据发布的格式及语言

XML（extensible Markup Language，可扩展标记语言）是一种可按应用目标进行扩展的通用标记语言。旨在通过使用XML，使互联网数据共享变得更容易。
XML和HTML都是从标准通用标记语言SGML（Standard Generalized Markup Language）简化而成。与HTML相比，它对数据的记录方式做了特殊处理。

第十一章 Web的攻击技术

针对Web的攻击技术

简单的HTTP协议本身并不存在安全性问题，因此协议本身几乎不会成为攻击的对象。应用HTTP协议的服务器和客户端，以及运行在服务器上的Web应用等资源才是攻击且标。目前，来自互联网的攻击大多是冲着Web站点来的，它们大多把Web应用作为攻击目标。

• *以服务器为目标的主动攻击
  主动攻击（active attack）是指攻击者通过直接访问Web应用，把攻击代码传入的攻击模式。由于该模式是直接针对服务器上的资源进行攻击，因此攻击者需要能够访问到那些资源。主动攻击模式里具有代表性的攻击是SQL注入攻击和OS命令注入攻击。

• 以服务器为目标的被动攻击
  被动攻击（passive attack）是指利用圈套策略执行攻击代码的攻击模式。在被动攻击过程中，攻击者不直接对目标Web应用访问发起攻击。
  被动攻击通常的攻击模式如下所示。

• 步骤1：攻击者诱使用户触发已设置好的陷阱，而陷阱会启动发送已嵌入攻击代码的HTTP请求。
• 步骤2：当用户不知不觉中招之后，用户的浏览器或邮件客户端就会触发这个陷阱。
• 步骤3：中招后的用户浏览器会把含有攻击代码的HTTP请求发送给作为攻击目标的Web应用，运行攻击代码。
• 步骤4：执行完攻击代码，存在安全漏洞的Web应用会成为攻击者的跳板，可能导致用户所持的Cookie等个人信息被窃取，登录状态中的用户权限遭恶意滥用等后果。

被动攻击模式中具有代表性的攻击是跨站脚本攻击和跨站点请求伪造。

因输出值转义不完全引发的安全漏洞

实施Web应用的安全对策可大致分为以下两部分。

• 客户端的验证
• Web应用端（服务器端）的验证
  • 输入值验证
  • 输出值转义