您好,歡迎來電子發(fā)燒友網(wǎng)! ,新用戶?[免費注冊]

您的位置:電子發(fā)燒友網(wǎng)>電子百科>語音視頻>安防監(jiān)控>

CGI安全問題專題

2010年01月14日 09:54 www.ttokpm.com 作者:佚名 用戶評論(0

CGI安全問題專題

在 計算機 領域——尤其在Internet上——盡管大部分Web 服務 器所編的程序都盡可能保護自己的內(nèi)容不受侵害,但只要CGI腳本中有一點安全方面的失誤--口令文件、私有數(shù)據(jù)、以及任何東西,就能使 入侵 者能訪問 計算機 。遵循一些簡單的規(guī)則并保持警惕能使自己的CGI腳本免受侵害,從而可以保護自己的權益。 1. 腳本和程序 在開始決定采用何種語言編寫CGI腳本時應考慮幾個因素,其中之一應是安全性。Shell 腳本,Perl程序和C可執(zhí)行程序是CGI腳本最常采用的形式,從安全性角度來說每種都備有優(yōu)缺。盡管沒有哪一種是最好的--基于其他方面的考慮,如速度和可重用性--每種都有實用的領域。 Shell腳本一般用于小的、快速的甚至可以用完就不要的CGI程序,因此,編寫它們時常常不考慮安全性。這種疏忽可以導致一些缺陷,使得僅對系統(tǒng)具有一般 知識 的人也能進入系統(tǒng)任意走動。 盡管Shell CGI 程序最容易寫,甚至只需拼湊一下即可,但控制它們卻很困難,因為它們一般是通過執(zhí)行外部的其他程序來完成工作的。這就導致一些可能的隱患,CGI 程序會繼承任何它使用的程序的安全問題。 例如,常用UNIX實用程序 awk對于它能處理的數(shù)據(jù)的數(shù)量有一些相當嚴格限制。如果在CGI腳本中使用awk,那么該程序也就有了同樣的限制。Perl比Shell腳本更進一步。Perl用于CGI 編程 有很多優(yōu)點,并且相當安全。但Perl能給CGI 作者提供足夠的靈活性從而導致對安全性的錯誤感覺。例如,Perl是解釋型的。這意味著它實際在調(diào)用時是先編譯,然后每次執(zhí)行一步。這就很容易使得不正確的用戶數(shù)據(jù)被包括進來作為 代碼 的一部分,從而錯誤地進行解釋,形成程序中止原因。 最后談談C。C迅速成為標準應用開發(fā)語言,幾乎所有的UNIX和windows NT系統(tǒng)都是用它開發(fā)的。從安全性的角度來看C 似乎是很不錯,但由于它的流行性,它的好幾種安全性問題已廣為人知,而這些問題也能很容易地被人利用。 例如,C 對串處理非常差。它不做任何自動的定位或清理而讓 編程 者自己處理所有事情。在處理串時,大部分C 程序員都是簡單地建立一個預定義的空間并希望它足夠大以便處理用戶輸入的任何內(nèi)容。 當然,Shell腳本、Perl和C 不是僅有的編寫CGI腳本語言。實際上,任何可以按預定義的方式與Web 服務 器進行交互的 計算機 語言都可以用于編寫CGI程序。在UNIX和Windows NT 服務 器上,數(shù)據(jù)是通過環(huán)境變量和標準輸入(stdin) 傳給腳本的,所以任何能從這兩種數(shù)據(jù)源讀取并寫入標準輸出(sidout)的語言都能用于創(chuàng)建CGI:awk、FORTRAN、C++、Basic和COBOL,等。windows的程序員可以使用流行的Visual Basic,這意味著有經(jīng)驗的VB程序員不必去學一門新語言。Macintosh使用AppleEvents、和AppleScript與CGI程序進行通信,所以任何可以讀寫這兩者的語言都可使用。 不過,Shell腳本(不管使用那種Shell)、Perl和C仍是最流行為的編寫CGI腳本的語言。這并不是說必須使用它們了只是說大部程序的庫——即大部分經(jīng)過測試的安全的庫——都是用這三種語言編寫的。如果自己來選擇CGI 編程 語言,最好是借鑒前人的經(jīng)驗。 2. 誰也不信 幾乎所有的CGI 安全問題都來自與用戶的交互。接收來自外部數(shù)據(jù)源的輸入之后一個簡單的、可預見的CGI程序突然向多方向伸展,每個方面都可能有最小的縫隙使得“黑客”可以溜進來。正是與用戶的這種交互——通過表單或文件路徑——才給予了CGI 腳本這種能力,但同時也使得它們成了運行在Web 服務 器上的最潛在的危險部分。 編寫安全的CGI 腳本很大程度上是創(chuàng)造性和妄想的結合。編寫者必須有足夠的創(chuàng)造性才能想到用戶使用的,不管是無意地還是別的所有的可能隱含導致問題的發(fā)送數(shù)據(jù)的方式。而且必須有點妄想,因為有可能不知道什么時候、什么地方、他們將會一一加以試驗。 2.1 兩種導致問題的方式 當用戶登錄進入Web 站點并開始進行交互訪問時,他們能以兩種方式惹麻煩。一種是不遵守規(guī)則,歪曲或違反頁面中建立的每個限制或約束;另一種方式是按要求去做。 大部分CGI 腳本是作為HTML表單的后臺運行的,負責處理由用戶輸入的信息并提供某種定制的輸出。因為在這種情況下,大部分CGI 腳本編寫時都等待某種特殊格式的數(shù)據(jù)。它們期望用戶的輸入能匹配收集并發(fā)送信息的表單。不過事情并不總是這樣。用戶可以有許多種辦法繞過這些預定義的格式而給腳本發(fā)送一些看起來是隨機的數(shù)據(jù)。CGI 程序必須對此有所準備。 其次,用戶可以給CGI 腳本發(fā)送所期望的數(shù)據(jù)類型,按預期的形式在表單中填入每個字段。這種類型的提交可以是想像中的來自某個與站點交互的無意的用戶,也可能來自某個惡意的“黑客”,憑借他有關操作系統(tǒng)和Web 服務 器 軟件 的 知識 并利用常見的 編程 錯誤。這些 入侵 ,表面上一切都正常,卻是最危險的、最難檢測出來。Web 站點安全性依賴干這種 入侵 的防止。 2.2 不要相信表單數(shù)據(jù) 在CGI 編程 中最常見的安全失誤就是相信從表單傳到腳本的數(shù)據(jù),用戶是未知的一大堆人,他們總能找到一些 編程 人員從來沒想到過的發(fā)送數(shù)據(jù)的方法--而且是程序員認為幾乎不可能的方法。 腳本必須對這些加以考慮。例如,下面這些情形都是可能的: 1)從一組單單選按鈕中選擇的結果可能不是表單中提供的選項之一。 2)來自某個文本字段的數(shù)據(jù)長度可能大于MAXLENGTH字段允許的長度。 3)字段本身的名字可能與表單中指定的不相符。 2.3 不合理數(shù)據(jù)的來源 因—些無意的或是有意的原因,導致自己的腳本接收到不知道如何去處理的數(shù)據(jù),有可能導致非預期的——同時很危險的——行為。 下面的 代碼 實現(xiàn)了一種表單并向某個搜索yahoo! 數(shù)據(jù)庫 的CGI腳本送垃圾。該腳本設計得很好并且很安全,因為它忽略了不認識的輸入。

Enter your name,first then last: $input _ Max) { return(0,input too big); } #Read the input from QUERY _ STRING return(1,$ENV{\\\QUERY _ TRING\\\}); } elsif ($input _ Method eq POST) { #POST local($input _ Size)=$ENV{\\\CONTENT _ LENGTH\\\}; local($input _ Data); #Check the size of the input if ($input _ Size>$input _ Max) { return(0,Input too big); } #Read the input from stdin unless (read(STDIN,$input _ Data,$input _ Size)) { return(0,Could not read STDIN); } return(1,$Input _ Data); } #Unrecognized METHOD return (0,METHOD not GET POST); } 總而言之,腳本應該不對接收的表單數(shù)據(jù)進行假設,應盡可能預計意料之外的情形并正確地處理不正確的或錯誤的輸入數(shù)據(jù)。在使用數(shù)據(jù)之前應按盡可能多的方式測試它拒絕不合理的輸入并打印一條錯誤消息如果某項出錯或漏了應自動選擇一個缺省值甚至可以試圖對輸入進行編碼以成為程序的合理的輸入。選擇哪種方式依賴于自己想花費多少時間和精力,不過記住永遠也不要盲目接收傳給CGI腳來的所有信息。 2.5不要相信路徑數(shù)據(jù) 用戶能修改的另一類型數(shù)據(jù)是PATH _ INTO的 服務 器環(huán)境變量。該變量由CGI URL中緊跟在腳本文件名之后的任何路徑信息填充的。例如,如果foobar.sh是一個CGl shell腳本,那么當foobar.sh運行時,URL http://www.server.com/cgi-bin/foobar.sh/extra/path/info 將導致/extra/path/info被放進PATH _ INFO環(huán)境變量中。 如果使用這個PATH _ INFO環(huán)境變量,就必須小心地完全驗證它的內(nèi)容。就像表單數(shù)據(jù)能以許多種方式被修改一樣,PATH _ INFO也可以修改。盲目地根據(jù)PATH _ INFO的中指定的路徑文件進行操作的CGI腳本可能會讓惡意的用戶對 服務 器造成傷害。 例如,如果某個CGI腳來設計用于簡單地打印出PATH _ INFO中引用的文件,那么編輯該CGI URL的用戶就可以讀取機器上的幾乎所有文件,如下所示: #!/bin/sh #Send the header echo Conext-type:text/html echo #Wrap the file in some HTML #!/bin/sh echo
File
echoHere is the file you requested:
\\n cat $PATH _ INFO echo 
盡管在用戶只單擊預定義的鏈接(即 http://www.server.com/cgi-bin/foobar.sh/public/faq.txt )時,該腳本正常工作,但是一個更有創(chuàng)造性的(或惡意的)用戶可能會利用它接收 服務 器上的任何文件。如果他想進入 http://www.server.com/cgi-bin/foobar.sh/etc/passwd ,前面的腳本會很高興地返回機器的口令文件——這可是不希望發(fā)生的事。 另一種安全得多的方式是在可能時使用PATH _ TRANSLATED環(huán)境變量。不是所有的 服務 器都支持該變量,所以腳本不能依賴于它。不過如果有的話,它能提供完全修飾的路徑名,而不是像PATH _ INFO提供的相對URL。 不過在某種情形下,如果在CGI腳本中使用PATH _ TRANSLATED的話,則可以訪問通過瀏覽器不能訪問到的文件。應該知道這點及它的應用。 在大部分UNIX 服務 器上,htaccess文件可以位于文檔樹的每個子目錄,負責控制誰能夠訪問該目錄中的特殊文件。例如它可以用于限制一組Web頁面只給公司雇員看。 雖然 服務 器知道如何解釋.htaccess,從而知道如何限制誰能還是不能看這些頁面,CGI腳本卻不知道。使用PATH _ TRANSLATED訪問文件樹中任意文件的程序有可能碰巧覆蓋了 服務 器提供的保護。 無論使用PATH _ INFO還是PATH _ TRANSLATED,另一個重要的步驟是驗證路徑以確保它或者是一個真正的相對路徑或者是腳本認可的幾個準確的、預知的路徑之一。對于預定的路徑,腳本將簡單地將提供的數(shù)據(jù)與認可可以使用的文件的內(nèi)部清單進行比較,這就是說在增加文件或修改路徑時必須重新編譯腳本,但安全性卻有了保障。只允計用戶選擇幾個預定義的文件而不允許用戶指定實際的路徑和文件名。 下面是處理訪問者提供的路徑時應遵循的一些規(guī)則。 1)相對路徑不以斜線開頭。斜線意味著相對于根或絕對路徑。如果有的話,CGI腳本也是很少需要訪問Web根之外的數(shù)據(jù)。這樣它們使用的路徑就是相對于Web根目錄,而不是絕對路徑。應拒絕任何以斜線開始的內(nèi)容。 2)在路徑中單個點(.)和兩個點(..)的序列也有特殊含義。單點意味著對對于當前目錄,而雙點意味著相對于當前目錄的父目錄。聰明的黑客可以建立象../../../etc/passwd這樣的串逆向三層,然后向下進入/etc/passwd文件。應拒絕任何包含雙點序列的內(nèi)容。 3)基于NT 服務 器使用驅動器字母的概念來引用磁盤卷。包含對驅動器的引用的路徑都以一個字母加上一個冒號開頭。應拒絕任何以冒號為第二個字符的內(nèi)容。 4)基于NT的 服務 器還支持Univesal Naming Conventions(UNC)引用。一個UNC文件規(guī)格指定機器名和一個共享點,其余部分與指定機器上的指定的共享點有關。UNC文件規(guī)格總是以兩個反斜線開頭。應拒絕任何UNC路徑。

非常好我支持^.^

(0) 0%

不好我反對

(0) 0%

相關閱讀:

( 發(fā)表人:admin )

      發(fā)表評論

      用戶評論
      評價:好評中評差評

      發(fā)表評論,獲取積分! 請遵守相關規(guī)定!

      ?