翻译:中国科学技术大学信息安全专业老师 第十一章万维网wwW安全 WwW(万维网)已经把分布式计算提升到了一个新的水平。移动( Mobile)代码 通过 Internet移动,而且在客户的机器上运行。电子商务带来了新的商业机会。在IT(信 息技术)领域安全突然变成了一个非常关注的问题。这样,你自己会再次发现过去习惯使 用的IT系统已经有了相当大的变化。这些问题是显而易见的 老的安全范例( paradigm)还适合吗?或者我们需要新的策略和新的安全机制吗? 对于在设计时并不支持安全的IT系统,我们应该怎样布置其安全基础? 这一章带你漫游由wwW安全引起的主要挑战。 目标 了解Web计算模型的某些方面已经导致了新的保护要求 ·理解存在各种各样的不同的保护问题。 给出目前用于解决这些问题的机制的综述 快速地考查围绕知识产权的保护方面的问题 11.1背景 WwW已经引起了大量的和压倒性地对安全不感知的(已使得大量的压根没有安全 意识的)用户群与新的计算范例直接接触。早期的分布式系统应用是基于客户服务器模型 的。客户想要在服务器上执行计算时,服务器便认证客户以保护它自己。在这种方式下提 供服务的数量不是太多,以至于存在一个适当机会,在服务中的安全缺陷最终被消除。 这种情况是怎样改变的呢?首先,WWW提供了创建和处理复杂的超文本文档的标 准,超文本包括文本、图形、声音等。编写超文本文档的原始标准是HIM( Hypertext Markup Language),与之对应的通信协议是HITP( Hypertext Transfer Protocol,RFC1945)。 超文本的特征对于新的一组允许用户检索任何信息(内容)的应用来说是非常有吸引力的 新闻内容、像时刻表或地图这样的旅游信息、会议通告、图片、音频、软件、技术文档和 其他许多信息都可以是内容。近年来,大量的商业服务公司已经进入了这个市场。WwW 不可避免地改变了分布式计算的本质。 程序和数据的分离再一次被取消。内容提供者可以在文档中嵌入可执行内容 ( applets,Java的小应用程序),来创建可以处理用户输入的交互的Web页面。 ·计算被移到了客户端。文档中包含了可执行代码,客户端运行在相当有功效的机 器上,所以服务器可以把一些计算任务转移到客户机上,而释放它自己的一些资源。所以 现在需要保护的是客户,以防止恶意的内容提供者威胁安全。 移动代码从一台机器传送到另外一台机器,从不同的地方收集信息,或者寻找空 闲的计算资源。客户需要保护以防止来自移动代码的威胁:移动代码也可能需要保护,以 防止来自移动代码正在其上运行的客户机的安全威胁 用户被迫地变成了系统管理员和策略制定人 Web也为软件的分发建立了一个新的范例( paradigm)。软件恰恰是另外一种可以从 Internet上下载的内容。可以说出很多赞同这种模型的理由。因为你已经通过网络连接到 你的软件提供者,你为什么还应该必须从软盘上获得软件呢?然而,在你思考从早期的 PC时代获得的经验时,你的积极性可能会受到抑制。从任意来源接受软盘变成了传播计 算机病毒传染的高速途经。许多组织在认识到这个问题的时候,都对软盘输入进行了严格 的管制。同样的警戒措施必须在WwW中采用 WWW没有引起从根本上来说是新的安全问题,但是它改变必须实施安全的上下文 第1页共9页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 1 页 共 9 页 创建日期：2003-11 第十一章 万维网 WWW 安全 WWW（万维网）已经把分布式计算提升到了一个新的水平。移动（Mobile）代码 通过 Internet 移动，而且在客户的机器上运行。电子商务带来了新的商业机会。在 IT（信 息技术）领域安全突然变成了一个非常关注的问题。这样，你自己会再次发现过去习惯使 用的 IT 系统已经有了相当大的变化。这些问题是显而易见的。 ·老的安全范例（paradigm）还适合吗？或者我们需要新的策略和新的安全机制吗？ ·对于在设计时并不支持安全的 IT 系统，我们应该怎样布置其安全基础？ 这一章带你漫游由 WWW 安全引起的主要挑战。 目标 ·了解 Web 计算模型的某些方面已经导致了新的保护要求。 ·理解存在各种各样的不同的保护问题。 ·给出目前用于解决这些问题的机制的综述。 ·快速地考查围绕知识产权的保护方面的问题。 11.1 背 景 WWW 已经引起了大量的和压倒性地对安全不感知的（已使得大量的压根没有安全 意识的）用户群与新的计算范例直接接触。早期的分布式系统应用是基于客户服务器模型 的。客户想要在服务器上执行计算时，服务器便认证客户以保护它自己。在这种方式下提 供服务的数量不是太多，以至于存在一个适当机会，在服务中的安全缺陷最终被消除。 这种情况是怎样改变的呢？首先，WWW 提供了创建和处理复杂的超文本文档的标 准，超文本包括文本、图形、声音等。编写超文本文档的原始标准是 HTML(Hypertext Markup Language)，与之对应的通信协议是 HTTP（Hypertext Transfer Protocol，RFC 1945）。 超文本的特征对于新的一组允许用户检索任何信息（内容）的应用来说是非常有吸引力的。 新闻内容、像时刻表或地图这样的旅游信息、会议通告、图片、音频、软件、技术文档和 其他许多信息都可以是内容。近年来，大量的商业服务公司已经进入了这个市场。WWW 不可避免地改变了分布式计算的本质。 ·程序和数据的分离再一次被取消。内容提供者可以在文档中嵌入可执行内容 （applets，Java 的小应用程序），来创建可以处理用户输入的交互的 Web 页面。 ·计算被移到了客户端。文档中包含了可执行代码，客户端运行在相当有功效的机 器上，所以服务器可以把一些计算任务转移到客户机上，而释放它自己的一些资源。所以 现在需要保护的是客户，以防止恶意的内容提供者威胁安全。 ·移动代码从一台机器传送到另外一台机器，从不同的地方收集信息，或者寻找空 闲的计算资源。客户需要保护以防止来自移动代码的威胁；移动代码也可能需要保护，以 防止来自移动代码正在其上运行的客户机的安全威胁。 ·用户被迫地变成了系统管理员和策略制定人。 Web 也为软件的分发建立了一个新的范例（paradigm）。软件恰恰是另外一种可以从 Internet 上下载的内容。可以说出很多赞同这种模型的理由。因为你已经通过网络连接到 你的软件提供者，你为什么还应该必须从软盘上获得软件呢？然而，在你思考从早期的 PC 时代获得的经验时，你的积极性可能会受到抑制。从任意来源接受软盘变成了传播计 算机病毒传染的高速途经。许多组织在认识到这个问题的时候，都对软盘输入进行了严格 的管制。同样的警戒措施必须在 WWW 中采用。 WWW 没有引起从根本上来说是新的安全问题，但是它改变必须实施安全的上下文
翻译:中国科学技术大学信息安全专业老师 环境到这样的程度,以至于万维网的安全值得用一章的篇幅来描述。WWW安全是一个快 速变化的主题,我们的处理办法既不主张是完全的,也不主张是最新的。所有我们瞄准的 是解释那些已经被提出来的安全机制,而且注意这些解决方法的内在的局限性。这本书的 主题是讨论计算机安全,我们将仅仅简要地提到对 Internet上传输数据的保护。 112Web浏览器 为了访问WWW(万维网)服务,客户端需要一个Web浏览器。Web浏览器仅仅是 一个程序,给用户提供图形化用户界面(GUI),包括连接到Web必须的协议。最常用的 浏览器是美国网景公司的 Navigator和微软的因特网浏览器IE。这些浏览器: 提供铃声和哨声,以呈现有吸引力的Web页面 ·是Web应用的服务层 ·包括与Web服务器通信的各种协议 为客户管理与安全相关的信息。 在我们的Web安全模型中,最主要的部分是客户、客户浏览器和Web服务器。在这 章,我们提到的Web服务器常常指提供服务的软件,而不是运行服务软件和维护Web页 面的机器。浏览器对于客户的安全是重要的,你应该能够区别当前产品特定的特征和对于 浏览器的概念是固有的一般特征。由于很多原因,使得浏览器变成了TCB(可信计算基) 的一个部分。 浏览器处理客户的web通信( traffic)。在客户和服务器之间平稳地传输数据 浏览器将关于用户和用户计算环境的很多信息报告给服务器。最低限度,浏览器必须说 明一个返回地址。这就产生了关于隐私( privacy)保护的问题,由于服务器是处在建 立和使用关于它的客户的数据库的位置,用于客户并不欣赏的目的 浏览器管理客户环境的缺省设置和优先选择。缺省设置包括可执行的位置。安 全优先选择指出了客户对它们的Web会话想要应用的保护 浏览器保存历史记录和最近访问的web页面的高速缓存。这样方便了用户。当 用户要返回前面已经浏览过的页面时,可以从本地高速缓存很快且很容易地获得先前浏 览过的页面。现在想象一个公共终端,例如,在一个机场的休息室,为旅客提供Web服 务。不同的旅客轮流使用这个终端。屏幕显示内容滚动回到先前的页面也就意味着返回 到其他旅客浏览过的页面。一个安全的Web浏览器必须处理好对象的重用( reuse)问 Web安全应用喜欢使用加密和数字签名算法。当浏览器为客户执行这些任务时 客户会把自己的私有密钥委托给浏览器。对输入通信( traffic)的数字签名和证书的 数字签名必须进行验证。所以,目前浏览器以主证书主要部分的根验证密钥出现。显而 易见,浏览器必须保护好验证密钥,使它不被修改,并且使签名和加密密钥不被泄漏。 为了对用户友好且呈现给他们简单的访问 Internet工具,浏览器集成了其他的 通信服务,例如电子邮件。从安全角度来说,这样构成了复杂程序的不必要的使用 个攻击者可能发送一个利用浏览器中的漏洞的E-mail消息。最初的mail程序对这种攻 击可以是有免疫力的。但是集成服务可能导致无法预料的相互作用,这在服务分离的情 况下是不会出现的。 浏览器常常运行在系统模式下,对所有的系统资源有完全访问权 综上所述,浏览器呈现了越来越多的功能,包括那些原来由操作系统执行的功能 到适当时候,浏览器变成了操作系统整体的一部分,比如 Microsoft的浏览器IE4。在这 个过程中,浏览器承担了与安全有关的任务,比如用户认证,或者控制对浏览器自身的访 问,或者控制对某些Web页面的访问 当浏览器变成商业产品的时候,问题变得复杂起来,而且它们的内在规范是不公开 的。即使专家有时也不得不承认这是一个失败,且承认某些细节是超出他们的影响范围之 外的。 第2页共9页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 2 页 共 9 页 创建日期：2003-11 环境到这样的程度，以至于万维网的安全值得用一章的篇幅来描述。WWW 安全是一个快 速变化的主题，我们的处理办法既不主张是完全的，也不主张是最新的。所有我们瞄准的 是解释那些已经被提出来的安全机制，而且注意这些解决方法的内在的局限性。这本书的 主题是讨论计算机安全，我们将仅仅简要地提到对 Internet 上传输数据的保护。 11.2 Web 浏览器 为了访问 WWW（万维网）服务，客户端需要一个 Web 浏览器。Web 浏览器仅仅是 一个程序，给用户提供图形化用户界面（GUI），包括连接到 Web 必须的协议。最常用的 浏览器是美国网景公司的 Navigator 和微软的因特网浏览器 IE。这些浏览器： ·提供铃声和哨声，以呈现有吸引力的 Web 页面； ·是 Web 应用的服务层； ·包括与 Web 服务器通信的各种协议； ·为客户管理与安全相关的信息。 在我们的 Web 安全模型中，最主要的部分是客户、客户浏览器和 Web 服务器。在这 一章，我们提到的 Web 服务器常常指提供服务的软件，而不是运行服务软件和维护 Web 页 面的机器。浏览器对于客户的安全是重要的，你应该能够区别当前产品特定的特征和对于 浏览器的概念是固有的一般特征。由于很多原因，使得浏览器变成了 TCB（可信计算基） 的一个部分。 ·浏览器处理客户的 Web 通信（traffic）。在客户和服务器之间平稳地传输数据， 浏览器将关于用户和用户计算环境的很多信息报告给服务器。最低限度,浏览器必须说 明一个返回地址。这就产生了关于隐私（privacy）保护的问题，由于服务器是处在建 立和使用关于它的客户的数据库的位置，用于客户并不欣赏的目的。 ·浏览器管理客户环境的缺省设置和优先选择。缺省设置包括可执行的位置。安 全优先选择指出了客户对它们的 Web 会话想要应用的保护。 ·浏览器保存历史记录和最近访问的 web 页面的高速缓存。这样方便了用户。当 用户要返回前面已经浏览过的页面时，可以从本地高速缓存很快且很容易地获得先前浏 览过的页面。现在想象一个公共终端，例如，在一个机场的休息室，为旅客提供 Web 服 务。不同的旅客轮流使用这个终端。屏幕显示内容滚动回到先前的页面也就意味着返回 到其他旅客浏览过的页面。一个安全的 Web 浏览器必须处理好对象的重用（reuse）问 题！ ·Web 安全应用喜欢使用加密和数字签名算法。当浏览器为客户执行这些任务时， 客户会把自己的私有密钥委托给浏览器。对输入通信（traffic）的数字签名和证书的 数字签名必须进行验证。所以，目前浏览器以主证书主要部分的根验证密钥出现。显而 易见，浏览器必须保护好验证密钥，使它不被修改，并且使签名和加密密钥不被泄漏。 ·为了对用户友好且呈现给他们简单的访问 Internet 工具，浏览器集成了其他的 通信服务，例如电子邮件。从安全角度来说，这样构成了复杂程序的不必要的使用。一 个攻击者可能发送一个利用浏览器中的漏洞的 E-mail 消息。最初的 mail 程序对这种攻 击可以是有免疫力的。但是集成服务可能导致无法预料的相互作用，这在服务分离的情 况下是不会出现的。 ·浏览器常常运行在系统模式下，对所有的系统资源有完全访问权。 ·综上所述，浏览器呈现了越来越多的功能，包括那些原来由操作系统执行的功能。 到适当时候，浏览器变成了操作系统整体的一部分，比如 Microsoft 的浏览器 IE4。在这 个过程中，浏览器承担了与安全有关的任务，比如用户认证，或者控制对浏览器自身的访 问，或者控制对某些 Web 页面的访问。 当浏览器变成商业产品的时候，问题变得复杂起来，而且它们的内在规范是不公开 的。即使专家有时也不得不承认这是一个失败，且承认某些细节是超出他们的影响范围之 外的[128]
翻译:中国科学技术大学信息安全专业老师 113cGl脚本 在传统的客户服务器模型中,许多的客户只允许访问少数的服务,比如FTP,而且 几乎没有客户可以通过RPC( remote procedure call,远程过程调用)进行大范围的访问 CGl( Common Gateway Interface,公共网关接口)脚本授予许多客户更灵活的访问服务 安全问题的实质并没有改变。服务器对它的客户提供控制调用。然而,问题的规模是不同 的。现在,要求服务器运行越来越多的程序,这些程序能完成更多的任务,且是由更多的 程序设计者编写的。在它里面的每一项对安全来说应该是受关注的 CGI是一种元语言(中间件, middleware),用来传送URLs( Uniform Resource locator, 统一资源定位器〕或者HIML表单(form)到可执行程序。这些程序可以用任何语言编 写,只要它们满足CGI要求的几个标准。像Perl、Tl或者Safe-Tl这样的脚本语言特别 适合于这种目的。在更通用意义上来说,CGI代表了给客户更多选择的全部的概念,这些 选择影响着他们要求服务器执行的计算 CGI工作如图11.1所示。客户发送一个URL或者一个HIML表单的内容到服务器 指定了CGI脚本和它的输入参数。这个请求被传送到一个程序,而该程序以Web服务器 程序的用户身份执行。web服务可以调用像服务器端嵌入( Server-Side includes,SSls)这 样的应用程序。用服务器端嵌入,在服务器上的文档可以包括系统命令,称为内嵌的SSI 当客户请求这样的文档时,文档中的这些系统命令就被计算,且结果插入在返回给客户的 文档中 图11.1运行CGI脚本的服务器 根据文献([128改编的例子举例说明了CGI脚本怎样可能成为破坏的原因。给客户发 送文件的脚本程序可以像: cat thefile mail clientaddress 其中, thefile是文件的名字, clientaddress是客户的邮件地址。当一个恶意的用户输入: ser @address rm-rf/ 作为邮件地址时,服务器将执行如下命令: cat thefile mail user(@address |rm-rf/ 而且在把文件邮寄给用户以后,删除这个脚本文件允许删除的所有文件 所以为了管理Web服务器主机的安全,必须执行很多任务。在下面的描述中,我们 假设主机是Unⅸ系统。首先,系统管理员必须明了在主机上的所有CGI脚本。存在两种 选择: 混淆脚本CGl(Scip- aliased CGI):所有的CGl脚本都存放在一个目录下,例 如,/cgi-bin,或者在Web服务器的根目录,例如,ar/httd 非混淆脚本CGI(Non- script-aliased CGI):所有的CGI脚本都由它们的扩展名来 标识,例如 第一种选择较安全,因为这样比较容易找到所有的脚本程序。下一步,你必须为Web 服务器程序决定UD(用户标识符)。你必须对最坏的情况有所准备,并且假设有些奇怪 的CGI程序可能会失去控制。以root权限运行web服务器程序可能引起灾难性的后果 所以你最好的选择是创建一个特殊的Web服务器UD,并且小心地控制它的访问权限 注意,这种解决方案不提供在属于不同用户的Web页面之间区别。所有的CG脚本都在 同一个UID下运行。为了使脚本在它的作者允许权限范围内运行,你需要像 CGl Wrap这 样的包装( wrapper)软件 为了保护Web服务器的完整性,web服务器UID将不应该拥有web服务器的bin 文件和配置文件。为了同样的理由,Web服务器UID不应该与其他的服务一起共享。Web 务器特别不应该在特殊用户 Nobody(UD是-2)下运行。你应该认为在这个UID下已 经运行的其他服务。 CGI脚本的代码检查可以清除具有安全漏洞的脚本。如果你有这样做的时间和专门技 术,这当然是一个很好的想法。如果你正在为顾客管理一个Web站点,而用户只想尽快 第3页共9页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 3 页 共 9 页 创建日期：2003-11 11.3 CGI 脚本 在传统的客户服务器模型中，许多的客户只允许访问少数的服务，比如 FTP，而且 几乎没有客户可以通过 RPC（remote procedure call, 远程过程调用）进行大范围的访问。 CGI（Common Gateway Interface , 公共网关接口）脚本授予许多客户更灵活的访问服务。 安全问题的实质并没有改变。服务器对它的客户提供控制调用。然而，问题的规模是不同 的。现在，要求服务器运行越来越多的程序，这些程序能完成更多的任务，且是由更多的 程序设计者编写的。在它里面的每一项对安全来说应该是受关注的。 CGI 是一种元语言（中间件，middleware），用来传送 URLs（Uniform Resource Locator， 统一资源定位器）或者 HTML 表单（form）到可执行程序。这些程序可以用任何语言编 写，只要它们满足 CGI 要求的几个标准。像 Perl、Tcl 或者 Safe-Tcl 这样的脚本语言特别 适合于这种目的。在更通用意义上来说，CGI 代表了给客户更多选择的全部的概念，这些 选择影响着他们要求服务器执行的计算。 CGI 工作如图 11.1 所示。客户发送一个 URL 或者一个 HTML 表单的内容到服务器， 指定了 CGI 脚本和它的输入参数。这个请求被传送到一个程序，而该程序以 Web 服务器 程序的用户身份执行。Web 服务可以调用像服务器端嵌入（Server-Side Includes, SSIs）这 样的应用程序。用服务器端嵌入，在服务器上的文档可以包括系统命令，称为内嵌的 SSI。 当客户请求这样的文档时，文档中的这些系统命令就被计算，且结果插入在返回给客户的 文档中。 图 11.1 运行 CGI 脚本的服务器 根据文献[128]改编的例子举例说明了 CGI 脚本怎样可能成为破坏的原因。给客户发 送文件的脚本程序可以像： cat thefile | mail clientaddress 其中，thefile 是文件的名字，clientaddress 是客户的邮件地址。当一个恶意的用户输入： user@address | rm –rf / 作为邮件地址时，服务器将执行如下命令： cat thefile | mail user@address | rm –rf / 而且在把文件邮寄给用户以后，删除这个脚本文件允许删除的所有文件。 所以为了管理 Web 服务器主机的安全，必须执行很多任务。在下面的描述中，我们 假设主机是 Unix 系统。首先，系统管理员必须明了在主机上的所有 CGI 脚本。存在两种 选择： ·混淆脚本 CGI （Scrip-aliased CGI）：所有的 CGI 脚本都存放在一个目录下，例 如，./cgi-bin，或者在 Web 服务器的根目录，例如，/var/httpd。 ·非混淆脚本 CGI （Non-script-aliased CGI）：所有的 CGI 脚本都由它们的扩展名来 标识，例如，.cgi。 第一种选择较安全，因为这样比较容易找到所有的脚本程序。下一步，你必须为 Web 服务器程序决定 UID（用户标识符）。你必须对最坏的情况有所准备，并且假设有些奇怪 的 CGI 程序可能会失去控制。以 root 权限运行 web 服务器程序可能引起灾难性的后果。 所以你最好的选择是创建一个特殊的 Web 服务器 UID，并且小心地控制它的访问权限。 注意，这种解决方案不提供在属于不同用户的 Web 页面之间区别。所有的 CGI 脚本都在 同一个 UID 下运行。为了使脚本在它的作者允许权限范围内运行，你需要像 CGIWrap 这 样的包装（wrapper）软件。 为了保护 Web 服务器的完整性，Web 服务器 UID 将不应该拥有 Web 服务器的 bin 文件和配置文件。为了同样的理由，Web 服务器 UID 不应该与其他的服务一起共享。Web 服务器特别不应该在特殊用户 Nobody（UID 是-2）下运行。你应该认为在这个 UID 下已 经运行的其他服务。 CGI 脚本的代码检查可以清除具有安全漏洞的脚本。如果你有这样做的时间和专门技 术，这当然是一个很好的想法。如果你正在为顾客管理一个 Web 站点，而用户只想尽快
翻译:中国科学技术大学信息安全专业老师 地看到在服务器上的他们新的Web页面,这种选择对你来说可能是不可利用的。 最后,像在任何其他的控制调用情况一样,给CGI脚本的输入应该经过过滤。调用 操作功能越是强大,你越是要小心地对待它接收的输入。服务器端包含(SSI, server side ncludes)的功能可以是非常强大的。内联( in-line)SSI的格式是: 最终的灵活性是通过带有参数cmd的操作符exec提供的。内联SSI是: 传送字符串" myprogram myparameters"到/bin/sh目录下执行。恶意代码可能来自于程序, 或者来自于一个给完全无知的程序传递的参数,如果 myparameters包含 shell(命令解释 程序)转义字符的话。“非转义操作”( unescap operation)通过注释掉转义字符除去了在 来自客户的输入中的 shell转义字符。命令 escape"stringl; string2 返回" stingl; string2\" 像Perl这样的脚本语言也支持非转义。非转义阻止了在服务器端包含中的最显著的漏 洞(hole)。留给攻击者的仍然是所有的Unⅸx命令,玩弄他们所有的输入。如果你不准备 接受这种风险,那么你可以在服务器选项中通过详细说明禁止exec命令: Options IncludesNOEXEC 11.4 Cookies 在任何形式的商业活动中,都存在对各个客户的偏爱进行适应的服务( tailoring services),web服务也不例外。在这种情况下,web服务器需要存储关于顾客信息的区域。 这些信息可以保存在服务器,但是存储需求和搜索时间将不利于形成很大的用户群。而且 HTP请求并不自动识别每个用户的身份。因此,在协同工作的浏览器的帮助下使用用户 的站点是比较容易的。服务器要求浏览器存储一个 cookie(网上信息块,一种网络服务器 传递给浏览器的信息), cookie包含了客户下次调用时服务器将查阅的信息,如图11.2所 示。在Unⅸx系统中一个典型的存储该信息的特定区域可能是一个文件,像在用户主目录 下的 netscape/cookie文件 图112存储在客户端的 cookies 使用cookies也有一个技术原因。HTTP协议是无状态的。所有的HTTP请求都被当 成独立的事件进行处理,即使当它们来自同一个客户时。所有关联的管理任务都是不断地 重复。例如,如果访问一个Web页面需要口令,每一次当你点击这个页面时,口令必须 传送给服务器。这个问题已经由HTIP10在一个会话期持续时间内解决了。浏览器会存 储在第一次请求时输入的口令,然后会在所有进一步的对服务器的回答中自动包含口令 Cookies推广了这个概念,使得浏览器可以创建有状态的HTP会话,减少了他们管理的 开销,也减少了用户的开销。现在,状态信息甚至可以在会话持续时间外还能保存。 Cookies在把工作负荷从服务器转移到客户方面走出了试验性的一步。它们存在安全 问题吗? Cookies不会破坏你的系统的完整性,它们是数据,不是可执行代码。 Cookies 不直接把信息泄露给服务器。毕竟,服务器要求浏览器存储 cookie。所以单独的 cookies 也不会产生机密性问题。 这里仍然存在隐私问题。没有必要因单个的 cookies而兴奋不已:无论如何各自的服 务器获得了这些信息。然而,整个由浏览器存储的 cookies集合形成了客户概要( profile) 浏览器的访问控制功能因此变得至关重要。通常, cookies属于一个特定的域,服务器仅 仅能访问属于它们域的 cookies。目前,大多数的浏览器能够被设置成请求允许存储 cookies 的模式:但是,这很容易变成一个麻烦事。有的浏览器并不存储 cookies,在一个会话结 束时总是有删除 cookies的选择项 第4页共9页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 4 页 共 9 页 创建日期：2003-11 地看到在服务器上的他们新的 Web 页面，这种选择对你来说可能是不可利用的。 最后，像在任何其他的控制调用情况一样，给 CGI 脚本的输入应该经过过滤。调用 操作功能越是强大，你越是要小心地对待它接收的输入。服务器端包含（SSI，server side includes）的功能可以是非常强大的。内联（in-line ）SSI 的格式是： 最终的灵活性是通过带有参数 cmd 的操作符 exec 提供的。内联 SSI 是： 传送字符串myprogram myparameters到/bin/sh 目录下执行。恶意代码可能来自于程序， 或者来自于一个给完全无知的程序传递的参数，如果 myparameters 包含 shell（命令解释 程序）转义字符的话。“非转义操作”（unescape operation）通过注释掉转义字符除去了在 来自客户的输入中的 shell 转义字符。命令 unescape string1; string2 返回sting1\;string2\。 像 Perl 这样的脚本语言也支持非转义。非转义阻止了在服务器端包含中的最显著的漏 洞（hole）。留给攻击者的仍然是所有的 Unix 命令，玩弄他们所有的输入。如果你不准备 接受这种风险，那么你可以在服务器选项中通过详细说明禁止 exec 命令： Options IncludesNOEXEC 11.4 Cookies 在任何形式的商业活动中，都存在对各个客户的偏爱进行适应的服务（tailoring services），Web 服务也不例外。在这种情况下，Web 服务器需要存储关于顾客信息的区域。 这些信息可以保存在服务器，但是存储需求和搜索时间将不利于形成很大的用户群。而且， HTTP 请求并不自动识别每个用户的身份。因此，在协同工作的浏览器的帮助下使用用户 的站点是比较容易的。服务器要求浏览器存储一个 cookie（网上信息块，一种网络服务器 传递给浏览器的信息），cookie 包含了客户下次调用时服务器将查阅的信息，如图 11.2 所 示。在 Unix 系统中一个典型的存储该信息的特定区域可能是一个文件，像在用户主目录 下的.netscape/cookie 文件。 图 11.2 存储在客户端的 cookies 使用 cookies 也有一个技术原因。HTTP 协议是无状态的。所有的 HTTP 请求都被当 成独立的事件进行处理，即使当它们来自同一个客户时。所有关联的管理任务都是不断地 重复。例如，如果访问一个 Web 页面需要口令，每一次当你点击这个页面时，口令必须 传送给服务器。这个问题已经由 HTTP1.0 在一个会话期持续时间内解决了。浏览器会存 储在第一次请求时输入的口令，然后会在所有进一步的对服务器的回答中自动包含口令。 Cookies 推广了这个概念，使得浏览器可以创建有状态的 HTTP 会话，减少了他们管理的 开销，也减少了用户的开销。现在，状态信息甚至可以在会话持续时间外还能保存。 Cookies 在把工作负荷从服务器转移到客户方面走出了试验性的一步。它们存在安全 问题吗？Cookies 不会破坏你的系统的完整性，它们是数据，不是可执行代码。Cookies 不直接把信息泄露给服务器。毕竟，服务器要求浏览器存储 cookie。所以单独的 cookies 也不会产生机密性问题。 这里仍然存在隐私问题。没有必要因单个的 cookies 而兴奋不已；无论如何各自的服 务器获得了这些信息。然而，整个由浏览器存储的 cookies 集合形成了客户概要（profile）。 浏览器的访问控制功能因此变得至关重要。通常，cookies 属于一个特定的域，服务器仅 仅能访问属于它们域的 cookies。目前，大多数的浏览器能够被设置成请求允许存储 cookies 的模式；但是，这很容易变成一个麻烦事。有的浏览器并不存储 cookies，在一个会话结 束时总是有删除 cookies 的选择项
翻译:中国科学技术大学信息安全专业老师 115认证码 软件是由它的作者签名的,当软件从服务器上下载下来后,客户验证对软件的数字签 名,如图113所示。这样,客户可以验证代码的来源,或者更一般地说,可以验证内容 的来源。在以前的时代,有一个称为正式版软件( shrink-wrapped software)相似的概念 认证码( certified code)解决了比计算机安全问题更多的通信安全问题。软件编写者在 Internet上提供他们的产品,可以受到保护以避免其他参与者假冒的欺骗。在客户知道了 他们想要下载的代码的来源的情况下,也为客户提供了一些保护。 在这种方案中,在客户想要与服务器打交道时,客户需要服务器的验证密钥。客户可 以通过除 Internet之外的其他信道获得验证码,但是对验证密钥使用证书( certificates)是 更符合游戏的精神。证书又必须由其他的某个人(或者团体)签名,且客户需要验证密钥 来检验证书。有一些公司会对它们的顾客提供证书服务。在这种方案中,任何被验证的密 钥都可以通过一个证书链来验证;其中,链中的最后一个元素将借助该方案中根签名密钥 来签名。为了认证码的自展验证( bootstrap verification),必须给客户提供适当的根验证密 钥。如今的浏览器都配备了这些密钥 图11.3客户端运行签名的 applets 这里留下了一个小小的问题。如果从 Internet上下载的内容在你没有对它的签名验证 前,你对它是不信任的,而且如果你从 Internet上下载浏览器,你将怎样开始验证呢?从 安全方面考虑,你必须通过web以外的方式证实根验证密钥的真实性。关于Web安全的 书可能是根验证密钥的好的和通用的来源 认证码保证了你能够知道你所获得内容的来源。认证码对代码的行为并不提供任何 保证。不要忘记,即使是声誉很好的软件供应商也偶尔会发售携带计算机病毒的简易包装 的软件。认证码在你访问一个没有通过你所预订的方案进行认证的Web站点时也会失去 作用 客户保存一个他们信任来源的经过认证的密钥表。这张表是一个显而易见的攻击点 如果一个恶意的Web服务器设法把它自己的认证密钥加入到这张表中,则来自这个服务 器的任何代码都将被视为可信任代码 认证码的一个重要例子就是对于 ActiveX控件的 Microsoft的认证码( authenticode) ActiveX控件是嵌入在Web页面中的软件组件。一旦一个 ActiveX控件已经通过验证,且 允许其运行,则它执行的动作都不会受到任何进一步的约束。为了从 Microsoft发布软件 和从 Microsoft认可的软件供应商发布软件,这是Web安全机制的一个合理的选择。有了 这样的实现方案,从一个Web站点下载的代码变成了与从一个可信任的有名的软件店购 买的软件是完全等效的。如果你想要运行一个来自不熟悉来源的执行内容,认证码是没有 任何帮助的 1.6沙盒 为了充分享受Web技术带来的魅力,用户必须准备接受来自任何引起他们注意的 web站点的可执行内容( applets,小应用程序)。为了做好准备,他们必须能够控制 applets 的行为。这必须在一个非常苛刻的环境下才能实现: 用户对 applet的来源不能依赖于预先熟悉和可信任关系 ·几乎没有用户愿意亲自控制由 applet引起的每一个访问请求 不能期望客户的操作系统会提供任何的保护。 这就是Java语言的设计者们发现他们自己所处的情况。想创建一种语言来编写平台 无关的 applet(小应用程序),他们必须创建一个沙盒( sandbox,即运行程序安全区), 如图11.4所示,且阻止 applets离开这个沙盒。安全考虑也进入了几个相关的设计决策 第5页共9页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 5 页 共 9 页 创建日期：2003-11 11.5 认证码 软件是由它的作者签名的，当软件从服务器上下载下来后，客户验证对软件的数字签 名，如图 11.3 所示。这样，客户可以验证代码的来源，或者更一般地说，可以验证内容 的来源。在以前的时代，有一个称为正式版软件（shrink-wrapped software）相似的概念。 认证码（certified code）解决了比计算机安全问题更多的通信安全问题。软件编写者在 Internet 上提供他们的产品，可以受到保护以避免其他参与者假冒的欺骗。在客户知道了 他们想要下载的代码的来源的情况下，也为客户提供了一些保护。 在这种方案中，在客户想要与服务器打交道时，客户需要服务器的验证密钥。客户可 以通过除 Internet 之外的其他信道获得验证码，但是对验证密钥使用证书（certificates）是 更符合游戏的精神。证书又必须由其他的某个人（或者团体）签名，且客户需要验证密钥 来检验证书。有一些公司会对它们的顾客提供证书服务。在这种方案中，任何被验证的密 钥都可以通过一个证书链来验证；其中，链中的最后一个元素将借助该方案中根签名密钥 来签名。为了认证码的自展验证（bootstrap verification），必须给客户提供适当的根验证密 钥。如今的浏览器都配备了这些密钥。 图 11.3 客户端运行签名的 applets 这里留下了一个小小的问题。如果从 Internet 上下载的内容在你没有对它的签名验证 前，你对它是不信任的，而且如果你从 Internet 上下载浏览器，你将怎样开始验证呢？从 安全方面考虑，你必须通过 Web 以外的方式证实根验证密钥的真实性。关于 Web 安全的 书可能是根验证密钥的好的和通用的来源。 认证码保证了你能够知道你所获得内容的来源。认证码对代码的行为并不提供任何 保证。不要忘记，即使是声誉很好的软件供应商也偶尔会发售携带计算机病毒的简易包装 的软件。认证码在你访问一个没有通过你所预订的方案进行认证的 Web 站点时也会失去 作用。 客户保存一个他们信任来源的经过认证的密钥表。这张表是一个显而易见的攻击点。 如果一个恶意的 Web 服务器设法把它自己的认证密钥加入到这张表中，则来自这个服务 器的任何代码都将被视为可信任代码。 认证码的一个重要例子就是对于 ActiveX 控件的 Microsoft 的认证码（authenticode）。 ActiveX 控件是嵌入在 Web 页面中的软件组件。一旦一个 ActiveX 控件已经通过验证，且 允许其运行，则它执行的动作都不会受到任何进一步的约束。为了从 Microsoft 发布软件 和从 Microsoft 认可的软件供应商发布软件，这是 Web 安全机制的一个合理的选择。有了 这样的实现方案，从一个 Web 站点下载的代码变成了与从一个可信任的有名的软件店购 买的软件是完全等效的。如果你想要运行一个来自不熟悉来源的执行内容，认证码是没有 任何帮助的。 11.6 沙盒 为了充分享受 Web 技术带来的魅力，用户必须准备接受来自任何引起他们注意的 Web 站点的可执行内容（applets，小应用程序）。为了做好准备，他们必须能够控制 applets 的行为。这必须在一个非常苛刻的环境下才能实现： ·用户对 applet 的来源不能依赖于预先熟悉和可信任关系。 ·几乎没有用户愿意亲自控制由 applet 引起的每一个访问请求。 ·不能期望客户的操作系统会提供任何的保护。 这就是 Java 语言的设计者们发现他们自己所处的情况。想创建一种语言来编写平台 无关的 applet（小应用程序），他们必须创建一个沙盒（sandbox，即运行程序安全区）， 如图 11.4 所示，且阻止 applets 离开这个沙盒。安全考虑也进入了几个相关的设计决策：
翻译:中国科学技术大学信息安全专业老师 ·语言自身应该使程序更难产生破坏 ·执行环境提供了访问控制的机制。 ·必须正确地设置由执行环境实施的安全策略 图11.4Java沙盒 Java是强类型的面向对象的语言。从安全的观点来看,这与取消针有很大关系。在C 或C+语言中,通过指针的存储器访问是引起故障和安全漏洞的主要原因之一。Java加强 了类型安全。Java对象的类型是通过和对象存储在一起的类标签( class tag)指示的 静态类型检査检验在执行期间获得的操作数的参数是否总是有正确的类型。静态类型检査 比在运行时间的动态类型检查更复杂,但是它可以更快地执行,因为困难的工作在运行前 就已经完成了 Java源代码被翻译成独立于机器的字节码( byte code),且作为类文件存储。Java 字节码类似于汇编语言。特定平台的虚拟机解释字节码,并且把它翻译成特定机器的指令 当运行一个程序时,类加载程序( loader)装入要求的任何附加类。内置的类形成了由运 行时间环境提供的操作系统的更多部分 Java是通用程序设计语言,它具有很多特征,可以说服你使用Java而不是C++来编 写你的应用程序。在这里,我们不必关心运行Java应用程序的安全方面的问题。我们想 要在安全的方式下运行 Java applets,即用Java编写的、来自远程服务器的可执行内容。 在这里的上下文中,安全可能意味着 Applets不能访问用户的文件系统 Applets不能获得关于用户名、e-mail地址以及机器配置等的信息。 Applets可以做向外的连接,但只能是回到它们来自的服务器。 Applets仅仅能够弹出标志为不可信任的窗口 Applets不能重新配置系统,例如,不能创建一个新的类加载程序,或者一个新 的安全管理器(如下面所述的)。 允许运行Java的浏览器带有它们自己的Java虚拟机。Java虚拟机有三个安全组件, 即字节码验证器、类加载程序和安全管理器。目前,浏览器都执行类似的策略,但这是出 于选择,不是必须的 116.1字节码检验程序 字节码检验程序( verifier)分析Java类文件,执行语法检査,使用定理证明程序和 数据流分析进行静态类型检查。检验保证了下面这些特性: 类文件采用了正确的格式 堆栈不会溢出 ·所有的操作数都具有正确类型的参数( argument) ·在类型之间没有数据转换; 对其他类的所有的引用都是合法的 字节码检验程序减少了解释程序的工作量,因为保证了代码的可靠的特性,且在运 行时间不必再次检査。尽管如此,安全仍然依赖于运行时间的环境 l162 Applet类加载程序 类加载程序必须保护运行时间环境的完整性。绝对不允许 Applets创建它们自己的类 加载程序,且小应用程序之间不应该互相干涉。每一个类加载程序都有它自己的名字空间 ( name space)。每一个类都由安装它的类加载程序进行标签。 Apples由 applet类加载程序 处理。从网络中输入的类根据它们的来源保存在不同的名字空间中 Java带有它自己的类库。在库中的类是非常有用的,它不必隶属于从网络中来的类 同样的控制。 CLASSPATH环境变量确定内置类( built- in class的位置,即这些类被自动 地装载而不需要进一步的安全检查。改变 CLASSPATH或者添加值得怀疑来源的类到 CLASSPATH,对安全的的影响是明显的 当一个类引用了另外一个类的时候, applet类加载程序首先在本地名字空间中搜索 第6页共9页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 6 页 共 9 页 创建日期：2003-11 ·语言自身应该使程序更难产生破坏。 ·执行环境提供了访问控制的机制。 ·必须正确地设置由执行环境实施的安全策略。 图 11.4 Java 沙盒 Java 是强类型的面向对象的语言。从安全的观点来看，这与取消针有很大关系。在 C 或 C++语言中，通过指针的存储器访问是引起故障和安全漏洞的主要原因之一。Java 加强 了类型安全。Java 对象的类型是通过和对象存储在一起的类标签（class tag）指示的。 静态类型检查检验在执行期间获得的操作数的参数是否总是有正确的类型。静态类型检查 比在运行时间的动态类型检查更复杂，但是它可以更快地执行，因为困难的工作在运行前 就已经完成了。 Java 源代码被翻译成独立于机器的字节码（byte code），且作为类文件存储。Java 字节码类似于汇编语言。特定平台的虚拟机解释字节码，并且把它翻译成特定机器的指令。 当运行一个程序时，类加载程序（loader）装入要求的任何附加类。内置的类形成了由运 行时间环境提供的操作系统的更多部分。 Java 是通用程序设计语言，它具有很多特征，可以说服你使用 Java 而不是 C++来编 写你的应用程序。在这里，我们不必关心运行 Java 应用程序的安全方面的问题。我们想 要在安全的方式下运行 Java applets，即用 Java 编写的、来自远程服务器的可执行内容。 在这里的上下文中，安全可能意味着： ·Applets 不能访问用户的文件系统。 ·Applets 不能获得关于用户名、e-mail 地址以及机器配置等的信息。 ·Applets 可以做向外的连接，但只能是回到它们来自的服务器。 ·Applets 仅仅能够弹出标志为不可信任的窗口。 ·Applets 不能重新配置系统，例如，不能创建一个新的类加载程序，或者一个新 的安全管理器（如下面所述的）。 允许运行 Java 的浏览器带有它们自己的 Java 虚拟机。Java 虚拟机有三个安全组件， 即字节码验证器、类加载程序和安全管理器。目前，浏览器都执行类似的策略，但这是出 于选择，不是必须的。 11.6.1 字节码检验程序 字节码检验程序（verifier）分析 Java 类文件，执行语法检查，使用定理证明程序和 数据流分析进行静态类型检查。检验保证了下面这些特性： ·类文件采用了正确的格式； ·堆栈不会溢出； ·所有的操作数都具有正确类型的参数（argument）； ·在类型之间没有数据转换； ·对其他类的所有的引用都是合法的。 字节码检验程序减少了解释程序的工作量，因为保证了代码的可靠的特性，且在运 行时间不必再次检查。尽管如此，安全仍然依赖于运行时间的环境。 11.6.2 Applet 类加载程序 类加载程序必须保护运行时间环境的完整性。绝对不允许 Applets 创建它们自己的类 加载程序，且小应用程序之间不应该互相干涉。每一个类加载程序都有它自己的名字空间 （name space）。每一个类都由安装它的类加载程序进行标签。Apples 由 applet 类加载程序 处理。从网络中输入的类根据它们的来源保存在不同的名字空间中。 Java 带有它自己的类库。在库中的类是非常有用的，它不必隶属于从网络中来的类 同样的控制。CLASSPATH 环境变量确定内置类（built-in class）的位置，即这些类被自动 地装载而不需要进一步的安全检查。改变 CLASSPATH 或者添加值得怀疑来源的类到 CLASSPATH，对安全的的影响是明显的。 当一个类引用了另外一个类的时候，applet 类加载程序首先在本地名字空间中搜索
翻译:中国科学技术大学信息安全专业老师 内置的类。如果没有发现需要的类,搜索扩展到引用类的名字空间。通过跟踪这种搜索路 径,内置类不可能被假冒。 1163安全管理器 安全管理程序是Java安全模型的引用监控程序( reference monitor),执行对危险方法 的运行时间检査。它可以被定制来执行特定的策略,它可以在输入的类、本地类和内置类 之间进行区分。而且,Java类被分组成软件包( packages)。软件包使得对类的基本访问控 制容易实现。根据面向对象的范例( paradigm),类有变量(属性)和方法。变量和方法 都能够被说明为: Private(私有的):只有创建变量或者方法的类可以访问。 Protected(保护的):只有创建变量或者方法的类和它的子类可以访问。 Public(公共的)所有的类都可以访问。 None of the above(与上述无关):仅仅在同一个软件包中的类可以访问。 类在它们所属的软件包中说明。安全管理程序必须阻止类把它们自己附加到特权软件 包。新的Java版本已经增加签名的 applets到访问控制标准的防护库( armoury)中 1164目前的Java安全 到目前为止,Java安全还不是绝对的成功,尽管Sun公司做出了真正的努力来解决 这些安全问题。文献[95]给出了目前发现的(和修补的)Java问题的详细说明。在第8章, 我们提到了若干这样的事件。在大多数情况下,攻击是通过破坏类型系统发起的。(然而, 破坏类型系统并不自动导致安全攻击。)对于那些试图在面向对象的抽象基础上建立强安 全的任何人和对于希望不要求任何附加努力来坚固底层对象管理系统的安全的任何人来 这应该是一个警告信息。使一个复杂的系统具有无懈可击的安全是困难的任务。(破 坏类型系统是为了访问在下面层的另外一个实例。)Java安全是web浏览器中虚拟机的任 务。再一次,安全位于在操作系统之上的服务层。一旦用户访问了在安全机制下面的层, 例如运行了其他的应用程序,而不是web浏览器,保护系统完整性的所有考虑都被破坏了。 另一方面,操作系统中的安全特征又为加强Web安全创造了机会。作为最后一点说明 Java安全模型只是给出了一个框架结构,它并没有托管一个固定的安全策略 117知识产权保护 内容提供者想要通过在他们的web页面上显示信息获得相应的收益。数字信息可以 很容易地被拷贝和传播。内容提供者因此需要一些机制,以帮助他们保护他们的商业利益 这种Web安全的风格决不是一个新的问题。在过去,软件公司和音像工业都必须面对这 个问题。不管是现在或者将来,对知识产权权益(IPRs)的保护没有一个轮廓鲜明的解决 方案。在软件保护方面的简要回顾会说明这是因为什么。软件保护指的是阻止没有得到许 可证的软件使用。两个主要的技术解决方法是 ·拷贝保护:将软件同存储它的硬件联系在一起。 使用限制:将软件同执行它的硬件联系在一起 两种方法都有它们自己的缺点,现在很多的软件供应商宁愿依赖于通过法律系统来 实施他们的权利。软件供应商在计算机病毒的形式上发现了一个令人吃惊的支持者,使用 户确信购买原版的软件比购买较便宜的盜版软件更好。 117.1拷贝保护 在软件还是通过软盘发布时,曾经使用过拷贝保护( copy protection)。存储在磁盘 上的数据典型地排列在磁道上,磁道又划分为扇区。扇区可以包含定位数据的头部和对基 本完整性检测的校验和。存储在偏离标准格式的磁盘上的软件,只有通过软件供应商提供 的特定的例行程序才可以恢复。一旦拷贝例行程序可以生成一个好的非标准的拷贝,这个 防御设施则被破解了。拷贝保护机制的出现实际上导致了更强有力的拷贝程序的开发。对 第7页共9页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 7 页 共 9 页 创建日期：2003-11 内置的类。如果没有发现需要的类，搜索扩展到引用类的名字空间。通过跟踪这种搜索路 径，内置类不可能被假冒。 11.6.3 安全管理器 安全管理程序是 Java 安全模型的引用监控程序（reference monitor），执行对危险方法 的运行时间检查。它可以被定制来执行特定的策略，它可以在输入的类、本地类和内置类 之间进行区分。而且，Java 类被分组成软件包（packages）。软件包使得对类的基本访问控 制容易实现。根据面向对象的范例（paradigm），类有变量（属性）和方法。变量和方法 都能够被说明为： ·Private（私有的）： 只有创建变量或者方法的类可以访问。 ·Protected（保护的）： 只有创建变量或者方法的类和它的子类可以访问。 ·Public（公共的）： 所有的类都可以访问。 ·None of the above（与上述无关）： 仅仅在同一个软件包中的类可以访问。 类在它们所属的软件包中说明。安全管理程序必须阻止类把它们自己附加到特权软件 包。新的 Java 版本已经增加签名的 applets 到访问控制标准的防护库（armoury）中。 11.6.4 目前的 Java 安全 到目前为止，Java 安全还不是绝对的成功，尽管 Sun 公司做出了真正的努力来解决 这些安全问题。文献[95]给出了目前发现的（和修补的）Java 问题的详细说明。在第 8 章， 我们提到了若干这样的事件。在大多数情况下，攻击是通过破坏类型系统发起的。（然而， 破坏类型系统并不自动导致安全攻击。）对于那些试图在面向对象的抽象基础上建立强安 全的任何人和对于希望不要求任何附加努力来坚固底层对象管理系统的安全的任何人来 说，这应该是一个警告信息。使一个复杂的系统具有无懈可击的安全是困难的任务。（破 坏类型系统是为了访问在下面层的另外一个实例。）Java 安全是 web 浏览器中虚拟机的任 务。再一次，安全位于在操作系统之上的服务层。一旦用户访问了在安全机制下面的层， 例如运行了其他的应用程序，而不是 web 浏览器，保护系统完整性的所有考虑都被破坏了。 另一方面，操作系统中的安全特征又为加强 Web 安全创造了机会。作为最后一点说明， Java 安全模型只是给出了一个框架结构，它并没有托管一个固定的安全策略。 11.7 知识产权保护 内容提供者想要通过在他们的 Web 页面上显示信息获得相应的收益。数字信息可以 很容易地被拷贝和传播。内容提供者因此需要一些机制，以帮助他们保护他们的商业利益。 这种 Web 安全的风格决不是一个新的问题。在过去，软件公司和音像工业都必须面对这 个问题。不管是现在或者将来，对知识产权权益（IPRs）的保护没有一个轮廓鲜明的解决 方案。在软件保护方面的简要回顾会说明这是因为什么。软件保护指的是阻止没有得到许 可证的软件使用。两个主要的技术解决方法是： ·拷贝保护：将软件同存储它的硬件联系在一起。 ·使用限制：将软件同执行它的硬件联系在一起。 两种方法都有它们自己的缺点，现在很多的软件供应商宁愿依赖于通过法律系统来 实施他们的权利。软件供应商在计算机病毒的形式上发现了一个令人吃惊的支持者，使用 户确信购买原版的软件比购买较便宜的盗版软件更好。 11.7.1 拷贝保护 在软件还是通过软盘发布时，曾经使用过拷贝保护（copy protection）。存储在磁盘 上的数据典型地排列在磁道上，磁道又划分为扇区。扇区可以包含定位数据的头部和对基 本完整性检测的校验和。存储在偏离标准格式的磁盘上的软件，只有通过软件供应商提供 的特定的例行程序才可以恢复。一旦拷贝例行程序可以生成一个好的非标准的拷贝，这个 防御设施则被破解了。拷贝保护机制的出现实际上导致了更强有力的拷贝程序的开发。对
翻译:中国科学技术大学信息安全专业老师 拷贝保护研究了下述的选择方案 逻辑保护:重写拷贝和列表的程序,以至在设置了一个“不可列表”的标志或 者“不可见”标志时,则不能列出或拷贝这些文件。对于具有足够的操作系统知识人来说 这种保护是不适用的。 非标准磁盘格式:改变逻辑盘格式的选择包括非格式化的磁道、改变磁道/扇区 计数或者编号,改变扇区大小、校验和或者螺旋形的磁道轨迹。这种机制可以有效地阻止 那种认定标准磁盘格式的拷贝程序。敌对者可以用半字节/位( nibble/bit)拷贝程序来 破解这种保护:半字节/位拷贝程序实现磁盘的物理拷贝,并且忽略磁盘的逻辑格式。 ·磁盘指纹:把软件同它的公司出售的原型磁盘的唯一物理标识特征联系在一 并且软件只能从具有正确指纹的磁盘上才能运行。指纹可能是存在格式化的40号磁道(40 磁道通常不进行格式化)、在读每个磁道的零扇区之间的时间延迟、每个道的位(bit)数、 或者磁盘上故意损坏的坏扇区的位置 当拷贝保护程序存储在微处理器或者RAM中时,通过获得对代码的访问即可绕过基于 盘的拷贝保护。例如,一个程序无论什么时候运行,修改中断处理程序可以调用拷贝程序。 可以在微处理机的内部总线放上一块拷贝插件板(存储插件板),修改中断表,以使控制 传递到这块卡上 基于磁盘的拷贝保护存在非常严重的缺陷,由于用户不能使用标准软件组件,基于 磁盘的拷贝保护阻断了备份和在不同的产品之间的互操作能力。软件维护已在用户的能力 范围之外,用户就只能依赖软件供应商在商业上的支持 11.7.2使用限制 拷贝保护的主要问题可以通过限制软件的使用而不是限制软件的拷贝次数来避免 软件自己可以检查它正在运行的机器的身份。这个身份可以是机器名、它的网络地址、以 太网地址等。通常这些值参与校验和的计算,再同存储的值进行比较。这种类型的软件保 护可以被非常有经验的用户使用下述方法破解 调试程序( debuggers),分析软件做了哪种检验 修补软件( patching),以便保证即使软件运行在没有获得许可证的机器上,也让 它的检验成功。 升级或者重新给机器命名要求供应商提供新的校验和,增加了成本,也增加了麻烦 软件狗( Dongles)和智能模块是防篡改的电子设备。如果它们拥有微处理器,那么 它们就是智能的。这个模块与计算机连接,例如,通过RS-232打印接口、以太网接口、 智能卡阅读器、或者微处理机的内部总线。在运行期间,这个模块必须存在。软件可以简 单地检查它的存在。智能模块可能包含了软件的有决定性的部分或者仅以加密格式存储的 解密程序。软件修补程序可以再一次地仿真与智能模块非常简单化的交互 用户可以自由地拷贝由软件狗保护的软件,例如,用于备份的目的。限制仅仅应用 于程序同时执行的数量。当更多的程序需要保护,且几个软件狗必须同时插入时,互操作 问题可能发生。最后,用户必须应付这样的事实,即软件狗可能失败,软件狗的制造者也 可能歇业 11.7.3指纹和水印 在数字文档中嵌入指纹( fingerprint)和水印( watermark)作为内容保护的期待已久 的解决方案目前正在付诸实施。说得宽松一点,水印应该识别文档上知识产权的拥有者 指纹则应该识别文档的购买者。因此要求的特征是很多的,并且有时这些要求自身都是互 相矛盾的: 水印和指纹应该比较容易地合并在一个文档中 水印和指纹应该是很难或者几乎是不可能删除的 ·水印和指纹应该对图象质量没有影响 水印和指纹应该经受得住通常的图像修改 水印和指纹应该由有关权威机构容易地检测到。 创建者能够检验其所有权,但能够使非法翻印者不能删除水印吗?仲裁者必须知道在 哪里可以寻找水印。盗版者则可能修改在这些位置的数据。正是这种情况,更多的帮助将 第8页共9页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 8 页 共 9 页 创建日期：2003-11 拷贝保护研究了下述的选择方案。 ·逻辑保护： 重写拷贝和列表的程序，以至在设置了一个“不可列表”的标志或 者“不可见”标志时，则不能列出或拷贝这些文件。对于具有足够的操作系统知识人来说， 这种保护是不适用的。 ·非标准磁盘格式： 改变逻辑盘格式的选择包括非格式化的磁道、改变磁道/扇区 计数或者编号，改变扇区大小、校验和或者螺旋形的磁道轨迹。这种机制可以有效地阻止 那种认定标准磁盘格式的拷贝程序。敌对者可以用半字节/位（nibble/bit）拷贝程序来 破解这种保护；半字节/位拷贝程序实现磁盘的物理拷贝，并且忽略磁盘的逻辑格式。 ·磁盘指纹：把软件同它的公司出售的原型磁盘的唯一物理标识特征联系在一起， 并且软件只能从具有正确指纹的磁盘上才能运行。指纹可能是存在格式化的 40 号磁道（40 磁道通常不进行格式化）、在读每个磁道的零扇区之间的时间延迟、每个道的位（bit）数、 或者磁盘上故意损坏的坏扇区的位置。 当拷贝保护程序存储在微处理器或者 RAM 中时，通过获得对代码的访问即可绕过基于 盘的拷贝保护。例如，一个程序无论什么时候运行，修改中断处理程序可以调用拷贝程序。 可以在微处理机的内部总线放上一块拷贝插件板（存储插件板），修改中断表，以使控制 传递到这块卡上。 基于磁盘的拷贝保护存在非常严重的缺陷，由于用户不能使用标准软件组件，基于 磁盘的拷贝保护阻断了备份和在不同的产品之间的互操作能力。软件维护已在用户的能力 范围之外，用户就只能依赖软件供应商在商业上的支持。 11.7.2 使用限制 拷贝保护的主要问题可以通过限制软件的使用而不是限制软件的拷贝次数来避免。 软件自己可以检查它正在运行的机器的身份。这个身份可以是机器名、它的网络地址、以 太网地址等。通常这些值参与校验和的计算，再同存储的值进行比较。这种类型的软件保 护可以被非常有经验的用户使用下述方法破解： ·调试程序（debuggers），分析软件做了哪种检验； ·修补软件（patching），以便保证即使软件运行在没有获得许可证的机器上，也让 它的检验成功。 升级或者重新给机器命名要求供应商提供新的校验和，增加了成本，也增加了麻烦。 软件狗（Dongles）和智能模块是防篡改的电子设备。如果它们拥有微处理器，那么 它们就是智能的。这个模块与计算机连接，例如，通过 RS-232 打印接口、以太网接口、 智能卡阅读器、或者微处理机的内部总线。在运行期间，这个模块必须存在。软件可以简 单地检查它的存在。智能模块可能包含了软件的有决定性的部分或者仅以加密格式存储的 解密程序。软件修补程序可以再一次地仿真与智能模块非常简单化的交互。 用户可以自由地拷贝由软件狗保护的软件，例如，用于备份的目的。限制仅仅应用 于程序同时执行的数量。当更多的程序需要保护，且几个软件狗必须同时插入时，互操作 问题可能发生。最后，用户必须应付这样的事实，即软件狗可能失败，软件狗的制造者也 可能歇业。 11.7.3 指纹和水印 在数字文档中嵌入指纹（fingerprint）和水印（watermark）作为内容保护的期待已久 的解决方案目前正在付诸实施。说得宽松一点，水印应该识别文档上知识产权的拥有者， 指纹则应该识别文档的购买者。因此要求的特征是很多的，并且有时这些要求自身都是互 相矛盾的： ·水印和指纹应该比较容易地合并在一个文档中。 ·水印和指纹应该是很难或者几乎是不可能删除的。 ·水印和指纹应该对图象质量没有影响。 ·水印和指纹应该经受得住通常的图像修改。 ·水印和指纹应该由有关权威机构容易地检测到。 创建者能够检验其所有权，但能够使非法翻印者不能删除水印吗？仲裁者必须知道在 哪里可以寻找水印。盗版者则可能修改在这些位置的数据。正是这种情况，更多的帮助将
翻译:中国科学技术大学信息安全专业老师 来自于Web浏览器。控制则会集中在访问操作上,而不是对象上。 进一步的阅读 文献[28]是关于Web安全的一个全面的参考。文献[24包括了 Cookie和 Internet隐 私的描述,Java安全的详细分析在95中给出。关于Web安全的很多有用的信息可以毫不 意外地在下列Web站点找到: htt/w.w3.org(WwW联盟的主页 http:/java.sun.com/sfaq/index.html(JavaSoft对Java安全的介绍 http://java.sun.com/forum/securityForum.html(更多的关于Java安全的信息) http://hoohoo.ncsauiucedu/cgi((事实上的CGi标准); http://www.microsoft.com/intdev/security/authcode/authwp.zip(geaMicrosoft 的认证代码 http://wwwcgi.umr.edu/-cgiwrap/intro.htmi(适合于CGIWrap) 对Java安全模型的最新进展在文献[59中描述。如果你可以使用专用机器( dedicate machine),为了获得关于可以做什么的思想,查看文献[94]。 Internet进一步促进了关于软件保护的法律基础(版权,专利法等)的讨论。这些问 题仍然远未解决,并且可能在不同的法律系统,采用不同的方法来解决。ACM通信是一个 好的来源,它始终跟踪了这些最新的发展。 在拷贝保护和拷贝程序之间的“军备竞赛”的非常有趣的评论( review)可以在文 献62]中得到。目前试图对IPR保护使用信息隐藏(隐写术, steganography),在文献[4] 中进行了评价。 练习题 练习题11.1写出你的Web浏览器现行的安全设置。在你的系统中,与安全有关的信息 存储在什么地方? 练习题11.2定义一个安全策略,使它可以满足你在Web安全方面的期望,为你的策略 构建一个模型。 练习题113对一个安全策略和相关的安全模型作简洁陈述,它能阻止用户在同一个浏览 器会话中运行电子商务应用和计算机游戏。 练习题114为了改善性能,浏览器在客户机的本地高速缓存中存储Web页面。一个怀 有恶意的 Java applet怎样利用这种特征,获得比授予它的更多的特权?描述高速缓存引入 了安全脆弱性的其他例子。 练习题115描述在你的Unix客户机上为了防御有恶意的 applet而可能实施的保护方案。 练习题11.6在有些环境下,期望保护移动代码免受它正在运行的系统的影响。这个目标 真正可以实现到什么程度?列出可以达到的保护特性,哪些是固有的不可能达到的保护特 性? 练习题11.7软件产业曾试图通过拷贝保护来保护他们的财产,但在90年代早期,他们 基本上放弃了这种方法。现在,再次努力开发为了知识产权的保护机制。依你的观点,这 次在技术方面的变化有更大成功的可能吗? 练习题11.8拷贝保护会增加软件产业的收益吗?在你的答案中想一想字处理软件、ⅤLSI 设计工具和计算机游戏。 第9页共9页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 9 页 共 9 页 创建日期：2003-11 来自于 Web 浏览器。控制则会集中在访问操作上，而不是对象上。 进一步的阅读 文献[128]是关于 Web 安全的一个全面的参考。文献[124]包括了 Cookie 和 Internet 隐 私的描述，Java 安全的详细分析在[95]中给出。关于 Web 安全的很多有用的信息可以毫不 意外地在下列 Web 站点找到： http://www.w3.org (WWW 联盟的主页)； http://java.sun.com/sfaq/index.html (JavaSoft 对 Java 安全的介绍)； http://java.sun.com/forum/securityForum.html (更多的关于 Java 安全的信息)； http://hoohoo.ncsa.uiuc.edu/cgi (事实上的 CGI 标准)； http://www.microsoft.com/intdev/security/authcode/authwp.zip (适合 Microsoft 的认证代码)； http://wwwcgi.umr.edu/~cgiwrap/intro.html (适合于 CGIWrap)。 对 Java 安全模型的最新进展在文献[59]中描述。如果你可以使用专用机器（dedicate machine），为了获得关于可以做什么的思想，查看文献[94]。 Internet 进一步促进了关于软件保护的法律基础（版权，专利法等）的讨论。这些问 题仍然远未解决,并且可能在不同的法律系统，采用不同的方法来解决。ACM 通信是一个 好的来源，它始终跟踪了这些最新的发展。 在拷贝保护和拷贝程序之间的“军备竞赛”的非常有趣的评论（review）可以在文 献[62]中得到。目前试图对 IPR 保护使用信息隐藏（隐写术，steganography），在文献[4] 中进行了评价。 练习题 练习题 11.1 写出你的 Web 浏览器现行的安全设置。在你的系统中，与安全有关的信息 存储在什么地方？ 练习题 11.2 定义一个安全策略，使它可以满足你在 Web 安全方面的期望，为你的策略 构建一个模型。 练习题 11.3 对一个安全策略和相关的安全模型作简洁陈述，它能阻止用户在同一个浏览 器会话中运行电子商务应用和计算机游戏。 练习题 11.4 为了改善性能，浏览器在客户机的本地高速缓存中存储 Web 页面。一个怀 有恶意的 Java applet 怎样利用这种特征，获得比授予它的更多的特权？描述高速缓存引入 了安全脆弱性的其他例子。 练习题 11.5 描述在你的 Unix 客户机上为了防御有恶意的 applet 而可能实施的保护方案。 练习题 11.6 在有些环境下，期望保护移动代码免受它正在运行的系统的影响。这个目标 真正可以实现到什么程度？列出可以达到的保护特性，哪些是固有的不可能达到的保护特 性？ 练习题 11.7 软件产业曾试图通过拷贝保护来保护他们的财产，但在 90 年代早期，他们 基本上放弃了这种方法。现在，再次努力开发为了知识产权的保护机制。依你的观点，这 一次在技术方面的变化有更大成功的可能吗？ 练习题 11.8 拷贝保护会增加软件产业的收益吗？在你的答案中想一想字处理软件、VLSI 设计工具和计算机游戏