注意：在这种混乱的交互中，指责任意一方都属徒劳。近有一件和firefoxurl:协议有关的漏洞，微软和信息安全圈里半数的人在指责Mozilla，而Mozilla和另一半的专家则怪罪于微软7。谁对谁错其实并不重要：反正结果还是一团乱麻。

　　另一个紧密相关的问题是，即使浏览器的安全机制表面上看来很相似，实际上却并不兼容，这种情况在Web出现之前很少发生。如果各家浏览器安全模型是不同的，那么某条Web应用开发规范对其中一种浏览器可能是合理的，但对另一种却可能完全不适用且会产生误导。实际上，哪怕一些非常基本的任务，如打开一个用户提供的纯文本文件，在某些浏览器里也无法安全地实现。而这些问题程序开发人员往往意识不到，除非他们正好使用了这种受影响的浏览器—即使这样，也往往需要等他们踩上地雷才会意识得到。

　　后，本节描述的问题在安全缺陷分类学里会归到一个很吓人的全新类别里：“无法描述又未被记录的各种问题”，但这类问题实际上随处可见。

客户端和服务器端界限的日益模糊

　　信息安全人员喜欢静态的世界和清晰分配的角色，这样在映射到安全交互上至少还有个熟悉的参照体系，否则事情可能会很复杂。比如，我们假设有两位努力工作的诚实用户爱丽丝和鲍勃想要互相通信，而居心叵测的攻击者马洛里则在暗处想攻陷他们。然后我们有客户端软件（基本上没啥话语权，有时候恶意的I/O终端会乱发服务请求），还有谦逊的服务器们会老老实实地响应客户端的这种恶搞。程序员清楚这些角色后开始处理问题，然后创建出一个相当全面又可供测试的网络计算环境。

　　Web的起源完全符合常规的“客户端–服务器端”架构，但客户端和服务器端响应的功能边界被迅速模糊了。罪魁是JavaScript技术，它在浏览器里（也是“客户端”）代理了HTTP服务器的应用逻辑的执行，这么做有两个非常有吸引力的原因。首先，这种方式使得用户界面的响应更灵敏，因为每次微小的UI状态变化不需要再和服务器端进行同步了。其次，极大地降低了服务器端的CPU和内存要求（也是降低了服务的运营成本），因为相当于通过遍布全球的每台独立计算机的参与，降低了运算量。

　　尽管“客户端–服务器端”边界的模糊起源于单纯的目标，但连同客户端的常规功能一起，迟早也会需要引入安全机制的。因为既然数据都是由客户端JavaScript动态生成的，那仅仅在服务器端严格地清理HTML页面又有什么意义呢。

　　在某些应用里这种趋势已经走向，服务器逐渐变成了一个沉默的存储设备，几乎所有的解析、编辑、显示和配置任务都转移到浏览器端执行了。按照这种设计，甚至可以用诸如HTML5的持久存储作为离线Web扩展而不太需要依赖于服务器端。

　　尽管在整个应用的设计里，这点改变可能不算什么大事，但决不能指望客户端负责所有的安全问题。例如，即使服务器只是用作沉默的存储设备，客户端也不能不受限制地访问到服务器端其他用户的数据，也不能由客户端来指派访问控制权限。后，因为把所有的应用安全逻辑都放在服务器端不是很合理，而把它完全移到客户端也完全不可能，结果导致大部分应用取而代之的是搞个随意的中间层，在此中间层里客户端和服务器端的组件往往很难区分了，对责任的逻辑隔离也完全欠奉。这有别于传统程序里优雅健康的安全角色划分，导致其设计和应用的行为也完全不可同日而语。

　　这种情况带来的远不止是设计层面的混乱，还使得复杂度大增。在传统的“客户端–服务器”模型里都有用途清晰具体的API，无需考虑客户端可以非常容易评估服务器的行为，反之亦然。此外，在每个组件里，都可以轻易地隔离出较小的功能区间，确定在此区间内会有什么操作。但Web的全新模型，再加上Web上常见应用API都是既模糊又临时，所以通过以前那些分析手段，理性地推断一个系统的安全性已经完全不可能了。

　　尽管人们期望能找出Web上标准化的建模和测试协议，但终出人意料地失败了，这也使得Web安全在信息安全领域具有独特而令人胆寒的地位。

来源：数据来自公开的NetApplications报告