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腳本送垃圾。該腳本設計得很好并且很安全，因為它忽略了不認識的輸入。
<FORM METHOD="POST" ACTION="http://search.yahoo.com/bin/search">
Enter your name，first then last:
<INPUT TYPE="TEXT" NAME="first">
<INPUT TYPE="TEXT" NAME="last">
</FORM
也許用戶碰巧(或者意識地)將URL編輯為這個CGI腳本。當瀏覽器向CGI程序提交數據時，要簡單地將輸入表單中的數據連到CGI的URL上(用于GET METHODS)，就像用戶可以很容易地將Web頁面地址輸入到他的瀏覽器一樣，用戶也可以自己修改發送給這個腳本的數據。
例如，當單擊表單上的Submit按鈕時，Netscape將一個長串字符放入Location字段，該串由CGI的URL后接一串數據組成，大部分看起來像表單中定義的NAMES和VALUES。如果愿意的話，可以自由地編輯Location字段的內容并按自己的意愿修改數據:增加表單中沒有的字段，擴展由MAXLENGTH選項限制的文本數據，或者幾乎任何對象。以下顯示了某CGI腳本預期從表單中提交的URL。
http://www.altavista.digit.com/cgi-bin?pg=q&what=web&imt=&q=%22An+Entirely+Other%22
用戶可以修改同一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 http://www.server.com/cgi-bin/foobar.sh/extra/path/info將導致/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"<HTML><HEADER><TITLE>File</TITLE><HEADER><BODY>"
echo"Here is the file you requested:<PRE>n"
cat $PATH_INFO
echo "</PRE></BODY><HIML>"
盡管在用戶只單擊預定義的鏈接(即http://www.server.com/cgi-bin/foobar.sh/public/faq.txt)時，該腳本正常工作，但是一個更有創造性的(或惡意的)用戶可能會利用它接收服務器上的任何文件。如果他想進入http://www.server.com/cgi-bin/foobar.sh/etc/passwd，前面的腳本會很高興地返回機器的口令文件——這可是不希望發生的事。
另一種安全得多的方式是在可能時使用PATH_TRANSLATED環境變量。不是所有的服務器都支持該變量，所以腳本不能依賴于它。不過如果有的話，它能提供完全修飾的路徑名，而不是像PATH_INFO提供的相對URL。
不過在某種情形下，如果在CGI腳本中使用PATH_TRANSLATED的話，則可以訪問通過瀏覽器不能訪問到的文件。應該知道這點及它的應用。
在大部分UNIX服務器上，htaccess文件可以位于文檔樹的每個子目錄，負責控制誰能夠訪問該目錄中的特殊文件。例如它可以用于限制一組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路徑。
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腳本送垃圾。該腳本設計得很好并且很安全，因為它忽略了不認識的輸入。
<FORM METHOD="POST" ACTION="http://search.yahoo.com/bin/search">
Enter your name，first then last:
<INPUT TYPE="TEXT" NAME="first">
<INPUT TYPE="TEXT" NAME="last">
</FORM
也許用戶碰巧(或者意識地)將URL編輯為這個CGI腳本。當瀏覽器向CGI程序提交數據時，要簡單地將輸入表單中的數據連到CGI的URL上(用于GET METHODS)，就像用戶可以很容易地將Web頁面地址輸入到他的瀏覽器一樣，用戶也可以自己修改發送給這個腳本的數據。
例如，當單擊表單上的Submit按鈕時，Netscape將一個長串字符放入Location字段，該串由CGI的URL后接一串數據組成，大部分看起來像表單中定義的NAMES和VALUES。如果愿意的話，可以自由地編輯Location字段的內容并按自己的意愿修改數據:增加表單中沒有的字段，擴展由MAXLENGTH選項限制的文本數據，或者幾乎任何對象。以下顯示了某CGI腳本預期從表單中提交的URL。
http://www.altavista.digit.com/cgi-bin?pg=q&what=web&imt=&q=%22An+Entirely+Other%22
用戶可以修改同一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 http://www.server.com/cgi-bin/foobar.sh/extra/path/info將導致/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"<HTML><HEADER><TITLE>File</TITLE><HEADER><BODY>"
echo"Here is the file you requested:<PRE>n"
cat $PATH_INFO
echo "</PRE></BODY><HIML>"
盡管在用戶只單擊預定義的鏈接(即http://www.server.com/cgi-bin/foobar.sh/public/faq.txt)時，該腳本正常工作，但是一個更有創造性的(或惡意的)用戶可能會利用它接收服務器上的任何文件。如果他想進入http://www.server.com/cgi-bin/foobar.sh/etc/passwd，前面的腳本會很高興地返回機器的口令文件——這可是不希望發生的事。
另一種安全得多的方式是在可能時使用PATH_TRANSLATED環境變量。不是所有的服務器都支持該變量，所以腳本不能依賴于它。不過如果有的話，它能提供完全修飾的路徑名，而不是像PATH_INFO提供的相對URL。
不過在某種情形下，如果在CGI腳本中使用PATH_TRANSLATED的話，則可以訪問通過瀏覽器不能訪問到的文件。應該知道這點及它的應用。
在大部分UNIX服務器上，htaccess文件可以位于文檔樹的每個子目錄，負責控制誰能夠訪問該目錄中的特殊文件。例如它可以用于限制一組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路徑。