网站类安全测试流程规范

网站类安全测试指导文档34/34网站类安全测试流程规范说明：本文仅适用于：国际站、中文站和国际交易站

目录1. 安全测试流程规范 41.1定义 41.2角色和职责 41.3流程图 51.4安全测试必要性的评估 61.5任务描述 71.6自动化安全测试录制场景设计指导方法 101.7手工测试方法 101.8安全测试手工测试用例规范 101.9记录安全漏洞的规范性 111.10主要产出物 111.11注意点说明 112. Web安全漏洞简介及测试说明 122.1XSS(CrossSiteScript) 132.2CSRF(Cross-siteRequestForgery) 142.3SQLInjection 152.4URLRedirect 162.5AccessControl 162.6上传下载文件 182.7Flash安全 193. 自动化工具Hatirx介绍 203.1自动化工具Hatirx 203.2Hatirx工具使用 203.3报表中信息 233.4手动测试工具 233.5安全工具的原理 233.6漏洞特征代码库在哪里？ 243.7Hatrix工具注意事项 244. 安全测试分析举例 24

安全测试流程规范定义此文档的主要作用是对测试工程师在测试过程中的安全测试进行指导。安全测试过程包括测试工程师对安全测试范围的界定、安全工程师的代码安全审核、测试工程师验证及测试。测试工程师目前主要采用两种方法做安全测试，一种是采用自动化安全工具Hatrix扫描测试，自动化安全工具主要能够覆盖XSS、CSRF、SQLInjection，一种是对URLRedirect和Accesscontrol这两种漏洞采用手工方式进行测试验证，两者的区别主要就是针对的漏洞类型不同。安全审核和安全测试区别在于：安全审核属于白盒测试，而安全测试属于黑盒测试，两者并不能互相取代。两者的目的是一致的，为了保证代码的安全性。但安全测试采用的是黑盒测试方案，而安全审核是采用静态代码扫描的方案，不考虑应用的逻辑，仅仅关心代码本身的安全特性。并且只覆盖XSS，CSRF和SQLInjection三种漏洞，同时安全审核检测出的只是可疑点，不一定就是漏洞，是否是漏洞需要开发自己确定。所以安全审核的局限在于2点，1：无法覆盖URLRedirect和Accesscontrol漏洞。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、如何评估项目是否做安全测试：2011年要求项目均需要做安全测试，有特殊（如底层数据迁移等），需与安全工程师评估是否要做安全测试，并在《XXX项目安全测试传递清单》中注明。2、如何评估小需求是否做安全测试：Aone上安全测试评估选项（目前未集成）：说明：在Aone上未集成该安全测试评估选项时，暂且先用《小需求安全功能list模板》代替，在小需求提测前交给PM/技术经理，PM/技术经理进行各选项评估，将该模板填好传递给QA，QA再根据选项判断是否做安全测试。任务描述任务角色任务描述时间输入输出KickoffPMkickoff的时候，邀请安全工程师参加Kickoff，正式介入项目，了解项目背景及项目功能点和项目里程碑点。安全工程师理解FRD,对项目安全需求审核；视情况参加kickoff；（如不参加Kickoff安全工程师需要提前与PM沟通确认好）；评审后的FRD安全需求分析报告（给开发同学的一些安全性建议）需求分析QA（现阶段由安全工程师辅助完成）评审需求，识别哪些需求可以用脚本覆盖测试；哪些需要测试工程师编写用例形式，手工完成；需求分析《XXX项目/小需求安全测试传递清单》项目测试负责人协助测试工程师一起评估手工安全测试范围；测试计划里增加安全测试点的测试用例及执行安全测试工作量、时间安排；手工安全测试执行周期与功能测试周期保持一致。安全测试工具运行周期为第一轮功能测试，回归测试之前；需求分析测试设计QA对项目进行安全测试需求分析，对安全测试手工或自动化方法给出具体方案；自动化安全工具测试自动化安全工具扫描页面；手工安全用例测试手工测试点；添加安全用例评审；测试设计和用例编写QC上的安全测试策略测试用例评审测试工程师首先评审安全测试用例部分（评审前需要提前将用例发送给安全工程师预审）；安全工程师参与安全测试用例评审（带着问题参加评审）；代码安全review安全工程师开发提测前进行安全审核（代码安全review）：走Aone流程的直接于Aone上触发进行安全审核；不走Aone流程的提测前需提交给安全工程师进行安全审核，并记录安全审核结果报告；《XXX项目/小需求代码安全审核报告》开发自测开发工程师 根据安全测试工具输出的报告修复漏洞；编码阶段完成进行安全审核，回归测试前完成漏洞修复提交测试PM/技术经理根据项目计划，将代码版本提交QA进行测试；编码阶段至测试阶段执行安全测试QA自动化安全工具（Hatrix）测试进入功能测试阶段，录制设计好的场景并扫描，如发现安全漏洞，根据录制脚本在QC系统中提交安全类型的Bug，分配给相应开发工程师，描述中需注明安全漏洞的个数，并上传安全测试工具输出报告作为附件；注：项目扫描输出报表只需在QC平台提交一个安全类型的bug；第一轮功能测试启动时开始执行，第一轮功能测试结束前输出安全测试工具输出报告QC上的安全Bug《XXX项目/小需求安全测试工具输出报告》手工安全用例测试根据安全测试用例执行，如发现安全漏洞，在QC系统中提交安全类型的Bug，分配给相应功能开发人员，描述中需注明安全测试类型及操作步骤；验证安全测试发现的缺陷；功能测试执行全阶段（包括第一轮测试，第一轮回归测试、第二轮回归测试）QC上的安全类型Bug分配开发工程师修复漏洞PM/技术经理根据QA上传的安全测试工具输出报告，分派开发工程师对漏洞进行修复，确认漏洞全部修复或提交遗留问题给安全工程师审核；在QC安全类型bug中注释漏洞修复情况；将defer漏洞列表提交给安全工程师确认；若安全工程师不同意Defer，安排开发工程师修复漏洞或提请产品线经理审批。并将审批意见通知给安全工程师；功能测试阶段安全测试工具输出报告漏洞修复结果Defer漏洞列表验证安全漏洞修复情况QA再次运行安全测试工具及脚本，如果还有漏洞，将安全测试工具输出报告再次作为附件上传到QC的Bug中。bugreopen给相应开发人员；如果没有漏洞，将bugclose；安全漏洞处理完毕做为进入回归测试的条件；功能测试阶段PM/技术经理在QC安全类型bug中注释的漏洞修复情况QC上的安全Bug《XXX项目/小需求安全测试工具输出报告》确认DeferredBug安全工程师审核安全测试报告；对PM/技术经理提交的Deferred漏洞列表进行确认，确认并达成一致意见后在QC相应的bug上填写Deferred备注；功能测试阶段Defer漏洞列表QC上的安全BugDefer漏洞列表QA对安全工程师确认的Deferred安全类缺陷列表进行确认，达成一致意见后在QC相应的bug上填写备注，并将QC上的bug设置为deferred状态；功能测试阶段Defer漏洞列表QC上的安全BugDefer漏洞列表结果记录与备份QA将安全测试过程中的Bug和DeferredBug的记录；总的Bug数的统计均更新于《XXX项目/小需求安全测试传递清单》并邮件发出。回归测试阶段《XXX项目/小需求安全测试传递清单》《XXX项目/小需求安全测试传递清单》QA接口人将结果保存于SVN上，SVN地址：/repos/ali_QA/22_安全测试领域）《XXX项目/小需求安全测试传递清单》《XXX项目/小需求安全测试传递清单》自动化安全测试录制场景设计指导方法Hatitx脚本录制的覆盖面要求覆盖UC中涉及的所有请求的页面。请求包括了get和post请求，主要是页面中的链接和表单提交。录制场景的设计可以按照功能、业务逻辑进行等价类划分，

例如：可以按照会员类型划分等价类，UC中没有显示说明会员类型不同会引起业务或展示页面逻辑不同，那么只需要录制一遍，但是UC中说明了不同会员类型的业务逻辑不同，即使同样的请求或是表单提交都需要分别录制。一个场景从业务起始页面开始包含等价类划分后的业务逻辑流程直到业务结束页面，最终通过一个场景或者多个场景覆盖项目中包括的所有功能业务逻辑页面，场景以一个脚本保存或多个脚本无影响。对于流程的前置条件重复可以录制一遍，比如两个业务场景都需要用户登录，那登录操作的脚本只需要录制一遍。手工测试方法针对手工测试覆盖的两种漏洞类型URLRedirect和Accesscontrol测试方法比较简单，工具也只是用到浏览器及其插件。URL

Redirect漏洞的测试范围是UC中设计的外部跳转功能点，方法是如果跳转目的URL为用户输入参数，只要通过浏览器插件将对应参数改为非阿里巴巴的URL地址，然后发送请求后观察跳转页面是否为非阿里巴巴网站，如果是则说明有URL跳转的漏洞。Accesscontrol漏洞主要的测试方法是通过浏览器篡改HTTP请求的插件，获得HTTP请求参数，并进行非法参数替换并提交，查看服务端是否对权限进行校验。或者直接在地址栏拼接URL，测试服务端是否对访问权限进行校验。安全测试手工测试用例规范见QC账号：guest域：ALI_ICBU_TEST项目：英文站测试用例库路径：^Subject\_2011_测试用例体系\003_藏经阁\03_安全类^列出了一些典型的安全测试手工测试用例，供参考。针对安全测试用例，在项目文件夹中增加”安全用例”文件夹。记录安全漏洞的规范性Hatrix手工扫描--针对扫描出的安全漏洞进行分析--将分析结果在QC上提交Bug，同时上传相应Hatrix工程于附件中。对大量的录制进行筛选，只提交由Bug的地方的工程。手工测试部分--对于安全漏洞在QC上提交Bug。BUG需进行细分（必填）：缺陷类型--安全漏洞缺陷细分--CSRF/XSS/SQLInject/AccessControl/其它缺陷级别--high主要产出物1、《XXX项目/小需求代码安全审核报告》——安全工程师2、《XXX项目/小需求安全测试工具输出报告》——Hatrix自动导出3、《XXX项目/小需求安全测试传递清单》——QA记录并备份说明：项目中安全测试质量报告无需单独发出，但在功能测试质量报告中要说明安全测试的质量情况。SVN地址：/repos/ali_QA/22_安全测试领域注意点说明自动化安全测试工具Hatirx存在部分场景无法适用的情况，比如：页面中包含验证码（这种验证码包含显示和隐藏两种），由于工具无法获取验证码所以会导致回放请求失败。遇到类似情况，建议与开发协商绕过验证码校验的方案，例：部署两套环境，一套安全测试（修改代码使服务端不验证），一套功能测试。安全测试策略需要在测试计划中明确定义，实施方法要明确说明并体现在测试分析中，如策略中需要手工测试，手工测试的用例编写在QC平台中，在测试计划评审中review。是否进行安全测试是在项目立项时由安全审核部门来确定，非项目经理定义。如对项目中安全测试方法无法准确把握，可以咨询安全审核工程师（国际站接口人：姜禹）给出指导意见。由于fuzz原理，扫描过程中会提交大量数据。如果对脏数据比较敏感，请扫描后注意清理脏数据。推荐安全扫描报告的保存格式为RTF，以方便各执行人阅读。脚本录制需注意的问题：按页面或者功能录制，不建议整个操作流程录制一次，因为这样可能有很多重复相同的http请求，保证相同的http请求只录制一次。脚本录制细节不关心提交表单的输入参数组合（会被参数化），只关心提交表单这一操作。安全测试问题跟踪流程，需注意：提出问题：将所发现的问题导出一份安全测试报告作为附件，并在QC里提安全bug给相应开发工程师，保存录制的脚本并以附件形式上传于QC。修改问题确认：开发工程师修改后把问题fixed掉，验证前先和安全工程师确认下修改点。问题验证：再次用hatrix工具扫描录制的脚本，验证修改掉的问题，如果发现新问题或者已修改的问题没修改好，可以reopen这个安全bug给相应开发工程师。Web安全漏洞简介及测试说明按照公司的实际应用情况,我们目前主要面对的Web安全漏洞主要有以下五种:XSS,CSRF,SQLInjection,URLRedirect和AccessControl。XSS(CrossSiteScript)XSS(CrossSiteScript)，跨站脚本攻击。它指的是\o"恶意攻击"恶意攻击者往Web页面里插入恶意代码，当用户\o"浏览"浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。比如恶意攻击者将一段获取Cookie的脚本持久化到页面后，正常用户访问该页面后其Cookie信息就会被攻击者获取。参见wiki：/wiki/Cross-site_scripting案例:下面是公司法务部投诉系统的截图,图中显示的是一个登陆界面

图示2-1登陆界面当浏览器的url改为/legal/site/login/login.htm?site_type=%22%3E%3Cinput%20type=image%20src=x%20onerror=alert%28document.cookie%29%3E，浏览器显示截图如1-2，恶意用户提交的js被成功执行，所以说明系统的登录功能中存在XSS漏洞。图示2-2XSS漏洞主要采用Hatrix进行测试，Hatrix会根据Http数据，构建不同的测试用例进行Fuzzer测试Fuzzer测试：Isasoftwaretestingtechniquethatprovidesinvalid,unexpected,orrandomdatatotheinputsofaprogram.Iftheprogramfails(forexample,bycrashingorfailingbuilt-incodeassertions),thedefectscanbenoted。Fuzzer测试：Isasoftwaretestingtechniquethatprovidesinvalid,unexpected,orrandomdatatotheinputsofaprogram.Iftheprogramfails(forexample,bycrashingorfailingbuilt-incodeassertions),thedefectscanbenoted。CSRF(Cross-siteRequestForgery)CSRF(Cross-siteRequestForgery)，跨站点请求伪造。通常指在某个恶意站点的页面上，促使访问者请求你的网站的某个URL（GET，POST提交方式均可），从而达到改变服务器端数据的目的。这一类攻击依赖于你的网页中的表单，脆弱的表单很容易受到攻击。比如A站点有一删除功能URL为：/deleteB站点一页面中有这样一段代码：<imgsrc=”/delete”/>这样用户浏览B站点的该页面时，随即也触发了A站点的删除功能。参见wiki：/wiki/CSRF案例:下图是阿里巴巴国际站登录后top截图,可以看到用户intldev已经登录这时用户访问csrfsignout.html页面，注意这并不是原来alibaba域名下的，而是本地的一个页面：然后再刷新页面，截图如下：这时用户intdev已经不处于登录状态，但是这个期间并没有做退出操作，原因就在于csrfsignout.html的这张图片，代码是：<imgsrc="/user/sign/sign_out.htm"onerror="this.src='/images/eng/style/logo/logo_alibaba.gif';"/>图片做了退出的请求，因此用户就不知情的做了一个合法操作，这就是个简单CSRF攻击。CSRF的检测比较简单，主要还是通过Hatirx工具进行扫描测试，只要在form中检测是否存在_csrf_token_即可。但是CSRF漏洞之间的威胁程度是不同的，CSRF漏洞的严重程度是和form本身的作用有关的，对于一些敏感数据的操作，比如用户信息的CRUD是一定需要加入_csrf_token_TToken：用来防止CSRF漏洞和重复提交的认证码，服务端发送的http中包括一个hidden属性的认证码，客户端提交请求时会将该认证码一并提交，服务端接收后与发送的码进行比对，如果一致认为合法，如果不一致有可能该提交已过期或者非法，如果已接收过认为是重复提交。SQLInjectionSQLInjection就是向服务器端提交事先准备好的数据，拼凑出攻击者想要的SQL语句，以改变数据库操作执行计划。比如有一sql语句是select*fromUSERwhereUSER.id=idandUSER.read=’true’,而id的数据来自于用户的请求：/get?id=1这样用户只要用提交/get?id=1or1=1即可直接忽略sql中其他条件判断了。参见wiki/wiki/Sql_injection现有的防SQLInjection开发方案都是基IBatis的，所以在基于IBatis开发的应用中出现SQLInjection的可能性比较小。但是Hatrix的SQLInjection检测是基于返回信息中的数据库信息，对于进行错误处理的程序是很难进行检测的，比如自动跳转到404页面。所以如果测试工程遇到非IBatis开发的项目，可能需要手动构建SQLInjection的测试用例，这些用例可以参考hatrix中模版HHatrix模版:参考4.6节。URLRedirectURL跳转的应用很广，在这里我们只局限于可以修改URL地址的跳转，比如正确登录后的跳转到之前页。这个之前页的URL地址就是可以修改的，是不确定的。URLRedirect的主要威胁在于钓鱼网站，恶意用户可以利用URLRedirect将有恶意跳转的URL转发给其他用户，而此URL同时能顺利逃过域名检测，比如/?Done=/如果URLRedirect检测不严格，登录之后即跳转到案例：下图浏览器地址显示的是一个淘宝的合法url地址，由于该应用对url过滤不严格，接受了参数url=2/RmfishServlet/urldirect,并以该url做了一次跳转，于是用户在访问taobao页面时，实质是请求了一个第三方网页，可想这个危险有多大！URL跳转本身是属于业务逻辑跳转的一种实现，所以工具检测成本比较高，同时应用中URLRedirect数量比较小，在需求文档中应该有描述，所以URLRedirect漏洞需要测试进行手动检测，主要的检测方法是采用手工的方式将目的URL地址替换成非阿里巴巴域名的URL地址，检测是否会跳转到非阿里巴巴的网站。AccessControl这里的访问控制主要是一些越权操作漏洞。AccessControl主要包括了水平权限和垂直权限两种，水平权限是指能访问其他用户受保护的内容，从权限关系的角度来看，这种情况突破了权限的水平约束。垂直权限问题就是访问需要更高授权的资源，比如未登录用户能够访问需要登录的资源，普通用户访问须管理员权限的资源等，从权限关系的角度看，这种情况是突破了权限的垂直约束，获取到了更高权限。案例:下图是国际站MyalibabaContacts模块下的ManageContacts,其中有个一个查询联系人的功能，url为/mcadmin/contact/contactDetailInfo.htm?cid=XXX，XXX为一个联系人的ID，如下图所示，这个页面没有问题，因为ID为63488082联系人就是属于当前用户的联系人，但是问题在于当恶意用户修改了cid后就能任意获取到其他联系人的信息，即使该联系人并不是该用户的联系人，如图所示，ID为63422XXX的用户信息被获取了，但是他并不是当前用户的联系人。这就是一个AccessControl漏洞。应用中的越权操作的检测需要对应用的业务逻辑和数据扭转有很清晰的了解，所有现阶段框架上和工具上没有合适的解决方案，此类漏洞只能依赖于手工测试。而手工测试的方法主要有两种：1）用户对私有资源的访问或是操作，比如访问用户的信息，如联系人信息，这就是访问属于用户的私有信息；还比如修改用户信息和删除邮件，用户能修改和删除一定只能是归属于用户的资源。类似的例子有很多，它们的共同点就是，这些操作基本都依赖于一个ID，也就是操作资源的标示符。所以测试的时候就需要把这个标示符替换掉，换成其他不属于用户操作范围资源的标示符，并通过操作结果来判断程序是否存在AccessControl的漏洞问题。2）不同用户身份之间的越权。比如未登录用户向服务器请求一个登录用户的才能访问的url，如果未登录用户同样能访问，那说明存在AccessControl漏洞。同样一个普通用户访问一个只有管理员权限的资源，也需要做越权检测。这类漏洞需要测试人员在不同身份账号，或是不同权限授权下对更高授权的资源进行请求测试，以此来发现是否存在AccessControl漏洞。上传下载文件安全威胁：Fileupload，任意文件上传威胁。Web应用程序在处理用户上传的文件时，没有判断文件的扩展名是否在允许的范围内，就把文件保存在服务器上，导致恶意用户可以上传任意文件，甚至上传脚本木马到web服务器上，直接控制web服务器。防御方案 每个上传需求点都要明确允许上传的文件类型，程序实现时要在服务器端对文件进行类型检测。同时上传的文件要保存至没具有代码执行能力的专门存储服务器上，不能保存在Web应用目录下。对于上传的图片类型的文件，必须要进行图片格式化，即将图片读入再重新生成一张新的图片。2.7Flash安全为了提高阿里巴巴信息系统的安全性，规范集团内部FLASH的开发及部署规范，特制定本配置规范。1.服务端Crossdomain.xml访问策略文件的安全需求安全关注点：不当的crossdomain.xml配置解决方案：如果没有flash应用，禁止配置crossdomain.xml策略文件，如果有，需要定允许的跨域请求的域，详细请参考参考安全中心的flash安全部署与开发规范2.用户上传flash功能的安全需求安全关注点：利用flash进行跨站或者csrf攻击解决方案：用户上传的flash文件上传到单独域名下，详细请参考参考安全中心的flash安全开发与部署规范3.项目中的flash是否有与浏览器交互的需求安全关注点：我们自己开发的flash文件也可能存在漏洞解决方案：如果没有特殊需求需要设置allowscriptaccess属性为never，详细请参考参考安全中心的flash安全部署与开发规范4.项目中的flash是否有与远程通信的需求安全关注点：客户端直接提交数据与flash文件通讯解决方案：如果没有特殊需求需要设置allowNetworking为none，详细请参考参考安全中心的flash安全部署与开发规范从Web安全测试的角度可以把以上五种安全漏洞类型分成两类：代码执行漏洞，功能逻辑漏洞。代码执行漏洞是因为输入中有非法操作，而且这些操作通过某些方式在某处以某些权限被执行。其中XSS，CSRF，SQLInjection都属于代码执行漏洞，这种漏洞自身和攻击方法都具有很强的可识别性，因为其威胁主要来自于程序直接使用了用户提交的数据，所以对用户的输入进行处理就能很好应对此类漏洞。所以对于这三类漏洞，在框架、工具以及开发规范上都是比较容易解决的。功能逻辑漏洞分两类，一种是在应用设计阶段错误的逻辑设计导致的，另一种就是代码中忽略或是错误的描述了应用逻辑。所以功能逻辑漏洞并不一定是代码本身的缺陷，可能依托代码执行的应用逻辑出错。AccessControl漏洞就是属于这类，URLRedirect、Flash安全、上传下载文件也可以理解为此类漏洞。自动化工具Hatirx介绍自动化工具Hatirx安全自动化测试工具主要采用，集团安全部门开发的Hatrix，工具的下载页面是：/twiki/bin/view/Security/SecurityProject/Hatrix_Web_Vulnerability_Scanner工具使用的视频教程地址是：/twiki/pub/Security/SecurityProject/Hatrix_Web_Vulnerability_Scanner/hatrix_demo.rarHatirx工具使用安全测试过程中工具hatirx的操作流程：打开准备进行安全测试的页面。打开hatirx安全测试工具。点击DeepScan按钮，准备开始扫描，该选项为默认选项。点击按钮，使hatirx处于录制http交互的状态。按照预想测试的流程Hatirx工具支持多页面连续录制，只要页面没有验证码等防重复提交校验值。Hatirx工具支持多页面连续录制，只要页面没有验证码等防重复提交校验值。点击按钮，结束录制。在下拉框中选择，该选项也是默认选项。点击按钮，进行预扫描。预扫描是什么概念？为了提高工具的扫描速度，工具根据内部规则（对每个http请求参数只进行一次随机数替换，如果页面返回值中不包括该随机数，即认为不会有漏洞，在正式扫面中不会对该参数扫描，也就是说预扫描并不是用来检测漏洞的而是检测请求的参数是否对应返回。例如，一个页面的http请求有10个参数，那么会每次使用一个随机数替换一个请求参数，整个预扫满过程也就是回放10次表单提交，用来检测这10个参数有哪些是没有返回值，哪些是有返回值。如果没有预扫满过，针对该页面的正式扫描还是这10个参数，每次执行每个参数替换漏洞库中的一条特征码，如果漏洞库中定义50条特征码，那么一共会回放10×50＝500次表单提交。如果经过预扫描，认为有7个参数没有返回值则不会产生漏洞，那么只需要3×50＝150次表单提交，这样会大大减少回放次数，也就减少了运行时间。）自动识别哪些参数需要扫描哪些参数不需要扫描，这样既保证了扫描的有效性同时又提高了效率。预扫描和预扫描全部的区别？预扫描会扫描当前鼠标选中的url地址，而预扫描全部会扫描当前选中的url地址及列表位该选中项以下的全部地址。扫描和扫描全部的概念类似。点击按钮，进行全面扫描。当扫描的url前显示绿色对号时，代表该地址扫描结束，并且没有发现安全漏洞。当扫描的URL前显示红色感叹号时，代表该地址扫描结束，同时发现有安全漏洞。扫描完全结束后会自动提示扫描结束。如果扫描结果发现漏洞，点击按钮的加号，显示所有扫描出的漏洞，如果查看漏洞详细信息，选中具体发现的漏洞。漏洞的详细信息在页面右侧显示（注意：此时一定要选中漏洞才会显示4个tab页，否则只显示2个tab页）。。Infor：本次扫描的整体结果简介。ViewSource：查看扫描url的html源码，漏洞位置及脚本会高亮显示。Browser：通过内嵌浏览器渲染该url地址的页面。Description：该漏洞的详细描述。点击按钮，导出本次安全扫描结果。点击按钮，进行场景和结果保存，在1.24版中，保存功能增加了扫描结果的保存，不仅仅是保存了录制的URL还有这些URL扫描后的结果，该结果比报表中描述的内容更加全面，所以建议扫描后一定要保存。报表中信息表单中提交的数据脚本录制时访问的url表单中提交的数据脚本录制时访问的urlhttp的提交表单名称服务端响应的关键字上下文漏洞类型，主要有：XSS、csrf、SQLinjection、DataInvalid 返回值中包含特征值手动测试工具当漏洞类型或场景不适用自动化工具时，需要手动测试，手动测试根据每个人的习惯不同而方法工具不同，不过我们推荐的组合有Firefox+Firebug+TemperData以上工具，只需要在google搜索关键字就能够很容易下载安装。以上工具，只需要在google搜索关键字就能够很容易下载安装。安全工具的原理实际上安全工具只是通过录制和回放，将安全部门整理的漏洞特征代码进行提交和验证。其原理和目前网站自动化原理基本类似，都是包括输入项、实际结果和预期结果并进行比较。如果实际结果中有预期的特征代码一致即认为有漏洞。其实手工完全可以自己输入漏洞特征代码并比较预期结果以达到和自动化工具一样的效果。漏洞特征代码库在哪里？在1.24版本中，所有的漏洞特征码已存放在服务器端，由程序运行时从服务端取，本地客户端无法配置。Hatrix工具注意事项禁止使用Hatirx工具扫描阿里巴巴线上应用以及其他网站的生产线上环境。因为本工具会产生大量http请求，服务器处理这些请求会占用大量资源，所以禁止扫描任何线上网站，Hatrix工具只适用于测试环境。安全测试分析举例这里用Myalibaba普通会员的Contacts功能作为例子，给大家演示一下安全工程师是如何分析安全问题的简要过程：如图5-1所示，Contacts主要包括了AddNewContact;MyContacts;ManageContacts;Settings;EmailAlert;BlockList;MatchingSellers几个子功能，其中MyContacts的部分功能属于AccountSettings，MatchingSellers属于SellingTools。这里对这部分不做讨论，只分析属于Contacts的功能。通过分析可以得出这几个功能的特点:图示4-1Myalibaba的Contacts功能AddNewContact是一个表单提交,里面涉及了部分数据验证。图示4-1Myalibaba的Contacts功能MyContacts是一个人相关信息的查询，是基本的Get请求，不涉及数据提交。ManageContacts中包括了Contacts的删除、修改，发送消息的功能。都是采用表单实现功能的。Settings中包括了Folders,ContactGroup,Templates,BlockList,ContactSettings的子功能，其中前4个子功能类似，都包括了新建、编辑和删除功能，也都是采用表单实现的。EmailAlert和BlockList都是一个表单提交。通过上面的简单分析，能明白Contacts的功能点和基本技术实现。然后综合考虑Contacts涉及的有表单提交，Get请求，数据验证，权限控制这些操作。这里可以用Hatrix自动化工具扫描的也比较清楚了，上面提到所有涉及request的地方，包括Post表单和Get请求，经过Hatrix扫描后能扫出这些地方是否存在XSS，CSRF和SQLInjection漏洞。但是这还是不够，因为Hatrix提交的数据只是一些具有攻击特征的代码，不能发现程序逻辑上的问题。在Contacts中有业务逻辑的包括了数据验证和权限控制，数据验证包括了表单中一些限制，比如AddNewContact中名字只能采用英文，Products/Services有字数限制，邮箱格式限制等。这部分是需要测试手工测试的。权限控制我们单独讨论，程序权