1. 数据验证流程:一个好的web系统应该在IE端,server端,DB端都应该进行验证。但有不少程序偷工减料,script验证完了,不管了;app server对数据长度和类型的验证与db server的不一样,这些都会引发问题。有兴趣的可参看一下script代码,设计一些case,这可是你作为一个高级测试人员的之处哦。我曾修改了页面端的script代码,然后提交了一个form,引发了一个系统的重大漏洞后门


  2. 数据验证类型: 如果web server端提交sql语句时,不对提交的sql语句验证,那么一个黑客可暗喜了。他可将提交的sql语句分割,后面加一个delete all或drop database的之类语句,能将你的数据库内容删个精光!我这一招还没实验在inte.net网站上,不知这样的网站有没有,有多少个。反正我负责的那个web系统曾经发现这样的问题。

  3. 网络加密,数据库加密不用说了吧。

  WEB软件常碰到的BUG为:


  1、SQL INJETION

 

  2、对文件操作相关的模块的漏洞


  3、COOKIES的欺骗

  4、本地提交的漏洞

 

  ●SQL INJETION的测试方法

 

  原理:

 

  如有一新闻管理系统用文件news.asp再用参数读取数据库里的新闻譬如

 

  http://www.xxx.com/news.asp?id=1这一类网站程序

  如果直接用

  rs.open "select * from news where id=" &

  cstr(request("id")),conn,1,1

  数据库进行查询的话即上面的URL所读取的文章是这样读取的

  select * from news where id=1

 

  懂得SQL语言的知道这条语言的意思是在news读取id为1的文章内容。

  但是在SQL SERVER里select是支持子查询和多句执行的。如果这样提交URL的话

  http://www.xxx.com/news.asp?id=1and 1=(select count(*) from admin

  where left(name,1)=a)


  SQL语句变成了


  select * news where id=1 and 1=(select count(*)


  from admin where left(name,1)=a)

 

  意思是admin表里如果存在字段字为name里左边第一个字符是a的查询news表里id为1的内容,news表里id为1是有内容的,从逻辑上的角度来说是1&P。只要P为真,表达式为真,页面会返回一个正确的页面。如果为假页面会报错或者会提示该id的文章不存在。黑客利用这点可以慢慢得试用后台管理员的用户和密码。


  测试:

 

  测试存不存在SQL INJETION很简单如果参数为整数型的在URL上分别提交http://www.xxx.com/news.asp?id=1and 1=1 和http://www.xxx.com/news.asp?id=1and 1=2

 

  如果第一次返回正确内容,第二次返回不同页面或者不同容内的话表明news.asp文件存在SQL INJETION。如何利用不多说了,毕竟我们都不是为了入侵。

  ● 对文件操作相关的模块的漏洞在测试

 

  原理:

  如一上传文件功能的程序upload.asp如果程序员只注重其功能上的需求没有考虑到用户不按常规操作的问题。如上传一个网页木马程序上去,整个网站甚至整个服务器的架构和源码都暴露而且还有一定的权限。

 

  测试:

 

  试上传asp,php,jsp,cgi等网页的文件看是否成功。

 

  补充:


  还有像 http://www.xxx.com/download/filespath.asp?path=../abc.zip

 

  下载功能的软件如果

 

  http://www.xxx.com/download/filespath.asp?path=../conn.asp

  很可能下载到这些asp的源码数据库位置及用户密码都可能暴露。

 

  其它还有很多,不一一举例了。

  ● COOKIES的欺骗


  原理:

 

  COOKIES是WEB程序的重要部分,COOKIES有利有弊。利在于不太占用服务器的资源,弊在于放在客户端非常容易被人修改加以利用。所以一般论坛前台登陆用COOKIES后台是用SESSION,因为前台登陆比较频繁,用SESSION效率很低。但如论坛程序管理员用户在前台也有一定的权限,如果对COOKIES验证不严的话,严重影响了WEB程序的正常工作。如前期的LEADBBS,只有后台对COOKIES验证严格,前台的位置只是从COOKIES读取用户的ID,对用户是否合法根本没有验证。

 

  测试:

  推荐使用MYBROWER浏览器,可即时显示及修改COOKIES。尝试一下修改里面的对应位置。


  ● 本地提交表单的漏洞

 

  原理:

  Action只接爱表单的提交,所以表单是客户WEB程序的接口。先举一个例子,一个投票系统,分A,B,C,D各项的VALUE是100,80,60,40。

 

  但是如果先把些页面以HTML形式保存在本地硬盘里。然后修改其VALUE,再向其ACTION提交,ACTION会不会接受呢?

  测试:


  如一投票系统,把投票的页面保存在本地硬盘,用记事本打开,找到对应项的VALUE值,对其修改,然后提交。

  强制后台浏览:绕过登陆页面,直接提交系统文件夹或文件页面。不完善的系统如果缺少index.html可能被绕过登陆验证页面。在系统文件夹中保留一些公司机密内容也会造成不可估计的损失。

 

  跨站脚本攻击:基本上这个我只是在论坛??各种形式的论坛里看到过,具体的一个例子,比如这段代码可以被填在任何输入框里 “ SCRIPT>alert("攻击!");

  堆栈溢出攻击:完全的不了解,只是在某个网站上看到,可以对现在的2000、XP、2003进行攻击,非常恐怖,MS应该打了补丁了吧?