在Web应用安全测试里面，经常会碰到这样的问题，就是BurpSuite扫描器的检查项，到底要怎么去选，还有扫描完了以后，那一堆结果，又要怎么去把重点给筛出来，我们不能以为，把扫描器打开，让它全扫一遍，这件事就算做完了，如果检查项选得太宽，扫描花的时间就会变得很长，出来的结果里面，也会混进去很多价值不高的信息；可要是选得太窄了呢，又很容易漏掉一些接口、参数，还有那些需要登录以后，才能看到的业务入口，根据PortSwigger的文档，Burp扫描器在审计阶段，是通过被动检查、主动检查，还有对JavaScript的分析，来找出问题的，而那些审计方面的设置，也可以帮助我们在覆盖的范围和扫描的速度之间，找到一个平衡。

　　一、检查项要怎么选择

　　在选择扫描器的检查项时，我们不能一上来，就把所有的检查都给拉满，而是要先看这一次测试的目标是什么，比如说，去测登录页面、后台管理、上传的接口、支付的流程，还有那些开放的API，这些地方要关注的点，都是不一样的，所以检查的配置，也应该跟着做出变化。

　　1、按照业务的风险来选审计的范围

　　我们从仪表盘里，新建一个扫描任务之后，要先去确认好目标的地址、当前的登录状态、扫描的范围，还有哪些路径，是要排除在外的，对于那些核心的业务接口、表单提交的地方、文件上传的入口、搜索查询的功能，还有用户修改自己资料的页面，这些都要优先把它们放进检查的范围里；而对于那些静态的资源、没有什么意义的重复路径、退出登录的链接，还有发送短信的接口，就要小心去处理了，免得在扫描的时候，造成一些不必要的干扰。

　　2、按照测试的阶段来选扫描的深度

　　在前期摸底的时候，我们可以去选择一种比较轻的配置，先大概看一看站点的结构、入口是不是都覆盖到了，还有那些比较明显的风险在哪里；等到了正式测试的时候，再动手把检查的深度给提上去，Burp的审计配置，它允许我们去调整覆盖的范围和扫描的速度，这样就能根据目标应用本身的特点，来安排扫描的策略了，如果站点的接口特别多，会话又很容易就失效了，那最好还是先在一个小范围里，把配置给验证一下，然后再去扩大扫描的范围。

　　3、去关注插入点的覆盖情况

　　我们要检查的项目，不光是指漏洞的那些类型，还包括到底有哪些参数，会被拿来测试，在扫描完的结果里面，有一个地方可以让我们看到审计的条目和插入点，在那里，就能查出来，某一条请求里面的哪些参数、路径、Cookie，或者是请求体的哪些位置，被包含进了审计的范围里，根据官方文档的说法，这个面板就是用来帮你理解，扫描器到底覆盖到了哪些攻击面的，要是发现关键的参数，并没有被识别出来，那就要去调整一下请求的样本、登录的状态，或者是扫描的范围了。

　　二、审计结果要怎么筛重点

　　对扫描出来的结果进行筛选，不能光是盯着数量去看，一个严重程度高的问题，比十几个仅仅起提示作用的问题，更需要被优先拿出来确认；而一个确信程度高的结果，也要比那些不大确定的结果，更适合先被放进修复的流程里面。

　　1、先按照严重度和可信度来筛

　　我们在仪表盘里，打开对应的那个扫描任务，然后进到问题列表里面，去查看结果，根据PortSwigger文档，问题列表这个页面，就是用来查看新发现的问题的，而且它还能按照严重程度和确信程度，去处理这些结果；在它们给出的示例报告里，严重程度被分成了高、中、低、信息提示这几个等级，而确信程度，则被分成了确信、比较确定、和不确定这几档，在实际动手筛选的时候，我们可以先去看那些高和中风险的，然后再去关注确信和比较确定的，那些严重程度很低、只是信息提示的条目，可以放到后面再去慢慢整理。

　　2、优先去看那些能复现，而且有证据的问题

　　当我们点开一条具体的问题，就可以看到当时的请求、响应、证据是在哪个位置、影响的说明，还有修复的建议，那些能够看到明确的参数、响应上的差异，还有触发路径的问题，通常就要给一个更高的优先级；至于那些只是给出一个倾向性的提示、缺少稳定证据的问题，就可以先把它们标记成等待人工去复核，不要直接把这些问题推给开发人员，免得引起一些不必要的争论。

　　3、按照资产和功能的链路来排序

　　哪怕同样是中等风险的问题，如果它们是出现在登录、权限、订单、支付、上传，还有后台管理这些关键的位置，那处理的顺序，也要比那些出现在普通展示页面上的，更靠前一些，在筛选重点的时候，我们可以把结果按照请求的地址、功能的模块、接口的类型，去做一轮归类，先把那些能够影响到账号、数据、权限，还有交易流程的问题，给处理掉。

　　三、怎么避免结果的误判

　　扫描器给出来的结果，是需要经过人工去审计的，并不适合就这么原封不动地，整包直接交付出去了，工具能帮我们找到一些线索，但最终到底是不是问题，还是要结合业务的场景、权限的边界，还有代码到底是怎么实现的，来做出判断。

　　1、去查看审计日志的变化

　　在扫描任务的审计日志里面，会把审计过程中发生的关键事件都给记下来，比如说，什么时候发现了新的问题、给已有问题补充了证据、某个问题不再存在了，然后从列表里面被移除了等等，如果有一个问题，在好几次的扫描当中，都反反复复地出现，那我们就可以把它的优先级给提高；要是它只在某一次网络不太正常的情况下才冒出来，那在确认的时候，就要格外地谨慎了。

　　2、重新复核一下登录的状态和扫描的路径

　　很多被误报成问题的情况，其实都是因为登录的状态已经失效了、页面跳转到了统一的报错页面、被验证码给拦住了，或者是被应用防火墙的响应给干扰了，所以，在筛选结果的时候，我们要去看一看，当时的请求，是不是真的处在一种真实的业务状态里面，服务器返回来的那个页面，到底是不是来自我们要测的那个功能，而不是什么登录页、报错页，或者那种统一的拦截页面。

　　3、输出的时候，要分层去归档

　　在出报告的时候，不要把所有的问题，都平铺直叙地摆在上面，我们可以把它们分成四类来整理，一类是需要马上去确认的，一类是需要交给开发去修复的，一类是需要人工再复核一遍的，还有一类，就仅仅是信息的提示，同时，还要把请求和响应的内容、地址、参数、证据的截图、能够复现的条件，还有处理的建议，都给保留下来，这样的话，开发那边拿到手以后，就能直接去定位问题，等做安全复查的时候，也能看明白，每一个问题当时为什么会被保留下来，或者为什么会被降级处理。

　　总结

　　总的来说，扫描器的检查项要怎么选，还有结果又要怎么去筛重点，这里面最核心的思路，就是先把范围给定下来，再去控制检查的深度，最后，再根据严重程度、可信度、它们在业务中所处的位置，还有证据的质量，来一层一层地筛选，检查项不能盲目地去全开，要围着登录状态、那些关键的接口、插入点的覆盖情况，还有当前所处的测试阶段，来去配置；而对于结果，也不要只盯着数量看，要先去处理那些风险高、可信度高、能够被复现，并且会影响到核心业务链路的问题，这样处理下来，扫描器给出的结果，才会更像是一张可以被执行的安全清单，而不是一大堆很难落地的扫描提示。