web開發者不會注意到由 “AJax（Asynchronous JavaScript And XML）”所帶來的激情。不費力氣就能創建像Google Suggest那樣的智能網站或者像Gmail那樣基於Web的應用程序，這在很大程度上要歸功於這種技術。然而，伴隨著AJAX應用程序的發展，我們發現了它的一些不足之處，我們發現它的安全漏洞也在逐漸變大，就像慢慢地把基於AJax的站點放入了一顆定時炸彈中。
AJax的好處 在當年“Web應用程序”的美好時代，事情非常簡單。你填寫了一個表單，點擊“提交”按鈕，然後當前屏幕就消失了，等待一小會兒後你就轉入到了下一個頁面。今天的狀況已經不是這樣的了，用戶需要的是一種就像任何桌面應用程序那樣流暢、快捷和人性化的Web體驗。
AJax經常是和DHtml（Dynamic Html）一起協作的，它的順利執行需要允許網頁中的JavaScript代碼和web服務器在後台無縫通訊。比方說，當你開始在Google Suggest的搜索框中輸入東西時，web頁面就和服務器在後台開始交換數據，然後會給出一些你可能需要的詞條等。所有的這一切都不需要頁面刷新或者按下任何按鈕。同樣這也就是像Gmail那樣的應用程序怎麼能對實時拼寫檢查做的那麼好的原因。
AJax怎樣工作 AJax復雜的原理已經超出了今天所要闡述的范圍，這裡只簡單描述一下。你的頁面上的JavaScript代碼能夠在不依賴於用戶的情況下和你的Web服務器取得聯系。這裡面起核心作用的就是Javascript的XMLHttpRequest對象，這個對象能夠被就像用戶敲擊鍵盤或者時鐘事件在後台或者異步觸發（也就是術語異步JavaScript和XML）。
如果你在Google Suggest中輸入“AJax”後，就會得到像我輸入後得到的服務器請求一樣：
1. www.google.com/complete/search?hl=en&JS=true&qu=aj
2. www.google.com/complete/search?hl=en&JS=true&qu=aja
3. www.google.com/complete/search?hl=en&JS=true&qu=AJax
在這個術語中的XML部分有一點會引起人們的誤解，其實這一部分是沒有任何意義的。它是從Javascript對象得來的名字，同時許多AJax風格的應用程序使用了XML，這個對象能夠就任何事務向服務器發出一個請求。甚至JavaScript代碼本身也能夠被取回和評估。繼續完成我的輸入“AJax example”，將會從Google的服務器產生下面的回應：
sendRPCDone(frameElement, "ajax example", new Array("ajax example", "AJax examples"), new Array("153,000 results", "177,000 results"), new Array(""));
這將會給你一些關於強大的AJax的暗示吧，它具有在運行中（on the fly）把新的JavaScript代碼加入到浏覽器中的能力。然而，最優化的方法看起來好像束縛了XML協定。舉個例子說明一下，比如Google產生了下面的這個東西：
AJax example
153,000
AJax examples
177,000
顯然，你可以在一個合適的表單中解釋這些XML數據，但我們要感謝JavaScript，它確實能夠在一些非常典型的限制條件下和大量討厭的IE bug環境裡非常好的處理XML對象。
為了幫助你理解一些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開始嘗試他的新想法時，他會逐漸嘗試增加更多新的功能，完全忽視測試的需要。