Veracode动态扫描怎么启动Veracode动态扫描站点认证怎么设置，关键并不是简单地把网址填好就直接去点运行，而是一定要把扫描目标、认证方式、扫描范围和需要排除的规则预先整理妥当。Veracode动态分析也就是常说的DAST，这项功能专门用来扫描Web应用和API当中的安全漏洞，在扫描过程中它会顺着目标URL一路爬取过去，把运行状态下可能暴露出来的那些安全问题逐个识别出来；如果站点还有登录这道限制，那还得提前把认证给配好，否则扫描器能看到的就只有登录之前的那几张公开页面了。
一、Veracode动态扫描怎么启动
准备启动动态扫描之前，应当先判断一下扫描对象到底适不适合被DAST去访问，通常情况下测试环境和预生产环境会更加合适，如果是直对着生产站点扫描，就得格外留心扫描的窗口时间、账号上的权限、限流策略还有对业务的影响，不能让扫描动作意外触发真实交易、批量往外发出短信邮件，或者是往后台写入一大批多余的数据。
1、先确认扫描目标
事前要把扫描对象彻底搞清楚，要明确意图是要扫一个Web站点、一套REST API，还是指向某一个单独的业务入口，Web应用一般会从根地址或者核心入口页面开始扫描，而API扫描则多半需要配上接口规格文件，或者是先归拢好一组接口集合再做。Veracode的文档里面也提到，Web应用扫描和API扫描不能为图省事就混在同一个分析任务里面去用，而是应当按照目标类型分别配置才行。
2、创建或选择目标
进入【Scans&Analysis】→【DAST】后，选择已有目标或新建扫描目标。
给目标填配置的时候，要把URL、它到底是挂在哪个应用下属、扫描的名称叫什么，还有扫描范围是多大这几项全部交代清楚。名称这一块最好不要起得过于随意，最好能把项目名称、环境类别和版本信息一并编进去，例如“订单系统-测试环境-回归扫描”这样的叫法，后面再去翻阅报告和对比历史结果时，就不容易把几次的分析记录搅在一起而弄混了。
3、设置扫描范围
扫描的范围不能单纯靠默认的那一套配置，要回过头去检查初始URL是什么、允许它去触碰哪些域名、要把哪些路径排除出去、最多可以往下爬到哪一层，还有整趟扫描任务到底会持续多长时间。要是站点中存在退出登录、删除数据、提交订单、往外发送通知这一类路径，建议提前就把它们放进排除项或者限制范围里面，省得在扫描进行的过程中生出多余的无用数据，或者反过来干扰到测试环境的稳定。
4、启动扫描任务
前面这些配置全部处理好之后，可以选立即把它跑起来，也可以排一个按钟点走的计划任务去执行。Veracode既支持在平台里面直接配置动态扫描，也允许通过REST API去创建动态分析任务，这种用法跟现有的流水线搭配在一起集成是非常顺手的。
二、Veracode动态扫描站点认证怎么设置
站点认证这一环的目的，就是想让扫描器也能像一个普通的测试账号那样，平平稳稳地进到登录过后才能看到的页面里面去。这个环节最容易出问题的地方，往往并不是账号密码那两样本身，而是在登录的一整条流程里夹进了验证码、多因素认证、动态跳变的Token值、来回跳转的页面，又或者是会话保持不住很快就超时了。
1、选择认证方式
在目标配置中进入【Authentication】页面，选择适合当前站点的认证方式。
如果当前站点只用基础认证这一层，那可以直接配Basic Authentication；如果遇到的是表单登录，一般就要靠登录脚本才能撑得起来；如果是接口只认准固定的几个请求头，也大可以把自定义的HTTP Header揉进来一块儿用。Veracode文档里面也列举了，动态分析可以用自动登录、基础认证、靠登录脚本驱动的表单登录，还有自己定下的HTTP头这么多种方式。
2、录制登录脚本
碰着装填表单登录的场景，可以用Selenium IDE把一整套登录流程从头到尾录下来，再把这个流程存成SIDE文件往平台上传。官方文档里面也提到过，登录脚本能够模仿真实浏览器里面的那些动作，比如填写用户名、输入密码、点击登录按钮，然后再耐着性子等待登录之后的页面上那些标志性元素全都显露出身形才算完。
3、准备测试账号
拿来作认证凭据用的账号绝对不要去碰管理员号，也不要去借用真实用户手里正在使用的号，更稳妥的搞法是单独去申请一个专门用来做测试的账号，只把扫描所必须要用到的那一点权限分给它，同时把那些可能会惹出高危操作的大权限全部关掉。此外这个账号也不能在扫描跑到半截的时候，就因为密码过了期、突然弹出二次验证，或者被风控规则锁定而整个掉线。
4、验证登录是否成功
认证的相关配置全部上传好以后，要先去看一遍预扫描或者认证测试跑下来的结果，要是登录没能顺利淌过去，那就要去翻失败瞬间截下来的那幅图，查看它到底被跳转到了哪一个地址，页面上的那些元素有没有走样，Token是不是已经过期了，以及脚本里面设定的等待时长是不是掐得太短。Veracode的更新说明同样指出，登录脚本认证失败时可以向用户给出关联的排查消息和截图，方便快速定位到问题根源。
三、动态扫描认证失败时怎么排查
如果认证一直过不去，就不能光是在那里一遍遍机械地修改密码了。很多情况下账号它本身一点错也没有，是脚本里的等待条件、突然拍过来的跳转页面、背上传着的那串请求头、孤零零落着的Cookie，或者那套拨来拨去的访问限制策略没给弄对，所以扫描器才没能真的进入登录以后的会话状态。
1、检查登录流程变化
如果前端那些页面已经做过了翻新改版，那登录按钮上挂的ID、输入框的名称，还有一整套跳来跳去的路径，说不定早就连位置一起搬到别处去了，原来好不容易调通的那套Selenium脚本一下子就会趴掉。遭遇这种局面，应该直接把脚本重新录制一次，而不是在旧脚本里光去改动一下账号密码就交出去完事。
2、检查安全拦截
要是站点那边已经把验证码、短信校验、设备指纹、IP访问限制，再不就是WAF这层防护策略全给升了起来，那扫描器就很有可能会被当作不循常规的异常访问而给一膀子搡到墙外面去。到了这一步，得去跟负责安全或者管运维的团队把测试环境里面的策略再核对一遍，真遇到非放不可的情况，就给扫描来源、测试用的账号，或者测试爬取的那几条路径放开一个能拿得出理由的通行口子。
3、检查会话保持
有些站点从表面看是已经顺顺溜溜地登进去了，可是过不多久就自行超时断开了，再要不就是只要一伸手去碰某几个特定的页面，马上就被一脚踢回登录那面去。落到这种处境，就要去细查Cookie、Session、CSRF Token，还有藏在后头的那一套重定向的门道，动态扫描必须具备能持续扒住登录之后页面的能力，否则扫出来的海量结果很可能会一股脑儿全堆在登录页、错误页，或者那些完全不设防的公开页面上头。
总结
整体来看，Veracode动态扫描怎么启动，还有站点认证又要怎样去把它支起来，总可以照着“先认准扫描目标是什么、然后再把扫描范围圈出来、接着把认证方式配上去、之后回身去验证一下登录到底走没走通、最后才去按下扫描”这样一条趟子来走。动态扫描这桩事情并不是只把URL挂上去就能换到顶用的结果，站点认证、扫描边界、测试用的账号，以及该当被撇到排除清单里的那几条路径，件件都会去牵动最终结果的成色，认证那一截配得越是牢靠，扫描器就越能把真实跑着的业务页面盖得严实，后面挖出来的漏洞结论也才更好拿去从容地修复和安排复测。
