CGI 安全問題

    在計算機領域——尤其在Internet上——盡管大部分Web服務器所編的程序都盡可能保護自己的內容不受侵害，但只要CGI腳本中有一點安全方面的失誤--口令文件、私有數據、以及任何東西，就能使入侵者能訪問計算機。遵循一些簡單的規則并保持警惕能使自己的CGI腳本免受侵害，從而可以保護自己的權益。

1. 腳本和程序

    在開始決定采用何種語言編寫CGI腳本時應考慮幾個因素，其中之一應是安全性。Shell 腳本，Perl程序和C可執行程序是CGI腳本最常采用的形式，從安全性角度來說每種都備有優缺。盡管沒有哪一種是最好的--基于其他方面的考慮，如速度和可重用性--每種都有實用的領域。

    Shell腳本一般用于小的、快速的甚至可以用完就不要的CGI程序，因此，編寫它們時常常不考慮安全性。這種疏忽可以導致一些缺陷，使得僅對系統具有一般知識的人也能進入系統任意走動。

    盡管Shell CGI 程序最容易寫，甚至只需拼湊一下即可，但控制它們卻很困難，因為它們一般是通過執行外部的其他程序來完成工作的。這就導致一些可能的隱患，CGI 程序會繼承任何它使用的程序的安全問題。

    例如，常用UNIX實用程序awk對于它能處理的數據的數量有一些相當嚴格限制。如果在CGI腳本中使用awk，那么該程序也就有了同樣的限制。Perl比Shell腳本更進一步。Perl用于CGI編程有很多優點，并且相當安全。但Perl能給CGI 作者提供足夠的靈活性從而導致對安全性的錯誤感覺。例如，Perl是解釋型的。這意味著它實際在調用時是先編譯，然后每次執行一步。這就很容易使得不正確的用戶數據被包括進來作為代碼的一部分，從而錯誤地進行解釋，形成程序中止原因。

    最后談談C。C迅速成為標準應用開發語言，幾乎所有的UNIX和windows NT系統都是用它開發的。從安全性的角度來看C 似乎是很不錯，但由于它的流行性，它的好幾種安全性問題已廣為人知，而這些問題也能很容易地被人利用。

    例如，C 對串處理非常差。它不做任何自動的定位或清理而讓編程者自己處理所有事情。在處理串時，大部分C 程序員都是簡單地建立一個預定義的空間并希望它足夠大以便處理用戶輸入的任何內容。

    當然，Shell腳本、Perl和C不是僅有的編寫CGI腳本語言。實際上，任何可以按預定義的方式與Web服務器進行交互的計算機語言都可以用于編寫CGI程序。在UNIX和Windows NT服務器上，數據是通過環境變量和標準輸入(stdin) 傳給腳本的，所以任何能從這兩種數據源讀取并寫入標準輸出(sidout)的語言都能用于創建CGI:awk、FORTRAN、C++、Basic和COBOL，等。windows的程序員可以使用流行的Visual Basic，這意味著有經驗的VB程序員不必去學一門新語言。Macintosh使用AppleEvents、和AppleScript與CGI程序進行通信，所以任何可以讀寫這兩者的語言都可使用。

    不過，Shell腳本(不管使用那種Shell)、Perl和C仍是最流行為的編寫CGI腳本的語言。這并不是說必須使用它們了；只是說大部程序的庫——即大部分經過測試的安全的庫——都是用這三種語言編寫的。如果自己來選擇CGI編程語言，最好是借鑒前人的經驗。

2. 誰也不信

    幾乎所有的CGI 安全問題都來自與用戶的交互。接收來自外部數據源的輸入之后一個簡單的、可預見的CGI程序突然向多方向伸展，每個方面都可能有最小的縫隙使得“黑客”可以溜進來。正是與用戶的這種交互——通過表單或文件路徑——才給予了CGI 腳本這種能力，但同時也使得它們成了運行在Web服務器上的最潛在的危險部分。

    編寫安全的CGI 腳本很大程度上是創造性和妄想的結合。編寫者必須有足夠的創造性才能想到用戶使用的，不管是無意地還是別的所有的可能隱含導致問題的發送數據的方式。而且必須有點妄想，因為有可能不知道什么時候、什么地方、他們將會一一加以試驗。

2.1 兩種導致問題的方式

    當用戶登錄進入Web 站點并開始進行交互訪問時，他們能以兩種方式惹麻煩。一種是不遵守規則，歪曲或違反頁面中建立的每個限制或約束;另一種方式是按要求去做。

    大部分CGI 腳本是作為HTML表單的后臺運行的，負責處理由用戶輸入的信息并提供某種定制的輸出。因為在這種情況下，大部分CGI 腳本編寫時都等待某種特殊格式的數據。它們期望用戶的輸入能匹配收集并發送信息的表單。不過事情并不總是這樣。用戶可以有許多種辦法繞過這些預定義的格式而給腳本發送一些看起來是隨機的數據。CGI 程序必須對此有所準備。

    其次，用戶可以給CGI 腳本發送所期望的數據類型，按預期的形式在表單中填入每個字段。這種類型的提交可以是想像中的來自某個與站點交互的無意的用戶，也可能來自某個惡意的“黑客”，憑借他有關操作系統和Web 服務器軟件的知識并利用常見的編程錯誤。這些入侵，表面上一切都正常，卻是最危險的、最難檢測出來。Web 站點安全性依賴干這種入侵的防止。

2.2 不要相信表單數據

    在CGI 編程中最常見的安全失誤就是相信從表單傳到腳本的數據，用戶是未知的一大堆人，他們總能找到一些編程人員從來沒想到過的發送數據的方法--而且是程序員認為幾乎不可能的方法。

    腳本必須對這些加以考慮。例如，下面這些情形都是可能的:

1)從一組單單選按鈕中選擇的結果可能不是表單中提供的選項之一。

2)來自某個文本字段的數據長度可能大于MAXLENGTH字段允許的長度。

3)字段本身的名字可能與表單中指定的不相符。

2.3 不合理數據的來源

    因—些無意的或是有意的原因，導致自己的腳本接收到不知道如何去處理的數據，有可能導致非預期的——同時很危險的——行為。

    下面的代碼實現了一種表單并向某個搜索yahoo！數據庫的CGI腳本送垃圾。該腳本設計得很好并且很安全，因為它忽略了不認識的輸入。

 

Enter your name，first then last:
 
I

    也許用戶碰巧(或者意識地)將URL編輯為這個CGI腳本。當瀏覽器向CGI程序提交數據時，要簡單地將輸入表單中的數據連到CGI的URL上(用于GET METHODS)，就像用戶可以很容易地將Web頁面地址輸入到他的瀏覽器一樣，用戶也可以自己修改發送給這個腳本的數據。

     例如，當單擊表單上的Submit按鈕時，Netscape將一個長串字符放入Location字段，該串由CGI的URL后接一串數據組成，大部分看起來像表單中定義的NAMES和VALUES。如果愿意的話，可以自由地編輯Location字段的內容并按自己的意愿修改數據:增加表單中沒有的字段，擴展由MAXLENGTH選項限制的文本數據，或者幾乎任何對象。以下顯示了某CGI腳本預期從表單中提交的URL。

    用戶可以修改同一URL，CGI腳本仍被調用，但現在接收的是非預期的數據。為了保證安全，該腳本應該在編寫時就設計為能將這種輸入識別為不被要求的數據并加以拒絕。

    最后，某個有野心的"黑客"也許會寫一個程序連到Web上的服務器并假裝是一個Web瀏覽器。該程序可能做一些任何一個真正的web瀏覽器從未做過的事，例如給CGI腳本發送成百兆字節的數據。如果CGI腳本不限制從POST METHOD讀取數據，那怎么辦？它有可能會崩潰，也許允許那個崩潰了系統的人訪問系統。

2.4 拒絕不合要求的表單數據

    CGI腳本可以有幾種方式拒絕接收提交給它的非預期的輸入。編寫CGI時應該使用其中一些技巧或所有這些技巧。

    首先，CGI 腳本應設置接收多少數據的限制，不僅限制整個提交，也限制提交中的每個NAME/VALUE對。例如，CGI腳本讀取POST METHOD，檢查CONTENT-LENGTH環境變量的大小來確定某輸入是不是合理的預期輸入。如果CGI 腳本設計接收的唯一數據是某人的姓名，那么如果CONTENT-LENGTH大于100字節，就應該有理由返回一個錯誤。沒有哪個合理的姓有那么長，通過設置限制，就能使腳本不再盲目地讀取發送給它的內容。

注意

    令人高興的是，不必擔心去限制通過POST方法提交的數據。GET是自限制的并且不會向腳本發送多于1KB的數據。服務器自動限制放人QUERY-STRING環境變量中的數據的大小，而這正是GET發送給CGI程序的信息。

    當然，"黑客"們可以很容易地將表單由GET改為PUT從而繞過這種內置的限制。至少，程序應該檢查一下數據是否是用預期的方法提交的;最好是能正確且安全地處理兩種方法。

    下一步，應保證腳本知道在接收到不能識別的數據時該怎么辦，例如，如果某表單要求用戶選擇兩個單選按鈕之一，腳本就不應該假設因為一個按鈕未被選擇，另一個就一定被選擇了。下面的Perl代碼就犯了這樣的錯誤:

if ($form_Data{"radio_choice"} eq "button_one"){
# Button One has been clicked }
else {
# Button Two has been clicked }

    這段代碼假定因為表單僅提供了兩個選項，而第一項未被選中，那么第二項就肯定被選中了。這不一定是真的。盡管前面的例子沒有什么害處，但在某些情況下這樣的假設可能很危險。

    CGI腳本應該能預期這種情形而相應地進行處理。例如，如果出現一些非預期的或"不可能"的情形，可以打印一個錯誤，如下所述:

If ($form_Data{"radio_choice"} eq "button_one") {
#Button One seleted }
elsif ($form_Data{"radio_choice} eq "button_two") {
#Button Two Selected }
else {
#Error }

    通過加入第二個if語句－－顯式檢查"radio_choice"實際上是"button_two"－－這樣腳本更安全了;它不再做假設了。

    當然，錯誤不一定是期望腳本在這些情形下生成的。有些腳本過于小心，驗證每個字段，即使是最輕微的非預期數據都生成錯誤信息，這樣往往很掃用戶的興。讓CGI 腳本識別非預期數據然后扔掉它，并且自動選擇一個缺省值也可以。

    另一方面，腳本還可幫助用戶糾正錯誤而不是簡單地發一條錯誤消息或設置一個缺省值。如果表單要求用戶輸入機密文字，腳本應能在進行比較之前自動跳過輸入中的空白字符。下面即是一個完成此功能的Perl程序片段。

$user_input =~ s/s//;
#Remove white space by replacing it with an empty string
if ($user_input eq $secret_Word) {
#Match! }

    最后，可以更進一步，讓CGI腳本能處理盡可能多的不同的輸入表單。盡管不可能預期到可能發送給CGI程序的所有內容，但對某個特定方面一般經常有幾種常用的方式，因而可以逐個檢查。

    例如，僅僅因為所寫的表單使用POST方法向CGI腳本提交數據，并不意味著數據必須按那種方法進來。應該檢查REQUEET_METHOD環境變量來確定是使用了GET還是POST方法并相應地讀取數據，而不是假定數據都是來自預期的標準輸入(stdin)。一個真正編寫成功的CGI腳本能接收無論使用什么方法提交的數據并在處理過程中很安全。以下程序清單即是用Perl編寫的一個例子。

    程序清單 CGI_READ.PL 一個充滿活力的讀取格式輸入的程序

#Takes the maximum length allowed as a parameter
#Returns 1 and the raw form data，or "0" and the error text
sub cgi_Read
{
local($input_Max)=1024 unless $input_Max=$_[0];
local($input_Method)=$ENV{@#REOUEST_METHOO@#);
#Check for each possible REQUEST_METHODS
if ($input_Method eq "GET") {
#"GET"
local($input_Size)=length($ENV{@#QUERY_STRING@#});
#Check the size of the input
if($input_Size>$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");
}

    總而言之，腳本應該不對接收的表單數據進行假設，應盡可能預計意料之外的情形并正確地處理不正確的或錯誤的輸入數據。在使用數據之前應按盡可能多的方式測試它；拒絕不合理的輸入并打印一條錯誤消息；如果某項出錯或漏了應自動選擇一個缺省值；甚至可以試圖對輸入進行編碼以成為程序的合理的輸入。選擇哪種方式依賴于自己想花費多少時間和精力，不過記住永遠也不要盲目接收傳給CGI腳來的所有信息。

2.5不要相信路徑數據

    用戶能修改的另一類型數據是PATH_INTO的服務器環境變量。該變量由CGI URL中緊跟在腳本文件名之后的任何路徑信息填充的。例如，如果foobar.sh是一個CGl shell腳本，那么當foobar.sh運行時，URL 將導致/extra/path/info被放進PATH_INFO環境變量中。

    如果使用這個PATH_INFO環境變量，就必須小心地完全驗證它的內容。就像表單數據能以許多種方式被修改一樣，PATH_INFO也可以修改。盲目地根據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""
echo"Here is the file you requested:
n"
cat $PATH_INFO
echo "
"

    盡管在用戶只單擊預定義的鏈接(即)時，該腳本正常工作，但是一個更有創造性的(或惡意的)用戶可能會利用它接收服務器上的任何文件。如果他想進入，前面的腳本會很高興地返回機器的口令文件——這可是不希望發生的事。

    另一種安全得多的方式是在可能時使用PATH_TRANSLATED環境變量。不是所有的服務器都支持該變量，所以腳本不能依賴于它。不過如果有的話，它能提供完全修飾的路徑名，而不是像PATH_INFO提供的相對URL。

    不過在某種情形下，如果在CGI腳本中使用PATH_TRANSLATED的話，則可以訪問通過瀏覽器不能訪問到的文件。應該知道這點及它的應用。

    在大部分UNIX服務器上，htaclearcase/" target="_blank" >ccess文件可以位于文檔樹的每個子目錄，負責控制誰能夠訪問該目錄中的特殊文件。例如它可以用于限制一組Web頁面只給公司雇員看。

    雖然服務器知道如何解釋.htaccess，從而知道如何限制誰能還是不能看這些頁面，CGI腳本卻不知道。使用PATH_TRANSLATED訪問文件樹中任意文件的程序有可能碰巧覆蓋了服務器提供的保護。

    無論使用PATH_INFO還是PATH_TRANSLATED，另一個重要的步驟是驗證路徑以確保它或者是一個真正的相對路徑或者是腳本認可的幾個準確的、預知的路徑之一。對于預定的路徑，腳本將簡單地將提供的數據與認可可以使用的文件的內部清單進行比較，這就是說在增加文件或修改路徑時必須重新編譯腳本，但安全性卻有了保障。只允計用戶選擇幾個預定義的文件而不允許用戶指定實際的路徑和文件名。

    下面是處理訪問者提供的路徑時應遵循的一些規則。

1)相對路徑不以斜線開頭。斜線意味著"相對于根"或絕對路徑。如果有的話，CGI腳本也是很少需要訪問Web根之外的數據。這樣它們使用的路徑就是相對于Web根目錄，而不是絕對路徑。應拒絕任何以斜線開始的內容。

2)在路徑中單個點(.)和兩個點(..)的序列也有特殊含義。單點意味著對"對于當前目錄",而雙點意味著"相對于當前目錄的父目錄"。聰明的黑客可以建立象../../../etc/passwd這樣的串逆向三層，然后向下進入/etc/passwd文件。應拒絕任何包含雙點序列的內容。

3)基于NT服務器使用驅動器字母的概念來引用磁盤卷。包含對驅動器的引用的路徑都以一個字母加上一個冒號開頭。應拒絕任何以冒號為第二個字符的內容。

4)基于NT的服務器還支持Univesal Naming Conventions(UNC)引用。一個UNC文件規格指定機器名和一個共享點，其余部分與指定機器上的指定的共享點有關。UNC文件規格總是以兩個反斜線開頭。應拒絕任何UNC路徑。

2.6一切看起來都正常，不過…

    現在已經知道了用戶能給CGI腳本提供非預期的數據的幾種方式以及如何對付它們了，余下的更大問題是如何驗證用戶提交的合法數據。

    大部分情況下，正確但聰明地編寫的表單提交會導致比越界數據更多的問題。忽略無意義的輸入很容易，但確定合法的、正確格式的輸入會不會導致問題就要困難得多。因為CGI腳本非常靈活，幾乎可做計算機能做的任何事情，所以安全方面的一個很小失誤往往能被無限制地加以利用——而這正是最危險的地方。

2.7 處理文件名

    文件名是提交給CGI腳本的簡單數據，但如果不小心的話，卻能導致許多麻煩。如果用戶輸入的名字中包含路徑因素，如目錄斜杠和雙點，盡管期望的是輸入一個簡單的文件名--例如file.txt--但結果卻可能是/file.txt或../../../file.txt。根據Web服務器的安裝以及對提交的文件名做什么操作，系統中的所有文件就有可能都暴露給了一個聰明的黑客。

    進一步，如果用戶輸入了一個已有文件的名字或者一個對系統的運行很重要的文件名，怎么辦？對如果輸入的名字是/etc/passwd或C:WINNTSYSTEM32KRNL32.DLL怎么辦？根據在CGI腳本中對這些文件進行什么操作，它們有可能被發送給用戶或者被垃圾覆蓋了。在Windows 95和Windows NT下，如果不檢查反斜杠字符()，可能會允許Web 瀏覽器通過UNC文件名訪問甚至不在該Web機器上的文件。

    如果用戶在文件名中輸入了不合法的字符怎么辦？在UNIX下，任何以句點(.)開頭的文件名都是不可見的。在Windows下斜杠(/)和反斜杠()都是目錄分隔符。很可能不小心寫了一個Perl程序，當文件名以管(pipe)(|)開頭時，盡管自己以為僅僅是打開了一個文件，實際上卻是執行了一個外部程序。如果用戶知道怎么辦的話，甚至可以把控制字符(例如Escape鍵或Return鍵)作為文件名的一部分送給腳本。

    更壞的情況是，在shell腳本中，分號用于結束一條命令并開始另一條命令。如果腳本設計目的是cat用戶輸入的文件，用戶可能輸入file.txt;rm-rf/作為文件名，導致返回fi1e.txt，然后清除整個硬盤而不經任何確認。

2.8 輸入合理，輸出卻不合理

    為了避免所有這些問題，關閉由它們打開的所有安全縫隙，檢查用戶輸入的每個文件名。必須確保輸入正是程序預期的輸入。

    這樣做的最好辦法是將輸入的文件名的每個字符與可接收字符的清單進行比較，如果不匹配就返回一個錯誤。這比維持一個所有合法字符的清單并比較它們要安全得多——要想讓什么字符溜掉太容易了。

    以下程序清單是用Perl如何完成這種比較的例子。它允許任何字符字母(大寫或小寫調)、任何數字、下劃線和句點。它還進行檢查以確保文件名不以句點開頭。這樣，該段代碼就不允許可以改變目錄的斜杠，不允許可以將多條命令放在一行的分號，或者破壞Perl的Open()調用的Pipes了。

   程序清單 保證所有字符都是合法的

if (($file_Name =~ /[^a-zA-Z_.]/) || ($file_Name =~ /^./)) {
#File name contains an illegal characgter or starts with a period
}

警告

    盡管上述程序清單中的代碼清除了大部分不合法的文件名，但操作系可能還有一些限制，而該代碼沒有覆蓋到。例如，文件名可以用數字開頭嗎？或者以下劃線開頭？如果文件中包含多個句點或者句點后多于三個字符怎么辦？整個文件名足夠短得能滿足文件系統的限制嗎？

    必須不斷向自己提出這種問題。在寫CGI腳本時最危險的事是認為用戶會遵守指令。其實用戶是不會的。保證用戶不犯錯誤是編程者自己的事。

2.9 處理HTML

    另外一種看起來無害的但卻能導致很大麻煩的輸入是在請求用戶輸入文本信息時得到的HTML。以下的程序清單是一個Perl程序片段；它向任何在$user_Name變量中輸入了一個名字的人,例如John Smith,發出問候信息。

    程序清單 發出定制的問候腳本

print (""
echo "
"
fortune
echo "
"

    該腳本看起來可一點沒有害處。它不接收用戶輸入，所以用戶不能籍此搞什么把戲。因為它僅由Web服務器運行，所以腳本本身的權限設置可以非常嚴格，可以防止任何有企圖的本地用戶修改它。如果對該腳本所在的目錄也設置了正確的權限的話，看起來就沒什么地方可以出問題了，是不是？

當然還有問題。記住得要有點偏激。

    上述程序清單調用了外部程序，在本例中是echo和fortune。因為這些腳本沒有用顯式路徑指明它們在硬盤上的位置，該shell即使用PATH環境變量來找到它們，從變量中的每一項查找要執行的程序。這可能很危險。例如，如果fortune程序安裝在/usr/games中，但PATH中在它之前列出了/TMP，那么任何碰巧命名為"fortune"并位于臨時目錄的程序都會被執行，而不是真正的fortune。

    該程序可以做它的創建者想做的任何事情，可以刪除文件，也可以登記有關請求信息并將數據傳給真正的fortune——使用戶和編程者誰也不聰明。在CGI腳本中運行外部程序時一定要指定顯式的路徑。PATH環境變量有很大作用，但它與其他變量一樣也能被非法使用。

4 使用他人CGI腳本時的注意事項

    關于CGI，可以從很多地方獲得信息——從Internet上，從學校圖書館中，從像本書這樣的書中，UseNet組中以及朋友和同事中。從這些地方不僅可以獲得信息，還可以得到實際的程序和庫。有些程序和庫如果已經有人做過了為什么自己還要從頭再做一遍呢？但就像不能盲目聽從別人的意見一樣，關于如何理財，如何駕車或者生活中的別的方面，同樣，也不能在自己的服務器上盲目地運行另從的代碼。從Net上得到的腳本也可能真正是很好的腳本。但也許并不是?；ㄐr間考察一下腳本的來源以及獲取它的站點的可靠性是值得的。

4.1 追根求源

    某些Web擁有者。如果不能看到并研究源代碼的話，他們甚至都不會運行一個公共的、免費的或商業性的腳本。這可能有點偏激。如果某個聲譽很好的公司銷售一個文檔詳細且廣為使用的腳本，該腳本應該比自己寫的腳本更安全一些。原因有二。首先，專業人才知道并能避免一些常見的安全漏洞；其次，公司是為了嫌錢而做生意，如果他們以次充好或銷售那些惡意的產品就不能再做生意賺錢了。

    從另一方面來看，如果UseNet組中看到一個編譯好的可執行文件出自一個從沒聽說過的人，沒有什么文檔可以看，也沒有該程序的用戶可以交流交流，那么在將它放入自己的服務器之前一定要仔細考慮。也有可能這是來自一個像自己一樣的另一個CGI編程者的完全合法的貢獻，目的是想讓全世界共享他的編程成果。但它也可能來自某個惡意的，具有變態幽默感的，只想看到自己能使多少人清盤的人。

    在評價公共的免費軟件或商業性軟件時，應考慮下面這些方面:

    該腳本來自一個聲譽好的站點嗎？該站點存在很長一段時間了嗎？它維護得好嗎？Web擁有者在發布文件前進行檢查嗎？

    有沒有足夠的文檔說明該程序如何工作以及用戶如何使用等信息？

    有多少人已經下載了該腳本？該站點愿意提供顧客名單嗎？(僅在有疑問時才去詢問；Web擁有者不會整天去回答這類問題。)

    有人在UseNet上討論該腳本嗎?如果有，他們說好還是不好？如果沒人提到該腳本可以進一步請求別人的見解。一般總會有人響應的。

提示

在評價腳本時檢查下面這些useNet組: comp.security.announce,comp.securiy.unix,以及comp.infosystem.www.authority.cgi。另外還可以訪問位于的Computer

Emergency Response Team，以了解安全問題的歷史及有關工作以及安全保護的軟件。

5)該腳本的作者有沒有一些別的好名聲的腳本？

6)源代碼能得到嗎？免費的或有價的都行。

7)該程序是不是過份宣傳它的能力？如果是，這可能是一個編程新手。

8)該站點自己運行了該腳本嗎？如果沒有，為什么？能找到別的站點運行該腳本嗎？過分偏激以及時間限制

    盡管游覽取自Web的所有代碼是個好主意，但要花費很多時間，特別是當代碼比較復雜時更是如此。

    例如，NCSA HTTPd就太大了，一般用戶不可能一行行去讀，但是從它的主站點下載它卻能保證極好的完整性，滿足任何用戶的需要。實際上，任何從NCSA下載的東西都是有保障的。

    實際上，Web上的許多著名的站點已經為用戶做了大部分的幾乎偏激的代碼檢查工作。從它閃中下載代碼是可能利用的另一層另一層保護。這些站點包括：

NCSA Archive)
Webwerx Division Zero-CGI Land)
World-Famous Guestbook Server)
++)
Web Developers Warehouse)

4.2 注意禮貌

    最后，如果確實希望從Web上下載一些CGI代碼，或者完整地使用它，或者用作自己編寫的更大程序的一部分，還應了解一些事情。

    代碼是兔費的并不意味著可以自由地用它作自己想做的任何事情。通常程序和庫是禁止拷貝的，如果原始作者沒有放棄這個權力，他即能限制如何使用該程序。例如，作者可能禁止拆散該腳本，及禁止用作別的腳本的一部分。

    一跟來說，在使用別人的代碼之前(即使已經確定它是安全的)，最好與作者進行聯系取得許可。至少這樣做比較有禮貌。而大部分情況下，作者會很高興他的代碼能被別人利用。當然，如果在自己程序某個片段處注明原始作者將是很禮貌的。

作者：Jeffry Dwight

原文轉自：http://www.kjueaiud.com