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

　　2. 数据验证类型： 如果web server端提交sql语句时，不对提交的sql语句验证，那么一个黑客可暗喜了。他可将提交的sql语句分割，后面加一个delete all或drop database的之类语句，能将你的数据库内容删个精光！我这一招还没实验在internet网站上，不知这样的网站有没有，有多少个。反正我负责的那个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的文章不存在。黑客利用这点可以慢慢得试用后台管理员的用户和密码。