Fortify漏洞路径怎么分析，以及污点传播路径太长的时候又该怎样筛选重点，是很多团队在复核SAST结果时都会碰到的情况。Fortify扫出一条SQL注入、命令注入、路径遍历或者跨站脚本问题，如果只在列表里看漏洞名称，那是不够的。真正要判断它是不是有效风险，还是要看数据是从哪里来的，中间经过哪些变量和函数，最后流向了哪个危险的调用。Fortify的数据流类问题会在Analysis Trace里面展示污染数据从source到sink的路径，审计的时候这条路径就是主要的判断依据之一。

　　一、Fortify漏洞路径怎么分析

　　分析Fortify漏洞路径的时候，不要一上来就从最后一行开始改。不少人看到sink是数据库执行、文件读取、命令拼接，就直接判定这里有漏洞，但中间可能已经做过校验了，也可能校验虽然写了，却没有真正作用到后面的变量。路径要从入口慢慢往下读，着急不得。

　　1、先看Source和Sink

　　打开Analysis Trace以后，先要确认Source是在哪里，Sink又落在哪里。Source常见的位置，有请求参数、Header、Cookie、文件输入、外部接口的返回值等等；Sink则可能是SQL的执行、系统命令、文件路径、日志输出、HTML响应这一类的敏感点。先要把头和尾都看清楚，后面再去看中间的传播，才不会觉得乱。

　　2、顺着中间节点完整地读一遍

　　中间的节点不要跳过去。一个参数可能会经过Controller、Service、DAO，也可能被塞进对象的字段里面、放进Map里面、经过工具方法，然后再被取出来使用。Fortify的Dataflow Analyzer会做跨过程的污点传播分析，用来发现从输入点一直到危险点的数据流。但是静态分析看到的是可能的路径，并不代表每一条路径在所有业务条件下，都会真实地被执行到。

　　3、看安全处理是不是真正起了作用

　　如果中间出现了白名单、编码、转义、参数化查询、路径规范化这些处理，就要看一看处理以后的变量，是不是继续传到了Sink那里。很多误判就是出在这个地方的：代码看上去是做了过滤，但是后面用到的还是原来那个没有处理过的变量；或者是确实用了安全的API，只是工具没有完全把它识别出来。不要只看函数的名字，要去看数据的对象到底有没有被替换掉。

　　二、Fortify污点传播路径太长怎么筛重点

　　污点的路径如果太长了，一行一行地去看会很吃力，特别是在大型的Java、.NET项目里面，封装的层次一多，一条路径可以拉得非常长。这个时候并不是每一个节点都同等重要，把重点筛出来会更加现实一些。

　　1、先抓住三类节点

　　可以优先去看入口的节点、数据发生了变形的节点，还有危险调用的节点。入口决定了数据本身是不是可信的；数据变形的节点决定了风险是不是已经被消除掉了；危险的调用节点则决定了漏洞的类型。中间那些普通的getter、setter，还有DTO的转换，可以先大致读一下，不一定每一行都需要深挖下去。

　　2、重点去看条件分支

　　路径里面如果经过了if判断、权限判断、角色判断、配置开关，这些地方需要多停一下。有些漏洞只在特定的配置下面才会成立，有些则需要管理员的权限，还有一些外部的用户根本触发不到。能不能被触发，比路径本身是长还是短，要更加关键。

　　3、把重复的路径合并起来看

　　同一类的漏洞，有可能是从多个接口进入的，最后流到了同一个Sink；也有可能是Source不一样，但是中间的处理逻辑是一样的。这一类的审计结果，可以先按照Sink、漏洞的类型、公共的方法，分组放在一起看。先去判断公共的那一段链路有没有问题，然后再回过头来，看每一个入口是不是真的可以到达，这样会比一条一条单独去审，快上很多。

　　三、路径太复杂时怎么避免误判

　　Fortify的路径很长，这并不代表它就一定是个误报，也不代表一定要立刻去修。比较稳的做法，是把可达性、可利用性、还有现有的控制措施，分开来去看。如果把这些混在一起去判断，是很容易出现前后矛盾的情况的。

　　1、确认代码的版本是不是一致的

　　先去对照扫描的版本、分支、提交记录和本地的代码。版本不一致的时候，路径的行号、函数的位置，甚至变量的名字，都有可能对不上。很多“路径看不太明白”的问题，到最后查下来，不过是扫描的包已经旧了。

　　2、补充一些运行时的证据

　　要是怀疑这条路径实际上走不通，可以用接近真实业务的输入，去做一次验证。断点可以放在Source、中间关键赋值的地方，还有Sink的附近，不要只在最后的那一行等结果。断点没有进去，也不一定就代表是误报，也有可能是触发的条件没有满足。

　　3、把审计的结论写清楚

　　如果确认了它是真实存在的问题，那就说明入口在哪里、危险点在哪里，以及缺少的防护是什么；如果认为是误报，也要把原因写清楚，比如输入是来自固定的枚举、已经做过参数化查询了、路径已经经过白名单的限制，或者当前的角色没有办法触发。如果只写一句“false positive”，或者是“业务上不会发生”，后面做复核的时候，通常还是会被人追问。

　　总结

　　Fortify漏洞路径怎么分析，以及污点传播路径太长的时候怎么筛重点，核心是先把Source、中间的传播节点和Sink看明白，然后再去判断中间到底有没有有效的安全处理。路径太长的时候，不需要平均用力，可以优先去看入口、变形点、危险调用，还有条件分支。最后再结合代码的版本、触发的条件和业务的权限，去判断它到底是不是真实可利用的。这样分析下来，Fortify的结果才不会只变成一堆告警的列表，而是能够真正转化成可以被修复、可以被解释的安全问题。