翻译:中国科学技术大学信息安全专业老师 第十一章万维网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的格式是: <l-#operator argI="string l"arg2"string2".-> 最终的灵活性是通过带有参数cmd的操作符exec提供的。内联SSI是: <l-#exec cmd="myprogram myparameters"-> 传送字符串" 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 的格式是： <!-#operator arg1=string1 arg2=string2… -> 最终的灵活性是通过带有参数 cmd 的操作符 exec 提供的。内联 SSI 是： <!-#exec cmd=myprogram myparameters-> 传送字符串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 离开这个沙盒。安全考虑也进入了几个相关的设计决策：