在Veracode的动态分析里面，对于那种需要先登录进去，才能接着往下访问业务页面的扫描，平台的认证配置是支持好几种方式的，按照官方文档的说法，可以去用自动登录、表单认证、参数认证、OAuth 2验证、SAML验证，还有Selenium的登录脚本，来把认证这一关给搞定，要是碰上的登录流程，是好几个步骤才走得完的，官方也说了，是可以去录一段Selenium的登录操作，再把它给传上去，这样扫描器在要去访问应用的时候，就能自己先去把登录给完成了。
一、登录流程要怎么录
在Veracode的动态分析里面去录登录流程，这件事的重点，并不是要你照着人工登录的样子，把它给完完整整地录下来，而是要去录出一条，足够稳定、可以被人来回重复着用、而且还没什么干扰的认证路径出来，这个用来登录的脚本，越是简单，到了真正扫描的时候，它就越不容易，卡在那种弹窗、验证码、跳来跳去的页面，或者是某些临时的状态上面。
1、要先去准备一个拿来做测试的账号
要先去准备一个，专门就是给扫描来用的测试账号，这个账号的权限，得能覆盖到你打算去扫描的那些业务页面，但是，最好是别去用那种管理员的账号，另外，这个账号，也别给它绑上那种临时的验证码、强制要求你改密码、第一次登录时候的引导流程，还有那些很复杂的风控校验，要不然的话，你在自己录制的时候，它是能顺顺利利地登进去的，可到了扫描的时候，没准儿就会失败了。
2、去用Selenium IDE把流程给录下来
先去把Selenium IDE这个工具给装好，然后把它给打开，从那个登录的页面开始，去点一下录制的按钮，然后，照着正常的顺序，把用户名给填上、密码也给输进去，再去点那个登录的按钮，最后，就等着页面稳稳当当地进到那个，登录成功以后才能看到的内容里去，按照Veracode官方文档的说明，这个登录的操作序列，是可以用Selenium IDE去录下来的，然后，再把它给保存成那种标准的、后缀是SIDE的格式文件。
3、只把那些必须要有的步骤给留下来
等录完了以后，要去检查一下那个脚本，把里面那些跟登录没关系的小动作、鼠标跟着到处乱晃的轨迹、还有等得实在太久了的地方，都给删掉，在这个登录的流程里面，就只去保留住，像是打开登录的页面、往输入框里填东西、把填好的表单给提交上去，还有等着那个关键的、能证明你已经登录成功的元素，安安稳稳地出现在页面上，这么几类动作就够了，在登录完成了以后，那个脚本最后去到的页面，最好也选一个比较稳当的，就比如，应用的首页、那个能看数据概览的仪表盘，或者是随便一个业务的列表页。
4、把它给上传到认证的配置里面去
去登录进Veracode的平台，然后进到扫描和分析的那个模块，找到动态分析，再接着去找到你这次要测的那个Web应用，在它旁边那个操作列里面，去选上配置的选项，然后进到认证的那个页面里面去，把你刚才录好的那个登录脚本，给上传上去，在官方的文档里面，也是给出了这么一条，从动态分析的配置页，一路进到认证的页面，然后再去把脚本给传上去的，清清楚楚的路径。
二、登录态失效了要怎么排查
碰到登录状态失效这种情况，先别一股脑儿地只去怀疑，是不是Veracode的扫描器出了什么毛病，比较常见的原因，其实是出在了账号那边的策略上、会话能撑多久、Cookie自己带着的属性上、登录的脚本跑得不够稳、应用的跳转逻辑发生了变化，或者是，扫描的范围，压根儿就没有把登录成功以后，才会去到的那种域名，给包含进来。
1、先去看一看，你选的认证方式，它到底合不合适
要是碰上的就是一个普普通通的表单登录，那就可以优先去用平台自己提供的，那种自动登录，或者是表单认证的功能；可要是碰上的，是那种要好几个步骤才能完成的登录、或者是除了用户名和密码，还得再填一个PIN码、再或者是那种跳来跳去的流程很复杂的情况，到了那个时候，再来考虑去用Selenium的登录脚本，Veracode的文档里也提到过，在最近的增强之后，现在是更推荐，先去配置那个自动登录的，而不是一上来，不管什么情况，都跑去用登录脚本。
2、去检查一下你的那个脚本，是不是每次都能跑得通
在Selenium IDE的那个工具里面，去把你录好的脚本，重新再跑一遍看看，去观察一下，它是不是每一次，都能从一个完全没登录的状态开始，顺顺当当地就进到了那个，登录之后才能看到的目标页面里面去，有不少失效的问题，它其实就出在，那个脚本，还在依赖着以前留下的旧Cookie、页面上用来定位元素的特征不太稳定、那个按钮它加载出来的速度实在是太慢了，又或者，是登录完成以后，页面上那个网址，它自己发生了变化。
3、去检查一下，服务器那边设置的那个会话超时的时长
要是应用它本身的会话，能保持的时间就特别短，那么在扫描的过程当中，就有可能会被服务器，给一脚踢回到登录的页面去，这就需要，让测试环境那边，那个会话的有效时间，得长到足够撑完一次完整的扫描才行，或者是，去确认一下，这个应用，它是不是能在你不停地访问它的过程里，把那个会话的状态，给维持住，要是系统里还设了那种，人待着不动就会超时、单点登录它有自己的超时限制、或者是同一个账号不许同时在好几个地方登录，这些情况，也都要一并去检查一下。
4、去检查一下Cookie还有域名，它们所覆盖的范围
在你登录成功了以后，那个用来证明你身份的Cookie，它一般都是被死死地绑定了域名、路径、安全的属性，还有SameSite的那套策略的，要是扫描的入口，是从一个域名登进去的，可是后面再执行业务操作的时候，又跳到了另一个不同的子域下面，那这个Cookie，很有可能就带不过去了，所以，得去确认一下，你要扫描的目标网址、登录的那个页面、业务操作的页面、还有回调的页面，这些全都在那个允许的范围内，并且那个Cookie，是可以被正常地复用的。
三、认证失败了要怎么去定位
在去定位认证失败的原因时，是要把平台给出来的提示、预扫描里跑出来的信息，还有应用那边自己记下来的日志，这好几样东西，结合到一块儿去看的，不能只是盯着最后的那份扫描报告，因为认证失败这件事，它往往是在扫描，真正地、深到业务的那些页面里面去之前，其实就已经发生了。
1、去看一下预扫描里头的认证结果
要先去Veracode的平台上面，看一看预扫描的详情，或者是认证失败的时候，给出的那些提示信息，在Veracode的更新记录里，是有提到过的，说动态分析，它会对着登录脚本认证失败的那些情况，提供出用来排查问题的信息，而且，在预扫描的详情里面，还能跟着里面的链接，去看到，当时出错的时候，截下来的那张图。
2、去对照着应用那边记下来的访问日志
去找一下管着应用的管理员，让他去查一查，那个测试的账号，在扫描的那个时间段里，是不是真的成功登进去了，是不是刚一登进去，就立马又被人家给踢了出来，又或者，是不是触发了风控的规则、被限制了访问的频率、被权限给拦住了，还是跳转的时候出了什么异常，从应用这边记下来的日志，是要比前端的报错，来得更直接的。
3、去把登录完成以后，用来验证的那个页面，给固定下来
在那个脚本的最后一步，可不要让它停在一个，内容加载得不太稳定的页面上，最好是去等着一个，位置和样子都比较固定的元素，安安稳稳地出现在那里，就比如，用户头像那个小图标、那个用来退出登录的按钮、首页上最大的那个标题，或者是业务导航菜单，只要这个元素，它是稳定地在那里的，那它就能帮着你去判断，登录这件事，到底是不是已经做完了。
4、去把登录流程里面，那些不确定的变量，给减到最少
给扫描专用的那个账号，最好是不要去开启，那种多台设备同时登录就会被踢下线的策略、短信验证、人机的校验、还有第一次登录的时候弹出来的那些个协议窗口，在测试的环境里面，是可以提供一个，更加稳定的认证入口的，这么做，就能避免扫描器它每一次跑起来，都会撞上一条，跟上次完全不一样的分支。
总结
在Veracode的动态分析里，登录的流程要怎么去录，这件事的关键，就是拿着一个稳稳当当的测试账号，去录出一套精简过的Selenium登录操作，等把它存成了那种SIDE格式的文件以后，再到动态分析的认证配置页面那边，把它给上传上去；而登录状态失效了以后，又要怎么去排查，这里的重点，就是要去看，你选的认证方式对不对、脚本是不是能经得住反复地跑、会话多久会过期、Cookie能管到的范围是多大、域名是怎么跳的，还有应用那边都记下了哪些日志，只要那个登录脚本，放在本地的工具里，是能一遍又一遍地、稳稳当当地跑成功的，而且扫描账号的权限，还有服务器那边的会话策略，也都是靠谱的，那这个动态分析，才能真的进到，登录之后才能看到的那片业务页面里头去。
