小型系统数据库安全小结

1、目录更改不容易猜到
2、如果是asp的一般小系统的数据用mdb就把mdb数据库后序名改为asp，还可以打开IIS添加一个MDB的映射，让mdb解析成其他下载不了的文件：“IIS属性”—“主目录”—“配置”—“映射”—“应用程序扩展”里面添加。mdb文件应用解析，至于用于解析它的文件大家可以自己进行选择，只要访问数据库文件出现无法访问就可以了，在如果是安装了dotnet framework2.0以上，则在iis建立站点或者建立虚拟目录，它默认帮你做好了该项映射安全了。
   如果是.net系统，则

1. 把数据库文件放置到站点目录之外 2. 设置存放数据库文件的IIS目录权限为不可读取（IIS信息服务管理->选择需要设置目录->右键->属性->目录选项卡->取消读取复选框）---测试中，这个有问题，显示不大正常。3. 采用ODBC数据源  4. 将你的 Access 重命名 *.asax：因为 ASP.NET 的处理机制中，默认情况下，对这样的请求是直接拒绝的，并不会有思归提到的解析过程耗费资源等问题。按照这个思路，其实还可以把 Access 重命名为 *.config，*.vb， *.cs 等等。5. 将你的 Access 放在你的应用程序根下 bin 目录（也就是你放置 DLL 文件的那个目录）中：已经发现，IIS 默认被配置为拒绝直接访问 bin 目录中的文件，用以保护对 DLL 的请求，事实上也同时保护了放在 bin 目录中其他文件。但是对于这种方法，有人提出疑问： 会不会有这样的后果，数据库读写时会造成程序集被频繁的刷新，也会Session和Application不断丢失

第6种方法

以上前种方法都比较经典也比较安全，适合能对服务器直接操作的情况

3、注意：无论是ASP中还是。NET下，对于直接把Access数据库后缀直接改为。asp和。aspx，或者在文件名前面添加“#”或文件名中加入空格，用FlashGet照下不误。找到一种FlashGet无法下载的方法，但是如何才能让他无法下载呢？大概是因为以前受到unicode漏洞攻击的缘故，网站在处理包含unicode码的链接的时候将会不予处理。所以我们可以利用unicode编码（比如可以利用“%3C ”代替“<”等），来达到我们的目的。而FlashGet在处理包含unicode码的链接的时候却“自作聪明”地把unicode编码做了对应的处理，比如自动把“%29”这一段unicode编码形式的字符转化成了“（”，所以你向FlashGet提交一个 http://127.0.0.1/xweb/data/%29xadminsxx.mdb的下载链接，它却解释成了

http://127.0.0.1/xweb/data/（xadminsxx.mdb，看看我们上面的网址的地方和下面的重命名的地方是不同的，FlashGet把“%

29xadminsxx.mdb”解释为了“（xadminsxx.mdb”，当我们单击“确定”按钮进行下载的时候，它就去寻找一个名为“（xadminsxx.mdb”的文件。也就是说FlashGet给我们引入了歧途，它当然找不到，所以提示失败了。不过如果提示下载失败，攻击者肯定要想采取其他的攻击方法。由此我们可以采用另一个防范的方法，既然FlashGet去找那个名为“（xadminsxx.mdb”的文件了，我们可以给它准备一个，我们给它做一个仿真的数据库名为“（xadminsxx.mdb”，这样当入侵者想下载文件的时候的的确确下载了一个数据库回去，只不过这个数据库文件是虚假的或者是空的，在他们暗自窃喜的时候，实际上最终的胜利是属于我们的。

4、用多种工具测试，如FlashGet，刚石，扫描器等对付下自己的系统看是否多漏洞，要做到100%是没有可能，但对付那些2打6我想还是足够的。