昨天和animator試驗了一下，把data.mdb文件改名為data.asp文件后放在wwwroot目錄里。然后在IE中輸入data.asp路徑后，發現IE顯示一片空白，右鍵->察看源文件，跳出記事本，將內容另存為.mdb文件，用ACCESS打開，發現需要密碼，也就是說至少文件頭被破壞。
然后用Flashget試驗下載data.asp文件，并另存為data.mdb文件，發現用ACCESS打開完好無損！看來，好一些編程人員在開發的時候都認為，改了mdb后綴為asp就能防下載的概念，是錯的！后臺數據庫被下載對于一個asp+access的網站來說無疑是一場慘絕人寰的災難。今天找了各方的文章，歸納一下有以下9種辦法防止數據庫被下載(歡迎補充)。
1.發揮你的想象力修改數據庫文件名
不用說，這是最最偷懶的方法，但是若攻擊者通過第三方途徑獲得了數據庫的路徑，就玩完了。比如說攻擊者本來只能拿到list權，結果意外看到了數據庫路徑，就可以冠冕堂皇地把數據庫下載回去研究了。另外，數據文件通常大小都比較大，起再隱蔽的文件名都瞞不了人。故保密性為最低。
2.數據庫名后綴改為ASA、ASP等
此法須配合一些要進行一些設置，否則就會出現本文開頭的那種情況。
(1)二進制字段添加。
(2)在這個文件中加入，IIS就會按ASP語法來解析，然后就會報告500錯誤，自然不能下載了。可是如果只是簡單的在數據庫的文本或者備注字段加入<%是沒用的，因為ACCESS會對其中的內容進行處理，在數據庫里他會以<%的形式存在，無效！正確的方法是將<%存入OLE對象字段里，這樣我們的目的就能達到了。
操作方法：
首先，用notepad新建一個內容為<%的文本文件，隨便起個名字存檔。
接著，用Access打開您的數據庫文件，新建一個表，隨便起個名字，在表中添加一個OLE對象的字段，然后添加一個記錄，插入之前建立的文本文件，如果操作正確的話，應該可以看到一個新的名為"數據包＂的記錄。即可。
3.數據庫名前加"#"
只需要把數據庫文件前名加上#、然后修改數據庫連接文件（如conn.asp）中的數據庫地址。原理是下載的時候只能識別#號前名的部分，對于后面的自動去掉，比如你要下載：http://www.pcdigest.com/date/#123.mdb(假設存在的話）。無論是IE還是FLASHGET等下到的都是http://www.test.com/date/index.htm(index.asp、default.jsp等你在IIS設置的首頁文檔)。
另外在數據庫文件名中保留一些空格也起到類似作用，由于HTTP協議對地址解析的特殊性，空格會被編碼為"%",如http://www.test.com/date/123;456.mdb，下載的時http://www.test.com/date/123%456.mdb。而我們的目錄就根本沒有123%456.mdb這個文件，所以下載也是無效的這樣的修改后，即使你暴露了數據庫地址，一般情況下別人也是無法下載！
4.加密數據庫
首先在選取"工具->安全->加密/解密數據庫，選取數據庫（如：employer.mdb），然后接確定，接著會出現"數據庫加密后另存為"的窗口，存為：employer1.mdb。接著employer.mdb就會被編碼，然后存為employer1.mdb..要注意的是，以上的動作并不是對數據庫設置密碼，而只是對數據庫文件加以編碼，目的是為了防止他人使用別的工具來查看數據庫文件的內容。
接下來我們為數據庫加密，首先以打開經過編碼了的employer1.mdb，在打開時，選擇"獨占"方式。然后選取功能表的"工具->安全->設置數據庫密碼"，接著輸入密碼即可。這樣即使他人得到了employer1.mdb文件，沒有密碼他是無法看到employer1.mdb的。
加密后要修改數據庫連接頁，如：
|
這樣修改后，數據庫即使被人下載了，別人也無法打開（前提是你的數據庫連接頁中的密碼沒有被泄露）。
但值得注意的是，由于Access數據庫的加密機制比較簡單，即使設置了密碼，解密也很容易。該數據庫系統通過將用戶輸入的密碼與某一固定密鑰進行"異或"來形成一個加密串，并將其存儲在*.mdb文件從地址"&H42"開始的區域內。所以一個好的程序員可以輕松制作一個幾十行的小程序就可以輕松地獲得任何Access數據庫的密碼。因此，只要數據庫被下載，其信息安全依然是個未知數。
5.數據庫放在WEB目錄外或將數據庫連接文件放到其他虛擬目錄下
如你的WEB目錄是e:\webroot，可以把數據庫放到e:\data這個文件夾里，在e:\webroot里的數據庫連接頁中修改數據庫連接地址為："../data/數據庫名"的形式，這樣數據庫可以正常調用，但是無法下載的，因為它不在WEB目錄里！這個方法一般也不適合購買虛擬空間的用戶。
6.使用ODBC數據源
在ASP等程序設計中，如果有條件，應盡量使用ODBC數據源，不要把數據庫名寫在程序中，否則，數據庫名將隨ASP源代碼的失密而一同失密，例如：
|
可見，即使數據庫名字起得再怪異，隱藏的目錄再深，ASP源代碼失密后，也很容易被下載下來。如果使用ODBC數據源，就不會存在這樣的問題了：conn.open "ODBC-DSN名"，不過這樣是比較煩的，目錄移動的話又要重新設置數據源了，更方便的方法請看第7，8法！
7.添加數據庫名的如MDB的擴展映射
這個方法就是通過修改IIS設置來實現，適合有IIS控制權的朋友，不適合購買虛擬主機用戶(除非管理員已經設置了）。這個方法我認為是目前最好的。只要修改一處，整個站點的數據庫都可以防止被下載。無須修改代碼即使暴露目標地址也可以防止下載。
我們在IIS屬性---主目錄---配置---映射---應用程序擴展那里添加.mdb文件的應用解析。注意這里的選擇的DLL（或EXE等）似乎也不是任意的，選擇不當，這個MDB文件還是可以被下載的，注意最好不要選擇選擇asp.dll等。你可以自己多測試下，樣修改后下載數據庫如：http://www.test.com/data/dvbbs6.mdb，就出現（404或500等錯誤）。
8.使用.net的優越性
動網的木鳥就寫過一個防非法下載文件的"WBAL防盜鏈工具"。
不過那個只實現了防止非本地下載的，沒有起到真正的防下載數據庫的功能。不過這個方法已經跟5法差不多可以通過修改.NET文件，實現本地也不能下載！
這幾個方法中，只有第7和8個是統一性改的，一次修改配置后，整個站點的數據庫都可以防止下載，其他幾個就要分別修改數據庫名和連接文件，比較麻煩，不過對于虛擬主機的朋友也只能這樣了！
其實第6個方法應該是第5個方法的擴展，可以實現特殊的功能，但對于不支持.net的主機或者怕設置麻煩的話，還是直接用第5個方法了，而且默認情況下第6個方法，依然可以通過復制連接到同主機的論壇或留言本發表，然后就可以點擊下載了。（因為這樣的引用頁是來自同主機的）
9.利用NTFS分區的文件權限設置(bypercyboy)
我們已經知道，ASP.NET中使用ADO.NET訪問數據庫，通過OleDb的連接可以訪問Access數據庫——我們非常常用的低端數據庫之一。本文討論了ASP.NET中可能看到的若干錯誤提示，從中看到Access2000和AccessXP創建的數據庫文件，在訪問出現錯誤時會出現不太相同的錯誤提示。希望對大家有所幫助。另一個要點是，希望通過此文，使大家對ASP.NET中Access數據庫文件的NTFS權限設置有所新的認識。
(一)實驗過程
為了敘述方便，舉個具體例子做個實驗：應用程序為/test，數據庫存放在D:\wwwroot\test\data\db1.mdb，我們已經知道在ASP.NET中是以一個叫做ASPNET虛擬用戶的身份訪問數據庫的，我們需要給這個賬戶以特定的NTFS權限才能使ASP.NET程序正常運行。
為了得到最嚴格的NTFS權限設置，實驗開始時我們給程序最低的NTFS權限：
a)D:\wwwroot\test\data\文件夾的給用戶ASPNET以如下權限：
|
b) D:\wwwroot\test\data\db1.mdb文件本身給用戶ASPNET以如下權限：
√允許將來自父系的可繼承權限傳播給該對象
1.1對于某個只包含有"SELECT"命令的aspx程序，上述權限設置運行時無障礙，即：上述權限已經滿足這類程序的運行了。
1.2對于包含有"UPDATE""INSERT""UPDATE"等命令的aspx程序。
(a)如果db1.mdb是Access2000創建的數據庫，出現如下錯誤：
"/test"應用程序中的服務器錯誤。
MicrosoftJet數據庫引擎打不開文件'D:\wwwroot\test\data\'。 它已經被別的用戶以獨占方式打開，或沒有查看數據的權限。
說明：執行當前Web請求期間，出現未處理的異常。請檢查堆棧跟蹤信息，以了解有關該錯誤以及代碼中導致錯誤的出處的詳細信息。
異常詳細信息:System.Data.OleDb.OleDbException:MicrosoftJet數據庫引擎打不開文件'D:\wwwroot\test\data\'。它已經被別的用戶以獨占方式打開，或沒有查看數據的權限。
(b)如果db1.mdb是AccessXP創建的數據庫，出現如下錯誤：
"/test"應用程序中的服務器錯誤。
操作必須使用一個可更新的查詢。
說明：執行當前Web請求期間，出現未處理的異常。請檢查堆棧跟蹤信息，以了解有關該錯誤以及代碼中導致錯誤的出處的詳細信息。
異常詳細信息：System.Data.OleDb.OleDbException：操作必須使用一個可更新的查詢。
(c)原因初步分析：因為包含有"UPDATE""INSERT""UPDATE"等命令，需要對數據庫文件本身進行寫入操作，所以上述權限不能滿足此需求，我們需要進一步放開權限。
我們放開一些權限，
a) D:\wwwroot\test\data\ 文件夾不變；
b) D:\wwwroot\test\data\db1.mdb 文件本身給用戶ASPNET以如下權限；
|
1.3 放開權限后繼續實驗
(a)如果db1.mdb是Access2000創建的數據庫，出現如下錯誤：
"/test"應用程序中的服務器錯誤。
不能鎖定文件。
說明：執行當前Web請求期間，出現未處理的異常。請檢查堆棧跟蹤信息，以了解有關該錯誤以及代碼中導致錯誤的出處的詳細信息。
異常詳細信息：System.Data.OleDb.OleDbException:不能鎖定文件。
(b)如果db1.mdb是AccessXP創建的數據庫，沒有出現錯誤。
(c)原因初步分析：我們發現在打開Access數據庫時，同時會在所在目錄生成一個同名的*.ldb文件，這是一個Access的鎖定標記。鑒于此，我們猜測，用戶ASPNET訪問Access數據庫時，也需要生成一個鎖定標記，而該目錄沒有允許其寫入，因此出錯。至于AccessXP創建的數據庫為什么沒有這個錯誤，原因還不得而知。
我們進一步放開權限，
a)D:\wwwroot\test\data\文件夾給用戶ASPNET以如下權限：
|
b) D:\wwwroot\test\data\db1.mdb文件本身給用戶ASPNET以如下權限：
√允許將來自父系的可繼承權限傳播給該對象
1.4繼續實驗，發現錯誤已解決，那么上面這個權限就是我們需要放開的"最低權限"。
(a)如果db1.mdb是Access2000創建的數據庫，我們會發現一個小問題：生成的*.ldb文件不會自己刪除，訪問后該文件依然存在，但這個問題不會影響ASP.NET的正常運行。
(b)如果db1.mdb是AccessXP創建的數據庫，沒有出現上面類似問題。
(c)原因初步分析：我們僅僅是給了ASPNET以寫入文件夾的權限，沒有給它修改的權限，所以文件一旦寫入，便無法修改其內容，*.ldb也就刪除不掉了。
如果非要解決這個問題，進一步放開權限為：
a)D:\wwwroot\test\data\文件夾給用戶ASPNET以如下權限：
|
b) D:\wwwroot\test\data\db1.mdb 文件本身給用戶ASPNET以如下權限：
√允許將來自父系的可繼承權限傳播給該對象
1.5附帶著，實驗另一種情形：我們把db1.mdb在Access打開編輯，同時訪問ASP.NET。
(a)如果db1.mdb是Access2000創建的數據庫，我們發現并沒有出現什么問題。
(b)如果db1.mdb是AccessXP創建的數據庫，出現如下錯誤：&nb。
