andrew van der stock，是修正开放web 应用安全项目(owasp)指南的主要负责人，这一举动是为了创建安全web应用，下面是他谈论的开发人员需要关注的ajax安全和风险问题。

　　andrew van der stock，是修正开放web 应用安全项目(owasp)指南的主要负责人，这一举动是为了创建安全web应用，下面是他谈论的开发人员需要关注的ajax安全和风险问题。

　　在开放web 应用安全项目(owasp)指南中关于ajax的新增章节中，你写到:ajax应用程序除了面临和所有的web应用程序一样的安全问题之外，ajax应用程序还有自己的风险。那么开发人员需要关注的关键风险是什么呢?

　　andrew van der stock:从本质上讲，主要的额外风险是:

　　(1)从理论上讲，ajax应用程序比普通的应用程序的受攻击范围更大。

　　(2)ajax应用程序必须把状态和过程代码存储在完全不受信任的客户端――用户的浏览器。不要相信你从用户那得到的任何数据，也不要信任客户端验证，因为你的客户端验证程序对于黑客而言完全是形同虚设的。

　　(3)ajax应用程序有着更多用于执行令人关注的html注入的方法。

　　(4)ajax应用程序可以在后台做一些事情(“异步”比特)，而且一个未经授权的动作完全不需要显示在用户屏幕上，因此用户也许根本不知道已经受到了攻击。攻击者已经在激活的ajax应用程序中扩展了会话拦截攻击(交叉站点需求伪造)，比如samy myspace蠕虫病毒。我们认为还有更多。

　　(5)数据混搭程序可能会涉及到非常严重的隐私问题――当你发送私有数据时一定要注意，尤其是当你在欧联盟国家或者是其他强隐私权国家时。

　　你同时也写到，ajax的使用需要对架构、服务器端访问控制、状态管理和严格的验证体系进行仔细考虑以防止受到攻击。让我们对这些因素逐个分析。有没有合适的架构能够解决一些ajax的安全弱点呢?

　　van der stock:有。ajax从本质上说是客户端模型，而且我们有足够的理由来写一次代码以避免增加更多的费用和开发时间。使用ajax，这就意味着首先在客户端写代码然后把问题留给服务器端(如果在服务器端有什么程序的话)。这从安全角度而言是个错误的方法。重用服务器端控制来实现重新验证、执行规范和编码以及适当的授权活动，这是至关重要的。

　　架构应该围绕瘦客户端和面向对象架构模型来设计ajax应用程序(你不必一定要使用web服务来实现soa)。把授权、验证和业务逻辑放在服务器端执行。客户端从本质上讲是不受信任的而且应该非常谨慎地对待。

　　你给出了ajax框架连接到不可靠的soa终端的实例。那么ajax可以在soa环境下安全地使用么?

　　van der stock我个人认为soa服务已经有20多年了，大部分甚至可以说全部无国界的cics(客户信息控制系统)事务处理都是用cobol(面向商业的通用语言)或者pl/1语言编写。以往的cics事务处理没有对那些持有可用的测试工具并且熟悉z/os、 ebcdic 和xml注入这些应用知识的恶意攻击者进行防范。对于这些旧代码，很难判断出要花费多大的代价来雇佣cobol方面的大师来增加xml的警惕性、验证和规范。这些最初的程序员在开发时进行了这样的假设:cics事务处理可以映射到一个3270型绿屏终端，而且该用户是受信任的人员。但是，当你已经通过web服务或者ajax兼容的web接口把事务处理暴露了的话，这个假设就不再正确了。

　　如果ajax应用程序运行在不受信任的客户端，并且通常只是实现一些很基础的完成服务器端调用的方法，如简单的gets或者posts。那么，为了允许通过调用一个soa终端来调用“从x帐户支付$2,500作为我的抵押金” 这样的应用程序，并且而使被称为ws-security的安全警报不会报警，这就需要授权给客户端更多的信任。

　　所有soa终端应该实现哪种安全标准呢?

　　van der stock:所有的soa终端应该实现(1)访问控制――认证和授权――用来防止恶意调用;(2)数据传输过程中的保密性和完整性，如加密套接字协议层(ssl)，按照事务处理的价值或者受保护的资源;(3)某些形式的加强顺序控制以防止重放攻击，如加密的随机参考数(4)验证机制以加强服务器端的数据验证;(5)各种形式的注入的警惕性，如xml、html或者dom注入，并且防止“interesting”数据;(6)业务逻辑验证以加强业务规则;还有(7)在事务处理之间有空间来存放终端敏感状态而不是暴露给调用者。

　　我相信大多数的soa终端都不足以抵挡从攻击者发来的连接，哪怕这些攻击者只具备我所掌握技术的很少一部分――而且穿透测试也不是我的强项。对于授权给不受信任的或潜在可能被注入的浏览器使其能够通过主线访问公开的调用原始代码的soa服务，我认为这是不合适的，尤其是当实际的钱或者物品可能被蓄意的攻击者盗走的话。

　　你推荐了一个三层应用程序模型。可以解释一下么?

　　van der stock: soa层应该放在web应用服务器之上。这就给了ajax客户端一定的空间来登陆和完全验证自身、允许适当地经授权的调用soa服务、安全地中断敏感状态，并且更多的控制应用程序，尤其是在采用瘦客户端方式的情况下。

　　这个三层模型也允许应用服务器把一组调用者中的一个保留在soa层(而不是保留几千个)，允许现有的控制器存在，如防火墙和ws-security，并且保持对大多数企业的易处理性。可测量性也可以通过使用可靠的通讯方式来掌握，如mq或者队列组件。ajax不是可靠通讯层，这一点对于像“给我支付抵押”这样的消息非常关键。

查看本文国际来源