网站类安全测试流程规范.docx
《网站类安全测试流程规范.docx》由会员分享，可在线阅读，更多相关《网站类安全测试流程规范.docx（34页珍藏版）》请在冰点文库上搜索。
网站类安全测试流程规范
网站类安全测试流程规范
说明：
本文仅适用于：
国际站、中文站和国际交易站
目录
1.安全测试流程规范4
1.1定义4
1.2角色和职责4
1.3流程图5
1.4安全测试必要性的评估6
1.5任务描述7
1.6自动化安全测试录制场景设计指导方法9
1.7手工测试方法10
1.8安全测试手工测试用例规范10
1.9记录安全漏洞的规范性10
1.10主要产出物11
1.11注意点说明11
2.Web安全漏洞简介及测试说明12
2.1XSS（CrossSiteScript）12
2.2CSRF（Cross-siteRequestForgery）14
2.3SQLInjection15
2.4URLRedirect15
2.5AccessControl16
2.6上传下载文件18
2.7Flash安全18
3.自动化工具Hatirx介绍19
3.1自动化工具Hatirx19
3.2Hatirx工具使用20
3.3报表中信息22
3.4手动测试工具23
3.5安全工具的原理23
3.6漏洞特征代码库在哪里？
23
3.7Hatrix工具注意事项24
4.安全测试分析举例24
1.
安全测试流程规范
1.1定义
此文档的主要作用是对测试工程师在测试过程中的安全测试进行指导。
安全测试过程包括测试工程师对安全测试范围的界定、安全工程师的代码安全审核、测试工程师验证及测试。
测试工程师目前主要采用两种方法做安全测试，一种是采用自动化安全工具Hatrix扫描测试，自动化安全工具主要能够覆盖XSS、CSRF、SQLInjection，一种是对URLRedirect和Accesscontrol这两种漏洞采用手工方式进行测试验证，两者的区别主要就是针对的漏洞类型不同。
安全审核和安全测试区别在于：
安全审核属于白盒测试，而安全测试属于黑盒测试，两者并不能互相取代。
两者的目的是一致的，为了保证代码的安全性。
但安全测试采用的是黑盒测试方案，而安全审核是采用静态代码扫描的方案，不考虑应用的逻辑，仅仅关心代码本身的安全特性。
并且只覆盖XSS，CSRF和SQLInjection三种漏洞，同时安全审核检测出的只是可疑点，不一定就是漏洞，是否是漏洞需要开发自己确定。
所以安全审核的局限在于2点，1：
无法覆盖URLRedirect和Accesscontrol漏洞。
2：
无法最终确认漏洞。
安全测试正好能够祢补安全审核的局限。
1.2角色和职责
序号
角色
职责
（1）
PM/技术经理
a）分配漏洞修复任务给研发工程师；
b）提交达到提测要求的代码版本给QA；
（2）
开发工程师
a）在提交测试前进行安全审核，并在代码安全审核报告中登记信息；
b）对漏洞进行修复；
c）对于需要defer的漏洞，跟安全工程师确认，并输入defer漏洞列表；
（3）
QA
a）评估是否需要做安全测试，提交安全测试范围（《xxx项目/小需求安全测试传递清单》）给产品线安全测试接口人或安全工程师Review；
b）测试分析阶段，将安全漏洞的测试方法加入到测试分析中；
c）对提测版本的安全状态进行测试；
d）将安全漏洞提bug到QC；
e）对已修复漏洞进行验证；
f）对QC中的安全bug进行跟踪；
g）项目或小需求完成后，记录安全漏洞数据，并将安全测试质量报告（《安全测试传递清单》）邮件发出。
（5）
安全测试接口人
a）帮助QA划分安全测试范围，辅助安全测试人员成长（前期需安全工程师协助）
b）Review安全测试范围（《xxx项目/小需求安全测试传递清单》）（前期需安全工程师协助）
c）数据保存，由于安全权限控制严格，最后的《xxx项目/小需求安全测试传递清单》由安全测试接口人负责在SVN上保存。
Svn地址：
http:
//svn.alibaba-
（4）
安全工程师
a）提供必要的协助，以使开发工程师顺利修复漏洞；
b）帮助QA划分安全测试范围，辅助安全测试人员成长；
c）对defer漏洞进行确认；
1.3流程图
项目中安全测试流程图
小需求中安全测试流程图
1.4安全测试必要性的评估
1、如何评估项目是否做安全测试：
2011年要求项目均需要做安全测试，有特殊（如底层数据迁移等），需与安全工程师评估是否要做安全测试，并在《XXX项目安全测试传递清单》中注明。
2、如何评估小需求是否做安全测试：
Aone上安全测试评估选项（目前未集成）：
说明：
在Aone上未集成该安全测试评估选项时，暂且先用《小需求安全功能list模板》代替，在小需求提测前交给PM/技术经理，PM/技术经理进行各选项评估，将该模板填好传递给QA，QA再根据选项判断是否做安全测试。
1.5任务描述
任务
角色
任务描述
时间
输入
输出
Kickoff
PM
1.kickoff的时候，邀请安全工程师参加Kickoff，正式介入项目，了解项目背景及项目功能点和项目里程碑点。
安全工程师
1.理解FRD,对项目安全需求审核；
2.视情况参加kickoff；（如不参加Kickoff安全工程师需要提前与PM沟通确认好）；
评审后的FRD
安全需求分析报告（给开发同学的一些安全性建议）
需求分析
QA（现阶段由安全工程师辅助完成）
1.评审需求，识别哪些需求可以用脚本覆盖测试；哪些需要测试工程师编写用例形式，手工完成；
需求分析
《XXX项目/小需求安全测试传递清单》
项目测试负责人
1.协助测试工程师一起评估手工安全测试范围；
2.测试计划里增加安全测试点的测试用例及执行安全测试工作量、时间安排；
3.手工安全测试执行周期与功能测试周期保持一致。
安全测试工具运行周期为第一轮功能测试，回归测试之前；
需求分析
测试设计
QA
1.对项目进行安全测试需求分析，对安全测试手工或自动化方法给出具体方案；
自动化安全工具测试
1.自动化安全工具扫描页面；
手工安全用例测试
2.手工测试点；
3.添加安全用例评审；
测试设计和用例编写
QC上的安全测试策略
测试用例评审
测试工程师
∙首先评审安全测试用例部分（评审前需要提前将用例发送给安全工程师预审）；
安全工程师
∙参与安全测试用例评审（带着问题参加评审）；
代码安全review
安全工程师
开发提测前进行安全审核（代码安全review）：
•走Aone流程的直接于Aone上触发进行安全审核；
•不走Aone流程的提测前需提交给安全工程师进行安全审核，并记录安全审核结果报告；
《XXX项目/小需求代码安全审核报告》
开发自测
开发工程师
1.根据安全测试工具输出的报告修复漏洞；
编码阶段完成进行安全审核，回归测试前完成漏洞修复
提交测试
PM/技术经理
1.根据项目计划，将代码版本提交QA进行测试；
编码阶段至测试阶段
执行安全测试
QA
自动化安全工具（Hatrix）测试
进入功能测试阶段，录制设计好的场景并扫描，如发现安全漏洞，根据录制脚本在QC系统中提交安全类型的Bug，分配给相应开发工程师，描述中需注明安全漏洞的个数，并上传安全测试工具输出报告作为附件；
注：
项目扫描输出报表只需在QC平台提交一个安全类型的bug；
第一轮功能测试启动时开始执行，第一轮功能测试结束前输出安全测试工具输出报告
QC上的安全Bug
《XXX项目/小需求安全测试工具输出报告》
手工安全用例测试
1、根据安全测试用例执行，如发现安全漏洞，在QC系统中提交安全类型的Bug，分配给相应功能开发人员，描述中需注明安全测试类型及操作步骤；
2、验证安全测试发现的缺陷；
功能测试执行全阶段（包括第一轮测试，第一轮回归测试、第二轮回归测试）
QC上的安全类型Bug
分配开发工程师修复漏洞
PM/技术经理
1、根据QA上传的安全测试工具输出报告，分派开发工程师对漏洞进行修复，确认漏洞全部修复或提交遗留问题给安全工程师审核；
2、在QC安全类型bug中注释漏洞修复情况；
3、将defer漏洞列表提交给安全工程师确认；
4、若安全工程师不同意Defer，安排开发工程师修复漏洞或提请产品线经理审批。
并将审批意见通知给安全工程师；
功能测试阶段
安全测试工具输出报告
漏洞修复结果
Defer漏洞列表
验证安全漏洞修复情况
QA
1、再次运行安全测试工具及脚本，如果还有漏洞，将安全测试工具输出报告再次作为附件上传到QC的Bug中。
bugreopen给相应开发人员；
2、如果没有漏洞，将bugclose；
3、安全漏洞处理完毕做为进入回归测试的条件；
功能测试阶段
PM/技术经理在QC安全类型bug中注释的漏洞修复情况
QC上的安全Bug
《XXX项目/小需求安全测试工具输出报告》
确认DeferredBug
安全工程师
1、审核安全测试报告；
2、对PM/技术经理提交的Deferred漏洞列表进行确认，确认并达成一致意见后在QC相应的bug上填写Deferred备注；
功能测试阶段
Defer漏洞列表
QC上的安全Bug
Defer漏洞列表
QA
1、对安全工程师确认的Deferred安全类缺陷列表进行确认，达成一致意见后在QC相应的bug上填写备注，并将QC上的bug设置为deferred状态；
功能测试阶段
Defer漏洞列表
QC上的安全Bug
Defer漏洞列表
结果记录与备份
QA
1、将安全测试过程中的Bug和DeferredBug的记录；
2、总的Bug数的统计均更新于《XXX项目/小需求安全测试传递清单》并邮件发出。
回归测试阶段
《XXX项目/小需求安全测试传递清单》
《XXX项目/小需求安全测试传递清单》
QA接口人
1、将结果保存于SVN上，SVN地址：
http:
//svn.alibaba-
《XXX项目/小需求安全测试传递清单》
《XXX项目/小需求安全测试传递清单》
1.6自动化安全测试录制场景设计指导方法
Hatitx脚本录制的覆盖面要求覆盖UC中涉及的所有请求的页面。
请求包括了get和post请求，主要是页面中的链接和表单提交。
录制场景的设计可以按照功能、业务逻辑进行等价类划分， 例如：
可以按照会员类型划分等价类，UC中没有显示说明会员类型不同会引起业务或展示页面逻辑不同，那么只需要录制一遍，但是UC中说明了不同会员类型的业务逻辑不同，即使同样的请求或是表单提交都需要分别录制。
一个场景从业务起始页面开始包含等价类划分后的业务逻辑流程直到业务结束页面，最终通过一个场景或者多个场景覆盖项目中包括的所有功能业务逻辑页面，场景以一个脚本保存或多个脚本无影响。
对于流程的前置条件重复可以录制一遍，比如两个业务场景都需要用户登录，那登录操作的脚本只需要录制一遍。
1.7手工测试方法
针对手工测试覆盖的两种漏洞类型URLRedirect和Accesscontrol测试方法比较简单，工具也只是用到浏览器及其插件。
URL Redirect漏洞的测试范围是UC中设计的外部跳转功能点，方法是如果跳转目的URL为用户输入参数，只要通过浏览器插件将对应参数改为非阿里巴巴的URL地址，然后发送请求后观察跳转页面是否为非阿里巴巴网站，如果是则说明有URL跳转的漏洞。
Accesscontrol漏洞主要的测试方法是通过浏览器篡改HTTP请求的插件，获得HTTP请求参数，并进行非法参数替换并提交，查看服务端是否对权限进行校验。
或者直接在地址栏拼接URL，测试服务端是否对访问权限进行校验。
1.8安全测试手工测试用例规范
见QC
账号：
guest
域：
ALI_ICBU_TEST
项目：
英文站测试用例库
路径：
^Subject\_2011_测试用例体系\003_藏经阁\03_安全类^
---列出了一些典型的安全测试手工测试用例，供参考。
针对安全测试用例，在项目文件夹中增加”安全用例”文件夹。
1.9记录安全漏洞的规范性
Hatrix手工扫描--针对扫描出的安全漏洞进行分析--将分析结果在QC上提交Bug，同时上传相应Hatrix工程于附件中。
对大量的录制进行筛选，只提交由Bug的地方的工程。
手工测试部分--对于安全漏洞在QC上提交Bug。
BUG需进行细分（必填）：
缺陷类型--安全漏洞
缺陷细分--CSRF/XSS/SQLInject/AccessControl/其它
缺陷级别--high
1.10主要产出物
1、《XXX项目/小需求代码安全审核报告》——安全工程师
2、《XXX项目/小需求安全测试工具输出报告》——Hatrix自动导出
3、《XXX项目/小需求安全测试传递清单》——QA记录并备份
说明：
项目中安全测试质量报告无需单独发出，但在功能测试质量报告中要说明安全测试的质量情况。
SVN地址：
http:
//svn.alibaba-
1.11注意点说明
●自动化安全测试工具Hatirx存在部分场景无法适用的情况，比如：
页面中包含验证码（这种验证码包含显示和隐藏两种），由于工具无法获取验证码所以会导致回放请求失败。
遇到类似情况，建议与开发协商绕过验证码校验的方案，例：
部署两套环境，一套安全测试（修改代码使服务端不验证），一套功能测试。
●安全测试策略需要在测试计划中明确定义，实施方法要明确说明并体现在测试分析中，如策略中需要手工测试，手工测试的用例编写在QC平台中，在测试计划评审中review。
●是否进行安全测试是在项目立项时由安全审核部门来确定，非项目经理定义。
●如对项目中安全测试方法无法准确把握，可以咨询安全审核工程师（国际站接口人：
姜禹）给出指导意见。
●由于fuzz原理，扫描过程中会提交大量数据。
如果对脏数据比较敏感，请扫描后注意清理脏数据。
●推荐安全扫描报告的保存格式为RTF，以方便各执行人阅读。
●脚本录制需注意的问题：
1）按页面或者功能录制，不建议整个操作流程录制一次，因为这样可能有很多重复相同的http请求，保证相同的http请求只录制一次。
2）脚本录制细节不关心提交表单的输入参数组合（会被参数化），只关心提交表单这一操作。
●安全测试问题跟踪流程，需注意：
1）提出问题：
将所发现的问题导出一份安全测试报告作为附件，并在QC里提安全bug给相应开发工程师，保存录制的脚本并以附件形式上传于QC。
2）修改问题确认：
开发工程师修改后把问题fixed掉，验证前先和安全工程师确认下修改点。
3）问题验证：
再次用hatrix工具扫描录制的脚本，验证修改掉的问题，如果发现新问题或者已修改的问题没修改好，可以reopen这个安全bug给相应开发工程师。
2.Web安全漏洞简介及测试说明
按照公司的实际应用情况,我们目前主要面对的Web安全漏洞主要有以下五种:
XSS,CSRF,SQLInjection,URLRedirect和AccessControl。
2.1XSS（CrossSiteScript）
XSS（CrossSiteScript），跨站脚本攻击。
它指的是恶意攻击者往Web页面里插入恶意代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。
比如恶意攻击者将一段获取Cookie的脚本持久化到页面后，正常用户访问该页面后其Cookie信息就会被攻击者获取。
参见wiki：
http:
//en.wikipedia.org/wiki/Cross-site_scripting
案例:
下面是公司法务部投诉系统的截图,图中显示的是一个登陆界面
图示2-1登陆界面
当浏览器的url改为
图示2-2
XSS漏洞主要采用Hatrix进行测试，Hatrix会根据Http数据，构建不同的测试用例进行Fuzzer测试，但是这个测试数据量是非常大的，所以在使用Hatrix的一个注意点是，如果明确一个参数是系统级别的，比如_csrf_token_,event_submit_do_login,action等，在工具测试时不需要将这些选上。
2.2CSRF（Cross-siteRequestForgery）
CSRF（Cross-siteRequestForgery），跨站点请求伪造。
通常指在某个恶意站点的页面上，促使访问者请求你的网站的某个URL（GET，POST提交方式均可），从而达到改变服务器端数据的目的。
这一类攻击依赖于你的网页中的表单，脆弱的表单很容易受到攻击。
比如A站点有一删除功能URL为：
B站点一页面中有这样一段代码：
这样用户浏览B站点的该页面时，随即也触发了A站点的删除功能。
参见wiki：
http:
//en.wikipedia.org/wiki/CSRF
案例:
下图是阿里巴巴国际站登录后top截图,可以看到用户intldev已经登录
这时用户访问csrfsignout.html页面，注意这并不是原来alibaba域名下的，而是本地的一个页面：
然后再刷新页面，截图如下：
这时用户intdev已经不处于登录状态，但是这个期间并没有做退出操作，原因就在于csrfsignout.html的这张图片，代码是：
图片做了退出的请求，因此用户就不知情的做了一个合法操作，这就是个简单CSRF攻击。
CSRF的检测比较简单，主要还是通过Hatirx工具进行扫描测试，只要在form中检测是否存在_csrf_token_即可。
但是CSRF漏洞之间的威胁程度是不同的，CSRF漏洞的严重程度是和form本身的作用有关的，对于一些敏感数据的操作，比如用户信息的CRUD是一定需要加入_csrf_token_的，但是对于部分非业务逻辑form，比如用于数据仓库日志打点的空form便不需要加入_csrf_token_。
2.3SQLInjection
SQLInjection就是向服务器端提交事先准备好的数据，拼凑出攻击者想要的SQL语句，以改变数据库操作执行计划。
比如有一sql语句是select*fromUSERwhereUSER.id=idandUSER.read=’true’,而id的数据来自于用户的请求：
这样用户只要用提交or1=1即可直接忽略sql中其他条件判断了。
参见wikihttp:
//en.wikipedia.org/wiki/Sql_injection
现有的防SQLInjection开发方案都是基IBatis的，所以在基于IBatis开发的应用中出现SQLInjection的可能性比较小。
但是Hatrix的SQLInjection检测是基于返回信息中的数据库信息，对于进行错误处理的程序是很难进行检测的，比如自动跳转到404页面。
所以如果测试工程遇到非IBatis开发的项目，可能需要手动构建SQLInjection的测试用例，这些用例可以参考hatrix中模版。
2.4URLRedirect
URL跳转的应用很广，在这里我们只局限于可以修改URL地址的跳转，比如正确登录后的跳转到之前页。
这个之前页的URL地址就是可以修改的，是不确定的。
URLRedirect的主要威胁在于钓鱼网站，恶意用户可以利用URLRedirect将有恶意跳转的URL转发给其他用户，而此URL同时能顺利逃过域名检测，比如http:
//ha.ckers.org/如果URLRedirect检测不严格，登录之后即跳转到http:
//ha.ckers.org
案例：
下图浏览器地址显示的是一个淘宝的合法url地址，由于该应用对url过滤不严格，接受了参数url=http:
//202.113.13.92/RmfishServlet/urldirect,并以该url做了一次跳转，于是用户在访问taobao页面时，实质是请求了一个第三方网页，可想这个危险有多大！
URL跳转本身是属于业务逻辑跳转的一种实现，所以工具检测成本比较高，同时应用中URLRedirect数量比较小，在需求文档中应该有描述，所以URLRedirect漏洞需要测试进行手动检测，主要的检测方法是采用手工的方式将目的URL地址替换成非阿里巴巴域名的URL地址，检测是否会跳转到非阿里巴巴的网站。
2.5AccessControl
这里的访问控制主要是一些越权操作漏洞。
AccessControl主要包括了水平权限和垂直权限两种，水平权限是指能访问其他用户受保护的内容，从权限关系的角度来看，这种情况突破了权限的水平约束。
垂直权限问题就是访问需要更高授权的资源，比如未登录用户能够访问需要登录的资源，普通用户访问须管理员权限的资源等，从权限关系的角度看，这种情况是突破了权限的垂直约束，获取到了更高权限。
案例:
下图是国际站MyalibabaContacts模块下的ManageContacts,其中有个一个查询联系人的功能，url为，XXX为一个联系人的ID，如下图所示，这个页面没有问题，因为ID为63488082联系人就是属于当前用户的联系人，但是问题在于当恶意用户修改了cid后就能任意获取到其他联系人的信息，即使该联系人并不是该用户的联系人，如图所示，ID为63422XXX的用户信息被获取了，但是他并不是当前用户的联系人。
这就是一个AccessControl漏洞。
应用中的越权操作的检测需要对应用的业务逻辑和数据扭转有很清晰的了解，所有现阶段框架上和工具上没有合适的解决方案，此类漏洞只能依赖于手工测试。
而手工测试的方法主要有两种：
1）用户对私有资源的访问或是操作，比如访问用户的信息，如联系人信息，
升级会员 