ajax|安全|安全性导读】本文中，Ajax in Action 作家之一Eric Pascarello 谈论了关于 Ajax 安全方面的相关议题。  
  
  
Eric Pascarello 是 Ajax in Action " 的作家之一。Pascarello Penn 州立大学的 2002 毕业生，获得了机械工程学位。他也是 JavaRanch.com 上的知名人物。在这一次面谈中，他谈论 Ajax 安全方面的相关议题。  

Ajax 作为一种技术传达着使用者更为丰富的使用经验从而受到广泛的赞美。但是 XMLHttpRequest 的使用真的能确保安全? 

Eric Pascare： 人们在面对 Ajax 的时候往往就是看到一个在网页上表演魔术的被称为 XMLHttpRequest 的东西，而且他们认为这东西能完美的弥补安全上的一些差漏。当我们在页上做简单的视野来源的时候, 我们见到的是我们调用,用来传送参数的页。任何使用 JavaScript 的人只要拥有最基本知识就能很容易地在每个页面上进行编写，改变数据。因此，攻击是很有可能的, 但是这并不需要害怕. 

人们可能会说，如果某人能如此容易的接管一个请求，这是多么可怕啊。但是这些人需要了解 XMLHttpRequest 并不比普遍的技术容易被破坏。你能想象出它在另外的框架被调用的一种形式。表现出来就像是在页上形成的标签和隐藏的本文领域。通过一个正常的 HTML 格式, 我们能抓取元素名字而且见到传送给服务器的参数。我们能看行动属性而且见到我们正在调用数据的地方。正如同我们如何去认识 XMLHttpRequest 一样, 我们能在任何的网页上见到这一切。 

为什么说在服务器上做确认是非常重要的? 

Pascarello： 我们能利用本地属性改变浏览器上相对页面上的内容。不完整的，只读的, 隐藏的。但可能在客户端看来这也许根本不过是一个笑话。输入 javascript：document.FormName.ElementName.disabled="false";void(0) 后可以见到那些很可能被改变的领域是否是受到保护了的。这就是为什么任何经验丰富的开发者告诉你需要在服务器上做确认的原因。你无法确定那些你收到的数据从何而来。我能在我的桌面上写一种形式且使它遵从你所看到的页。这可能是一个电脑黑客尝试注射 SQL 指令划除你的数据。或是在JavaScript 中加入有害的代码。数据是不安全的，这一点得随时保持警惕。 

对于 Ajax 是否遇到一些不同于以往的威胁? 

Pascarello：Ajax所遇到的一些安全上的威胁一个开发者可能不了解。如果他们只是单纯的设计和实现以 Ajax 为基础的控制，他们可能很容易地导致他们的服务器崩溃。想像一个网页同时有1,000个使用者。他们的服务器能够在这样的负荷下处理以正常形式进入的数据。他们一起在客户端或者服务器身上没有做存储而直接进入数据库得到数据的控制。现在我们1,000个人将这样的请求重复十次。那这个服务器将达到10倍于以往的运算。如果服务器不能够处理它, 他们可能会漏掉或者根本就完全停止了。 

你注意到利用 JavaScript 在跨领域请求时所受到的攻击。你能对此做相应解释吗? 

Pascarello： 对于安全方面的问题真正让我吃惊的是开发者想要能够用 JavaScript 运行跨领域的请求。现在有一些好的理由去做这, 像是Web服务这些, 但是大部份还只能在本地上作为服务器端的代码。一般的使用者设定的 JavaScript 不能够操纵或者访问来自另外的一个领域的数据。开发者想要能够做这,他们必须明确能够不需要在领域外工作的目的。这样的安全设定给我们带来很大的保护，免于我们打通另外的框架遭到攻击，或者是利用 XMLHttpRequest抓我们的电子邮件,存入银行的数据,卡片数据， eBay 帐户以及其他。我确定这些人也是真的不想这样。在一个不熟悉的地方调用数据，并交换代码，可是，你会真的信赖正在调用数据的安全么? 对一个罐头火腿肉新品种的广告说hello? 

看 Samy 在 MySpace.com 上写的 Ajax 蠕虫 [2005 年十月,一个青少年 "Samy" 在MySpace 发布了一条自我繁殖的 Ajax 蠕虫 ]。这对于主要使用 Ajax 技术的网站是一种大的安全威胁。你得了解蠕虫的作者藉由服务器端的安全检查将病毒注入到一个网页。现在他可能已经可以很容易地改变密码，在页面上抓取使用者数据。XMLHttpRequest相对于其他的并不是更容易受到攻击，相对而言，你所需要担心的依旧是一些常规的问题。 

Pascarello为 Ajax 安全性所提出的经验法则： 

如果你使用身份验证, 确定你在请求页上检查!  
为 SQL 注入检查。  
为 JavaScript 注入检查。  
保留商务逻辑在服务器上!  
不要假设每个请求是真正的!  
确认检查数据!  
审查请求的数据而且确定它是正确的。 
  <