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讀取數據，那怎么辦？它有可能會崩潰，也許允許那個崩潰了系統的人訪問系統。