1 / 45

第11章 WEB 的安全性

第11章 WEB 的安全性. WEB 的安全性问题. WEB 已经成为 Internet 上最重要的应用。 WEB 的安全性问题的原因。 HTTP 协议的安全性是非常脆弱的； 服务实现上的复杂性系统的配置和管理趋于复杂化 ，导致许多的安全隐患； WEB 最终用户常常是未经训练或不了解系统安全细节的用户。. WEB 安全威胁 （ 1 ）. 根据威胁的位置 ，可分为： 对 WEB 服务器的攻击； 对 WEB 浏览器的攻击； 对浏览器与服务器间通信流量的攻击。. WEB 安全威胁 （ 2 ）. 根据威胁的后果 ，可分为： 对信息完整性的攻击；

aminia
Download Presentation

第11章 WEB 的安全性

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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)

  19. 握手协议定义的消息类型(2)

  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协议的典型交易事件序列 • 申领信用卡。 • 持卡用户获得证书。 • 商家获得证书。 • 持卡用户订购商品。 • 用户对商家的身份认证。 • 用户发送订购和支付信息。 • 商家请求支付认可。 • 商家确认订购。 • 供货。 • 商家请求支付。

  26. 双向签名 • 持卡用户需要将订购信息（OI）和支付信息（PI）一起发送给商家。 • 但是实际上订购信息是发送给商家的，而支付信息是需要发送给银行系统的。为了向持卡用户提供更好的隐私保护，SET将OI和PI分离开来，由不同的机构处理。 • 简单地将OI和PI分离是不行的。这两个方面的信息也必须采用某种必要的方式连接起来，以解决可能出现的争端。 • 双向签名可以连接两个发送给不同接收者的消息报文 ，可以满足这种需求。

  27. SET的双向签名机制

  28. SET支持的交易类型（1）

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

More Related