专家警告：Ajax应用安全面临危机

文/Jennette Mullaney

Ajax 应用安全正逐步成为人们优先考虑的问题，但是关于Ajax 安全的很多信息是不充分的、不正确的或是很难得到的。这些警告来自Bryan Sullivan（SPI Dynamics的开发经理和 SPI 中心主管）和Billy Hoffman（ Ajax常驻安全专家和SPI中心的首席研究工程师）。

Sullivan 和 Hoffman 数年来一直倡导重视 Ajax的安全。二人决定查阅当时流行的 Ajax书籍、论文、论坛，并据此设计了Ajax应用程序。但结果却发现Ajax的应用程序“相当糟糕”且“非常不安全”，Sullivan 说。“普通的建议最终变得非常、非常地可怕” 。

这两个人几星期前在美国黑帽子安全会议（Black Hat USA security conference）上提交了他们的大作。论文以令人惊奇的标题“不成熟的 Ajax-ulations”为名，以实用的建议来反驳流行的Ajax 知识。下面是他们的发现。

Ajax 不是本来就不安全，而是忽视安全造成的不安全

Ajax 具有传统网络安全的所有问题，Hoffman 说。这些问题在Ajax应用程序中被成倍放大。增加的复杂性、用户端的脚本运行以及更大的攻击面意味着：需要提升传统的网络安全解决方案来处理这些较大的危险。

Hoffman和Sullivan强调了他们喜爱Google Map及其他运行Ajax的应用。他们说，主要的问题是Ajax的成长发展超过了Ajax的安全。

“Ajax 的额外攻击面不是来自体系结构方面，而是由于人们正在不断增加功能”，Sullivan 说。当鼠标在Google Map上平滑地移动时,其后面的应用正在努力工作,经常来回地从服务器向用户发送信息。

“Ajax 真的很妙。只需为额外的功能支付额外的费用,”Sullivan 说。“额外的费用” 包括遵循最佳的基本应用安全原则以及改善开发、QA和测试团队之间的沟通。其中的许多安全原则应已为人熟知。

输入验证、白名单是极其有效的安全措施

“我唯一最好的建议是验证你的输入，”Sullivan 说。这么做可以立即排除80%的攻击,与习惯的应用相类似。“像其他的输入一样只看表面的信息参数,而且就像它在通过一个形式代码一样验证，”他解释说。通常的攻击如SQL注入和交叉地址脚本 (XSS)事实上能以正确的输入验证来消除，他说。

然而，使用正确的输入确认类型很重要，Hoffman强调说。 黑名单因其被动反应的特性而无效。白名单是积极主动的，Hoffman以美国邮政编码输入为例来解释。美国邮政编码码是五个数字且不包括字母或符号。如果白名单遇到五个数字以外的数字或字母，它将拒绝进入。

为了增强安全，黑名单分层放在白名单之上。“而起作用的理由是因为白名单在上面大幅减少了所要得到的安全性，所以，”Hoffman 说。在列入白名单之后，“ 在处理很小的子集时就可能会使黑名单实际上有效”。

在服务器端做验证, 而不是在用户端

Ajax应用验证输入时需要考虑另一个重要因素。 “所有的验证都得在服务器一端进行，否则它就没有用，”Sullivan 说。其原因是因为“用户是邪恶的”。

如果开发者、测试者和QA需要在他们是否想保证Ajax应用的安全，他们需要付出大量工作的前提下工作，，Sullivan 说。因为要在用户端运行如此多的Ajax功能，所以不能轻易相信用户端因此只信赖用户不是一种好的选择。

“任何时候，你都不能相信用户端发生的任何事情。”Hoffman 说。“要是我可以和世界上的每一个Web开发者坐在一起，这就是我要告诉他们的。”

沟通是关键

如果开发者、QA和测试者没有就应用达成共识，系统的漏洞就会成倍增加。一个开发者可能想使用某大开发框架中的一个小特性，Hoffman假定。 那么开发者“为了一个小小的功能特性，向应用中引入了这个庞然大物，但是开发者却忘记关闭框架中许多其他的特性，”他说。

如果就这样把开发的应用程序发送到QA处，QA可能根本就不知道这些额外特性的存在。基于同样的原因，测试者也忽视了这些额外的特性。接下来，这个带有一整套未测试过的功能的应用，就这样发行了，Hoffman 说。黑客们发现这些漏洞就会利用它们发起攻击。

Hoffman又说，如果在软件开发生命周期的每个步骤都考虑到安全问题，并且各个不同的团队都能知道其他人正在做什么，就可以避免上述情形。 “我们可以谈论工具，但是需要彼此之间的沟通和理解，”他说。

Hoffman 建议增加现有的业务流程。“已经有一种机制让QA和开发者对话、让设计者和实施者对话。而且当QA正在制定其测试计划时，他们已经是在与开发部门沟通”他说。

至于测试团队， Sullivan建议安全测试者要“停止用户会采取的测试方式，而以黑客会采取的方式进行测试工作。”