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 来用于浏览器与服务器之间
的安全通信。