安全基礎知識 細說暴庫的原理與方法

　　這種方法被認為是暴庫絕招，很是流行了一陣（隨著知道的人多了，防備也加強了，沒以前那么有效了）。這種方法，簡單點說就是，打開網頁時，把網址址中的"/"換成"%5c"，然后提交，就可以暴出數據庫的路徑。

　　實際上，并不是所有網址都有效，需要"asp?id="這樣的網頁地址（表示有調用數據庫的行為），如果你確認這個網頁有調用數據庫的，后面不是這樣的也可以，比如chklogin.asp等也可以。（當然，也還有其它條件，后面再談。）

　　先舉個例子，
http://219.237.81.46/yddown%5cview.asp?id=3
　　把第二個"/"換成"%5c"
http://219.237.81.46/yddown%5cview.asp?id=3
　　提交后會得到如下結果：

　　Microsoft JET Database Engine 錯誤 ’80004005’

　　’D:\111\admin\rds_dbd32rfd213fg.mdb’不是一個有效的路徑。 確定路徑名稱拼寫是否正確，以及是否連接到文件存放的服務器。

　　/yddown/conn.asp，行12

　　（說明：這是黑防實驗室的一個網站，暴庫是他們故意開放的，因為它的關口不是注入，而是進入后臺后如何獲得shell）。

　　現在很多人都知道這個方法了，我就不多舉例了。但清楚暴庫原理的人估計是不多的。有人成功，有人不成功，《再談%5c暴庫的利用》一文總結說，須變換第二個"/"為"%5c"才行。很有實用性，但這個結論只是一種經驗，其實并不正確。讓我們先看看它的原理 "%5c"暴庫法，它不是網頁本身的漏洞，而是利用了ＩＩＳ解碼方式中的一個特性，如果ＩＩＳ安全設置不周全，而網頁設計者未考慮ＩＩＳ錯誤，就會被人利用。

　　為何要用"%5c"？它實際上是"\"的十六進制代碼，也就是"\"的另一種表示法。在電腦中，它們是一個東東。（十六進制轉換圖）

　　但提交"\"和"%5c"卻會產生不同的結果，在ie中，我們把下面第一個地址中的"/"換成"\"提交：
http://219.237.81.46/yddown/view.asp?id=3

　　http://219.237.81.46/yddown\view.asp?id=3

　　二者的訪問結果是一樣的。ie會自動把"\"轉變成"/"，從而訪問到同一地址。

　　但是，當我們把"/"換成十六進制寫法"%5c"時，ie不會對此進行轉換。地址中的"%5c"被原樣提交了。這是抓包結果：

　　GET /yddown%5cview.asp?id=3 HTTP/1.1

　　當ＩＩＳ收到后解析時，又會將%5c還原成"\"。這樣，iis中網址的相對路徑就變成/yddown\view.asp。這一點很重要。問題正是從這里開始的。

　　在ＡＳＰ網頁中，凡調用數據庫時，都會用到一個連接數據庫的網頁conn.asp，它會創建一個數據庫連接對象，定義要調用的數據庫路徑
一個典型的conn.asp如下：

　　＜%
 dim conn
 dim dbpath
 set conn=server.createobject("adodb.connection")
 DBPath = Server.MapPath("admin/rds_dbd32rfd213fg.mdb")
 conn.Open "driver={Microsoft Access Driver (*.mdb)};dbq=" & DBPath
%＞

　　比如：上面的網站中，網站：http://219.237.81.46的根目錄為："D:\111\"雨點下載目錄則在根目錄（D:\111）內的"yddown"下，我們網站訪問該站時，就是在訪問D:\111\yddown\目錄，而http://219.237.81.46/yddown/admin/，它只表明了admin與yddown這個目錄的相對關系，把這個網站放在e:盤，也一樣不改變admin位于yddown目錄下的關系。

　　當Server.MapPath方法將相對路徑轉為真實路徑時，它實際是三部分路徑加在一起得到真實路徑的：網頁目前執行時所在的相對路徑，也就是從網站物理根目錄起的相對路徑，比如上面例子中conn.asp處在從根目錄起的"/yddown/"下；然后調用的數據庫的相對路徑是admin/rds_dbd32rfd213fg.mdb，這樣就得到從根目錄起的完整相對路徑："/yddown/admin/rds_dbd32rfd213fg.mdb"。

　　這些都只是相對的路徑，如何變為真實路徑呢？

　　設置過iis的人都會知道，每一個網站，都必須指定它在硬盤上的物理目錄，比如上例中，網站根目錄所在的物理目錄為："D:\111"，Server.MapPath方法正是通過把"網站根目錄的物理地址＋完整的相對路徑"，從而得到真實的物理路徑。這樣，數據庫在硬盤上的物理路徑是：d:\111\yddown\admin\rds_dbd32rfd213fg.mdb。

　　在這里，ＩＩＳ以"\"表示真實路徑的目錄關系，而以"/"表示虛擬路徑，這可能就是ＩＥ會自動把我們地址中的"\"轉為"/"的原因吧。

　　明白這些，我們再來理解暴庫就不難了，當我們提交http://219.237.81.46/yddown%5cview.asp?id=3時，view.asp調用conn.asp后，得到的網頁相對路徑是這樣的：/yddown\　（見上），再加上"admin/rds_dbd32rfd213fg.mdb"，就得到"/yddown\"＋admin/rds_dbd32rfd213fg.mdb。在iis中，"/"和"\"代表著不同的意義，遇到了"\"時，認為它已到了根目錄所在的物理路徑，不再往上解析（為何不再往上解析？后面還會分析的），于是網站的完整相對路徑變成了
："admin/rds_dbd32rfd213fg.mdb"，再加上根目錄的物理路徑，得到的真實路徑變成："D:\111\admin\rds_dbd32rfd213fg.mdb"，而這個路徑是不存在的，數據庫連接當然會失敗，于是ＩＩＳ會報錯，并給出錯誤原因：
Microsoft JET Database Engine 錯誤 ’80004005’

　　’D:\111\admin\rds_dbd32rfd213fg.mdb’不是一個有效的路徑。 確定路徑名稱拼寫是否正確，以及是否連接到文件存放的服務器。

　　/yddown/conn.asp，行12

　　這就是暴庫語句的來歷。

　　《再談%5c暴庫的利用》一文中說，必須是網址中的第二個才可以成功，第一個不行。我們從理論上來分析一下，看到底有無規律：
　還以上面網址為例，如果將第一個"/"換成"%5c"，得到的網站相對路徑變成\yddows/admin/rds_dbd32rfd213fg.mdb，解析到"\"時，認為已到物理目錄，不再往前解析。而事實上，它確實也是根目錄，所以得到的物理路徑為："D:\111\dydow\admin\rds_dbd32rfd213fg.mdb"
這個路徑是正確的，所以不會出錯，當然不會暴出數據庫路徑。

　　第二個個"/"換成"%5c"的情況，我們上面已作分析，那是不是真的就第二個可以暴出呢，事實上，它只是因為二級網站較為常見，并不是真理。如果這個下載系統是某一個網站中的三級目錄，變第三個也是可以的。有時，變第三個成功的可能性更大。也就是說， 右邊第一個成功可能性大。

　　不信？我先舉個例子，再說原因：

http://nice.xmu.edu.cn/channely%5cblog/showlog.asp?cat_id=31&log_id=246

　　這個網址，變第二個"/"為"%5c"時，網站打開很慢，但沒有出錯。

　　當我們把第三個"/"變成"%5c"后，提交：

　　http://nice.xmu.edu.cn/channely/blog%5cshowlog.asp?cat_id=31&log_id=246

　　可以看到，數據庫暴出來了！

　　Microsoft JET Database Engine 錯誤 ’80004005’

　　’H:\channely\log_mdb\%29dlog_mdb%29.asp’不是一個有效的路徑。 確定路徑名稱拼寫是否正確，以及是否連接到文件存放的服務器。

　　/channely/blog/conn.asp，行18

　　為何這樣？

　　這是因為網站內用了虛擬目錄，也就是說這個網站的子目錄channely并不在網站根目錄內，設置過ＩＩＳ的人會知道，可以將網站目錄外的一個真實物理目錄設置為網站的虛擬目錄。也就是說，網站的相對對徑并不總是從根目錄算起，很可能在某個子目錄就指向了物理目錄。

　　上面的結果很顯然：channely已位于H:盤的根目錄上，上面再沒有目錄。事實上，很可能網站在d:盤或e:盤，而通過ＩＩＳ中設置channely虛擬子目錄指向網站根目錄以外的"H:\channely\"，這里，我們可以更清楚的看到，微軟iis為何沒有到根目錄，只要遇上"\"就認為已到物理絕對路徑，不再往上解析的原因，就是為了處理這種網站虛擬目錄與根目錄不在一起的情況。它優先查詢每個目錄是否指向了物理路徑，如果指向了，則把它換成絕對路徑，而它上面的相對地址不再解析轉換。

　　從以上分析可知，我們只有在數據庫相對地址和它的目錄絕對地址之間使用"\"（"％５ｃ"），才能達到目的。上例中，如果在第二處使用，它只會影響到ＩＩＳ尋找虛擬的channely目錄地址，而conn.asp中解析出的數據庫地H:\channely\blog、log_mdb\%29dlog_mdb%29.asp仍是對的，當然不會暴庫。

　　《再談%5c暴庫的利用》中還說了一種針對只有一級目錄的解決方法：

　　"其實一級目錄我們也同樣可以成功的，我們可以通過構造一個多級目錄來達到暴庫的目的。
　　如下：
http://www.target.com/noexists/..%5clist.asp?id=1

　　這樣大家就會有新的驚喜了，呵呵。"

　　真的嗎？從理論上分析，這種方法是不會成功的。因為遇到"％５ｃ"時，不再解析，所以中間構造的目錄，不論是真是假，都是不起作用的，被舍棄了，相對路徑還是到了根目錄，路徑不會出錯。

　　這個網站我們先用conn.asp方法暴出數據庫(后面將講的），說明服務器和網站設置是可以暴庫的。

　　得到如下結果

　　http://www.om88.com/abc/..%5cArticle_Show.asp?ArticleID=481

　　卻暴不出庫，仍得到正常頁面（換成存在的路徑結果也一樣），但圖片無法顯示。這是因為相對路徑變了，所以無法正確找到圖片路徑，但絕對路徑解析時被"％５ｃ"舍棄了，沒有出錯，當然暴不出庫。

　　二，conn.asp暴庫大法

　　這里，conn.asp只是表示數據庫調用文件，因為多數都是這個名字（有些網站改名，我們也視同conn.asp）。其實，這種暴庫法是 先出現的，以前很多牛人都對此進行過探討。只是在"%5c"暴庫大法出現后，倒較少有人提及。其實個人認為，"%5c"暴大法隨著服務器設置安全性的加強，用武之地會越來越少。而conn.asp暴庫大法發揮的余地更大，可以人為構造，臭要飯的當年著名的動網大挪移實現暴庫，其實也屬于此類。

　　上面http://www.om88.com/

　　一例中，用"%5c"暴不出數據庫路徑，因為沒有二級目錄，但用第二種卻可以暴出。它是動力系統的。
我們再來看另外一個ＡＳＰ系統一個盜帥的例子:_blank>http://www.51see.org/

　　提交

　　http://www.51see.org/db/user.asp

　　得到如下結果

　　"Microsoft JET Database Engine 錯誤 ’80004005’

　　’d:\Hosting\wwwroot\uilady_com\htdocs\db\db\downloadwoaini12345.asp’不是一個有效的路徑。 確定路徑名稱拼寫是否正確，以及是否連接到文件存放的服務器。

　　/db/user.asp，行6 "

　　有人可能會說，這么簡單就暴庫，好爽！是不是所有網站都可以這樣啊？當然不是，已作了防護的肯定不行，沒作防護的，要暴庫也是有條件的。

　　如果說第一種暴庫法是利用了絕對路徑出錯，那么，這種暴庫法就是利用了相對路徑出錯。

　　一般來說，只要conn.asp不在根目錄的系統，而調用文件在根目錄，就會出現這種問題。當然這種說法也是經驗性的，準確的說就是，conn.asp與調用它的文件，如果相對位置改變了，就會報錯，暴出數據庫路徑。這樣說可能有人不明白，不要緊，接著看你就會明白的。

　　我們從動力文章系統說起：

　　動力文章系統的conn.asp位于系統的inc目錄下，而很多調用它的文件在系統根目錄下，比如User_ChkLogin.asp等，這樣當conn.asp執行時，它是在系統根目錄D:\wwwroot\zyx688\wwwroot\下執行的，因此，conn.asp文件中，調用數據庫時，它考慮到執行時的目錄路徑，因而數據庫的相對地址寫成如下：
dim db

db="database/fp360609.asp"

　　這樣，當它在系統根目錄下執行時，數據庫的相對路徑為根目錄下的"database"目錄內。但當我們直接請求它時，它工作的當前目錄是在根目錄下的ＩＮＣ目錄內，這時，數據庫的相對路徑就變成了"inc/database/fp360609.asp"，這樣它當然出錯。得到的絕對路徑中多出了"inc。為了讓大家看得更清楚，我們舉一個可以用兩種方法暴庫的網站，比較一下看有何不同：

　　提交：http://www.pofen.com/sc/down%5cshow.asp?id=437
　　得到：
　　"Microsoft JET Database Engine 錯誤 ’80004005’

　　’D:\Webdata\pofen.com\sc\db\download.mdb’不是一個有效的路徑。 確定路徑名稱拼寫是否正確，以及是否連接到文件存放的服務器。

　　/sc/down/db/user.asp，行6 "

　　再提交：http://www.pofen.com/sc/down/db/user.asp

　　得到：
　　"Microsoft JET Database Engine 錯誤 ’80004005’

　　’D:\Webdata\pofen.com\sc\down\db\db\download.mdb’不是一個有效的路徑。 確定路徑名稱拼寫是否正確，以及是否連接到文件存放的服務器。

　　/sc/down/db/user.asp，行6 "

　　兩種方法得到的絕對路徑，一個比實際路徑少了，一個則多了，所以路徑錯誤而報錯暴出數據庫。

　　這兩個系統都是因為conn.asp不在系統根目錄下，而引起的。（其實這樣的系統不止兩個）。

　　那是不是conn.asp放在根目錄，與調用的文件在一個目錄下就無事呢？如果在一起，當然沒事，但牛人自有牛法子，可以通過構造方法來造成相對路徑變化，一樣能達到暴庫的目的。比如，動網的大挪移手法，將conn.asp移位，從而暴庫。當然，實際操作中，因為conn.asp移走后，網站無法工作，所以沒有成功。但這種思路還是給很多人啟發。如果有一種方法可以復制而不是移動，或者說，移動的不是conn.asp,而是調用conn.asp的其它文件比如chklogin之類的，理論上就可以成功。（當然，如果服務器和網頁對暴庫進行了安全處理，就是另一回事）。這種方法，當也就是一些牛人把網頁存到本地改路徑而搞出來的。今天剛看到一個暴動易數據庫的 新方法，其原理也是構造錯誤而達到獲得真實路徑的目的。

　　三，暴庫的防范

　　說白了，暴庫是因為ＩＩＳ服務器會對每個執行錯誤給出詳細說明，并停止執行，而ＩＩＳ的默認設置又是將錯誤信息返回給用戶。因此，要避免暴庫，就應改變ＩＩＳ的默認設置，選取錯誤時只給一個出錯的頁面，不給詳細信息。

　　"處理 URL 時服務器出錯。請與系統管理員聯系。"
　　其實，作為網站管理者，無法對虛擬主機設置時，只能在網頁中加強防范。就是在可能出錯的頁面加上這一句：
　　"On Resume Next"，特別是在conn.asp文件中要加上。
　　它的意思是出錯后，恢復執行下面的，也就是不理會出錯，當然就不會給出錯誤信息了。
　　動易系統３．６２版的加上后，現在就暴不出路徑了。而天意商務網，conn.asp也不在根目錄，但因為加了這句，也暴不出數據庫。