1

第 11 章WEB 的安全性

2

WEB 的安全性问题 • WEB 已经成为 Internet 上最重要的应用。

• WEB 的安全性问题的原因。

– HTTP 协议的安全性是非常脆弱的； – 服务实现上的复杂性系统的配置和管理趋于

复杂化 ，导致许多的安全隐患；– WEB 最终用户常常是未经训练或不了解系

统安全细节的用户。

3

WEB 安全威胁 （ 1 ）• 根据威胁的位置 ，可分为：

– 对 WEB 服务器的攻击；– 对 WEB 浏览器的攻击；– 对浏览器与服务器间通信流量的攻击。

4

WEB 安全威胁 （ 2 ）• 根据威胁的后果 ，可分为：

– 对信息完整性的攻击； – 对信息保密性的攻击； – 拒绝服务攻击； – 对身份认证攻击。

5

TCP/IP 协议栈中的安全机制

6

SSL

• Secure socket layer, 是 Netscape 提出的。 • TLS （ Transport Layer Security ） 1.0

（ RFC 2246 ） =SSLv3.l 。• 设计目标是在 TCP 基础上提供一种可靠

的端到端的安全服务，其服务对象一般是 WEB 应用。

• 传输层的安全协议。

7

SSL 的体系结构

8

SSL 记录协议层• SSL Record Protocol layer 。• 为高层协议提供基本的安全服务。• 记录层封装各种高层协议。 • 具体实施压缩解压缩、加密解密、计算

和校验 MAC 等与安全有关的操作。

9

SSL 握手协议层 • SSL HandShake Protocol layer 。• 用于 SSL 管理信息的交换，允许应用协议传送

数据之前相互验证，协商加密算法和生成密钥等。

• 包括：– SSL 握手协议（ SSL HandShake Protocol ）；– SSL 密码参数修改协议（ SSL Change Cipher Spec

Protocol ）；– 应用数据协议（ Application Data Protocol ）；– SSL 告警协议（ SSL Alert Protocol ）。

10

SSL 的两个重要概念• SSL 连接（ connection)

– 一个连接是一个提供一种合适类型服务的传输；– SSL 的连接是点对点的关系；– 连接是暂时的，每一个连接和一个会话关联。

• SSL 会话（ session ）– 一个 SSL 会话是在客户与服务器之间的一个关联；– 会话由 Handshake Protocol 创建。会话定义了一组

可供多个连接共享的加密安全参数；– 会话用以避免为每一个连接提供新的安全参数所需

昂贵的谈判代价。

11

SSL 的会话状态会话状态• 状态分为两种：

– 待用状态（ pending state），它包含了当前握手协议协商好的压缩、加密和MAC的算法，以及加解密的密钥等参数。

– 当前操作状态（ current operating state），它包含了当前SSL纪录层协议正在使用的压缩、加密和MAC的算法，以及加解密的密钥等参数。

• 参数：– 会话标识符 : 服务器选择的一个任意字节序列，用以标识一个活动的或可激活的会话状态。

– 对方的证书 : 一个 X.509.v3证书。可为空。– 压缩算法 : 加密前进行数据压缩的算法。– 加密规约 : 指明数据体加密的算法（无，或 DES等）以及散列算法（如MD5 或 SHA-1）用以计算MAC。还包括其他参数，如散列长度。

– 主密值 : 48位秘密，在 client 与 server之间共享。– 可重新开始的标志 :一个标志，指明该会话是否能用于产生一个新连接。

12

SSL 记录协议• SSL 记录协议为 SSL 连接提供两种服务

– 保密性。利用握手协议所定义的共享密钥对SSL 净荷（ payload ）加密 。

– 完整性。利用握手协议所定义的共享的MAC 密值来生成报文的鉴别码（ MAC ）。

13

SSL 工作过程和 SSL 记录格式

14

SSL 工作过程• 发送方的工作过程

– 从上层接收要发送的数据（包括各种消息和数据）；

– 对信息进行分段，成若干记录；

– 使用指定的压缩算法进行数据压缩数据（可选）；

– 使用指定的 MAC 算法生成 MAC ；

– 使用指定的加密算法进行数据加密；

– 发送数据。

• 接收方的工作过程– 接收数据；– 使用指定的解密算法解

密数据；– 使用指定的 MAC 算法校

验 MAC ；– 使用压缩算法对数据解

压缩（在需要时进行）；– 将记录进行数据重组；– 将数据发送给高层。

15

SSL 握手协议层 (1)

• 加密规约修改协议 – 仅定义了一个由单个字节“ 1” 构成的消息报

文； – 该消息将改变了连接所使用的加密规约。

• 告警协议 – 用于将 SSL 有关的告警传送给对方实体； – 分为警告性告警（ warning ）或致命性告警

（ fatal ）两个级别。

16

SSL 握手协议层 （ 2 ）• 握手协议（ SSL Handshake Protocol ）是

SSL 中最复杂的一个部分。 • 其功能是使服务器和客户能够相互鉴别

对方的身份，并且协商一系列安全参数。

• 这些安全参数包括用于加密和 MAC 算法，以及用于在 SSL 记录中保护发送数据的加密密钥。

17

SSL 握手协议的消息格式

18

握手协议定义的消息类型 (1)消息类型 说明 参数

hello_request 握手请求，服务器可在任何时候向客户端发送该消息。若客户端正在进行握手过程就可忽略该消息。否则客户端发送 cleint_hello消息，启动握手过程。

无

client_hello 客户启动握手请求，该消息时当客户第一次连接服务器时向服务器发送的第一条消息。该消息中包括了客户端支持的各种算法。若服务器端不能支持，则本次会话可能失败。

版本、随机数、会话ID、密文族、压缩方法

server_hello 其结构与 client_hello消息，该消息是服务器对客户端client_hello消息的恢复。

版本、随机数、会话ID、密文族、压缩方法

server_certificate

服务器提供的证书。如果客户要求对服务器进行认证，则服务器在发送 server_hello消息后，向客户端发送该消息。证书的类型一般是 X.509v3。

X ． 509v3证书链

server_key_exchange

服务器密钥交换。当服务器不使用证书，或其证书中仅提供签名而不提供密钥时，需要使用本消息来交换密钥。

参数、签名

19

握手协议定义的消息类型 (2)消息类型 说明 参数

certificate_request 用于服务器向客户端要求一个客户证书。 类型、授权

server_hello_done 该消息表明服务器端的握手请求报文已经发送完毕，正在等待客户端的响应。客户端在收到该消息时，将检查服务器提供的证书及其他参数是否是有效、可以接受的。

无

client_certificate 客户端对服务器 certificate_request消息的响应，只有在服务器端要求客户证书的时候使用。一般该消息是客户端收到 server_hello_done消息后所发送的第一条消息。若客户端没有合适的证书，则向服务器端发送 no_certificate的告警消息（无证书可能导致握手失败）

X ． 509v3证书链

client_key_exchange 客户密钥交换。当客户不使用证书，或其证书中仅提供签名而不提供密钥时，需要使用本消息来交换密钥。

参数、签名

certificate_verify 该消息用于向服务器提供对客户证书的验证。 签名finished 该消息在“加密规约修改”（ Change Cipher Spec）消息之

后发送，以证实握手过程已经成功完成。本消息发送后，发送方开始使用协商的新参数来执行操作。该消息需要在两个方向上传送。

散列值

20

握手协议过程（ 1 ） • 第一阶段 安全能力的建立

(1) 客户 → 服务器 ： client_hello 。(2) 服务器 → 客户 ： server_hello 。

• 第二阶段 服务器认证和密钥交换(3) 服务器 → 客户 ： server_certificate 。(4) 服务器 → 客户 ： server_key_exchange 。(5) 服务器 → 客户 ： certificate_request 。(6) 服务器 → 客户 ： server_hello_done 。

21

握手协议过程（ 2 ）• 第三阶段 客户认证和密钥交换

(7) 客户 → 服务器 ： client_certificate 。(8) 客户 → 服务器 ： client_key_exchange 。(9) 客户 → 服务器 ： certificate_verify 。

• 第四阶段 结束阶段(10) 客户 → 服务器 ： change_cipher_spec 。(11) 客户 → 服务器 ： finished 。(12) 服务器 → 客户 ： change_cipher_spec 。(13) 服务器 → 客户 ： finished 。

22

安全电子交易 (SET)

• Security Electronic Transaction 。• 主要是为了解决用户、商家和银行之间通

过信用卡支付的交易而设计的，以保证支付信息的机密和支付过程的完整。

• SET 中的核心技术包括公开密钥加密、数字签名、电子信封、电子安全证书等。

• 是一个安全协议的集合。

23

SET 的设计目标• 为支付 /订购信息提供机密性。 • 通信信息的完整性。 • 鉴证持卡者是否是信用卡账户的合法用户。 • 持卡用户需要确认能与之进行安全交易的商家的身

份。 • 采用最好的安全策略和系统设计技术来保护电子商

务交易中的所有合法方。 • 安全性应不依赖于传运输层安全机制，但又可以充

分利用传输层的安全服务。 • 协议应该独立于硬件平台、操作系统和 WEB软件。

24

SET 安全电子商务的构成

25

利用 SET 协议的典型交易事件序列

1. 申领信用卡。 2. 持卡用户获得证书。3. 商家获得证书。 4. 持卡用户订购商品。5. 用户对商家的身份认证。 6. 用户发送订购和支付信息。 7. 商家请求支付认可。 8. 商家确认订购。 9. 供货。 10.商家请求支付。

26

双向签名 • 持卡用户需要将订购信息（ OI ）和支付信息

（ PI ）一起发送给商家。• 但是实际上订购信息是发送给商家的，而支付

信息是需要发送给银行系统的。为了向持卡用户提供更好的隐私保护， SET 将 OI 和 PI 分离开来，由不同的机构处理。

• 简单地将 OI 和 PI 分离是不行的。这两个方面的信息也必须采用某种必要的方式连接起来，以解决可能出现的争端。

• 双向签名可以连接两个发送给不同接收者的消息报文 ，可以满足这种需求。

27

SET 的双向签名机制

28

SET 支持的交易类型（ 1 ） 卡用户注册 持卡用户在 CA中注册，以便能够与商家进行 SET报文的

交互

商家注册 商家在 CA中注册，以便能够支持与持卡用户和支付网关之间的 SET报文交互

购买请求 持卡用户向商家发送报文，其中包含提交给给商家的订购信息 OI和提交给的银行系统的支付信息 PI

支付认可 支付认可是商家和支付网关之间的交换，用来核准用户的信用卡账号足以支付购买

支付获取 商家向支付网关请求支付

证书调查和状态 持卡用户或商家向 CA发出证书请求后，如果 CA不能立刻处理，它将给持卡用户或商家发送回答，指示请求者以后再查看。持卡用户或商家通过发送“证书调查”报文来确定该证书请求的状态，并且在请求被批准时接收证书

29

SET 支持的交易类型（ 2 ）购买调查 持卡用户在收到了对购买请求的响应以后，可以使用“购买

调查”报文来检查订购处理的状态。

认可撤销 它允许商家更正以前的认可请求。如果订购将不被完成，商家撤销整个认可；若部分订购不被完成，商家可以部分撤销认可数量。

收款撤销 允许商人纠正收款请求中的差错，如错误地输入了的交易数量。

信用 商家可向持卡用户的账号发出一个信用，用于退货或者在运输过程中损坏。

信用撤销 商家对先前请求的信用进行更正。

支付网关证书请求 用于商家请求验证支付网关的，并且接收支付网关当前的密钥交换和签名证书。

批管理 允许商家与支付网关之间的批量信息通信。

差错信息 用于指示由于报文错误而导致的报文被拒绝。

30

购买请求的交互过程 • 发起请求消息

– 向商家请求商家的证书和支付网关的证书。 • 发起响应消息

– 包括商家的签名证书以及支付网关的密钥交换证书； – 持卡用户对商家提供的证书和支付网关证书进行验证，

验证通过证书中 CA签名来进行。 • 购买请求消息

– 与支付相关的信息； – 与订购有关的信息； – 持卡用户的证书。

• 购买响应消息– 包含相应的交易号码用于确认订购。

31

购买请求消息• 与支付相关的信息：与支付相关的信息将被商家转发给支付网关。 – 支付信息（ PI ）；– 双向签名（ DS ），是在 PI 和 OI 上计算的散列值，并使用用户的私

有签名密钥进行签名；– 订购信息（ OI ）的报文摘要 OIMD ，支付网关需要 OIMD 来验证双向签名；

– 数字信封，是用支付网关的公开密钥 KUb 对对称密钥 Ks 进行加密而形成的。

• 与订购有关的信息 ：是商家处理交易所必需的信息。 – 订购信息 OI ， OI 是明文发送的；– 双向签名（ DS ），是在 PI 和 OI 上计算的散列值，并使用用户的私

有签名密钥进行签名；– 支付信息 PI 报文摘要（ PIMD ），用于商家进行双向签名的验证。

• 持卡用户的证书。– 包含了持卡用户的签名公开密钥，商家和支付网关都需要使用该密钥

来进行签名的验证。

32

持卡用户生成“购买请求”的过程

33

商家对用户“购买请求”的验证

34

商家对用户“购买请求”的验证过程

• 通过持卡用户的 CA签名来验证持卡用户的证书。

• 使用持卡用户的签名公开密钥来验证双向签名，以验证订购信息的完整性，即在传输过程中没有被篡改。

• 处理订购信息，并将支付信息转交给支付网关进行支付认可。

• 向卡用户发送“购买响应”消息报文。

35

支付认可 • 商家在处理来自持卡用户的购买请求期间，需要请求支付网关来认可和确认该项交易。

• 商家向支付网关发送一个“认可请求”消息报文。 – 与支付相关的信息； – 与认可有关的信息； – 证书。

• 接收到“认可请求” 后，支付网关完成以下操作：– 验证所有的证书。– 对认可数据块的数字信封进行解密，获得一次性对称密钥，然后解

密认可数据块。– 验证认可数据块中商家的签名。– 对认支付数据块的数字信封进行解密，获得一次性对称密钥，然后

解密支付数据块。– 验证支付数据块中的双向签名。– 验证从商家提交的交易 ID 是否与用户 PI 中的交易 ID匹配。– 向发卡机构请求并接收一个认可。从发卡机构获得了认可之后，支付网关就可向商家返回“认可响应”报文。

36

支付货款• 商家同支付网关交互。• 商家发送收款请求消息。• 支付网关收到了收款请求报文时，解密并验证获取请求数据块和收款权标，并检查它们的一致性。

• 支付网关通过专用支付网络向发卡机构发送清算请求，其执行的结果是将货款划拨到商家的账户。

• 操作完成后，支付网关向商家发送收款响应报文。

37

WEB 服务的系统安全问题 • 包含服务器和浏览器两个方面。 • 安全性威胁可能包括：

– 存放于 WEB 服务器文件系统上的私人或保密的文件被非法用户窃取；

– 由远程用户发送给服务器的私人或保密信息被窃取。– 有关服务器主机的详细信息被泄漏，使攻击者有机

会分析系统漏洞，并入侵系统；– 服务器存在允许外来者在服务器主机上执行命令的漏洞，使其有机会改动或破坏系统。

38

CGI 的安全性• CGI 提供了一种访问服务器资源的接收和处理客

户浏览器发出信息的程序接口。 • CGI强调的是动态和双向的交互特性，要求服务

器端的 CGI 程序去理解客户端的各种请求。 • 安全问题：

– Internet 的开放性，对网络开放的服务； – CGI 提供了双向数据流动，在用户的交互过程中的

CGI漏洞，将可能原有资源非法篡改和破坏。• 相应的措施

– 严格的输入合法性检查机制； – 每一个运行的 CGI 程序设置一个最长运行时间。

39

WEB 中的可执行代码 • 当前大多数的 WEB页面都含有可执行的活动

组件，以更有好、更具交互性的界面。 • 主要是对客户端的威胁。

– 对一个系统而言，从网上任意下载并运行程序它十分危险的；

– 操作系统通常也没有都没有防备恶意程序的保护功能；

– 在 WEB页面中，可执行组件的下载和执行通常在后台进行，可以是用户是透明的，用户不容易干预；对于经过伪装的有害代码，用户更难以察觉。

40

浏览器的辅助应用程序和插件 • 辅助应用程序的作用：当下载链接的数据类型是浏览器自身

不能解释的类型时，浏览器将自动启动运行与之相关联的辅助应用程序。 – 通过这种方式，很多信息种类都可以通过浏览器下载和浏览。

• 一个插件是一个用于浏览某种特定媒体信息类型的软件模块。 – 插件作为浏览器的一个模块，在浏览器的进程空间内运行，下载的

数据保存在浏览器的缓存中处理，而不是采用文件方式。 • 安全问题：

– 恶意站点就可以向辅助程序或插件发送有害数据来攻击用户； – 例如，有一些功能很强的辅助程序，能够支持某种程序语言的解释执行。

41

JAVA 的安全技术• Java沙箱（ sandbox ）

– 沙箱是一个能够控制 Java applet运行的软件环境，其作用对 Java 程序的权限进行控制，防止程序执行一些危险操作，如对文件和设备的系统调用等。

• 安全管理器（ SecurityManager ）– 在 Java 的安全模式中有一种特殊的类，即安全管理器类。该类在潜

在的危险可能发生之前被调用，它可确定一个特定操作能否被安全执行。在可能的不良操作之前， SecurityManager 将依次对 Java 系统库中访问控制方法进行检查。

• 类装载程序– 在 Java环境中，大部分的安全检查也是使用 Java 来编程的，因此必须保证这些安全检查代码不会被恶意代码所破坏（例如，恶意代码可能首先使 SecurityManager 类失效）。为了防止这类攻击， Java 的类装载程序将检查每一个类，以确保它们正常运行。

• 代码检验器– 为了进一步保护 Java 的运行系统， Java采用了运行代码的扫描检

验器，它能保证下载的 Java 代码是由一个有效的。字节码检验器可以通过行一系列的特别检查来实施其功能。

42

JavaScript 脚本 • 由 Netscape 发布的一种简单的脚本，其目的是

为 WEB 上的表单和交互的设计更为直观和方便。

• 从理论上说， JavaScript比其他的代码更安全。 – JavaScript没有定义直接访问客户计算机文件系统的

方法，也没有定义连接到其他计算机的方法。 • 可能的安全性问题：

– 拒绝服务攻击；– 保密性问题 ，存在泄露了机密信息的潜在可能性。

43

ActiveX 控件 • 由 Microsoft 发布的 ，基于 Microsoft 的组建对象模型（ COM ）技术构建的一种技术。

• 一个 ActiveX控件是一个对现有技术对象进行重新封装后形成的一个可用于 Internet 的对象。

• ActiveX控件在需要的时候自动地被下载和安装，然后在不需要时自动被删除。

• 有两种类型： – 机器代码形式的 ActiveX控件 ，其安全性完全取决于

程序员的设计； – Java 代码形式的 ActiveX控件 ，其安全性同 Java 类似。

44

Cookie • Cookie 用来代表服务器和浏览器之间传递

的状态信息。 – 有些 WEB 服务能够收集有关用户的特定状态

信息，用来在以后的会话中使用。这些信息将保存在用户的浏览器中，当下一次用户连接到这个服务器时，浏览器就可以将合适的状态发送给服务器使用。

• 其安全性问题在于它可能泄露用户的信息。

45

HTTP 协议的用户认证 • 基本认证

– HTTP1.0版本中定义；– 基于口令。

• 摘要认证– HTTP 1.1版本中定义；– 不需要明文传送口令。

• 基于证书的认证 – 采用了 SSL/TLS 来用于浏览器与服务器之间

的安全通信。