CGI教學:CGI安全問題(4)
發表時間:2023-12-26 來源:明輝站整理相關軟件相關文章人氣:
[摘要]2.5不要相信路徑數據 用戶能修改的另一類型數據是PATH_INTO的服務器環境變量。該變量由CGI URL中緊跟在腳本文件名之后的任何路徑信息填充的。例如,如果foobar.sh是一個CGl shell腳本,那么當foobar.sh運行時,URL http://www.server.co...
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路徑。
2.6一切看起來都正常,不過…
現在已經知道了用戶能給CGI腳本提供非預期的數據的幾種方式以及如何對付它們了,余下的更大問題是如何驗證用戶提交的合法數據。
大部分情況下,正確但聰明地編寫的表單提交會導致比越界數據更多的問題。忽略無意義的輸入很容易,但確定合法的、正確格式的輸入會不會導致問題就要困難得多。因為CGI腳本非常靈活,幾乎可做計算機能做的任何事情,所以安全方面的一個很小失誤往往能被無限制地加以利用——而這正是最危險的地方。