|
|
|
|
|
Web应用系统开发完成后，需要对Web应用进行全面的测试，其测试方法与其他系统的测试既有相同之处，又有不同之处。
|
|
|
|
|
|
. 测试内容基本相同：Web应用系统作为软件系统的一种形式，其测试内容也会包括功能、性能、易用性、兼容性和安全性测试等内容。
|
|
|
|
. 某些项目的测试方法基本相同：例如Web应用程序的功能测试与其他系统的功能测试方法是一样的，同样是根据功能说明书、需求说明书等文档，使用因果图法、边界值法等技术，设计测试用例进行测试。
|
|
|
|
. 测试手段基本相同：Web应用系统的测试一样会采用人工测试、工具测试、评估等手段。
|
|
|
|
鉴于Web系统的自身特点，其测试与传统的软件测试也有所不同，使测试基于Web的系统变得困难。
|
|
|
|
首先是测试的重点不一样：Web应用系统的性能可能是开发者或用户最关心的一个测试内容，由于Internet的不可预见性和用户连接数的不固定性，人们经常对Web系统的稳定水平有所担心。另外，一些不断发展中的Web设计技术也使Web组件测试变得重要。安全性对某些涉及交易或重要数据的Web应用系统也很重要。由于用户客户端的不确定性，易用性测试和客户端配置与兼容性测试也是必要的一个内容。
|
|
|
|
其次是测试采用的工具有所不同Web应用的一些测试，如链接测试、表单测试、界面测试等，通常采用可以重复执行的自动化工具进行，性能测试除了采用LoadRunner、QALoad等通用的负载压力测试工具外，还有很多专门用于Web系统性能测试的工具，如WAST（Web Application Stress Tool）、ACT (Application Center Test)、Webload等。
|
|
|
|
最后Web应用系统迫切需要新的测试技术和方法：Web应用系统的开发技术是更新最快的开发技术之一，针对这种新组件、新技术的测试手段也必须及时探索，甚至要开发出新的测试工具以满足需求。
|
|
|
|
|
|
Web应用功能测试指Web应用系统的基本功能的测试，其案例的设计方法可参见有关《黑盒测试技术》章节的内容。
|
|
|
|
考虑到Web应用本身的特点，其功能测试还要注意以下几个方面。
|
|
|
|
|
|
Web应用客户端软件环境主要包括操作系统和浏览器。除非有特殊要求，测试功能时，我们一般选择比较流行的配置，如选择WindowsXP+IE6.0的简体中文版本。需要注意的是，浏览器的种类和版本有可能影响功能的正确实现。
|
|
|
|
|
|
一般情况下，开发者不会过多地考虑客户端配置问题，只是将更多的时间用于实现服务端的程序，而用户也往往不会刻意地对所使用的浏览器进行适应性配置。如果测试人员完全按照浏览器的缺省配置测试一个Web应用的功能，有可能会出现较多的因浏览器配置而引起的问题。下面以IE6.0为例进行说明，IE6.0的主要配置界面如下图所示。
|
|
|
|
|
|
|
|
例如Cookie设置就会影响含有Cookie的Web应用的功能能否成功地实现。其他如脚本设置、安全设置、显示设置等大多数设置都会影响到Web应用功能的实现。
|
|
|
|
|
|
大多数人都喜欢使用1024×768像素的显示设置，但并不是所有的Web应用都支持这种设置。不合适的显示设置不但会使Web应用系统的界面显示异常，还可能导致应用功能无法实现。
|
|
|
|
|
|
由于Web应用带有一定的开放性，尤其是发布于互联网上的网站，其内容是完全开放的，因此在Web系统的功能测试中还要重点测试一个方面，即内容测试。
|
|
|
|
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题，甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的“拼音与语法检查”功能；信息的相关性是指，是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中所谓的“相关文章列表”。
|
|
|
|
下面介绍两种Web应用功能测试的自动化技术，一个是Web应用链接质量保证技术，另一个是Web应用功能测试技术，下面分别论述。
|
|
|
|
|
|
链接是使用户从一个页面浏览到另一个页面的重要手段，链接的质量决定着功能是否能够成功实现。
|
|
|
|
|
|
|
|
|
|
③保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面。
|
|
|
|
链接测试非常复杂。比如当网页的结构非常复杂且数量巨大时，链接检查的速度就迫切需要提高。当网络连接总是不稳定的时候，误判的频率增大导致工作量加大，就需要保证工作进度。还有，测试的结果能否清晰地报告出来等，这些需求都提高了测试的复杂度。
|
|
|
|
要测试Web应用的链接，可以借助于自动化的Web应用链接测试工具，例如WebCheck、Linkbot、TestPartner等。这些测试工具在测试过程中自动扫描Web应用的所有链接，定位及报告问题。针对应用中存在的各种各样的链接，比如图片、框架（Frame）、插件（Plugin）、背景、样式表（Style Sheet）、脚本、Java Applet等以及支持的连接种类，比如HTTP、FTP、GOPHER、HTTPS等工具都能够支持。另外，对本地的链接和重定向的链接也能很好地支持。例如WebCheck能够定位约50个的问题类型，并且提供19个HTML格式的报告。
|
|
|
|
利用自动化测试工具测试Web应用的链接，主要优势体现在以下几个方面。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
. 检查结果可以分类查看，自动生成HTML格式的报告。
|
|
|
|
|
|
. 测试内部和外部链接中成功和失败的链接点，以及应用中不被其他链接调用的页面；
|
|
|
|
. 测试链接中新网页、老网页、慢网页以及丢失的图象标题标签和属性标签等；
|
|
|
|
. 分析Web应用的结构是否合理，包括显示和某个URL相关的链接及按照标题、描述、作者、大小、最后修改时间、类型为URL链接分类等。
|
|
|
|
|
|
如果开发人员刚创立一个新的Web应用系统。在发布应用系统之前，它必须经过测试以确保一切设定功能都能正常运行，这样的测试任务中，针对同一模块或者同一功能点的测试可能需要重复多次。另外，在一个公司中不同项目的测试可能并行展开，例如人事部门的HR系统、客服部门的CRM系统、物流部门的ERP系统等。这样的现状就会使测试人员面临这样一个问题，即“如何有效地测试不断修改着的一个或多个应用程序”。如果资源有限的话，这个问题就更加棘手。人工测试的工作量太大，况且很多公司负担不起额外的时间来培训新的测试人员。为了解决这个问题，就需要一个能简单操作的测试工具来自动完成功能性测试。
|
|
|
|
Mercury Interactive的WinRunner就是一个功能性测试工具。它通过捕获和重放用户对Web应用程序的操作，WinRunner可自动执行功能性测试。下面我们来看一个标准的测试过程，主要步骤包括：创建测试脚本、插入检查点、运行测试以及分析结果。
|
|
|
|
|
|
创建测试脚本只需记录下一个标准的业务流程，如下一张订单或建立一个新的商家账户。测试人员在GUI上点击鼠标，测试工具记录流程就可建立测试脚本，即使技术知识有限的用户也能生成完整的测试。脚本可以直接编辑来满足各种复杂测试的需求。例如，WinRunner可以将两种测试脚本创建方式结合在一个环境下，来适应测试需求。这两种测试脚本创建方式分别是模拟控件操作和模拟鼠标操作。
|
|
|
|
|
|
在记录一个测试的过程的脚本中，测试工程师可插入检查点，测试工具会收集检查点的性能指标。脚本运行时，测试工具在查寻潜在错误的同时，会比较检查点所设定的结果和实际测试结果，对其一一验证。例如，WinRunner允许您使用几种不同类型的检查点，包括文本、GUI、位图和数据库。用一个位图检查点，可以确认一个位图图像，如公司的图标是否出现在指定位置。
|
|
|
|
|
|
建立起测试脚本，并插入检查点和做一些必要修改后，就可以开始运行测试。当测试工具执行测试时，它会自动操作应用程序，正如一个真实用户根据记录流程执行着每一步的操作。
|
|
|
|
|
|
一旦测试结束后，就需要分析测试结果。测试工具一般会提供详尽的、易读的报告，这些报告对在测试运行中发生的重要事件进行描述，如出错内容和检查点等。
|
|
|
|
一次测试结束后，随着时间推移，开发人员会对应用程序做进一步的修改，并需要另加额外的测试。有了前面利用自动化测试工具进行测试的基础，不必改动测试脚本，就可以重新建一个新的测试，这样大大地节省了时间和资源，充分利用了测试投资。
|
|
|
|
功能自动化测试工具还能验证数据库的数值，从而确保交易的准确性。例如，在创建测试脚本时，可以设定哪些数据库表格和记录资料需要检测。在重放时，测试程序就会核对数据库内的实际数值与脚本中设定的数值，在有更新/修改，删除或插入的记录上会使用突出标识以引起注意。
|
|
|
|
有时为了彻底全面地测试一个应用程序，需要了解对于不同类型的数据，它是如何运行的。测试工具可以将一个记录下的业务流程转化为一个数据驱动的测试，来反映多个用户各自独特且真实的操作行为。以一个订单输入的流程为例，测试人员或许希望将一些锁定的项目栏，如定单号或客户名转化为可变栏，这样就可以用多套数值来检测应用程序了。数据来源可以采用自动生成表格，也可直接从其他的表格或数据库中导入。数据驱动性测试不仅节省了时间和资源，而且提高了应用程序的测试覆盖率。
|
|
|
|
利用自动化测试工具在对脚本进行编辑的时候，可以从列表里选择一个功能函数加到脚本中，以提高测试能力。例如，点击“calendar”，然后从年历功能中的下属目录中选择，如“calendar_select_date()”，工具会提供函数的解释。选定了这个函数后，可以输入参数，再将这个函数插入到测试脚本中。
|
|
|
|
|
|
使用Web浏览器作为客户端的一个原因就是它易于使用。用户知道如何浏览一个构建良好的网站。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常重要了。
|
|
|
|
要评估一个Web系统是否易用，首先要分析最终用户的情况。用户的情况决定了Web系统在易用性方面需要花费多少时间，以及易用设计的方向。从用户角度讲，我们主要考虑以下几个方面的情况。
|
|
|
|
|
|
|
|
|
|
确定了最终用户使用的基础情况，我们就可以有针对性地测试一个Web系统的易用性了。我们把Web系统的易用性测试分为三个方面进行测试：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
有人说，除了一定的技术外，Web系统的好与坏取决于其页面的设计艺术水平。这个话虽有失偏颇，但也从另外一个角度说明了Web系统的界面的重要性。由于Web系统的客户端均采用浏览器，不同用户可能会在浏览器里设置不同的显示方式，因此，我们在作界面测试的时候尽量使用默认的设置。
|
|
|
|
在开始进行界面测试以前，我们需要重点调研两个问题：
|
|
|
|
|
|
. Web应用界面（大多数等同于网页）的设计策略是什么。
|
|
|
|
这两个问题决定了我们评价一个Web应用系统界面采用什么样的标准。尽管不同的Web应用系统的界面千变万化，但其测试方法和评价准则仍有一些共同的内容。以下是界面测试中需要重点关注的。
|
|
|
|
|
|
一个复杂的页面会包含多种元素，如文字、表单、图片、动画、表格、视频等，从美学的角度来看，如果只是把所有的Web应用功能简单地堆砌到页面上，其易用性是很差的。需要评估的协调性包括以下几个方面：
|
|
|
|
|
|
|
|
|
|
|
|
一个统一的Web系统的不同页面应该从颜色、框架、操作方式等多个方面统一起来。由于Web日益流行，很多人把它看作图形设计作品。人们为了体现出网页设计的丰富多彩，在不同页面使用很多不同风格的图片、特效，初看觉得网页非常艳丽多彩，但忽略了不同网页的协调统一。
|
|
|
|
|
|
网页设计中用得最多的是表格，而用户操作最容易导致界面缺陷的也就是表格，因此要对表格进行操作验证。例如，需要验证表格是否设置正确、用户是否需要向右滚动页面才能看见表格中的内容；每一栏的宽度是否足够宽，表格里的文字是否都有折行；是否有因为某一格的内容太多，而将整行的内容拉长等。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
辅助功能指为了方便用户更快更容易地使用网站而采用的一些设置，主要包括使用说明、导航、站点地图、帮助等。
|
|
|
|
①使用说明。应该确认站点有使用说明。即使网站很简单，也可能有人在某些方面需要证实一下。测试人员需要测试说明文档，验证说明是正确的。还可以根据说明进行操作，确认出现预期的结果。
|
|
|
|
②导航。导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观，Web系统的主要部分是否可通过主页存取。
|
|
|
|
在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。
|
|
|
|
导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
|
|
|
|
③站点地图。确认你测试的站点是否有地图。有些网络高手可以直接去自己要去的地方，而不必点击一大堆页面。另外，新用户在网站中可能会迷失方向。站点地图可以引导用户进行浏览。需要验证站点地图是否正确，确认地图上的链接是否确实存，地图有没有包括站点上的所有链接。
|
|
|
|
④帮助。帮助在软件的易用性中占很重要的位置，在Web系统中也不例外。Web系统中的帮助可以分为联机帮助、参考式帮助、教程式帮助等，可分别针对其主题进行测试。
|
|
|
|
|
|
我们这里谈到的图形，泛指页面中所有的图片以及彩色元素。在Web应用系统中，图形占有相当重要的位置，因为Web系统应用范围的特殊性，图形直接影响了用户浏览和使用Web系统的操作。
|
|
|
|
适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。和谐的颜色搭配既能体现出Web应用系统的主题，也能反映出业主企业的形象。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮，我们在进行图形测试时重点进行以下测试。
|
|
|
|
. 验证所有的图形是否有明确的用途。特别是图片或动画，有无堆砌的现象，因为过于集中的图片，既浪费传输时间，又影响视觉效果。
|
|
|
|
. 验证所有页面字体的颜色、风格是否一致。字体的颜色应与页面的主色调是否协调。
|
|
|
|
|
|
. 确认图片的大小和质量。这也是一个很重要的因素，图片是否采用JPG或GIF压缩，图片尺寸是否合适，分辨率是否满足需求等都需要进行评价。
|
|
|
|
|
|
性能是用户经常会遇到的一个棘手的问题，也可能是Web系统在投入实际使用以前最为关心的问题。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
从这个过程可以看出，由于客户端是一个单独的个体，几乎不会出现性能问题，而服务器为了响应多个客户端的请求，有可能出现响应错误、响应缓慢、数据丢失等错误。
|
|
|
|
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长，用户就会因没有耐心等待而离开。另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登录了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
|
|
|
|
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线处理的数据量。例如，Web应用系统能允许多少个用户同时在线；如果超过了这个数量，会出现什么现象；Web应用系统能否处理大量用户对同一个页面的请求。负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。
|
|
|
|
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。
|
|
|
|
|
|
|
|
|
|
. 模拟用户请求，以一个比较小的负载开始，逐渐增加模拟用户的数量，直到系统不能承受负载为止。
|
|
|
|
. 如果负载没有达到需求，那么应该优化这个Web程序。
|
|
|
|
|
|
|
|
要实现完全的配置测试和兼容性测试是不可能的，而且从测试成本的角度来看也是不可取的。本项测试目的，是发现Web系统在可能的用户环境下运行程序时出现的错误，对什么样的用户环境进行配置测试与兼容性测试，是需要我们进行分析与调查的。由于Web系统采用浏览器/服务器的模式，我们把配置测试与兼容性测试的着重点放在客户端。而客户端最重要的两个因素就是浏览器与操作系统，所以面向用户的配置测试与兼容性测试可分为以下三个方面：
|
|
|
|
|
|
|
|
|
|
|
|
前面提到，浏览器中有许多会影响Web功能的设置，例如缓存设置、cookies设置、显示设置、安全设置等，在完成了功能测试后，我要需要对选用的浏览器进行配置测试，也就是测试不同配置对Web功能的影响程度，再核查有影响的配置在功能说明书中是否有明确提示。
|
|
|
|
|
|
市场上有很多不同的操作系统类型，最常见的有Windows、UNIX、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能够正常运行，但在另外的操作系统下可能会运行失败。
|
|
|
|
因此，在Web系统发布之前，需要在用户可能用到的操作系统下，对Web系统进行兼容性测试。
|
|
|
|
|
|
浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java、Javascript、ActiveX、Plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，Javascript是Netscape的产品，Java是Sun的产品等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
|
|
|
|
测试浏览器的兼容性可以与操作系统的兼容性结合起来，最有效的方法是创建一个兼容性矩阵，如下表所示。在这个矩阵中，测试不同版本操作系统上的不同厂商、不同版本的浏览器对某些构件和设置的适应性。
|
|
|
|
|
|
|
|
|
|
测试应用程序的体系结构和设计可以消除很多与设计有关的漏洞，从而提高应用程序的整体安全性。设计时修复漏洞要比在开发后期解决问题更为简单，也更经济，因为开发后期可能要进行大量的重新工程处理。开发时如果考虑一些与目标部署环境相关的设计以及该环境定义的安全策略，可确保应用程序的部署更加平稳和安全。如果应用程序已创建完毕，安全测试可修复漏洞并完善未来的设计。
|
|
|
|
一个完整的Web安全体系测试可以从部署与基础结构、输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密、参数操作、异常管理、审核和日志记录等几个方面入手。
|
|
|
|
|
|
|
|
检验底层网络和主机基础结构提供给应用程序的安全设置，然后检验运行环境要求的所有限制。此外，考虑部署的拓扑结构以及中间层应用程序服务器、外围区域以及内部防火墙对设计的影响。检验下列问题，确定可能存在的部署和基础结构问题。
|
|
|
|
|
|
数据在客户端与服务器（或服务器与服务器）之间传输时最易受到攻击。网络负责数据传输的完整性和私密性。如果必须保证数据安全，可使用适当的加密算法。此外，还必须确保网络设备安全。因为这是维护网络完整性所必需的。
|
|
|
|
|
|
如果内部防火墙将Web服务器与应用程序服务器（或数据库服务器）分隔开来，则需要考虑下列问题，确保设计能适应这种配置。
|
|
|
|
|
|
②如果使用域账户和Windows身份验证，防火墙是否打开了必要的端口；
|
|
|
|
|
|
④如果Web服务器使用DTC（Microsoft Distributed Transaction Coordinator）的服务来启动分布式事务，内部防火墙是否为DTC通信打开了必要的端口。
|
|
|
|
|
|
如果部署拓扑结构包括了一个物理远程中间层，则需要考虑下列问题。
|
|
|
|
①是否使用企业服务。如果是，是否已限制了DCOM端口范围，内部防火墙是否打开了这些端口。
|
|
|
|
|
|
③远程处理用在受信服务器方案中，网络是否支持IPSec策略。
|
|
|
|
④ASP.NET承载远程组件是否支持身份验证和授权。
|
|
|
|
⑤是否使用Web服务，如果是，中间层Web服务如何验证Web应用程序的身份。Web应用程序是否通过在Web服务代理中配置凭据来使Web服务验证Web服务器的身份，如果否，Web服务如何明确调用者。
|
|
|
|
|
|
设计是否假定主机基础结构安全限制要失效。例如，安全限制可能要求根据所需的服务、协议或账户特权来对设计进行权衡。需要考虑下列问题。
|
|
|
|
①是否依赖可能不可用的服务或协议。开发和测试环境中可用的服务和协议可能在生产环境中不可用。
|
|
|
|
②是否依赖敏感的账户特权。设计应尽量使用特权最少的进程、服务和用户账户。
|
|
|
|
③要执行的操作是否要求可能不被许可的敏感特权。例如，应用程序是否要创建线程级模拟令牌来创建资源访问的服务身份。这项操作要求“作为操作系统的一部分”特权，而该特权不应授予Web服务器进程（因为可能增加进程被利用的风险）。如果需要此功能，设计应对更高级别的特权进行划分，例如，在进程外的企业服务应用程序中。
|
|
|
|
|
|
运行环境的代码访问安全信任级别决定了代码可访问的资源，以及它能执行的特权操作。请检查运行环境支持的信任级别。如果允许Web应用程序以完全信任级别运行，代码将能够访问操作系统安全性许可的任何资源。
|
|
|
|
如果Web应用程序必须以受限信任级别运行，则代码能访问的资源类型以及能执行的特权操作都将受到一定的限制。在部分信任案例中，设计应对特权代码进行沙盒（sandboxing）处理。此外，还应使用不同的程序集来分隔特权代码。这样，可以对特权代码和应用程序的其余部分单独配置特权代码，然后授予必要的附加代码访问权限。
|
|
|
|
注意：如果应用程序部署在共享服务器（或应用程序将由宿主公司运行），信任级别通常是个问题。此时，需要检查安全策略，然后确定Web应用程序的信任级别。
|
|
|
|
|
|
需要对应用程序验证输入内容的方式进行检验，因为很多Web应用程序攻击都故意使用格式错误的输入。SQL注入、跨站点脚本（XSS）、缓冲区溢出、代码注入以及无数其他拒绝服务和特权提升攻击都可利用输入验证中的漏洞。下表中重点列出了常见的输入验证漏洞。
|
|
|
|
|
|
|
|
测试时应考虑下列问题，以帮助发现潜在的输入验证安全问题。
|
|
|
|
|
|
设计指定的输入验证方法是什么？首先，设计必须展示策略。应用程序应对收到的所有输入进行约束、拒绝和净化。约束输入是最佳的方法，因为针对已知有效类型、模式和范围对数据进行验证，要比通过查找已知坏字符来验证数据简单得多。
|
|
|
|
|
|
|
|
确保设计标出了应用程序的入口点，以便跟踪各个输入字段的操作。可考虑Web页输入、输入到组件和Web服务，以及从数据库输入。
|
|
|
|
|
|
如果输入是从信任边界内受信源传递的，并非总要验证输入；但如果输入是从不受信任的源传递的，必须验证输入。
|
|
|
|
|
|
不要将最终用户看作受信任的数据源。确保对正常和隐藏的表单字段、查询字符串和cookie都进行验证。
|
|
|
|
|
|
如果不进行验证，惟一的安全条件就是数据接收自当前信任边界之内。但是，如果使用深层防御策略，则需要使用多层验证。
|
|
|
|
|
|
这种形式的输入也应验证，特别是当其他应用程序也写入该数据库时。不要对其他应用程序的数据验证程度进行假设。
|
|
|
|
|
|
对于相同类型的输入字段类型，检验使用的是否是相同的验证和筛选库，确保一致地执行验证规则。
|
|
|
|
|
|
客户端验证可用于降低到服务器的回程数量，但不能依靠它来维护安全性，因为它很容易被忽略。需要在服务器验证所有的输入。
|
|
|
|
|
|
检查应用程序处理输入的方式，不同类型的处理可能导致不同类型的漏洞。例如，如果在SQL查询中使用输入，应用程序可能易受SQL注入的攻击。
|
|
|
|
|
|
|
|
检查应用程序是否使用基于输入的名称来制定安全决策。例如，应用程序是否接受用户名、文件名或URL。由于名称的表示方法多种多样，以上各项都极易造成规范化错误问题。如果应用程序接受输入作为名称，则应确保对它们进行验证并在处理之前将它们转换为规范的表示法。
|
|
|
|
|
|
密切注意形成SQL数据库查询的所有输入字段。确保对这些字段的类型、格式、长度和范围进行正确的验证。此外，检查查询的生成方式。如果使用参数化的存储过程，输入参数将被当作文本，而不会当作可执行代码。这是降低风险的一种有效措施。
|
|
|
|
|
|
如果在HTML输出流中包括输入字段，可能受到XSS攻击。确保对输入进行验证，并对输出进行编码。密切注意系统对接受一定范围HTML字符的输入字段的处理方法。
|
|
|
|
|
|
检查应用程序验证调用者身份的方法，在何处使用身份验证，如何确保凭据在存储中或通过网络传递的安全。身份验证中的漏洞可能导致应用程序易受哄骗攻击、词典攻击、会话劫持等。下表重点列出了常见的身份验证漏洞。
|
|
|
|
|
|
|
|
测试中需要考虑下列问题，确定在应用程序进行身份验证的方法中的潜在漏洞。
|
|
|
|
|
|
如果应用程序既有不要求身份验证的公共区域，也有要求身份验证的受限区域，检查站点设计区分二者的方法。必须为受限的页和资源使用单独的子文件夹，然后在IIS中将它们配置为要求SSL来确保安全。这种方法允许只在需要的地方使用SSL来确保敏感数据和身法验证cookie的安全性，从而避免了因在整个站点中使用SSL而造成的附加性能负担。
|
|
|
|
|
|
设计应明确连接不同资源（包括数据库、目录服务和其他类型的网络资源）的服务账户范围。设计中不能使用单个的、有高度特权的账户（有足够的权限连接多种不同类型的资源）。
|
|
|
|
|
|
检查设计并准确标识各账户执行特定功能所需的特权，然后在任何情况下都使用特权最少的账户。
|
|
|
|
|
|
如果是，确保加密这些凭据，然后保存在受限的位置中。例如，保存在有受限访问控制列表（ACL）的注册表项。
|
|
|
|
|
|
测试时考虑与调用者身份验证相关的下列事项。具体事项由设计中使用的身份验证类型决定。
|
|
|
|
①是否在网络中传递明文凭据。如果使用表单或基本身份验证（或使用Web服务并在SOAP头中传递凭据），确保使用SSL来保护传输中的凭据。
|
|
|
|
②是否实现自己的用户存储。如果是，检查用户凭据的存储位置和存储方式。一种常见错误是将明文或加密密码保存在用户存储中。实际上，必须保存密码的哈希值来进行身份验证。
|
|
|
|
如果根据SQL Server用户存储验证凭据，密切注意用户名和密码的输入。检查是否存在恶意注入的SQL字符。
|
|
|
|
③是否使用表单身份验证。如果是，除使用SSL保护凭据外，还应使用SSL来保护身份验证cookie。此外，还要检查设计是否使用受限的会话生存期来抵御cookie重播攻击，并确保加密cookie。
|
|
|
|
|
|
如果应用程序要连接数据库，检查使用的身份验证机制、打算使用的账户（一个或多个），以及如何在数据库中授权应用程序。
|
|
|
|
|
|
|
|
在理想情况下，设计使用Windows身份验证来连接SQL Server，因为这种方法本身更加安全。如果使用SQL身份验证，检查在网络中和数据库连接字符串中确保凭据安全的方法。
|
|
|
|
如果网络基础结构不提供IPSec加密通道，确保在数据库中安装服务器证书来提供自动SQL凭据加密。此外，还要检验确保数据库连接字符串安全的方法，因为这些字符串中包含SQL账户的用户名和密码。
|
|
|
|
|
|
如果使用应用程序的进程账户并使用Windows身份验证连接SQL服务器，应在设计中使用特权最少的账户。本地ASP.NET账户便是为此提供的，尽管对于本地账户来说，用户需要在数据库服务器上创建一个相同的账户。
|
|
|
|
如果打算使用域账户，首先确保它是特权最少的账户，然后打开相关的端口来确保所有相关防火墙都支持Windows身份验证。
|
|
|
|
|
|
如果设计要求使用多个身份来支持数据库中的高粒度授权，则需要检查保存账户凭据（在理想情况下，这些凭据使用数据保护API（DPAPI）加密并保存在安全注册表项中）的方法，以及使用服务身份的方法。
|
|
|
|
此外，还要检查使用哪些进程通过该服务账户创建模拟的安全上下文。该操作不应由Microsoft Windows 2000中的ASP.NET应用程序进程来完成，因为它将强制提升进程账户的特权，并授予“作为操作系统的一部分”特权。这种情况必须尽量避免，它将大大增加风险。
|
|
|
|
|
|
对于使用表单或Passport身份验证的应用程序而言，可为各个程序配置单独的匿名用户账户。然后，启用模拟并使用匿名身份来访问数据库。该方法适于对同一服务器的不同应用程序进行单独的授权和身份跟踪。
|
|
|
|
|
|
如果设计要求模拟原始调用者，必须考虑该方法是否能提供足够的伸缩性，因为连接池是无效的。另一种备选方法是，通过受信的查询参数在应用程序级流动原始调用者身份。
|
|
|
|
|
|
如果数据库连接字符串硬编码，或以明文形式保存在配置文件或COM+目录中，则很容易受到攻击。实际上，应加密它们，然后限制对加密数据的访问。
|
|
|
|
|
|
如果应用程序使用Windows身份验证，Windows安全策略将强制使用强密码、受限登录和其他最佳账户管理策略。其他情况，则由应用程序层负责这些措施。测试要考虑与应用程序账户管理相关的下列问题。
|
|
|
|
|
|
例如，ASP.NET Web页是否使用正则表达式来验证密码复杂性规则。
|
|
|
|
|
|
|
|
|
|
确保不显示类似“不正确的密码”这样的消息，因为它将告诉恶意用户：用户名是正确的。结果，恶意用户便可集中精力破解密码。
|
|
|
|
|
|
如果不强制定期更改密码，用户极有可能不更改自己的密码，结果风险更高。
|
|
|
|
|
|
如果账户泄露，是否能方便地禁用账户来防止攻击者继续使用账户。
|
|
|
|
|
|
记录失败的登录企图是检测攻击者试图侵入的有效方法。
|
|
|
|
|
|
检查应用程序是如何向用户授权的。还要检验应用程序在数据库中是如何被授权的，以及如何控制系统级资源的访问。授权中的漏洞可能导致信息泄漏、数据篡改及特权提升。使用深层防御策略是一种重要的方法，它可应用于应用程序的授权策略中。下表重点列出了常见的授权漏洞。
|
|
|
|
|
|
|
|
测试中需要考虑下列问题，帮助验证应用程序设计的授权策略。
|
|
|
|
|
|
应在设计时从两种角度考虑授权。首先，考虑最终用户授权。哪些用户可访问哪些资源，并执行哪些操作。其次，如何防止恶意用户使用应用程序访问系统级资源。考虑下列问题，验证应用程序的授权策略。
|
|
|
|
|
|
确保设计不依赖于单个网关守卫来加强访问控制。考虑该网关守卫失败（或攻击者设法忽略它）时发生的情况。
|
|
|
|
|
|
可能的选择有IISWeb权限、NTFS权限、ASP.NET文件授权（仅适用于Windows身份验证）、URL授权和用户权限请求。如果不使用某个特定类型，需要明确不使用的理由。
|
|
|
|
|
|
如果是，如何维护角色列表，维护角色列表所需的管理界面安全性如何。
|
|
|
|
|
|
设计是否提供了适当的粒度，使不同用户角色的关联特权得到充分的隔离。避免出现仅为满足特定用户需要而授予角色较高特权的情况。
|
|
|
|
|
|
在应用程序中连接数据库的账户必须有受限的能力，只需满足应用程序的要求即可，不要再高了。
|
|
|
|
应用程序是否使用存储过程来访问数据库呢？建议应用程序使用存储过程来访问数据库，因为一般用户只能授予应用程序登录访问特定存储过程的权限。可以限制登录不在数据库中直接执行创建/读取/更新/删除（CRUD）操作。
|
|
|
|
|
|
设计应用程序时，应考虑应用程序在可访问系统级资源方面的限制。只能授予应用程序访问最低限度的资源。这是缓解风险的一种策略，可在应用程序遭受攻击时限制受损程度。考虑下列问题。
|
|
|
|
|
|
代码访问安全性提供了一种资源约束模型，该模型可防止代码（和Web应用程序）访问特定类型的系统级资源。如果使用代码访问安全性，设计必将受到影响。明确是否在设计规划中包括代码访问安全性，然后通过对特权代码进行隔离和沙盒处理（sandboxing），并将资源访问代码置于自己独立的程序集中，从而进行相应的设计。
|
|
|
|
|
|
设计必须明确应用程序使用的所有身份，包括进程身份和所有模拟身份（包括匿名Internet用户账户和服务身份）。此外，设计还要指出这些身份要访问的资源。
|
|
|
|
在部署时，可对系统级资源配置正确的ACL，确保应用程序的身份只能访问所需的资源。
|
|
|
|
|
|
如果应用程序提供了可配置的管理界面，要检查确保管理界面安全的方法。此外，还要检查如何确保敏感配置数据的安全。下表显示了常见的配置管理漏洞。
|
|
|
|
|
|
|
|
测试时考虑下列问题，帮助验证应用程序设计在配置管理方面的方法。
|
|
|
|
|
|
如果设计指定了远程管理，必须确保管理界面和配置存储的安全，因为这些操作本身非常敏感，而且通过管理界面访问的数据也很敏感。考虑与远程管理设计相关的下列问题。
|
|
|
|
|
|
必须要求对所有管理界面用户进行身份验证。使用强身份验证，如Windows或客户端证书身份验证。
|
|
|
|
|
|
使用经过加密的信道，如IPSec或虚拟专用网络（VPN）连接提供的通道。不支持不安全通道中的远程管理。IPSec允许对可用来管理服务器的客户计算机的身份和数量进行限制。
|
|
|
|
|
|
明确应用程序的配置存储，然后检查限制访问这些存储的方法，以及确保存储中数据安全的方法。
|
|
|
|
|
|
对于保存在Web空间文件中的配置数据，其安全性要低于保存在Web空间之外的数据。主机配置错误或未发现的Bug都可能导致攻击者通过HTTP检索，并下载配置文件。
|
|
|
|
|
|
确保在存储中加密关键的配置数据项（如数据库连接字符串、加密密钥和服务账户凭据）。
|
|
|
|
|
|
确保管理界面提供必要的授权，只有经过验证的管理员才可访问并操作这些数据。
|
|
|
|
|
|
如果管理界面支持不同的功能（如站点内容更新，服务账户重新配置和数据库连接详细信息），要确认管理界面支持基于角色的授权，从而区分内容开发人员和操作员或系统管理员。例如，不必许可更新静态Web站点的人改变客户的信用额度或重新配置数据库连接字符串。
|
|
|
|
|
|
检查应用程序对存储中、应用程序内存中以及网络中的敏感数据的处理方法。下表显示了与处理敏感数据相关的常见漏洞。
|
|
|
|
|
|
|
|
测试中要考虑下列问题，帮助验证应用程序处理敏感数据的方法。
|
|
|
|
|
|
机密信息包括了应用程序的配置数据，如账户密码和加密密钥。如果可能，明确其他避免保存机密信息的设计方法。如果要处理机密信息，由系统平台处理它们，尽可能不在应用程序中承担这一任务。如果确实要保存机密信息，则要考虑下列问题。
|
|
|
|
|
|
如果使用其他的实施技术，是否能避免存储机密信息。例如，如果只需了解用户是否知道密码，则无需存储密码。或者，仅保存单向的密码哈希值。
|
|
|
|
此外，如果使用Windows身份验证，可通过嵌套凭据来避免存储连接字符串。
|
|
|
|
|
|
如果使用加密，如何确保加密密钥的安全。考虑使用系统平台提供的DPAPI加密，这种加密能替用户完成密钥管理。
|
|
|
|
|
|
检查应用程序保存加密数据的方法。要获得尽可能高的安全性，应使用Windows ACL限制对加密数据的访问。确认应用程序不以明文或源代码形式存储机密信息。
|
|
|
|
如果使用本地安全机构（LSA），检索机密信息的代码必须使用管理员特权才可以运行，这将增加风险。另一种不要求扩展特权的方法是使用DPAPI。
|
|
|
|
|
|
检验应用程序访问机密信息的方法，以及它们以明文形式存留在内存中的时间。机密信息通常应根据需要检索，并尽快使用，然后丢弃。
|
|
|
|
|
|
如果是，应确保cookie是加密的，且不会永久保存在客户计算机中。
|
|
|
|
|
|
如果存储了敏感的应用程序数据（如客户信用卡详细信息），检查数据保护方法。
|
|
|
|
|
|
应使用强加密算法来加密。例如，使用较长的密钥（如Triple DES）。
|
|
|
|
|
|
数据的安全性与加密密钥安全性同等重要。因此，检查确保密钥安全的方法。在理想状况下，使用DPAPI加密密钥并保存在受限位置（如注册表项中）来确保安全。
|
|
|
|
|
|
如果通过网络传递敏感数据，应确保通过应用程序加密这些数据，或通过加密的通信链接来传递它们。
|
|
|
|
|
|
检查应用程序（或主机）是否在明文日志文件中记录用户账户密码这样的敏感数据。通常，必须避免这样做。确保应用程序不在查询字符串中传递敏感数据，因为查询字符串会被记录，并可在客户端浏览器地址栏中直接看到。
|
|
|
|
|
|
由于Web应用程序基于无状态的HTTP协议生成，因此会话管理是应用程序级任务。检查应用程序的会话管理方法，因为它将直接影响应用程序的整体安整。下表显示了与会话管理相关的常见漏洞。
|
|
|
|
|
|
|
|
测试中需要考虑下列问题，帮助验证应用程序处理敏感数据的方法。
|
|
|
|
|
|
检查应用程序管理用户会话的会话标识符，以及这些会话标识符的交换方式。考虑下列问题。
|
|
|
|
|
|
如果使用会话标识符（如cookie中包含的令牌）跟踪会话状态，检查是否仅通过加密的通道（如SSL）传递标识符或cookie。
|
|
|
|
|
|
如果使用表单身份验证，确保应用程序使用“”元素中的protection="All"属性加密身份验证。建议同时使用SSL和这种方法，以便降低XSS攻击的风险，XSS攻击可设法窃取用户的身份验证cookie。
|
|
|
|
|
|
确保应用程序不在查询字符串中传递会话标识符。这些字符串可在客户端轻易修改，使用户能作为另一用户访问应用程序，访问其他用户的私有数据，并可能提升特权。
|
|
|
|
|
|
检查应用程序认为会话标识符有效的时间。应用程序应限制这段时间的长度，以降低会话劫持和重播攻击的威胁。
|
|
|
|
|
|
检查应用程序存储会话状态的方法。会话状态可存储在Web应用程序进程、ASP.NET会话状态服务，或SQL Server状态存储中。如果使用远程状态存储，请确保Web服务器到该远程存储的链接使用IPSec或SSL加密，以保护在网络中传输的数据。
|
|
|
|
|
|
如果应用程序使用加密来提供安全性，检查加密的内容以及加密的使用方法。下表显示了与加密有关的常见漏洞。
|
|
|
|
|
|
|
|
测试中需要考虑下列问题，帮助验证应用程序处理敏感数据的方法。
|
|
|
|
|
|
加密只有在正确使用时才能提供真正的安全保障。不同作业使用不同的算法。算法的程度也非常重要。考虑下列问题，评价所使用的加密算法。
|
|
|
|
|
|
不应开发自己的加密技术。众所周知，加密算法和例程的开发非常难，而且很难成功。自定义实施的安全保护一般很弱，基本上不如久经考验的系统平台服务提供的安全措施。
|
|
|
|
|
|
检查应用程序使用的算法及使用该算法的目的。较大的密钥可提供较高的安全性，但会影响性能。对于在数据存储中长时间保存的永久数据，较强的加密非常重要。
|
|
|
|
|
|
加密数据的安全与密钥的安全同等重要。要破解加密数据，攻击者必须能检索出密钥和密码文本。因此，需要检查设计，确保加密密钥和加密数据的安全。考虑下列评价问题。
|
|
|
|
|
|
如果使用DPAPI，将由系统平台为用户管理密钥。其他情况下，则由应用程序负责密钥管理。检查应用程序确保加密密钥安全的方法。一种较好的方法是，使用DPAPI加密其他加密形式所需的加密密钥。然后，安全地保存加密密钥，例如，将其放在配置了受限ACL的注册表项目下。
|
|
|
|
|
|
不能滥用密钥。同一密钥使用的时间越长，被发现的可能性就越高。设计是否考虑了怎样回收密钥、回收的频率，以及如何将它们分发并安置在服务器中。
|
|
|
|
|
|
检查应用程序使用参数的方法。这些参数包括了在客户端和服务器间传递的表单字段、查询字符串、cookie、HTTP头和视图状态。如果使用像查询字符串这样的参数传递敏感数据（如会话标识符），恶意客户端可轻松使用简单的参数操作逃避服务器端检查。下表显示了常见的参数操作漏洞。
|
|
|
|
|
|
|
|
测试中需要考虑下列问题，以帮助确保您的设计不受参数操作攻击影响。
|
|
|
|
|
|
确保应用程序验证所有的输入参数，包括正常和隐藏的表单字段、查询字符串和cookie。
|
|
|
|
|
|
如果应用程序在参数（如查询字符串或表单字段）中传递敏感数据，应检查应用程序使用这种方法而不是更安全的方法（传递会话标识符）的原因。例如，在加密的cookie中传递会话标识符。使用这些信息将会话与在服务器状态存储中维护的用户状态相关联。考虑下列评价问题。
|
|
|
|
|
|
如果应用程序使用包含敏感数据的cookie，如用户名或角色列表，确保它是经过加密的。
|
|
|
|
|
|
不能这样做，因为就操作查询字符串或表单字段中的数据而言，没有简便的方法可用。实际操作过程中，应考虑使用加密的会话标识符，然后将敏感数据保存在服务器的会话状态存储中。
|
|
|
|
|
|
如果Web页或控件使用视图状态在HTTP请求之间维持状态，确保视图状态经过加密，并使用消息验证代码（MAC）检查其完整性。用户可在计算机级配置该设置，也可按页配置。
|
|
|
|
|
|
确保Web应用程序不根据HTTP头中的信息制定安全决策，因为攻击者可轻松地操作头数据。不要依赖HTTP引用站点字段的值来检查源于页的请求是否由Web应用程序生成，这将带来漏洞。这种操作本身很不安全，因为引用站点字段可在客户端轻松更改。
|
|
|
|
|
|
检查应用程序处理错误的方法。应前后一致地使用结构化的异常处理。同样，确保应用程序不在发生异常时公开太多信息。下表显示了两大异常管理漏洞。
|
|
|
|
|
|
|
|
测试时应考虑下列问题，以确保设计不易受到异常管理安全漏洞的影响。
|
|
|
|
|
|
检查应用程序如何使用结构化的异常处理。设计应强制在整个应用程序中使用一致的结构化异常处理。这将创建更强大的应用程序，使应用程序不易处在暴露安全漏洞的不一致状态下。
|
|
|
|
|
|
确保恶意用户无法利用错误信息中的细节信息，考虑下列问题。
|
|
|
|
|
|
确保应用程序不会将内部异常情况传播到应用程序边界以外。异常应在服务器中捕获并记录日志。如果必要，应向客户端返回常规错误信息。
|
|
|
|
|
|
在应用程序中一致处理并日志记录异常的最佳方法是，使用正式的异常处理系统。还可将该系统与操作组监视系统性能的监控系统相结合。
|
|
|
|
|
|
设计必须明确，应用程序在发生严重错误时使用自定义的错误信息。确保这些消息中不包含任何可能被恶意用户利用的敏感数据。
|
|
|
|
|
|
检查应用程序的审核和日志记录方法。除了防止抵赖之外，定期分析日志文件有助于识别入侵迹象。下表显示了常见的审核和日志记录漏洞。
|
|
|
|
|
|
|
|
测试中需要考虑下列问题，帮助验证应用程序审核和日志记录的方法。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
确保审核其他关键事件，包括数据检索、网络通信和管理功能（如启用和禁用日志记录）。
|
|
|
|
|
|
设计必须确保跨多个应用程序层来进行审核活动。为此，原始调用者的身份必须在每个层都可用。
|
|
|
|
|
|
|
|
|
|
日志文件是证明个人犯罪行为和解决抵赖问题的法律程序所必需的。通常，在访问资源的时候，如果由访问资源的同一例程生成审核，则审核最具权威性。确认应用程序设计中与日志文件同步相关的问题，然后记录某种形式的请求标识符，确保多个日志文件条目可互相关联，并能关联至同一请求。
|
|
|
|
|
|
如果不在操作系统级流动原始调用者身份（例如，由于此方法伸缩性有限），应明确应用程序如何流动原始调用者身份。对于跨层审核，这是必需的（对于授权来说，可能同样必需）。
|
|
|
|
此外，如果多个用户映射到同一应用程序角色，应确保应用程序记录原始调用者的身份。
|
|
|
|
|
|
检查应用程序设计是否考虑到日志文件的备份、存档和分析。日志文件必须定期存档来确保不被充满；如果充满，应开始回收。而且，还要经常分析日志文件来检测入侵迹象。此外，确保执行备份的账户都是特权最少的，确保仅为备份而公开的所有附加信道安全。
|
|
|
|
|
|
Web应用系统的安全性从使用的角度可分为应用级的安全与传输级的安全，安全性测试也可从这两个方面入手。
|
|
|
|
应用级的安全测试的主要目的是查找Web应用系统自身程序设计中存在的安全隐患，主要测试区域如下。
|
|
|
|
. 注册与登录：现在的Web应用系统基本采用先注册，后登录的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否存在大小写敏感，可以试多少次的限制，是否可以不登录而直接浏览某个页面等。
|
|
|
|
. 在线超时：Web应用系统是否有超时的限制，也就是说，用户登录后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登录才能正常使用。
|
|
|
|
. 操作留痕：为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件，是否可追踪。
|
|
|
|
. 备份与恢复：为了防范系统的意外崩溃造成的数据丢失，备份与恢复手段是一个Web系统的必备的功能。备份与恢复根据Web系统对安全性的要求可以采用多种手段，如数据库增量备份、数据库完全备份、系统完全备份等。出于更高的安全性要求，某些实时系统经常会采用双机热备或多机热备。除了对于这些备份与恢复方式进行验证测试以外，还要评估这种备份与恢复方式是否满足Web系统的安全性需求。
|
|
|
|
传输级的安全测试是考虑到Web系统的传输的特殊性，重点测试数据经客户端传送到服务器端可能存在的安全漏洞，以及服务器防范非法访问的能力。一般测试项目包括以下几个方面。
|
|
|
|
. HTTPS和SSL测试：默认的情况下，安全HTTP（Secure HTTP）通过安全套接字SSL（Secure Socket Layer）协议在端口443上使用普通的HTTP。HTTPS使用的公共密钥的加密长度决定的HTTPS的安全级别，但从某种意义上来说，安全性的保证是以损失性能为代价的。除了还要测试加密是否正确，检查信息的完整性和确认HTTPS的安全级别外，还要注意在此安全级别下，其性能是否达到要求。
|
|
|
|
. 服务器端的脚本漏洞检验：存在于服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。这可以通过设计一些相应的测试案例来进行验证。
|
|
|
|
. 防火墙测试：防火墙是一种主要用于防护非法访问的路由器，在Web系统中是很常用的一种安全系统。防火墙测试是一个很大很专业的课题，但这里所涉及的只是对防火墙的功能、设置进行测试，以判断是否满足本Web系统的安全需求。
|
|
|
