第十一章 万维网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上传输数据的保护。
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]。
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 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的选择项。
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.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类加载程序首先在本地名字空间中搜索内置的类。如果没有发现需要的类，搜索扩展到引用类的名字空间。通过跟踪这种搜索路径，内置类不可能被假冒。
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）作为内容保护的期待已久的解决方案目前正在付诸实施。说得宽松一点，水印应该识别文档上知识产权的拥有者，指纹则应该识别文档的购买者。因此要求的特征是很多的，并且有时这些要求自身都是互相矛盾的：
·水印和指纹应该比较容易地合并在一个文档中。
·水印和指纹应该是很难或者几乎是不可能删除的。
·水印和指纹应该对图象质量没有影响。
·水印和指纹应该经受得住通常的图像修改。
·水印和指纹应该由有关权威机构容易地检测到。
创建者能够检验其所有权，但能够使非法翻印者不能删除水印吗？仲裁者必须知道在哪里可以寻找水印。盗版者则可能修改在这些位置的数据。正是这种情况，更多的帮助将来自于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设计工具和计算机游戏。
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上传输数据的保护。
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]。
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 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的选择项。
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.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类加载程序首先在本地名字空间中搜索内置的类。如果没有发现需要的类，搜索扩展到引用类的名字空间。通过跟踪这种搜索路径，内置类不可能被假冒。
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）作为内容保护的期待已久的解决方案目前正在付诸实施。说得宽松一点，水印应该识别文档上知识产权的拥有者，指纹则应该识别文档的购买者。因此要求的特征是很多的，并且有时这些要求自身都是互相矛盾的：
·水印和指纹应该比较容易地合并在一个文档中。
·水印和指纹应该是很难或者几乎是不可能删除的。
·水印和指纹应该对图象质量没有影响。
·水印和指纹应该经受得住通常的图像修改。
·水印和指纹应该由有关权威机构容易地检测到。
创建者能够检验其所有权，但能够使非法翻印者不能删除水印吗？仲裁者必须知道在哪里可以寻找水印。盗版者则可能修改在这些位置的数据。正是这种情况，更多的帮助将来自于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设计工具和计算机游戏。
