自动化代码扫描平台探索2

Findsecbugs工作原理和配置(一)

上集回顾

上次写了一个findsecbugs的内容，findsecbug是intelli idea的插件引擎，同时也是sonar的扫描引擎，但是这个玩意儿分叉了，分叉了一个更牛逼的spotbugs出来，但是这两者差不多的。

其中ide的插件findbugs集成了find-sec-bugs 规则。

里面有很多的detector，开启detector即可，当然detector的逻辑你也可以写。

比如下图

可以看到在findbugs.xml里有很多被我注释掉的detector，细节的detector我就简单的提一下。官方的wiki有基础的detector，也就是extendbasicDetector这个类。但是这个类要实现很多功能是不够的，因为你只能拿到seen,然后判断下seen 是不是和你描述的sink，也就是字节码是一样的，光判断字节码不足以解决误报率，也就是说，这样的basicDetector和SAST分析技术毫无区别。

 

静态的代码扫描，真的，如果不用CFG技术，就和垃圾一样。。。误报率贼高，和开源的rips一样，扫了和没扫一个样。还不如我自己从orm开始审计，一步步跟踪代码debug呢。以我菜鸡的愚见，代码审计不能这样审计的。代码运行是有一个链的，来源就是HttpServletRequest.getParameter之类的，其实就是调用栈，调用栈每进入一个方法增加一帧，只要那一帧不是过滤方法，且最后一帧是一些指定的方法，例如query,exec,等方法，那么就被确定为是漏洞。

接下来就不得不提到findsecbugs的detector基类，这些基类提供了不同的功能，要知道这个玩意儿最开始是用来检测代码规范的，不是为你们这群安全工程师找漏洞的，是找bug的，顺带找下漏洞，毕竟你们这群安全工程师提了issue了。

对我们安全的需求来说，只有一个基类是可以用的，即使OpcodeStackDetector，其他的都可以不要看了，其他的基类没啥鸟用的(因为你无法绘制CFG)。OpcodeStackDetector中的sawOpcode方法，这个方法传入的操作码的值，根据这个值我们可以得到操作数的信息，如操作码是函数调用，则能获取到函数的名称、描述符等信息。另外我们还能获取到方法栈数据，程序计数器等数据，使用这些数据便能实现想要检测的代码模式。visit(JavaClass obj)方法在分析class文件时调用；visit(Method me)方法在findbugs分析方法时调用；visit(Code code)在findbugs分析字节码指令是调用。需要注意的是，调用visit(Code code)时，一定要调用super.visit(code)方法，否则我们实现的sawOpcode方法将不会调用，因为sawOpcode是在super.visit(code)方法中调用的。

算了，我也看不懂java，给我一个java大佬吧，我和他配合也许可以搞定。- -

 

 

说说PMD

PMD就没什么好说的了… 运行./run.sh designer

就看到测试代码的ast语法树。查阅了官方文档的rules真的是惨不忍睹啊，只能扫描特定的代码。。。那有毛用啊，好不容易找了一个pmd-security-rules ，一看名字很高大上的 一定是专门的安全规则。看了下github时间

8年前……

然后你自己去看下他的规则就会发现…不用跑，在我大脑里就感受到了大量的误报，别说应用在上千的应用场景下了。劝大家放弃PMD。。。。。

 

 

 

本文始发于微信公众号（xsser的博客）：自动化代码扫描平台探索2