1、web安全测试流程设计简介

web安全测试业务主要围绕流程、标准、规范三个方面展开，其中流程是核心，标准和规范在流程运作中落地与执行。

2、web安全测试流程概要设计

当需要测试的web应用数以千计，就有必要建立一套完整的安全测试流程，流程的最高目标是要保证交付给客户的安全测试服务质量。

立项：项目建立，时间安排，人力分配，目标制定，厂商接口人确定；

系统分析&威胁分析：针对具体的web应用，分析系统架构、使用的组件、对外提供的接口等，以STRIDE为威胁模型进行对应的安全威胁分析，输出安全威胁分析表，重点关注top3威胁；

制定测试用例：根据威胁分析的结果制定对应的测试用例，测试用例按照模板输出，具备可执行性；

测试执行&漏洞挖掘：测试用例执行&发散测试，挖掘对应的安全问题or漏洞；

问题修复&回归测试：指导客户应用开发方修复安全问题or漏洞，并进行回归测试，确保安全问题or漏洞得到修复，并且没有引入新的安全问题；

项目总结评审：项目过程总结，输出文档评审，相关文档归档。

3、web安全测试流程详细设计--立项

每一个web应用的安全测试第一步就是立项，确定流程实施内容，包括如下：

客户提出测试需求：需求方、web应用名称、期望的目标等；

安排测试人员：安全测试人员安排，测试环境搭建；

测试计划制定：与需求方沟通测试计划安排，每一个流程阶段的时间计划，具体的测试内容；

测试实施：确定需求方接口人，后续问题沟通反馈&修改；

流程评审&结项：确定web应用测试完成后的评审方案，向客户交付测试输出文档；

4、web安全测试流程详细设计--系统分析

web安全测试首先要进行的就是熟悉被测系统，将系统分解，分析系统使用的组件，使用何种web架构等等。

系统分析主要包括系统物理架构和逻辑架构的划分。

物理架构：按照系统使用的组件分析出来的架构，如底层使用何种数据库，控制层使用何种组件，表示层使用何种前端库等，组件之间使用那些通信协议等； 数据存储层：如mysql、oracle、redis、Bigtable等；

控制层：如Spring、Struts2、Tomcat、Weblogic等；

表示层：如ExtJS、Bootstrap等；

通信协议：如AMQP等；

分析系统使用的这些物理组件，有助于了解系统的特性，方便进行威胁分析和对应的用例编写。

不同的组件有对应的不同的威胁模式库，物理架构分析后就可以直接进行对应的映射即可得出被测系统的威胁库。

逻辑架构：按照系统的业务逻辑划分的，例如根据一个系统的组成业务模块就可得出其逻辑架构，分析逻辑架构有利于熟悉系统内部的数据流。

如下图所示为某商户管理系统的业务逻辑架构图。

个人用户侧的功能包含商户基本信息维护、清算信息维护、差错处理、系统管理；

外部链接包括银行的各种业务处理；

商户内的数据与两边业务都有交互，从业务逻辑图可以清晰地看出数据流的走向。

5、web安全测试流程详细设计--威胁分析

系统分析后需要进行的就是系统威胁分析，根据系统分析的结果，选择合适的威胁模型，分析系统面临的主要安全威胁。

常见的威胁模型如TVRA和STRIDE：

TVRA：Threat（威胁）、Vulnerability（脆弱点）、Risk Analysis（风险分析）.

其中Risk = Threat × Vulnerability × Consequence

Threat表示系统面临的威胁，Vulnerability表示系统存在的漏洞，consequence表示系统漏洞被利用所产生的后果，一般由CIA来衡量。

STRIDE是基于数据流的一种威胁分析模型，它包含六个维度威胁：

数据流图是从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。它一般包含以下几个元素：

数据流图一般分一层数据流和二层数据流图，一层数据流图是指整个系统的数据流图，其包含多个多处理过程，对每一个多处理过程继续分解就是二层数据流图，以web系统的登录模块为例，其分解的二层数据流图如下所示：

STRIDE模型一般应用在二层数据流图上，在外界操作与系统内部模块之间、系统模块与外界存储之间需要画立信任边界。数据流图元素和STRIDE的对应关系如下：

对于每一种威胁，其对应的消减方式如下表：

对于二层数据流图的每一个元素，结合其存在的对应威胁，即可确定安全测试中需要测试的内容，然后对应上图的消减措施，如果缺少对应的消减机制，就说明存在对应的安全问题或漏洞。

6、web安全测试流程详细设计--制定测试用例

威胁分析后就需要根据威胁分析的结果编写测试用例，针对分解的每一个二层数据流图，对每一个数据流图元素，映射对应的威胁，编写测试用例，用例必须按照模板输出，每一个用例具体内容包括：

用例名称：测试用例必须具有唯一可区分的名称；

用例执行步骤：用例的详细执行步骤，每一步必须无歧义，具备可执行性；

用例使用的工具：用例执行过程中使用的工具；

用例的执行条件：用例执行必须具备的条件，如网络可达、服务必须运行等；

用例的输入和输出：用例执行过程中涉及的输入，以及对应的输出；

用例的安全属性：目前规定的安全属性包括管理通道安全、XSS、注入攻击、CSRF、身份认证、会话安全、敏感数据保护、越权、中间件安全、配置安全这10个维度；

用例执行优先级：用例执行的优先顺序，在用例数量很多的情况下，应按照优先级高低的顺序执行。

7、web安全测试流程详细设计--测试执行&漏洞挖掘

测试用例编写完就需要开始用例的执行，具体的测试包括自动化的工具执行以及手动测试。

自动化的工具扫描包括：Nmap端口扫描、系统漏洞扫描、web安全扫描、协议安全扫描等；

手动测试包括：XSS、CSRF、SQL注入、XML注入、命令注入、横向/纵向越权、会话安全等等。

测试过程需要使用各种各样的工具，常见的web测试工具如下：

对于每一个用例的测试过程，需要有对应的操作截图。

对于每一个可以利用的安全漏洞，使用cvss2.0/3.0进行打分，以确定漏洞的严重程度。

测试执行与漏洞挖掘的过程与测试工程师的能力是强相关的，测试时的思路也会决定漏洞的挖局。

如果客户愿意提供应用源代码，我们也可以进行源码方向的安全审计。

8、web安全测试流程详细设计--问题修复&回归测试

测试执行完成后需要输出对应的测试报告，在报告中需要给出每个安全问题或漏洞的解决方案或建议。

如果可能，解决方案应当详细到源码级别。

问题修复应当遵循web应用开发安全规范的原则。

回归测试的目的为了防止问题修复引入新的安全问题，问题修复&回归测试是个循环的过程，测试没有新的问题时循环即终止。

9、web安全测试流程详细设计--项目总结评审

修复测试中发现的安全问题，完成回归测试后，整个安全测试流程就基本结束，最后需要就整个测试过程进行总结评审，例如测试方案、测试用例是否完善，测试过程发现了多少安全问题，web应用的高风险模块，测试过程有哪些薄弱项等等。

最后要做好客户交付件的输出，客户的交付文档包括：

总结：web安全渗透测试作为服务开展时，有必要建立一套对应的流程体系，以确保交付给客户的服务质量，从而建立良好的市场口碑！