想到了这点后，我打开刚才用X-Scan扫描后生成的报表文件，找到“安全漏洞及解决方案”栏目，看到了几个可能会有CGI漏洞的目录。在地址栏输入其中之一，返回结果如图1所示。

　　一些很典型的JSP文件和JS文件都列出来了。大喜之下，随便选择一个文件，点击右键，然后，选择“用FlashGet下载全部链接”选项，于是，这个目录下的所有文件都被我下载到了本地。

　　其中最有价值的是一个名字为dbconn.js的文件，看来程序设计者是为了方便省事，把一些数据库连接的密码和连接地址都写在里面了（这是很多开发者可能会忽略的问题）。不过，我现在最关心的还是Tomcat的管理员密码。

　　简单破解后，发现Tomcat系统中的admin用户使用了非常简单的口令：web123456。利用这个漏洞，有了这个密码，下面的工作就相对简单了。

　　专家支招：对于网站中的漏洞，我们要即时打上各种补丁，然后对几个已知的安全弱势方面进行加强，比如我们可以将“/admin”目录进行修改，让入侵者不容易找到管理路径。然后关闭Tomcat的目录浏览功能，让入侵者的漏洞尝试彻底失败。

　　入侵测试第三步：注入攻击

　　很多网站对于注入防范做得都很不到位，注入攻击可以让网站暴露出自己的数据库信息以至于暴露数据库表中的管理员账号和密码。

　　重新登录Tomcat的管理界面，点击“Context （Admin）”这个链接，列出了WEB目录下的一些文件和目录的名称，现在就可以对Tomcat的Context进行管理，例如查看、增加、删除Context。

　　回到Tomcat的管理界，我发现了一个上传文件的组件，并且网站还有一个论坛。于是，我编写了一个input.jsp文件，并将它当作一般的Web 应用程序，通过上传的组件上传到对方的WEB目录里。打开input.jsp这个页面（图2）。

　　网页对查询窗体不会做任何输入验证，但是对用户名称的窗体则会。将数据填入窗体，来测试一下网页的漏洞，例子如下：

　　（1）将<script language="javascript">alert(document.cookie)</script>填入搜索字段，以便用XSS 来显示进程的cookie。

　　（2）将<iframe src=http://jakarta.apache.org></iframe>填入搜索字段来示范HTML 注入攻击。

　　通过这些方法，我得到了一些论坛的用户信息，当然，这些都是针对JSP做的一些测试，以验证Web应用程序中的所有输入字段。有了用户信息，却没有密码，怎么办？在登录时，我发现了一个8888端口，这会是个什么服务呢？

　　专家支招：在网页连接数据库的设计中，网页设计人员要加入对一些敏感符号的审核机制，屏蔽一些在数据库中有作用的符号，这可以在很大程度上成功防御注入攻击。

　　入侵第四步：攻其“软肋”

　　根据入侵的逐渐深入，系统存在的安全问题也渐渐清楚，下面就是针对网站

上一页  [1] [2] [3] 下一页