有关TCP/IP协议族存在的脆弱性剖析

如果Web 服务需要输出敏感的、受限的数据，或者需要提供受限的服务，则它需要对调用方进行身份验证。如果客户访问都是在一个可信的域中，我们就完全可以放心使用，但在实际应用中是不可能实现的。所以，系统级的身份验证也就无法实现，至少在现阶段无法实现。例如：可以使用IIS为基本身份验证配置Web服务的虚拟目录。通过这种方式，使用者必须配置代理，并提供用户名和密码形式的凭据。然后在每次Web服务通过代理请求的时候由代理传递它们。这些凭据是以明文形式传递的，所以应该只在SSL中使用基本身份验证（如图3），但很少有管理员这样做。

图3

　　另外，Web服务本身不提供容错机制。如果Web服务采用了软件冗余技术，就可以保证一个版本出错，另一个版本就很少有机会出现相同的错误。代码的重复利用不能保证错误的完全避免，因此在某个模块发生某个物理故障时，其他模块也就完全瘫痪。

　　随着Java Applet、ActiveX、Cookie等技术的大量应用，当用户使用浏览器查看、编辑网络内容时，采用了这些技术的应用程序会自动下载并在客户机上运行，如果这些程序被恶意使用，就可能窃取、改变或删除客户机上的信息。对于恶意程序的侵害，用户很难实时判断程序性质，因此，在获得高度交互的Web服务时，如何抵御这些安全威胁绝非简单的客户端设置就可以解决的。

　　提高网络可信度

　　前面我们已经提到了IPv4存在的弊端，很多安全防范技术被忽略了，它不可避免地被新一代技术IPv6取代。IPsec安全协议就是事后发展的一种协议（如图4），而NAT（网络地址转换，Network Address Translation）解决了IP地址短缺的问题，却增加了安全风险，使真正的端到端的安全应用难以实现。端到端安全性的两个基本组件——鉴权和加密都是IPv6协议的集成组件；而在IPv4中，它们只是附加组件，因此，采用IPv6安全性会更加简便、一致。

图4

　　在现在的网络环境中，尤其是园区网当中，由于不存在NAT地址转换的问题，所以IPSec具备允许部署可信计算基础架构的基本特征。IPSec数据包验证能够确保整个IP报头、下一层协议（例如TCP、UPD或ICMP）报头以及数据包有效负载的数据完整性。

　　另外，针对数据包的单向Hash算法用以提供校验和。通信发起方计算校验和并在发送之前将其附加到数据包中；响应方则在收到数据包后为其计算校验和。如果响应方所计算出的校验和与数据包中附带的校验和完全匹配，则证明数据包在传输过程中未被修改。校验和的单向计算特性意味着其取值无法在传输过程中进行修改，这也就保证了端到端的数据传输过程的可信程度。