王健宇's BLOG

和黑客的ASP漏洞入侵说byebye

2010-3-11 王健宇 service

如何更好的达到防范黑客攻击，本人提一下个人意见!第一，免费程序不要真的就免费用，既然你可以共享原码，那么攻击者一样可以分析代码。如果在细节上注意防范，那样你站点的安全性就大大的提高了。即使出现了SQL Injection这样的漏洞，攻击者也不可能马上拿下你的站点。由于ASP的方便易用，越来越多的网站后台程序都使用ASP脚本语言。但是，由于ASP本身存在一些安全漏洞，稍不小心就会给黑客提供可乘之机。事实上，安全不仅是网管的事，编程人员也必须在某些安全细节上注意，养成良好的安全习惯，否则会给自己的网站带来巨大的安全隐患。目前，大多数网站上的ASP程序有这样那样的安全漏洞，但如果编写程序的时候注意一点的话，还是可以避免的。

　　1、用户名与口令被破解

　　攻击原理：用户名与口令，往往是黑客们最感兴趣的东西，如果被通过某种方式看到源代码，后果是严重的。防范技巧：涉及用户名与口令的程序最好封装在服务器端，尽量少在ASP文件里出现，涉及与数据库连接的用户名与口令应给予最小的权限。出现次数多的用户名与口令可以写在一个位置比较隐蔽的包含文件中。如果涉及与数据库连接，在理想状态下只给它以执行存储过程的权限，千万不要直接给予该用户修改、插入、删除记录的权限。

　　2、验证被绕过

　　攻击原理：现在需要经过验证的ASP程序大多是在页面头部加一个判断语句，但这还不够，有可能被黑客绕过验证直接进入。

　　防范技巧：需要经过验证的ASP页面，可跟踪上一个页面的文件名，只有从上一页面转进来的会话才能读取这个页面。

　　3、Inc文件泄露问题

　　攻击原理：当存在ASP的主页正在制作且没有进行最后调试完成以前，可以被某些搜索引擎机动追加为搜索对象。如果这时候有人利用搜索引擎对这些网页进行查找，会得到有关文件的定位，并能在浏览器中查看到数据库地点和结构的细节，并以此揭示完整的源代码。

　　防范技巧：程序员应该在网页发布前对它进行彻底的调试;安全专家则需要加固ASP文件以便外部的用户不能看到它们。首先对.inc文件内容进行加密，其次也可以使用.asp文件代替.inc文件使用户无法从浏览器直接观看文件的源代码。inc文件的文件名不要使用系统默认的或者有特殊含义容易被用户猜测到的名称，尽量使用无规则的英文字母。

　　4、自动备份被下载

　　攻击原理：在有些编辑ASP程序的工具中，当创建或者修改一个ASP文件时，编辑器自动创建一个备份文件，比如：UltraEdit就会备份一个.bak文件，如你创建或者修改了some.asp，编辑器会自动生成一个叫some.asp.bak文件，如果你没有删除这个bak文件，攻击者可以直接下载some.asp.bak文件，这样some.asp的源程序就会被下载。

　　防范技巧：上传程序之前要仔细检查，删除不必要的文档。对以BAK为后缀的文件要特别小心。

　　5、特殊字符

　　攻击原理：输入框是黑客利用的一个目标，他们可以通过输入脚本语言等对用户客户端造成损坏;如果该输入框涉及数据查询，他们会利用特殊查询语句，得到更多的数据库数据，甚至表的全部。因此必须对输入框进行过滤。但如果为了提高效率仅在客户端进行输入合法性检查，仍有可能被绕过。

　　防范技巧：在处理类似留言板、BBS等输入框的ASP程序中，最好屏蔽掉HTML、javascript、VBscript语句，如无特殊要求，可以限定只允许输入字母与数字，屏蔽掉特殊字符。同时对输入字符的长度进行限制。而且不但要在客户端进行输入合法性检查，同时要在服务器端程序中进行类似检查。

　　6、数据库下载漏洞

　　攻击原理：在用Access做后台数据库时，如果有人通过各种方法知道或者猜到了服务器的Access数据库的路径和数据库名称，那么他也能够下载这个Access数据库文件，这是非常危险的。

防范技巧：

　　(1)为你的数据库文件名称起个复杂的非常规的名字，并把它放在几层目录下。所谓 “非常规”， 打个比方说，比如有个数据库要保存的是有关书籍的信息， 可不要给它起个“book.mdb”的名字，而要起个怪怪的名称，比如d34ksfslf.mdb， 并把它放在如./kdslf/i44/studi/的几层目录下，这样黑客要想通过猜的方式得到你的Access数据库文件就难上加难了。

　　(2)不要把数据库名写在程序中。有些人喜欢把DSN写在程序中，比如：

　　DBPath = Server.MapPath(“cmddb.mdb”)>　　conn.Open “driver={Microsoft Access Driver (*.mdb)};dbq=” & DBPath

　　假如万一给人拿到了源程序，你的Access数据库的名字就一览无余了。因此建议你在ODBC里设置数据源，再在程序中这样写：

　　conn.open“shujiyuan”

　　(3)使用Access来为数据库文件编码及加密。首先在“工具→安全→加密/解密数据库”中选取数据库(如：employer.mdb)，然后按确定，接着会出现“数据库加密后另存为”的窗口，可存为：

　　“employer1.mdb”

　　要注意的是，以上的动作并不是对数据库设置密码，而只是对数据库文件加以编码，目的是为了防止他人使用别的工具来查看数据库文件的内容。接下来我们为数据库加密，首先打开经过编码了的 employer1.mdb，在打开时，选择“独占”方式。然后选取功能表的“工具→安全→设置数据库密码”，接着输入密码即可。这样即使他人得到了employer1.mdb文件，没有密码他也是无法看到 employer1.mdb中的内容。

　　7、防范远程注入攻击

　　这类攻击在以前应该是比较常见的攻击方式，比如POST攻击，攻击者可以随便的改变要提交的数据值已达到攻击目的。又如：COOKIES 的伪造，这一点更值得引起程序编写者或站长的注意，不要使用COOKIES来做为用户验证的方式，否则你和把钥匙留给贼是同一个道理。

　　比如:

　　If trim(Request. cookies ("uname"))="fqy" and Request.cookies("upwd")

　　=”fqy#e3i5.com” then

　　……..more………

　　End if

　　我想各位站长或者是喜好写程序的朋友千万别出这类错误，真的是不可饶恕。伪造COOKIES 都多少年了，你还用这样的就不能怪别人跑你的密码。涉及到用户密码或者是用户登陆时，你最好使用session 它才是最安全的。如果要使用COOKIES就在你的COOKIES上多加一个信息，SessionID，它的随机值是64位的，要猜解它，不可能。例：

　　if not (rs.BOF or rs.eof) then

　　login="true"

　　Session("username"sessionID) = Username

　　Session("password"& sessionID) = Password

　　'Response.cookies(“username”)= Username

　　'Response.cookies(“Password”)= Password

下面我们来谈谈如何防范远程注入攻击,一般的攻击都是将单表提交文件拖到本地,将Form ACTION=”chk.asp” 指向你服务器中处理数据的文件即可.如果你全部的数据过滤都在单表页上，那么恭喜你，你将已经被脚本攻击了.怎么才能制止这样的远程攻击?好办,请看代码如下：程序体(9)

　　以下是引用片段：

　　个人感觉上面的代码过滤不是很好，有一些外部提交竟然还能堂堂正正的进来，于是再写一个。这个是过滤效果很好，建议使用。

　　if instr(request.servervariables

　　("http_referer"),"http://"request.servervariables("host") )<1 then

　　response.write "处理 URL 时服务器上出错。如果您是在用任何手段攻击服务器，那你应该庆幸，你

　　的所有操作已经被服务器记录，我们会第一时间通知公安局与国家安全部门来调查你的IP. "

　　本以为这样就万事大吉了，在表格页上加一些限制,比如maxlength啦,等等……但天公就是那么不作美，你越怕什么他越来什么。你别忘了，攻击者可以突破sql注入攻击时输入框长度的限制。写一个SOCKET程序改变HTTP_REFERER?我不会，网上发表了这样一篇文章：

　　------------len.reg-----------------

　　Windows Registry Editor Version 5.00

　　[HKEY_CURRENT_USERSoftwareMicrosoftInternet ExplorerMenuExt扩展(&E)]

　　@="C:Documents and SettingsAdministrator桌面len.htm"

　　"contexts"=dword:00000004

　　-----------end----------------------

　　-----------len.htm------------------

　　----------end-----------------------

　　用法：先把len.reg导入注册表(注意文件路径)然后把len.htm拷到注册表中指定的地方。打开网页，光标放在要改变长度的输入框上点右键，看多了一个叫扩展的选项了吧单击搞定! 后记：同样的也就可以对付那些限制输入内容的脚本了。怎么办?我们的限制被饶过了，所有的努力都白费了?不，举起你de键盘，说不。让我们继续回到脚本字符的过滤吧，他们所进行的注入无非就是进行脚本攻击。我们把所有的精力全都用到ACTION以后的页面吧，在chk.asp页中，我们将非法的字符全部过滤掉，结果如何?我们只在前面虚晃一枪，叫他们去改.