应用程序指纹识别
指纹识别是web应用程序测试的第一个步骤。指纹识别会给测试者提供很多有用的信息，某种程度上暴露其他漏洞的脆弱性，更容易实施成功的漏洞攻击。
识别web服务器
识别web服务器是为了尝试检索尽可能多的有关服务器的信息，有以下几点：
服务器的名字和版本
后台是否用了应用程序服务器
后台用的数据库，数据库和服务器是不是在同一机器上
是否使用反向代理
负载均衡策略
运用哪种程序设计语言
检索服务器的名字和版本通过检查http头就很容易得到：
viewsource
09 | Date:Sun,03Mar201310:56:20GMT
|
11 | Server:Apache/2.2.16(Debian)
|
13 | X-Powered-By:PHP/5.3.3-7+squeeze14
|
你也可以用一个假的主机头（或者IP）来获取默认的虚拟主机以进一步获取更多的信息
viewsource
浏览网站
在指纹识别过程中要做的另一件事是简单的浏览下该网站，发现一些有意思的网站功能：
上传下载功能
认证表单和链接：登陆，登出，密码找回功能等
管理员功能部分
可留下数据部分：留言，联系我们等等表单
在这个阶段，有个要做的有意思的事是检查页面源代码检索html注释语。注释部分经常会提供一些关于网站的有意思的信息。所有的浏览器都能让你查看页面源代码。你可以查找html的注释标签：在<!—和–>之间的所有信息。大多数情况下，源代码都有颜色标注的，注释部分很容易被认出来。
网站页面文件的后缀能告诉你网站用的哪种脚本语言：
如果你看到.php结尾的文件，那么这个网站用的脚本程序是PHP
如果你看到.jsp或者.do的结尾的文件，那么这个网站用的脚本程序是java…
显然有些人能写个以.PHP结尾的java脚本程序，或者是以.do结尾的PHP脚本程序，但是这种可能性实际上很小。
通过URL的拓扑结构方式方法也能识别出网站的指纹。举个例子，在Ruby-On-Rails中，对于一个给定的对象，开发者能用脚手架程序自动生成代码管理视图（html源码），模型（存储逻辑）和控制器（业务逻辑）。这种生成的URL拓扑有如下类似的结构：
/objects/给你一个对象的列表
/objects/new给你一个页面去创建新的对象
/objects/12给你一个id为12的对象/objects/12/edit给你一个页面去修改id为12的对象…
检查favicon.ico图标
favicon.ico图标是个小小的图片，浏览网页时能在浏览器url标签找到它：
这个图片能被作为指纹识别的元素，因为大部分应用程序或者服务器有自己独特的标识图标，而大部分开发者或者系统管理员都没有去变更这个图标。举个例子，下面这个图片就是Drupal独有的。
检查robots.txt文件
另一个常被应用程序部署的文件是robots.txt。一些基于PHP的应用程序很经常使用robots.txt来组织网络爬虫来索引网站。这是信息来源的好地方，通过它我们能发现网站有意思的拓扑结构，并从中发现程序用的什么框架来搭建这个网站。
比如说，下面这个rotots.txt表明它用的是Joomla的CMS：
viewsource
01 | #IftheJoomlasiteisinstalledwithinafoldersuch
as at |
03 | #e.g.www.example.com/joomla/therobots.txtfileMUSTbe
|
05 | #movedtothesiterootate.g.www.example.com/robots.txt
|
07 | #ANDthejoomlafoldernameMUSTbeprefixedtothedisallowed
|
09 | #path,e.g.theDisallowrule
for the/administrator/folder
|
11 | #MUSTbechangedtoreadDisallow:/joomla/administrator/
|
15 | #Formoreinformationabouttherobots.txtstandard,see:
|
17 | #http: //www.robotstxt.org/orig.html |
21 | #Forsyntaxchecking,see: |
23 | #http: //tool.motoricerca.info/robots-checker.phtml |
27 | Disallow:/administrator/ |
39 | Disallow:/installation/ |
同时这个文件也告诉你需要接下来要做的检查。一个网站不愿意让别人索引的部分很可能是因为这里是个有意思的安全问题所在。
搜索目录和页面
浏览网站之后，很重要的去搜索网站存在的页面或者目录，但这不是说通过直接的点击页面链接得到。为了达成这个目的，你需要用一个包含所有可能存在的文件或者目录的列表，来检查这些表上的名字在服务器上是否存在。
目录/页面暴力测试
Wfuzz（http://www.edge-security.com/wfuzz.php）这个工具可以通过导入名字字典文件来检查服务器上存在的页面和目录。
下面的命令执行后可以检查存在的远程文件和目录：
$pythonwfuzz.py-c-zfile,wordlist/general/common.txt–hc404http://vulnerable/FUZZ
你可以用Wfuzz做更多的事情：
通过返回的http错误代码做过滤器
只检索给点后缀的文件名：http://vulnerable/FUZZ.php.
暴力破解证书凭据
…
用其他工具也是一样的，最好的学习方式是一边使用工具一边看你能做什么。
寻找管理后台页面
大部分管理页面都是耳熟能详的URL，通常可以用目录爆破器探知，但是为每一种架构的服务器***一份管理页面文件还是相当快捷有效的。你可以参考product/project文档说明来获取这个信息。
在你***的管理后台页面列表中，同时要保存着默认的可使用的登陆凭据。
产生的错误提示
测试过程中产生的404错误能给你许多关于后台服务器运行的web应用程序的信息。为了制造这种错误，你只需要在提交的url链接上加一些随机字符串，比如随机长串。
通过调节Web服务器的配置显然可以改变这一回显错误行为。如果你遇到的是tomcat服务器，将返回下面的404错误：
如果是Ruby-on-Rails：
有许多方法可以在web应用程序中制造错误。比如，在url中添加一些特殊字符，可以是空值（%00）、单引号（%27）、双引号（%22），这些字符都可能导致错误的产生。或者你也可以将http请求中的某些参数值给去除。一旦你成功的制造了错误并得到了相应的错误页面，你就能明白你所攻击的是什么类型的应用程序（举个tomcat的例子）：
任何事都有可能改变浏览器的行为，但是生成的错误页面是获取信息的好方法。对于一个php程序来说有个简单的测试方法，将形如/index.php?name=hacker替换为/index.php?name[]=hacker。
最重要的一件事是你要学会读懂这个错误提示。这个听起来可能不以为然，但是你会惊讶为什么那么多人把两种错误当做一样的，即使两者错误信息是不同的：细节决定成败。
记录信息
测试过程中的任何信息都要记录下来，任何事情都要被保存下来：
远程服务器的路径地址
错误信息
后台使用的数据库
报头泄露的内部IP地址
其他任何事情…
记录信息能帮助你实施另外的漏洞攻击。举个例子，假如你需要服务器网站的物理地址来完成攻击，你可能已经通过应用程序另一块的错误信息得到这个地址信息。
编写一些有用的工具
编写一些简单的脚本工具来发送http请求是非常方便的。推荐编写以下的辅助小工具：
一个用传统HTTP库函数（比如ruby的net/http）编写的HTTP客户端和一个用socket编写的只能发送简单的get和post请求的客户端
一个能支持SSL协议的HTTP客户端（包括用HTTP库和socket编写的两种）
一个支持cookie的HTTP客户端（包括用HTTP库和socket编写的两种）
一旦你成功开发并使用这些工具了，你可以尝试将他们整合在一个工具中。
只要你准备好了这些工具，就很容易利用它们实施一次漏洞攻击或者在测试中发现一些问题。复杂的漏洞都需要一些自动化的测试过程。如果你没有自己的HTTP客户端程序来辅助的话，你就很难成功实施漏洞攻击。我们将在下一章当中与大家分享一些Web漏洞、攻击的样例。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理
