网站类安全测试流程规范.doc

网站类安全测试指导文档 PAGE34 / NUMPAGES34 网站类安全测试流程规范 说明：本文仅适用于：国际站、中文站和国际交易站 目录 TOC \o "1-3" \h \z \u 1. 安全测试流程规范 4 1.1 定义 4 1.2 角色和职责 4 1.3 流程图 5 1.4 安全测试必要性的评估 6 1.5 任务描述 7 1.6 自动化安全测试录制场景设计指导方法 10 1.7 手工测试方法 10 1.8 安全测试手工测试用例规范 10 1.9 记录安全漏洞的规范性 11 1.10 主要产出物 11 1.11 注意点说明 11 2. Web安全漏洞简介及测试说明 12 2.1 XSS(Cross Site Script) 13 2.2 CSRF (Cross-site Request Forgery) 14 2.3 SQL Injection 15 2.4 URL Redirect 16 2.5 AccessControl 16 2.6 上传下载文件 18 2.7 Flash安全 19 3. 自动化工具Hatirx介绍 20 3.1 自动化工具Hatirx 20 3.2 Hatirx工具使用 20 3.3 报表中信息 23 3.4 手动测试工具 23 3.5 安全工具的原理 23 3.6 漏洞特征代码库在哪里？ 24 3.7 Hatrix工具注意事项 24 4. 安全测试分析举例 24 安全测试流程规范 定义 此文档的主要作用是对测试工程师在测试过程中的安全测试进行指导。 安全测试过程包括测试工程师对安全测试范围的界定、安全工程师的代码安全审核、测试工程师验证及测试。测试工程师目前主要采用两种方法做安全测试，一种是采用自动化安全工具Hatrix扫描测试，自动化安全工具主要能够覆盖XSS、CSRF、SQL Injection，一种是对URL Redirect和Access control这两种漏洞采用手工方式进行测试验证，两者的区别主要就是针对的漏洞类型不同。 安全审核和安全测试区别在于：安全审核属于白盒测试，而安全测试属于黑盒测试，两者并不能互相取代。两者的目的是一致的，为了保证代码的安全性。但安全测试采用的是黑盒测试方案，而安全审核是采用静态代码扫描的方案，不考虑应用的逻辑，仅仅关心代码本身的安全特性。并且只覆盖XSS，CSRF和SQL Injection三种漏洞，同时安全审核检测出的只是可疑点，不一定就是漏洞，是否是漏洞需要开发自己确定。所以安全审核的局限在于2点，1：无法覆盖URL Redirect和Access control漏洞。2：无法最终确认漏洞。安全测试正好能够祢补安全审核的局限。 角色和职责 序号 角 色 职 责 (1) PM/技术经理 分配漏洞修复任务给研发工程师； 提交达到提测要求的代码版本给QA； (2) 开发工程师 在提交测试前进行安全审核，并在代码安全审核报告中登记信息； 对漏洞进行修复； 对于需要defer的漏洞，跟安全工程师确认，并输入defer漏洞列表； (3) QA 评估是否需要做安全测试，提交安全测试范围（《xxx项目/小需求安全测试传递清单》）给产品线安全测试接口人或安全工程师Review； 测试分析阶段，将安全漏洞的测试方法加入到测试分析中； 对提测版本的安全状态进行测试； 将安全漏洞提bug到QC； 对已修复漏洞进行验证； 对QC中的安全bug进行跟踪； 项目或小需求完成后，记录安全漏洞数据，并将安全测试质量报告（《安全测试传递清单》）邮件发出。 (5) 安全测试接口人 帮助QA划分安全测试范围，辅助安全测试人员成长（前期需安全工程师协助） Review安全测试范围（《xxx项目/小需求安全测试传递清单》）（前期需安全工程师协助） 数据保存，由于安全权限控制严格，最后的《xxx项目/小需求安全测试传递清单》由安全测试接口人负责在SVN上保存。 Svn地址： /repos/ali_QA/22_安全测试领域） (4) 安全工程师 提供必要的协助，以使开发工程师顺利修复漏洞； 帮助QA划分安全测试范围，辅助安全测试人员成长； 对defer漏洞进行确认； 流程图 项目中安全测试流程图 小需求中安全测试流程图 安全测试必要性的评估 1、如何评估项目是否做安全测试： 2021年要求项目均需要做安全测试，有特殊（如底层数据迁移等），需与安全工程师评估是否要做安全测试，并在《XXX项目安全测试传递清单》中注明。 2、如何评估小需求是否做安全测试： Aone上安全测试评估选项（目前未