一个完整的Web安全体系测试可以从部署与基础结构，输入验证，身份验证，授权，配置管理，敏感数据，会话管理，加密，参数操作，异常管理，审核和日志记录等几个方面入手

Web安全性测试
数据加密：某些数据需要进行信息加密和过滤后才能进行数据传输，例如用户信用卡信息、用户登陆密码信息等。此时需要进行相应的其他操作，如存储到数据库、解密发送要用户电子邮箱或者客户浏览器。目前的加密算法越来越多，越来越复杂，但一般数据加密的过程时可逆的，也就是说能进行加密，同时需要能进行解密！
登录：一般的应用站点都会使用登录或者注册后使用的方式，因此，必须对用户名和匹配的密码进行校验，以阻止非法用户登录。在进行登陆测试的时候，需要考虑输入的密码是否对大小写敏感、是否有长度和条件限制，最多可以尝试多少次登录，哪些页面或者文件需要登录后才能访问/下载等。)s X*j*uL!LgW+I2F10542超时限制：WEB应用系统需要有是否超时的限制，当用户长时间不作任何操作的时候，需要重新登录才能使用其功能。
SSL：越来越多的站点使用SSL安全协议进行传送。SSL是Security Socket Lauer(安全套接字协议层)的缩写，是由Netscape首先发表的网络数据安全传输协议。SSL是利用公开密钥/私有密钥的加密技术。（RSA），在位于HTTP层和TCP层之间，建立用户与服务器之间的加密通信，确保所传递信息的安全性。SSL是工作在公共密钥和私人密钥基础上的，任何用户都可以获得公共密钥来加密数据，但解密数据必须要通过相应的私人密钥。进入一个SSL站点后，可以看到浏览器出现警告信息，然后地址栏的http变成https，在做SSL测试的时候，需要确认这些特点，以及是否有时间链接限制等一系列相关的安全保护。51Testing软件测试网 u~&K)y8k
服务器脚本语言：脚本语言是最常见的安全隐患，如有些脚本语言允许访问根目录，经验丰富的黑客可以通过这些缺陷来攻击和使用服务器系统，因此，脚本语言安全性在测试过程中也必须被考虑到。
日志文件：在服务器上，要验证服务器的日志是否正常工作，例如CPU的占用率是否很高，是否有例外的进程占用，所以的事务处理是否被记录等。
目录：WEB的目录安全是不容忽视的一个因素。如果WEB程序或WEB服务器的处理不适当，通过简单的URL替换和推测，会将整个WEB目录完全暴露给用户，这样会造成很大的风险和安全性隐患。我们可以使用一定的解决方式，如在每个目录访问时有index.htm,或者严格设定WEB服务器的目录访问权限，将这种隐患降低到最小程度。

WEB应用安全的增强只有两种解决途径，“黑箱子”安全测试和“白盒子”安全测试。
所谓“黑箱子”安全测试方法是指目标测试网站已经正常投入使用的情况下，采用不影响业务正常运转的技术手段进行远程测试，通过模拟黑客的惯用入侵伎俩和手法，测试目标WEB系统在真实的不法攻击压力下的安全性。所谓“白盒子”安全测试方法是指在目标网站还处于开发阶段的时侯，进行基于安全编码规则的源代码级别测试。这种测试方法所需要的代价很高，通常需要精通WEB系统安全的安全编码专家带领程序员对整个系统源代码进行阅读和纠错，增加安全代码以使得“黑箱子”安全测试得到安全的结论。所以，确保网上银行WEB系统应用程序的安全不是一件简单的事，而不幸的是对WEB应用程序的攻击是非常容易实施的。从信息安全的层面，黑客针对WEB的攻击可以达到从窃取产品和敏感信息到使整个WEB站点甚至后台核心数据库服务器完全瘫痪。
一个黑客通常都会花上几个小时来熟悉他企图突破的WEB应用程序，他会象编制这一套程序的程序员那样思考程序的设计和编码，然后找出编程时留下的漏洞，然后通过浏览器恶意地与应用程序以及数据库进行交互，造成或大或小的损害。要防止这些问题，公司必须预先找出网站的弱点然后关闭有可能被黑客可利用的缝隙。

针对电子商务和网上交易WEB应用平台的安全隐患分类如下：
应用层缓冲区溢出（压力测试）
COOKIE POISONING cookie安全使用状况评估

跨站脚本攻击风险评估

页面隐藏参数域篡改风险评估

系统隐蔽指令执行风险评估

第三方误配置安全隐患

各类型已知安全漏洞
URL参数篡改攻击风险评估
后门程序和调试选项遗留隐患
WEB内容强力浏览问题

一个完整的WEB应用是颇为复杂的，它提供电子商务系统的商务逻辑，使得用户可以与WEB站点进行交互操作，其交易活动可以和后台数据库系统接口。WEB应用通常包括下面几个关键组件。

用户接口代码：这是WEB应用的表示层，它创建了站点的可视界面，是联系客户端以及WEB服务器的接口部分，通常采用HTML、Java、Javascrīpt、ActiveX、VB以及其他第三方编写方式。

WEB服务器软件：WEB服务器用来支持用户浏览器和WEB应用之间的正常通信，它负责处理HTTP请求/响应消息、管理用户会话。几乎所有的WEB站点都采用第三方厂商的WEB服务器产品，例如IIS、iPlanet、Apache等。
前端系统：前端系统直接同用户接口代码、操作系统、后台系统进行交互，客户端通过用户接口代码传递的参数将被前端系统处理，最有代表性的例子就是各种CGI、JSP和ASP代码。

后台系统：后台系统是WEB应用真正的驱动部分，它负责处理真正的商务逻辑，直接与数据库系统接口。后台系统通常都是客户定制开发的。
数据库系统：WEB站点通常会采用第三方数据库软件，包括MySQL、Oracle、DB2等。
U:p&{ aF?10542一个如此复杂的WEB系统，其安全保护机制也应该是多层次全方位的，这是因为构成WEB系统的每一个环节都可能存在脆弱性并由此引入风险，所以每个环节都需要相应的安全控制，例如在WEB应用的用户接口代码中对一些违犯语法规则的数据进行过滤，在前端系统和后台系统中对异常内容进行校验。不过，我们也看到，尽管多数WEB应用都采用了这样那样的安全控制措施，但由于其本身构成的复杂多样，出现某些漏洞也在所难免。

   怎样最大程度发现并解决WEB应用系统的漏洞呢？一种方法就是在软件编写过程中进行测试，这也是软件开发周期中一项重要的工作。还有一点非常重要，那就是在WEB应用系统配置完毕正式启用之前对它进行在线评估，通常这是通过远程的安全扫描来实现的。
0m!r!F-j\C4b;PN10542但是，我们看到，传统的安全扫描技术是有许多缺陷的，一个是不能对未知漏洞进行检测，另一个就是其判断依据过于简单（只依靠HTTP响应消息中的状态码来判断），经常造成误报和漏报，极大地影响了WEB系统安全评估的可靠性和准确性。
那么，怎样才能解决这一问题呢？
   为了进行有效的WEB安全性审计，除了用传统的扫描器进行初步检测之外，更多时候，还得依靠技术高超的安全专家，手工检测分析目标系统的安全性。手工分析的方法通常包括三个阶段：分析、测试和报告。在分析阶段，测试人员需要对整个WEB应用系统的框架结构深入了解，对每一处牵涉到客户端数据处理的网页内容进行分析，并对与数据库操作相关的部分进行检查，当然，所有的分析工作，都是以一个普通用户的身份，通过正常的WEB访问过程来进行的。测试人员一旦在分析阶段发现了问题（例如某些网页表单存在隐患，某些网页交互功能不健全），就要在测试阶段对这些问题进行实际验证，通过构造各种复杂的测试代码（实际上就是构造客户端提交的表单信息或CGI参数），攫取WEB应用返回的响应消息，从中判断问题存在与否。最终，测试人员会对测试结果进行综合分析，汇总之后提交测试报告。
   上述过程不难给我们一些启发：WEB安全评估不应该只是简单地以已知漏洞库为核心来进行操作，而应该和WEB应用系统实际的操作内容及功能结合起来，进行更深入更智能的分析。实际上，就是把人工测试的过程自动化。
基于以上需求，新型实用的WEB应用安全评估系统具有以下特点：
能够遍历整个WEB系统的拓扑结构，从中找到所有可浏览和可交互的页面；
能够对所有可浏览页面进行内容检索和分析，从中找到所有与客户端/服务器交互相关的动态内容（例如表单）；

能够自动构造各种类型的“异常”提交参数，模拟大多数普遍存在的WEB攻击手段，探测各种已知漏洞和未知漏洞；

能够对响应消息进行内容分析，结合状态码，判断测试结果；

数据库的设计将不仅仅是一个保存已知漏洞特征的漏洞库，而是结合了普遍攻击手段描述内容的专家库，这种专家库可以方便地进行扩充；

基于WINDOWS的操作界面，，迎合用户操作习惯

    总的来说，这种新型的WEB应用安全评估系统应该是一个应用级的、内容分析的专家系统，它把手工测试过程中的专家经验嵌入到自动测试的工具当中，使得常规的静态WEB漏洞扫描演变成为动态可变的全方位的WEB应用系统安全评估。

附：简单的测试

　安全测试方面应该参照spi的web安全top 10来进行。
　　目前做软件测试人员可能对安全性测试了解不够，测试结果不是很好。如果经验不足，测试过程中可以采用一些较专业的web安全测试工具，如WebInspect、Acunetix.Web.Vulerability.Scanner等，不过自动化web安全测试的最大缺陷就是误报太多，需要认为审核测试结果，对报告进行逐项手工检测核对。

　　对于web安全的测试用例，可以参照top 10来写，如果写一个详细的测试用例，还是比较麻烦的，建议采用安全界常用的web渗透报告结合top10来写就可以了。

　　现在有专门做系统和网站安全检测的公司，那里做安全检测的人的技术都很好，大多都是红客。
　再补充点，网站即使站点不接受信用卡支付，安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。
　　目录设置　　Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路径"…com/objects/images".然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ，点击 jackpot.在该目录下有很多资料，其中引起我注意的是已过期页面。该公司每个月都要更改产品价格，并且保存过期页面。我翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。　

　　很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息，而且在地址栏中的 HTTP 变成 HTTPS.如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面（适用于3.0 以下版本的浏览器，这些浏览器不支持SSL.当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？

　　登录

　　脚本语言脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用

1.数据验证流程：一个好的web系统应该在IE端，server端，DB端都应该进行验证。但有不少程序偷工减料，scrīpt验证完了，就不管了；app server对数据长度和类型的验证与db server的不一样，这些都会引发问题。有兴趣的可参看一下scrīpt代码，设计一些case，这可是你作为一个高级测试人员的优秀之处哦。我曾修改了页面端的scrīpt代码，然后提交了一个form，引发了一个系统的重大漏洞后门51Testing软件测试网x6BT7{3^?^
2. 数据验证类型： 如果web server端提交sql语句时，不对提交的sql语句验证，那么一个黑客就可暗喜了。他可将提交的sql语句分割，后面加一个delete all或drop database的之类语句，能将你的数据库内容删个精光！我这一招还没实验在internet网站上，不知这样的网站有没有，有多少个。反正我负责的那个web系统曾经发现这样的问题。51Testing软件测试网Q mF4xa+i
3. 网络加密，数据库加密不用说了吧

在软件安全开始越来越受人重视的今天，软件的安全性测试是必不可少了。尤其是WEB软件的安全性，关系到一个
企业的形象和能力。
我把我对WEB软件安全性测试的方法和经验（见笑了只有半年，哈哈），给大家批评和讨论。
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=" &
"a10542cstr(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等网页的文件看是否成功。
补充：
(还有像51Testing软件测试网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值，对其修改，然后提交。这是我在测试过程中所最常碰到的BUG，也是最广泛存在的。由于本人水平有限，有错漏之处请指出，或者大家对WEB的安全性测试有什么心得请和我及大家分享