Web站点的安全测试

每个Web应用程序都必须经过测试，以验证Web应用程序是否满足功能规格文档中定义的需求。虽然安全特性是Web应用程序的一部分，但测试Web应用程序的安全特性与测试非安全特性相比，侧重点和途径都不相同。本章节讲解测试Web应用程序的安全特性与测试Web应用程序的非安全特性的区別，以及如何创建安全性测试计划以及怎样使用测试计划执行安全性测试。

一、Web应用程序的安全性测试

1、安全性测试的区别

测试Web应用程序的非安全特性时，重点是验证Web应用程序实现的功能是否满足功能规格文档定义的需求。功能规格文档用于编写测试计划，然后按照测试计划执行测试。功能规格文档中的每个特性都必须经过测试，以验证实现的功能与文档描述的是否相同。错误数据用于测试错误处理，国际化数据用于测试Web应用程序的全球化特性。压力测试用于测试Web应用程序能否满足功能规格文档中所指定的预期和较高的网络流量。最后，特殊测试用于测试特殊Web应用程序类型的一般错误情况。

测试Web应用程序安全性的倒重点不同于测试非安全特性。安全性测试是验证未经授权的访问和恶意行为是否能被恰当地阻止。安全性测试包括尝试数据的多个排列组合以验证Web应用程序是安全的。功能规格文裆一般不列出必须实现的每一项安全性，而是使用通甩的安全术语描述Web应用程序。测试人员必须使用有关系统漏洞的知识和黑客技术，确定如何测试安全性。

压力测试工具和Web应用程序压力工具，对安全性测试没有太多用处。这些工具重点将吞吐量作为测试的输出，而不是个别测试的返回结果。

2、测试方法

Web应用程序可以使用两种类型的测试技术，自盒测试和黑盒测试。

白盒测试。白盒测试包括阅读Web应用程序的功能规格、源代码，然后用这些知识执行测试。当使用白盒测试技术测试Web应用程序的安全性时，应该假定黑客可以访问web应用程序的实现细节。对Web应用程序实现细节的访问使黑客可以识别程序中的弱点，从而使黑客可以确定如何最大限度地利用这些弱点。即使黑客最终不能访问Web应用程序的实现细节，对黑客可以访问这些信息的假定也有助于进行Web应用程序安全性测试，以防止攻击带来最高级别的危脸。
黑盒测试。对Web应用程序的黑盒测试不用读源代码或功能规格文档。为了测试Web应用程序，惟一需要了解的就是它的外部接口，外部接口包括所有的Web页、任何外部可访问的Web服务以及任何启用的互联网应用程序(如FTP)。当使用黑盒测试技术测试Web应用程序的安全性时，应该假设不知道Web应用程序是如何实现的。黑盒测试在安全性测试中是—项很有用的技术，因为这项技术需要测试者模拟用户的实际操作，并预料到尽可能多的潜在操作错误。

3、保持最新版本

配置安全性测试平台必须与配置开发和部署平台一样，采用相同的最佳方案。而且，测试平台必须釆用所有可用的软件修补程序，以保持版本最新。

攻击者可使用各种各样的安全性弱点知识。如果测试者与攻击者具有同样的知识，安全性测试将最有效。通过安全警告和修补程序的帮助来保持测试平台的版本最新有助于测试者创建有效的安全性测试计划。

测试者可以使用“XX电脑管家”之类的辅助软件来确保系统、浏览器等是最新版本，如果用到了第三方测试软件，也应该将该软件更新到最新版本。

二、创建安全性测试计划

1、安全性测试计划概述

安全性测试计划是一个描述了Web应用程序在哪些方面需要测试以及怎样测试的文档。测试计划包括对要测试的每个Web应用程序组件的描述，也包括对每个组件基本的安全性假设,安全性假设包括组件的访问级别、运行组件的计算机配置以及组件数据的加密级别。

安全性测试计划的最大的一部分是测试用例，测试用例是测试过程中在Web应用程序上运行的一次特定的、单独的测试，测试用例包括要测试的组件功能、测试所用的数据和测试的预期结果。

2、决定测试接□

测试用例在接口级别上编写，因此，创建测试用例的第—步就是确定哪些接口需要测试。

组件。要找到Web应用程序的接口，必须从逻辑上把Web应用程序分解成不同的组件。应用程序组件包括ASP.net、php、jsp页面、COM或COM+组件、Web Services、数据库、启用的互联网应用程序（如FTP和可执行文件）。Web应用程序的每个组件均产生一个或多个接口。例如，一般而言，一个Web应用程序都有一种类型的组件：动态页面（如ASP.NET、PHP、JSP等）。里然这个Web应用程序也有数据库，但是客户端不能直接访问该数锯库，相反，这个数据库只能通过Web页访问。因此，数据库的安全性将通过这些动态Web页测试。
识别要测试的接口。当测试Web应用程序时，必须找出组成Web应用程序的每个组件的每个接口，接口是组件的任意编程访问点。接口包括页面的HTML表单、COM或COM+组件的接口、可执行文件中的导出函数或类，以及已打开的任何TCP/IP套接字。
接口的测试用例。每个接口都需要一次或多次安全性测试，每次测试都会成为一个测试用例。如果接口有多个功能，那么每个功能至少霈要一个测试用例。针对不同种类的恶意数据，每个功能可能需要多个测试用例。安全接口也需要测试用例以验证对它们的授权。例如，一个HTML表单将要多个测试用例，这些测试用例包括脚本注入、SQL注入以及格式错误的表单数据。
测试威胁种类。下表列出了一些常规指导原则，这些原则有助于制定基于威胁模型的测试计划。还应该确定是否存在对某些组件的攻击，这些组件虽然被使用到了，但你对它却没有直接的控制权，例如DLL或者类库。也应该包括以下这些威胁模型中的场景：

威胁类型	测试技术
身份欺骗	·尝试不经过身份验证而强制使用应用程序，是否存在允许这种情况的选项，并且非管理员可以设置这个选项？ ·尝试强制使用不安全的老版本身份验证协议。 ·可以在线或从永久存储区査看有效用户凭据玛？ ·“安全标记”例如Cookie能绕过身份验证阶段吗？ ·尝试强行破解用户的凭据，是否存在细微的错误信息的变化从而有助于尝试这种攻击。
篡改数据	·尝试绕过授权或者访问控制机制。 ·有可能篡改并重组数据吗？ ·创建无效的哈希、MAC和数字签名来确认它们能被正确地检査。 ·如果应用程序使用防止入侵篡改的协议（如SSL/TLS或者IPSec)，确定是否可以强制应用程序回滚到不安全的协议。
否认	·阻止记录或者审核的情况是否存在？ ·有没有可能创建的请求在事件日志中产生了不正确的数据？例如，在有效请求中包括文件尾、换行或者回车符。 ·绕过安全性检査的敏感操作可以执行吗？（参见本表上面的“身份欺骗”和“篡改数据”部分）
信息泄露	·尝试访问只有拥有更多特权的用户才能访问的数据。这些数据包括氷久性数据(基于文件的数据、注册表数据等)和临时数据、网络嗅探器是査找这些数据的有用工具。 ·结束进程并且执行磁盘清理操作来査找写入磁盘的敏感数据。为了便于发现那些数据，可能需要让开发人员在调试过程中用公用模式标记敏感数据。 ·泄漏有用信息给攻击者而使应用程序崩溃（例如错误信息）
拒绝激务（DoS）	·DoS攻击可能是最容易测试的威胁。 ·向进程中填充大量数椐，数据大到使进程停止响应有效请求。 ·格式错误的数据会使进程崩溃吗？这种情況在服务器上特别糟糕。 ·外部影响(例如被减少的磁盘空间、存储压力和资源限制)能迫使应用程序崩溃吗？
特权升级	·把最多的时间用于在权限升级的账户下运行应用程序（例如SYSTEM服务、Root账户服务）。 ·可以像执行代码一样操作数据吗？ ·能否迫使特权升级的进程调用一个在提升的特权下运行的命令外壳

3、测试数据无效的输入数据

测试用例包含需要在测试期间传递给接口的测试数据。接口能使用多种形式的数据，包括HTML表单变量、文件、数据库和注册表键。在编写测试用例时，必须定义这些多种形式的数据。

同时也应该使用缺陷数据测试应用程序，因为这样可以保证用户不能向Web应用程序输入非法数据。创建测试用例时，应该指定需要传给接口的缺陷数据。缺陷数据包括随机数据、部分正确数据、脚本注入尝试和SQL注入尝试。

随机数椐。随机数据用于测试错误路径是否会导致安全性漏洞。例如，一个Web应用程序中的登录页面使用表单变量来验证用户身份，可通过为表单数据传递(GET或POST)随机字符串来测试完全随机数据是否会危及登录过程。
部分正确数据。部分正确数据是含有无效值的格式良好的数据。例如，表单变量必须格式化为使用字段名和字段值的格式。部分正确数据可以包括正确的格式和字段名，但字段值无效。无效数据包括零值、空值、最大长度数据和无效数据类型值。例如，在一个Web应用程序中，登录页面可以传递部分正确数据，例如无密码、空密码、过长的密码和由随机字符组成的密码。
脚本注入。在任何有HTML表单的地方，都要编写尝试脚本植入的测试用例。例如，在编写测试用例时，用下面的脚本片段设定每个表单变量的字段名和字段值：
```
><script>alert(document.cookie);</script>
```
前面的脚本片段尝试关闭一个打开的标签并显示用户的Cookie。
SQL注入。如果存在与数据库通信的HTML表单，就需要编写尝试SQL注入攻击的测试用例。
不同数据类型和长度。改变输入HTML表单的数据类型和数据长度来测试可能产生安全性弱点的Web应用程序错误。如果一个HTML表单的字段需要数值型的值，那么就编写传递其他数据类型（如字符串类型）的测试用例。可使用如下表单字段来测试对Web应用程序的缓冲区溢出攻击：空字段值、最小长度值、最大长度值和超过最大长度的值等。

4、测试数据身份验证、授权数据和实现数据

测试用例还应该包括用于所有接口的身份验证、授权和实现数据测试。

身份验证数据。身份验证常常在中心接口(如登录页面）执行。例如，在一个Web应用程序中，代理商身份验证是在登录页面执行的。编写测试用例来验证身份验证过程的安全性和功能规格文档中描述的是否—样。编写测试用例尝试猜测默认口令。身份验证数据与每个身份验证请求—起被发送。编写测试用例来尝试危及身份验证数据的安全。这些尝试可能包括读取并修改客户的Cookie或者使用网络嗅探器监听客户端和Web应用程序之间的通信。
授权数据。Web应用程序的很多Web页对于未授权的访问是安全的。必须对每个安全的Web页进行授杈访问的测试。编写测试用例来验证未授权用户不能访问Web页，而所有授权用户都允许访问该Web页。例如，一个Web应用程序有一组应该只有拥有有效用户名和密码的代理商才能访问的Web页。因此，必须测试所有的匿名用户都不能访问这些代理商Web页。
Web应用程序中的一些Web页任何用户都不能访问，不管是什么用户。例如，inc文件、Machine.config文件、Web.config文件和代码隐藏文件。必须测试用户确实不能访问这些Web页。
实现数据。编写测试用例确定是否可以从Web页、错误信息或者表单数据中获得任何实现细节。

5、测试用例的组成元素

向接口传递缺陷数据的毎个实例都是测试用例。测试用例包括对要测试接口的描述、测试的优先级、详细的执行说明和预期结果。下表描述了构成测试用例的主要元素：

元素	例子
测试条件	包含对接口的简要描述和必须被测试的数据
优先权	指定测试用例的相对优先级（高，中或者低）和执行测试的类型（自动或者手动）。测试用例的优先权可以用于调整测试计划或者确定测试用例所用的测试工作量。使用本课程前面所描述的风险计算来划分测试用例的优先次序。
执行细节	包含对执行测试所必须遵循的步骤的详细描述。这些步骤包括要测试的接口以及测试过程中必须传递给接给接口的数据。
预期结果	包含测试成功时的响应或返回数据。与预期结果的任何偏差都导致测试失败。

三、执行安全性测试

安全性测试计划写好后必须被执行，实际上，在Web应用程序的整个生命周期中，安全性测试计划必须被执行多次，下面简要讲解用于执行测试计划的方法和工具。

1、测试方法

有两种测试方法用于执行测试计划：手动测试和自动测试。

手动测试。手动测试需要测试者阅读测试用例并且手动执行测试用例中指定的步骤，然后评价结果并且确定测试是成功还是失败。当测试结果很难以编程的方式验证时，如测试用户界面时，手动测试很有用。由于编写程序搜索实现细节逋常很困难，所以对于确定实现细节是否暴露在错误信息中的测试用例，手动测试也是较好的选择。手动测试在有些情况下是不充分的。当测试使用POST方法的HTML表单时，可能要编写使用无效表单字段名的测试用例。为此必须编写不同级别的代码(HTML、脚本或编译代码)来修改POST方法里的表单字段名。
自动测试。自动测试使用程序来执行和评价测试用例，这个程序可能是使用脚本语言或编译语言编写的。当测试用例的预期结果很容易地用通过或失败评价时，自动测试最适用，这样的预期结果包括HTTP错误（如拒绝访问）、HTML表单的发送结果（如往数据库添加记录）以及请求结果（如授录失敢）。自动测试非常适用于回归测试，在回归测试中需要验证新版本的Web应用程序是否通过前—版本已经通过的一组测试。自动测试容易重复，可以批量地创建一组测试用于Web应用程序的每个发布版本甚至每个内部版本。