上一篇中給大家著重談了“ADO 存取數據庫時如何分頁顯示”的問題,有位朋友來信給我指出我在計算頁面總數時忽略了 Recordset 對象的一個重要參數“PageCount”,它能在給 Pagesize 賦值後自動得出頁面的總數,而無須用“INT(RS.recordcount/PgSz*-1)*-1”這樣繁瑣的公式。我要感謝這位朋友熱心地給我指出程序中的不足,由於這個程序是我在很久以前寫的,因為在分頁顯示的時候記錄的總數不一定能整除頁面顯示記錄的數目,而當時我又不能肯定 PageCount 是否能正確得出頁面的數目,所以偷懶寫了這個公式:),說實話我到現在還都沒試過用 pagecount,有興趣的朋友千萬要試一下哦,可別學我的懶惰呀。
最近我在 chinaasp 的 bbs 上討論問題時發現很多朋友對於 asp 的一些安全性問題不甚了解,甚至不知道如何解決最常見的 asp::$DATA 顯示源代碼的問題,因此我覺得非常有必要在這裡給廣大朋友們重點談一談這個問題,在征得 chinaasp 飛鳥的同意下,我將他曾經寫過的一點關於 asp 漏洞的介紹加上我自己的一些實踐經驗拿出來給大家詳細分析一下這個對於 webmaster 來說至關重要的 asp 的安全性問題。
當去年 ::$DATA 的漏洞被發現並公布的第二天,我曾經檢測了當時國內大部分運用 asp 的站點,其中百分之九十九都存在以上可以看見源代碼的問題,當日我甚至在微軟的站點上抓下了 search.asp 這個文件的源代碼。可能你會覺得看到源代碼並沒有什麼大礙,如果作為 webmaster 的你這麼想就大錯特錯了。譬如,如果 asp 程序員將站點的登陸密碼直接寫在 asp 裡,那麼一旦源碼被發現,他人就可以很容易的進入本不該被看到的頁面,我就曾經利用這個方法免費成為了一個收費網站的成員(大家可別揭發我哦!),而且很多數據庫的連接用戶名和密碼也都是直接寫在 asp 裡,一旦被發現,如果你的數據庫允許遠程訪問而且沒有設防的話就相當危險了。在一些用 asp 開發的 bbs 程序中,往往使用的是 access mdb 庫,如果 mdb 庫存放的路徑被獲知,數據庫就很有可能被他人下載,加之如果數據庫裡含有的密碼不加密,那就非常危險了,獲取密碼的人如果有意進行惡意破壞,他只需要以 admin 身份登陸刪除所有 bbs 裡的帖子,就夠你嗆的了。下面列出了目前已經發現的一些漏洞,希望大家提高警惕一、經過實驗我們發現, win95+pws 上運行 ASP 程序,只須簡單地在浏覽器地址欄的 asp 文件名後多加一個小數點 ASP 程序就會被下載下來。 IIS3 也存在同樣的問題,如果你目前還在使用 IIS3 一定要測試一下。
二、 iis2、 iis3、 iis4 的一個廣為人知的漏洞就是 ::$DATA,通過它使用 ie 的 view source 或 netscape 直接訪問該 asp 文件就能輕而易舉地看到 asp 代碼。 win98+pws4 不存在這個漏洞。
究竟是什麼原因造成了這種可怕的漏洞呢?究其根源其實是 Windows NT 特有的文件系統在做怪。有一點常識的人都知道在 NT 提供了一種完全不同於 FAT 的文件系統: NTFS,這種被稱之為新技術文件系統的技術使得 NT 具有了較高的安全機制,但也正是因為它而產生了不少令人頭痛的隱患。大家可能不知道, NTFS 支持包含在一個文件中的多數據流,而這個包含了所有內容的主數據流被稱之為“DATA”,因此使得在浏覽器裡直接訪問 NTFS 系統的這個特性而輕易的捕獲在文件中的腳本程序成為了可能。然而直接導致 ::$DATA 的原因是由於 IIS 在解析文件名的時候出了問題,它沒有很好地規范文件名。
我們該如何解決這個問題呢?辦法有幾種:
a、是將 .asp 文件存放的目錄設置為不可讀(ASP 仍能執行),這樣 html、 css 等文件就不能放在這個目錄下,否則它們將不能被浏覽。
b、是安裝微軟提供的補丁程序,下載的地址如下(注意針對不同的系統有不同的補丁):
該補丁是針對 IIS3, Intel 平台
ftp.microsoft.com/bussys/iis/iis-public/fixes/cht/security/iis3-datafix/iis3fixi.exe
該補丁是針對 IIS3, Intel 平台
ftp.microsoft.com/bussys/iis/iis-public/fixes/cht/security/iis3-datafix/iis3fixa.exe
該補丁是針對 IIS4, Alpha 平台
ftp.microsoft.com/bussys/iis/iis-public/fixes/cht/security/iis4-datafix/iis4fixi.exe
該補丁是針對 IIS4, Alpha 平台
ftp.microsoft.com/bussys/iis/iis-public/fixes/cht/security/iis4-datafix/iis4fixa.exe
c、是在服務器上安裝 ie4.01sp1,這個是否有效,作者本人沒具體試過。
d、存粹作者的個人意見,盡量安裝英文版的 NT,而不要使用中文版,究其原因作者也說不清,只是根據實踐經驗英文版的 NT 較中文版 bug 少,如果哪位朋友知道原因千萬要告訴我。
三 . 支持 ASP 的免費主頁空間以及虛擬主機服務的服務器面臨的問題
1、服務器上的 ASP 代碼很可能被人其他擁有 asp 權限的人非法獲取。
舉個很簡單的例子,在微軟提供的 ASP1.0 的例程裡有一個 .asp 文件專門用來查看其它 .asp 文件的源代碼,該文件為 ASPSamp/Samples/code.asp。如果有人把這個程序上傳的服務器,而服務器端沒有任何防范措施的話,他就可以很容易地查看他人的程序。
例如 :
code.asp?source=/directory/file.asp
2、使用的 ACCESS mdb 數據庫可能被人下載一般來說在提供 asp 權限的免費主頁服務器上不可能提供代為設定 DSN 的服務,因此 asp 程序使用的數據庫通常都局限在使用 mdb 庫,而 mdb 遠端數據庫所在的位置是使用我們在第十四期中講到過的 DSN-less 方法直接在 asp 中指定的,方法如下 :
< %connstr = "DBQ="+server.mappath("database/source.mdb")+";DefaultDir=;DRIVER={Microsoft Access Driver (*.mdb)};DriverId=25;FIL=MS Access;ImplicitCommitSync=Yes;MaxBufferSize=512;MaxScanRows=8;PageTimeout=5; SafeTransactions=0;Threads=3;UserCommitSync=Yes;"%>
正如前文所言,在這種情況下 mdb 庫很可能被他人下載,從而造成諸如密碼等的洩露。
所以,作為 webmaster 應該采取一定的措施,嚴禁 code.asp 之類的程序(似乎很難辦到 , 但可以定期檢索特征代碼),限制 mdb 的下載。
3、來自強大的 filesystemobject 組件的威脅
IIS3、 IIS4 的 ASP 的文件操作都可以通過 filesystemobject 實現,包括文本文件的讀寫目錄操作、文件的拷貝改名刪除等,但是這個強大的功能也留下了非常危險的“後門”。利用 filesystemobjet 可以篡改下載 fat 分區上的任何文件。即使是 ntfs 分區,如果權限沒有設定好的話,同樣也能破壞,一不小心你就可能遭受“滅頂之災”。遺憾的是很多 webmaster 只知道讓 web 服務器運行起來,很少對 ntfs 進行權限設置,而 NT 目錄權限的默認設置偏偏安全性又低得可怕。因此,如果你是 Webmaster,作者強烈建議你密切關注服務器的設置,盡量將 web 目錄建在 ntfs 分區上,目錄不要設定 everyone full control,即使是是管理員組的成員一般也沒什麼必要 full control,只要有讀取、更改權限就足夠了。
四、 ASP 應用程序可能面臨的攻擊過去許多 Internet 上 CGI 寫的留言本或 BBS 是把客戶輸入的留言變為一個變量,然後再把這個變量插入到顯示留言的 HTML 文件裡,因此客戶輸入的文本如要在 HTML 文件裡顯示就得符合 HTML 標准,而 CGI 程序裡一般都加入了特定的 HTML 語言。當客戶輸入內容,插入 HTML 文件時,即同時插入到了頭尾 HTML 語句中,如:
< font>客戶輸入的變量 < /font>但如果把前後的 HTML 標記給敝屏了,就可以做很多事情了。
如輸入時打上:
< /font>符合 HTML 標准的語句 < font>前後的 < font>是用來敝屏 CGI 中的 HTML 語句用的。插入到 HTML 文件裡的就變成了:
< font>< /font>符合 HTML 標准的語句 < font>< /font>由於這樣一個特性,使得寫個 javascript 的死循環變得非常容易,只要在輸入框中輸入:
< a href="URL" onMouseover="while(1){window.close(\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\')}">或 < a herf="URL" onMousever="while(ture){window.close(\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\')}">
看完本期後,如果你非常的震驚,那麼你必須徹底對你現有的網站或 asp 程序進行一翻檢測,看看是否存在上述漏洞。如果你對文中所談到的漏洞都有所了解並已有