以黑客的眼光来审视网络安全性，往往可以发现很多潜在的安全漏洞。这样做不仅提供了审视你网络系统的不同视角，而且让你能够从你的敌人，即黑客的角度来指导你采取最有效的网络安全措施。下面，我们来看一下网络系统分析的过程。这个过程要用到开源工具和相关技术。 用开源工具收集信息 首先，登录Whois.com网站查找你企业的域名，检索结果将会显示出你的网络系统所使用的DNS服务器。然后再使用一些软件工具，如:nslookup，来进一步挖掘DNS服务器的详细信息。 此外，在你的上述搜索操作中，一定要特别注意这些网站上已显示的和没有显示的信息。最好，把这些网页存入你的电脑中，然后用记事本程序打开，查看网页的源代码。一般而言，查看网页的源代码可以大量的信息，这也就是某些站点有意对浏览者屏蔽源代码的原因。在源代码文件中，你也许能够了解到网站开发者建站的方式:他们所使用的软 件类型及软件版本、网站以及网页的架构，有时候甚至能够发现一些网站管理员的个人资料。 业务合作伙伴的站点或一些新的并购企业的站点往往是黑客入侵的关键点。这些站点是间接入侵目标站点的最佳突破口，容易被网站管理员所忽视，给黑客攻击者制造了大量的机会。如果你在这方面没有足够的警惕性，疏忽大意，很草率地新某个新的业务合作者的网站和你自己的站点联接起来，往往会造成很严重的后果，给你的站点带来极大的安全威胁。在这样的情况下，安全问题比经营问题更加重要，一定要确保安全操作。 从外部审视网络 有了上述信息收集，你可以开始审视你的网络了。你可以运用路径追踪命令来查看你的网络拓扑结构图和访问控制的相关设置。你会获得大量交换机的特征信息，用来旁路访问控制设备。 注意，命令的反馈结果会因为所使用操作系统的不同而有所差别。UNIX操作系统使用UDP，也可以选择使用ICMP;而Windows操作系统默认用ICMP来响应请求（Ping）。 你也可以用开源工具管理大量ping sweep、执行TCP/UDP协议扫描、操作系统探测。这样做的目的就是要了解，在那些外部访问者的眼中，你的网络系统的运行状况和一些基本的面 貌、特征。因此，你需要检验你的网络系统，哪些端口和服务对外部访问者是开放的或可用的，外部访问者是否可以了解到你所使用的操作系统和一些程序，极其版本信息。简言 之，就是要了解到你的网络系统究竟对那些外部访问者开放了哪些端口或服务，泄露了哪些站点的基本信息。 在你开始上述工作之前，你必须要先获得足够的授权，才能进入整个网络系统并对其进行考察、分析。千万不要将你了解到信息告知那些不怀好意的人。记住:安全防护是一个实 施过程，而不仅仅是一种技术。
2. 如何测试一个网站是否有安全漏洞
扫描网站漏洞是要用专业的扫描工具，下面就是介绍几种工具
1. Nikto
这是一个开源的Web服务器扫描程序，它可以对Web服务器的多种项目进行全面的测试。其扫描项目和插件经常更新并且可以自动更新。Nikto可以在尽可能短的周期内测试你的Web服务器，这在其日志文件中相当明显。不过，如果你想试验一下，它也可以支持 LibWhisker的反IDS方法。不过，并非每一次检查都可以找出一个安全问题，虽然多数情况下是这样的。有一些项目是仅提供信息类型的检查，这种检查可以查找一些并不存在安全漏洞的项目，不过Web管理员或安全工程师们并不知道。
2. Paros proxy
这是一个对Web应用程序的漏洞进行评估的代理程序，即一个基于Java的web代理程序，可以评估Web应用程序的漏洞。它支持动态地编辑/查看 HTTP/HTTPS,从而改变cookies和表单字段等项目。它包括一个Web通信记录程序，Web圈套程序，hash 计算器，还有一个可以测试常见的Web应用程序攻击的扫描器。
3. WebScarab:
它可以分析使用HTTP和HTTPS协议进行通信的应用程序，WebScarab可以用最简单地形式记录它观察的会话，并允许操作人员以各种方式观查会话。如果你需要观察一个基于HTTP(S)应用程序的运行状态，那么WebScarabi就可以满足你这种需要。不管是帮助开发人员调试其它方面的难题，还是允许安全专业人员识别漏洞，它都是一款不错的工具。
4. WebInspect：
这是一款强大的Web应用程序扫描程序。SPI Dynamics的这款应用程序安全评估工具有助于确认Web应用中已知的和未知的漏洞。它还可以检查一个Web服务器是否正确配置，并会尝试一些常见的 Web攻击，如参数注入、跨站脚本、目录遍历攻击等等。
5. Whisker/libwhisker :
Libwhisker是一个Perla模块，适合于HTTP测试。它可以针对许多已知的安全漏洞，测试HTTP服务器，特别是检测危险CGI的存在。 Whisker是一个使用libwhisker的扫描程序。
6. Burpsuite：
这是一个可以用于攻击Web应用程序的集成平台。Burp套件允许一个攻击者将人工的和自动的技术结合起来，以列举、分析、攻击Web应用程序，或利用这些程序的漏洞。各种各样的burp工具协同工作，共享信息，并允许将一种工具发现的漏洞形成另外一种工具的基础。
7. Wikto:
可以说这是一个Web服务器评估工具，它可以检查Web服务器中的漏洞，并提供与Nikto一样的很多功能，但增加了许多有趣的功能部分，如后端 miner和紧密的Google集成。它为MS.NET环境编写，但用户需要注册才能下载其二进制文件和源代码。
8. Acunetix Web Vulnerability Scanner :
这是一款商业级的Web漏洞扫描程序，它可以检查Web应用程序中的漏洞，如SQL注入、跨站脚本攻击、身份验证页上的弱口令长度等。它拥有一个操作方便的图形用户界面，并且能够创建专业级的Web站点安全审核报告。
9. Watchfire AppScan：
这也是一款商业类的Web漏洞扫描程序。AppScan在应用程序的整个开发周期都提供安全测试，从而测试简化了部件测试和开发早期的安全保证。它可以扫描许多常见的漏洞，如跨站脚本攻击、HTTP响应拆分漏洞、参数篡改、隐式字段处理、后门/调试选项、缓冲区溢出等等。
10. N-Stealth：
N-Stealth是一款商业级的Web服务器安全扫描程序。它比一些免费的Web扫描程序，如Whisker/libwhisker、 Nikto等的升级频率更高。还要注意，实际上所有通用的VA工具，如Nessus, ISS Internet Scanner, Retina, SAINT, Sara等都包含Web 扫描部件。N-Stealth主要为Windows平台提供扫描，但并不提供源代码。
3. 注入漏洞的检测方法
目前比较准确的检测注入漏洞的方法是进行网站漏洞扫描，推荐EeSafe网站安全联盟。
查找与修补
一、注入点的查找
当我们想要测试某个站点时，一般会架上注入工具对其狂轰乱炸，这样做虽然有时能找到注入点，但还是有些盲目，我个人的看法是：如果有源码的话，就从源码入手，在源码中查找注入点。对于源码，有些朋友可能觉得很难，其实源码并不神秘，它也是有一定的语法规则的，看一套优秀的源码就像是在欣赏一部精美的电影，只要我们坚持每天看一些优秀源码，再加上网络这个老师的指点，用不了多久，源码的神秘面纱就会被你揭去。闲话少说，下面我们就开始查找注入点，目标有两个：一是Request，二是SQL语句。
说到Request，这个是ASP程序中的一个内建对象，怎么？不懂？那就跟我先来恶补一下吧！它是用来获取客户端信息的，有五种方法，而会出现注入点的一般有以下三种：
1、Request.QueryString：取得客户端提交的信息。当Form以Get方法提交信息，或是直接在URL中提交变量值时，在服务器端接收数据时采用的就是这种方法。
2、Request.Form：同样也是取得客户端提交的信息，但它接收的是Form以Post方法提交的信息。
3、Request.Cookies：取得客户端浏览器的Cookies信息。Cookies就是小甜饼，指的是一些私人信息，如用户名、密码之类的信息。
有些程序员为了减少错误，对于前两种信息的获取，会采用Request来取得客户端提交的信息，这种方法，虽然可以通吃Request.QueryString和Request.Form的提交信息，但如果过滤的不好，就会被漏洞反咬一口。
了解过一些Request的知识后，下面就在“查找”中输入“request”进行搜索，OK！当找到上面所列的三项Request语句后，再来看一下程序对这些Request语句是否做了过滤，比如ID值是否用INT过滤，例：id=int(request(id))；字符串值是否用replace ()或instr()等函数进行过滤单引号或一些特殊字符，例：username=replace(request(username),, )；或者程序是否采用本身的一些过滤函数来过滤这些提交值。从查找到这句request参数起，一直到SQL语句中使用这个提交值至，如果中间没有上面的层层关卡，那么，一个注入点，基本上就算是出现了。
说到SQL语句，不能不提到以下几个常用的语句：
1、查询语句：Select [(<字段名1> [,<字段名2>, ...])] FROM <表名JMDCW> [Where <条件表达式> [AND|OR <条件表达式>...]
2、更新语句：Update <表名JMDCW> SET 列名1 = 常量表达式1[,列名2 = 常量表达式2 ...] Where <条件表达式> [AND|OR <条件表达式>...]
3、删除语句：Delete FROM〈表名JMDCW〉[Where <条件表达式> [AND|OR <条件表达式>...]]
这里不对SQL语句做介绍了。在上面列出的SQL语句中，注入点出现频率最高的是Select语句，而注入参数的出没地通常都是在Where之后的条件中。当一个没有过滤的Request语句进入SQL语句后，就是注入大显身手的时候了，不过，在进行注入之前还要先看一下该参数是直接引入，还是用单引号引入的，另外，该参数是否还应用于其他SQL语句中，然后，根据不同的信息，选择不同的处理方式，或直接暴破，或UNION查询，当然，如果存在注入点的程序使用的是SQL数据库，那就不单单是得到一些重要信息，甚至还可以增加管理员。
下面用“蚂蚁影院3.0”版注销用户(wantlogin.asp)中的一段源码来做一下介绍：
引用
<%
if request(userid1)<> then
set rst=server.createobject(adodb.recordset)
sql=select money,online from users where userid=&request(userid1)& and password=&md5(request(pws))&
rst.open sql,conn,1,3
if rst.eof and rst.bof then
response.write<script>alert(用户名或密码错误！);history.back();</Script>
else
response.write<script>alert(恢复成功你现在可以登陆！);</Script>
response.write<script Language=Javascript>location.href = index.asp;</script>
rst.close
set rst=nothing
conn.close
set conn=nothing
end if
end if
%>
在其流程中，首先判断取得的提交值userid1是否为空，不为空的话就进入SQL语句中，验证取得的用户名及密码是否和数据库内的用户名及密码一致，如果不一致，则弹出“用户名及密码错误”窗口，否则，就弹出“恢复成功”的窗口。这也是一段典型的注入漏洞源码，并且，接收的方式还是使用的 request，这就给我们提交注入语句提供了最大的方便。如果我们在URL地址中提交如下字符：http: //127.0.0.1/wantlogin.asp?userid1=aa&pws=bb，因为没有aa这个用户，那么就会弹出错误窗口，而如果我们将aa换成如下字符：aa or1=1 or 1=1，pws保持不变，这样提交的语句到了SQL语句中就成了如下语句：
select money,online from users where userid1=aa or 1=1 or 1=1 and password=md5(bb)，以往我们所见到的测试代码一般为“or 1=1”，而这里却多用了一个 or ，为什么要多用一个or呢？解释一下，在逻辑运算符中，and的优先级别高于or ，程序运行后会先运算后面的1=1 and password=md5(bb)，因为密码是随便输入的，所以and后的password值为假，而and前的1=1虽然为真，但真and 假=假，所以，这个and的运算值为假，再来看or运算，因为前面的用户名也是不存在的，其值当然为假，如此一来，where后的逻辑运算就成了如下表达式：假or真or假，结果值还是为真，这样就会弹出“恢复成功”窗口，如果将其中的or 1=1 改为or 1=2，那逻辑表达式则成了：假or假or假，值当然也为假，弹出的就是“用户名或密码错误”的窗口。这样，根据弹出窗口的不同，我们就可以构造一些特殊字符，然后猜测出需要的数据了，比如查询管理员ID的语句，将or后的1=1更改为： 1=(Select top 1 id from admin)，这里暂用admin表示管理员表名，如果存在ID为1的管理员，那么就会弹出“恢复成功”的窗口，否则，就证明管理员的ID不为1，那就要再用其他数字来测试。猜出管理员ID后，再把此段字符更改为猜测管理员名称长度的字符：5<(Select len(adminname) from admin where id=1)，如为真，则证明长度大于5，否则长度小于或等于5。猜出长度后，再用asc()函数来猜测管理员的名称：90<(select asc(mid(adminname,1,1)) from admin where id=1)，如此循环，就能暴破出管理员的名称及密码了。
上面提到的是Request.QueryString和Request.Form的注入方法，而Request.Cookies的注入方法则是要修改本地的Cookies值来实现的，推荐使用一些专门的Cookies修改工具，不过，用Cookies来注入相对而言，就麻烦了好多，但原理和前面的注入是一样的，这里就不介绍了。
二、注入点的修补
在上面着重讲了如何查找注入点及简单的利用方法，当我们知道了攻后，也就明白了如何守，攻和守之间虽然是对立的，但也是相互的。明白了什么地方存在注入点，再来修补也就容易多了。在前面查找注入点时，我也提到查看程序中是否对提交参数进行了过滤，每个程序对注入的过滤函数都不相同，我们在修补自已站点上的注入点时，可参照其他程序中的过滤函数，也可根据自已的需要，单独过滤一些敏感的字符。这里，还是以上面的那个例子来说一下如何修补注入点。在前面的 SQL语句中有这一句：userid=&request(userid1)&，这其中对提交来的参数是用单引号来引入的，而我们能成功注入也是在提交参数中加入了单引号来闭合其语句，这样，加入一个replace()函数对单引号进行过滤，修改后的语句为：userid= &replace(request(userid1),,)&，这样用户再提交带有单引号的字符时， Replace()就会将单引号过滤为空，如此一来，提交的那些特殊字符也就失去了其意义。
当然，我们还可以在userid1进入SQL语句之前，对其长度进行一下判断，如果超过规定的长度，就弹出错误，中止页面执行并返回到指定的页面。当然还可以借鉴一些优秀源码中的过滤方法。总之，注入漏洞是可以避免的，即使出现了注入点，只要我们分析出其出现的原因，也就能很容易地将其修补了！
