谈谈AJAX的安全性及AJAX安全隐患
http://tech.ddvip.com 2007年06月23日 社区交流
内容摘要：AJAX经常是和DHTML（Dynamic HTML）一起协作的，它的顺利执行需要允许网页中的JavaScript代码和web服务器在后台无缝通讯。比方说，当你开始在Google Suggest的搜索框中输入东西时，web页面就和服务器在后台开始交换数据，然后会给出一些你可能需要的词条等。所有的这一切都不需要页面刷新或者按下任何按钮。同样这也就是像Gmail那样的应用程序怎么能对实时拼写检查做的那么好的原因。
6.服务器端访问控制：使用JavaScript程序来触发AJAX经常会掩饰一些显而易见的编码错误，服务器端访问控制就是一个例子。假设Max想参考你上次游览的一个详细目的地来为你提供你中意的旅馆，他可能会是像下面这样：
showprevioushotels.aspx?userid=12345&destination=UK
这当然是非常好的，但是如果一个恶意用户把URL改成了如下所示该怎么办呢：
showprevioushotels.aspx?userid=12346&destination=%
他们会得到其他人最喜爱的旅馆吗？（注意：％在SQL语句中是通配符）。无疑，这是一个没有什么危害的例子，但是Max应该使用session、cookie或者其它符号形式来确保数据能并且只能发送到正确的用户那里。它们可能仅仅是数据的一小部分，但它们可能就是最重要的一小部分。
7.服务器端验证：实际上这里有两个问题。第一，AJAX控制经常被用来在用户最后提交到服务器之前的输入验证。这麻痹了Max，使Max有一种虚假的安全感，原因是他建立了称作alloweddestinations.php的函数，根据用户的ID来决定他们能够到达的正确目的地。
因为这是一个服务器端的检查，当这个页面最后被提交的时候他不必再次为在服务器上做检查而烦恼，这里我们假定不会有恶意的用户暗中破坏从alloweddestinations.php的响应或者破坏对服务器最后的请求。
AJAX控制可以比用户自己更仔细验证用户的输入，但是他们还是经常在服务器上最后做一次验证。
AJAX验证的第二个问题就是控制本身会受到验证漏洞的影响。这里再次强调一下，URL通常是隐藏着的，所以也会经常忘掉它。举例说明一下，也许我可以使用SQL Injection来对刚才的脚本进行攻击，如下所示：
showprevioushostels.aspx?userid='; update users set type='admin' where userid=12345;--
责编：豆豆技术应用