一、 引言

在XMLHttpRequest對象和AJAX給用戶和開發者帶給巨大好處的同時,也許還有一些問題你沒
有考慮到-但是的確到了值得引起每個人注意的時候了。

甚至非常討厭的人也都喜歡XMLHttpRequest，因為它提供給程序員真正夢想的功能。也正
是因為有了這樣的新技術，Web應用軟件開始變得具有象桌面應用軟件相似的行為。如今，
問題總是象"假定為……"那樣地簡單，這把幼稚的終端用戶從需要了解服務端、客戶、回
寄和提交按鈕-"提交？提交給什么東西？"-等一系列問題的苦海中解脫出來。

最近,無數可怕的案例爆炸式出現在Web上，它們充分說明為什么遠程腳本(或稱"AJAX"，如
果你喜歡的話)是自從單像素點gif技術以來最偉大的事情。事實上,成串的酷極的、有用的
應用軟件正日益增長,象站點Flickr,Google Maps,The WebORB Presentation Server等所
宣傳的那樣。

這些站點和另外許多地方大肆宣傳AJAX的能力。公正地說,這種技術在提高在線操作的質量
方面的確有相當的潛力來。然而,盡管它有許多的優點，但是這個神圣的Web通訊大杯中嗅
起來仍然有一股奇怪的味道；就象擺動在我們面前的啤酒和巧克力,仍有一個邪惡的方面存
在于其中-表面上看起來是多么地純潔和天真。

這種潛在的邪惡存在于用戶熟悉的操作界面背后的重要的功能性差距之中。你們當中許多
人可能已經使用互聯網近10年了，并且你知道它怎樣工作：你到處點按鼠標，填充表單，
修改你的輸入；當做完所有這些，你可以點擊提交按鈕。你們都了解這些精華經驗-它們從
因特網的一代傳遞到新的一代,如:"不要點按提交按鈕兩次-否則，表單可能要提交兩次"或
"等待稍微長一些時間，它正在處理"或"在你提交了表單后,不要點按'向后'按鈕"，等等。


但是既然現在AJAX已登堂入室，那么你可以把基本知識拋出窗外。簡直是"什么東西都可以
"-突然間出現一種新的可被跟蹤的數據-可以在任何時候發送出去，而不需要用戶的任何了
解，甚至用戶還不了解這竟然是可能發生的。每一次擊鍵，每一個鼠標移動，每一下點按
鼠標，每一次停頓，都能被捕獲并發送到Web服務器，而你對此無能為力。

二、 XMLHttpRequest:利與弊

就象許多技術存在利弊一樣，產生這種技術的目的是為了利用其優點。直到如今，XMLHtt
pRequest帶給人們如此多的優點，諸如不需回滾的輸入校驗，文本區域的拼寫檢查以及Gm
ail等等，簡直幾乎為人們捧之為神圣?；贏JAX技術創建的接口使用起來非常有趣，甚至
編碼更有趣味。簡直很難令人相信，這樣一種神奇的技術竟然能夠做錯事情。

但是，即使還沒有發現存在巨大的安全漏洞，該XMLHttpRequest也有可能因為其外在的優
雅而失敗。它很可能會失敗在"用戶輪廓圖"-用于更好的描述之目的-的應用之中。當前,用
戶輪廓圖幫助Web站主偵探趨勢,跟蹤網頁瀏覽習慣并幫助消除使用性問題。但是直到現在
，開發人員還只能分析寄回的數據-用戶決定讓服務器取得的數據并為提交后得到處理而高
興。

但是通過一種微秒的手段，這種能量平衡會發生易位。通過使用AJAX技術，一個用戶的行
為可以被持續地并小心地監控。因為它能被做,所以它將被做；這就帶給人們一個相當頭疼
的問題，而不僅僅是浪費帶寬、成兆的垃圾信息以及更慢的網頁裝載次數的問題。

設想一下，這里僅是舉例說明問題，你把一部新購買的iPod掉到地上去了，結果它停止了
工作。抱著希望得到免費的替換的想法，你發了一封電子郵件給Apple公司的售后服務部，
信中說："我剛剛買了一個新牌子的iPod。我不小心把它掉到了樓梯上，它突然停止工作了
。"之后，你決定刪去第二句以支持你的理由。太晚了！如果該網站使用了AJAX技術,你的
反映可能早就被殺死在了你的抱怨桌前！

或者-一個更惡意破壞性的例子-請考慮這種情況：大多數人都有一個或兩個用戶名/口令組
合以用于他們的"并不重要"的站點，如新聞站點、博客、論壇等。他們可能還有幾個保留
的這種組合以用于更敏感的網站-銀行業務，Web郵件和工作帳號等。在一個給定頁面中輸
入不正確的登錄細節是非常普通和極易犯的錯誤。雖然他們以前形成的習慣的影響應對此
負主要責任，但是在人們點擊提交按鈕前常常是已經意識到他們所做的事情的。

不幸的是，一個AJAX擊鍵記錄程序實現起來相當麻煩。使用如此的一個擊鍵記錄程序,就可
以用代碼來收集不正確的登錄嘗試，然后針對一系列"重要的"站點對之進行試驗-當然，也
可以使用XMLHttpRequest對象。

三、 "惡意"暗示

公平地說,上面引用的大多數的"惡意"應用軟件都能被合理地加以處理，即使在XMLHttpRe
quest技術出現以前。的確，request對象是一種相對于以前的IFrame技術更為優雅的成功
提交表單數據的方法。但是，XMLHttpRequest以一種更為自然的方式工作，這種方式簡直
可以能使客戶端與服務器端的交互差別逐漸消失。

具有諷刺意味的是，直到最近，隨著Firefox Web瀏覽器的不斷流行，才使得較多用戶真正
了解到可以由Web客戶端儲存和控制的信息的深度和廣度。隨著廣泛采用象Greasemonkey，
Web開發者擴展以及cookie編輯器這樣的工具，人們比以往任何時候更為確信，如果問題發
生在客戶端，那么責任一般應歸咎于該用戶。

但是現在,即使象我們這樣狂妄的人也不再只是右擊鼠標，看一下源代碼，然后就能確信正
在發生的事情了。請考慮下面的OnReadyStateChange JavaScript語句，運行它是為了響應
一個XMLHttpRequest:

xmlReq.onreadystatechange =
{
if( xmlReq.readyState == 4 )
eval( xmlReq.responseText );
}

上面的代碼執行包含在來自于XMLHttpRequest的響應中的JavaScript代碼。換句話說,有可
能出現這種情況：即使一個頁面加載完畢，也有可能在后臺再進行添加或修改JavaScript
函數和代碼！因此就算你觀察該頁面代碼的源代碼-它可能發送了鍵擊或鼠標移動事件到W
eb服務器,你也無法確信你所見的代碼是當前執行的唯一代碼。把這些特征與一些令人膽戰
心驚的困惑結合起來，那么你可以看到，惡意目的與XMLHttpRequest對象相結合，怎么不
能實現Web客戶的信息竊取！

四、 還不確信？

你還不感到害怕并因此而憤怒嗎？還不準備憤起并刪去你的瀏覽器中的XMLHttpRequest代
碼嗎？那么，好，也許本文強勢的措詞論證會嚇倒了你；那么在游戲"Fonzie尋寶記"（Th
e Search For 's Treasure。譯者注：在GOOGLE中輸入這幾個關鍵詞，你肯定能找到這個
在線文本游戲，本人沒有深入試驗。難道這個小東西那么可愛的面孔下竟然埋伏著上面所
述的那么恐怖的……）中-你能夠救出Fonzie嗎？

通過使用很有藝術的命令行接口,穿過充滿文本的門廳尋找丟失的Arthur 'Fonzie' Fonza
relli寶藏。祝你幸運，但是請記住…雖然它看上去就象無危害的客戶交互-你每作四次移
動，該游戲通過XMLHttpRequest對象發送一個請求到服務器上并保存你的移動。永遠記住
：不要做一個印刷工（Don't make a typo）；不要嘗試一些愚蠢的東西如"eat jukebox"

；不要在游戲中輸入一個用戶名和口令字；否則……