Internet软件发行、下载中的安全问题

llc

导言

90年代，随着因特网技术的不断发展，尤其是以WWW服务为代表的统一、跨平台、分布式的计算平台的广为使用，传统的C/S（客户机/服务器）结构的计算模式受到了来自B/S（浏览器/服务器）结构的强大冲击。B/S结构的计算模式巨大优点在于应用的发布、升级、使用和维护集中与服务端，而客户端的平台不相关性、界面风格统一等使得这种计算模式有着巨大的应用前景。然而，其中与生俱来的计算机网络安全问题则益发显得突出。
本文从应用的角度阐述开发B/S结构的系统时的安全问题。包括相关的技术、工具和方法与标准等。本文主要介绍以Internet Explorer为前端，IIS为后端的结构。

级别高低的区分是以用户通过浏览器发送数据和浏览器访问本地客户资源的能力高低来区分的。安全和灵活是一对矛盾的东西。高的安全级别必然带来灵活性的下降和功能的限制。Web技术的发展也是安全和功能强大的平衡。纯粹文字的HTML或许是安全的(如果我们把内容给予用户身心带来的冲击，比如暴力、色情等的不看作安全问题)，但显然其功能受到很大限制。允许在网页上下载和使用ActiveX显然是不安全的，但功能会很强大也是毋庸质疑的。

安全是和对象相关的。一般我们可以认为，小组里的十分可信的站点，比如办公室的软件服务器的数据和程序是比较安全的，公司的同时的站点是中等水平安全，当然Internet上的大多数访问被认为是相当不安全，其中黑客们的访问自然是极不安全。

基于对访问对象和访问方法的划分，IE5.0定义了四个通过浏览器访问Internet的安全级别和四类访问对象。高、中、中低、低。Internet、本地Internet、可信站点、和受限站点。
访问手段包括如户使用AxtiveX和控件、如何使用Cookies、如何使用脚本(Script)、如何下载数据和程序、如何验证用户登陆、以及对于标准HTML一些可能带来问题的特性的限制，如Frame的使用、提交表单的方式等等。

这里我们尤其关心的是软件下载、ActiveX下载、数据下载等问题。
众所周知的是，目前，HTML及其各种发展如XML、SGML、DHTML等置标语言的实际应用能力还十分有限，在B/S结构的应用中，表达能力一直必须通过使用下载本地可执行代码的扩展。因此，安全成为一个十分重要的问题。如何验证、信任和更新软件？一个基本也是十分普遍的解决方案是数字签名（digital signature）和认证鉴别(Authentication)。

ActiveX 部件的安全设置
安全设置用于确保 ActiveX 控件安全地与用户的计算机和计算机数据交互。当为 Internet 部件下载发布 ActiveX 控件时，必须为控件设置安全级别。否则，如果签名的控件发行后损坏了用户的计算机或破坏了用户的数据，开发者将对此负法律责任。

这些问题可以通过验证代码的安全性并作出相应的标记来解决。Internet 部件下载有两级安全： 设置初始化安全性和设置脚本安全性 。(注意 安全设置只适用于用 Internet Explorer 进行下载的部件。)

1. 设置初始化安全性
当将控件标记为设置初始化安全性后，就确保了无论在初始化时使用什么数据和脚本，都不会执行有损于最终用户计算机的操作。一个设置了初始化安全性的控件不会写入或修改任何注册条目、.ini 文件或作为初始化参数结果的数据文件。设置初始化安全性对控件的方法、运行时属性或提供给脚本书写器的信息的安全性没有要求。

缺省情况下，Internet Explorer 将显示一条警告信息，并且不下载没有标记为设置脚本安全性和设置初始化安全性的控件。在使用 Visual Basic 打包和展开向导为 Internet 发行的软件打包时，可以将软件指定为设置初始化安全性和设置脚本安全性。

2. 设置脚本安全性
当将控件标记为设置脚本安全性时，就确保了没有任何脚本可以使控件对用户的计算机或数据造成破坏。标记为设置脚本安全性的控件将不能从用户的计算机中获取未授权的信息，也不能对系统造成破坏。

在将控件标记为设置脚本安全性之前，必须验证该控件不执行任何非法行为或不允许可能造成破坏的打开文件的行为。一般来说，能够自动获得用户计算机中有关用户的任何信息并将其展示给脚本书写器的控件是没有设置脚本安全性的。这种看似无害的行为在某些国家/地区会被视为犯罪。

特别地，控件的脚本不应执行以下操作：

? 插入或检索自定义、脚本的注册表和 .ini 文件信息。换句话说就是，用户不能通过脚本来指定插入哪个注册表或 .ini 文件信息。
? 插入或检索不属于控件的注册表和 .ini 文件信息。
注意 控件在发行时可以插入和检索预先定义、只属于控件的、用于帮助控件管理其内部功能的注册表和 .ini 文件信息。
? 用脚本指定的名称从硬盘驱动器上读取文件。

安全与不安全操作之间的区别是非常细微的。例如，总是将信息写入自己的注册表条目的 ActiveX 控件可能是安全的，而允许用户命名条目的控件是不安全的。创建临时文件时不使用任何初始化或脚本值的控件可能是安全的，但允许初始化时或通过脚本对临时文件命名的控件是不安全的。

在将控件标记为设置脚本安全性之前，建议最好创建文档来记录其理由，对此应给予同签定法律合同一样的关注。可以将该文档包含在控件的 .inf 文件中。文档可能包括以下内容：
熟悉源代码和 VBScript 的专家、外部开发者对控件的评论。
一张列出控件所有显露的方法、事件和属性的列表。

一张列出所有打开的文件、使用的 API 调用、检索或写入的信息的列表。
如果以上两种列表的元素之间有任何依赖关系或数据传送，则控件可能没有设置脚本安全性。

3. 安全标志的局限性
一个标记为设置初始化安全性和设置脚本安全性的控件在使用时并不一定总是安全的。以上两节列出了控件作为初始化或脚本的结果不能执行的操作，但控件在其他时间仍可能执行这些不安全操作。

例如，假设创建了一个 ActiveX 控件，该控件在使用 10 次以后就对硬盘进行重新格式化。该操作并不作为初始化或脚本结果发生，因此可以将该控件标记为安全。当然，写这样一个控件的人应受到与写病毒的人同样的惩罚。

开发者，而不是最终用户或 HTML 作者，应当负有提供足够安全保证的责任。如果作为开发者没有提供足够的安全保证，那么他就应承担法律责任。

软件安全的最终审核一般是由对该安全问题非常熟悉且经验丰富的开发人员对软件独立评审后完成的。开发者可能希望将有关评审的信息包含在下载文件包的 .inf 文件中。

一般性的理论介绍
首先区别两个概念，授权（Authrization）和鉴别（Authentication）。在软件下载中，鉴别关心的是否在使用一个特定的软件开发商的特定软件，其中非常关心的是，软件包中标识的开发者是否被篡改过，软件是否被篡改过。而授权的核心问题是是否和如何允许该软件被下载、执行和访问资源。

所有的鉴别协议都使用类似的基本模型。用户A想要区别通讯的对象实体是否是B，首先A要通过某种渠道标识自己，这种标识要有被信任的中介机构参加或者A,B双方采用其他途径先行通知，公用的标识方法一般是通过被信任的中介机构完成的。在软件分发中这种标识就是证书（certificate）。
软件下载的用户首先相信某个和某些认证中心，称为CA，CA的工作是记录和调查软件发行实体的身份，授予和取消实体的数字签名证书。
以A和B的通讯为例：
A 发送一个认证请求给CA，其中包括A的名字和公钥
CA从A的消息中创建消息摘要m，然后把m用CA的私钥加密，形成一个CA的数字签名，然后CA把两者一起返回给A，这就是一个证书
A把证书发送给B
B用CA的公钥验证证书的合法性，如果成功则B从证书中获得A的公钥并信任这个公钥
实践数字签名
Internet Explorer 的缺省安全设置要求任何可下载的软件在下载之前必须拥有一个数字签名。数字签名能用于对以下内容进行核实：
1. 文件的内容。
2. 文件有可靠的来源。

签名提供了一种验证文件内容的方法，该方法确保该文件在可用于下载后未被改变过。数字签名通过标识创建软件的合法实体来验证来源。当在可下载的软件中加入了签名，发行者就是合法实体。合法实体应该为签名软件被下载时或运行后所造成的损失负责。

应被签名的软件

在Windows系统上，有五种类型的文件可以使用数字签名：
1. .exe 文件
2. .cab 文件
3. .dll 文件
4. .ocx 文件
5. .vbd 文件
如果提供以上类型的文件下载，就应为其设置数字签名。

注意 通常，只要在部件打包后的 .cab 文件中进行签名就足够了。然而，如果要发行的 .ocx、.exe、.vbd 或 .dll 文件没有打包在 .cab 文件中，就要单独为其进行签名。

可以通过向认证机构购买证书来获得数字签名。认证机构是一个确认身份并发行认证证书的公司。证书中包含发行者的数字签名，是发行者信用的验证。一旦出现问题，认证机构将成为发行者身份的见证人。

在使用数字签名时要使用 Authenticode 技术。Authenticode 的目的是通过建立责任制来阻止有害代码的发行。Authenticode 将验证发布代码的发行人的身份给要下载这份代码的 Internet 最终用户。此外，Authenticode 可以为用户确保该代码在签名后未被改动。

Authenticode 技术来源于公用密钥签名技术。该技术使用了密钥对来加密数据。密钥对用于文件的加密和解密。在公用密钥技术中，公用密钥和私用密钥确保了文件的私有性。公用密钥用于加密数据，而私用密钥则用来解密数据。尽管该技术用于保护诸如电子邮件之类的小文件是很成功的，但是对于大文件，这一过程却是非常消耗时间的。Authenticode 正是这种技术的一种改进形式，专供大文件使用。

以下是 Authenticode 过程中的一些步骤：

1. 在开发者对文件签名时，要计算一个哈希数。哈希数表示文件的总字节长度。一般可以选用不同的消息摘要技术，X.509标准要求至少提供MD5、SHA-1。该数字用私用密钥加密并插入到文件中。然后，开发者将文件进行打包并将其部署到 Web 服务器上。
2. 当用户下载或安装文件时，他们的计算机计算第二个哈希数，并同原先的进行比较。如果数字相同，则文件的内容就得到了验证。
3. 浏览器使用公用密钥来决定软件开发者的身份和提供数字签名的认证机构。
4. 认证机构核实开发者的身份，并将包含经私用密钥加密的开发者名字的证书授予开发者。
5. 浏览器使用公用密钥将文件解密。然后进行安装。


关于CA的建设
如前所述，CA成为通信活动的瓶颈，通信如果只能访问一个CA，那么CA的负担就会极大，同时由于地理和其他限制，也许有些实体访问CA的难度很大，这就引出了CA的体系结构的问题。
采用分层的想法是解决的一种途径。
如下图所示：


比如Root CA是各国的政府授权的CA机构总署，RootCA可以给各个地方CA授予一定程度的信任权限，在图一中标识为第一层CA（Tier1），当A收到由Tier1的CA或者Tier2的CA签发的证书时，A可以通过验证签发该证书的上级CA的授权来信任Tier1或者Tier2的CA。这样各级的CA都可以被认证。也就是说，只要A信任该CA的任意级的上级CA，A就可以验证该CA的证书的有效性。

实践中的RootCA可以有不止一个。如下图所示：


数字签名的工具与实践

1. Internet Client SDK中的数字签名工具
Internet Client SDK中提供了制作数字签名、证书和以及验证的工具。可以从文字处理实验室的服务器上免费获得。包括
? Cer2spc
这是一个生成软件发布证书（SPC）的工具。它可以从多个X.509证书创建一个SPC。
? Certmgr
管理SPC的工具，包括增加、删除、重新生成SPC Store的功能。
? Chktrust
检验一个文件包是否含有合法的数字签名
? Makecert
创建一个X.509证书。
? Signcode
使用软件证书为软件包签名的工具。

使用这些工具可以方便的制作各种证书、签名，以及校验。进一步的MSDN中另外还提供了Microsoft CryptoAPI来进一步的操纵生成X.509或者PKCS#7,PKCS#7（RSA Public-Key Cryptography Standard）的证书。

2. Microsoft CryptoAPI
使用CryptoAPI不但可以用于软件下载中的省份验证，而且可以用于网络通讯中的身份验证。
CryptoAPI包含以下几类功能：
? Cryptographic Functions
提供基本对称密钥和公钥系统加密解密算法的实现，以及密钥生成等辅助功能。
? Certificate Store Functions
提供证书存储、分类和目录的功能，协助管理证书、证书恢复列表Certificate Revocation Lists (CRLs), 证书信任列表and Certificate Trust Lists (CTLs).
? Certificate Helper Functions
提供操纵证书的功能，包括比较、证书转换、消息摘要、签名、校验等。
? Crypt Time Valid Object Retrieval Functions
提供时间服务，包括对时间服务器的访问，证书有效时间的验证、修改等。
? OID Support Functions
微软的对象标识技术的支持函数，提供对SDCOM（Security DCOM+）的支持

3. X.509证书的标准

ITU-T建议的X.509（ISO/IEC 9594-8）认证证书，结构如下：
域 描述
Version版本号 证书版本
Serial Number序列号
Algorithm Identifier数字签名算法标识
Issuer Name发布证书者
Validity:有效日期 不早于XX/XX/XX,不晚于XX/XX/XX
Subject Name证书持有者名
Subject Public Key Info: 证书持有者公钥 公钥算法标识与公钥串
Optional Fields可选
Extensions扩展


参考文献：
1. MSDN April, 1999
2. Andrew S. Tanenbaum Computer Network
3. ISO/IEC 9594-8
4. Sape Mullender : Dostribued Systems
5. Microsoft Internet Client SDK

参考站点:
http://www.microsoft.com/security
http://www.microsoft.com/workshop/prog/security/authcode/certs.htm
http://www.microsoft.com/workshop/prog/sdk/
http://www.microsoft.com/workshop/prog/inetsdk/