如何构造CodeDB来探索全新的白盒静态扫描方案

如何构造CodeDB来探索全新的白盒静态扫描方案，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。我用了一个简单的例子描述了一下基于.QL的扫描思路，但实际在这个领域我可能只见过一个活的SemmleQL（也就是CodeQL的原型）。下面我聊一聊这相关的东西，也分享一些我尝试探索的一些全新的静态扫描方案。QL全称Query Language，是一种用于从数据库查询数据的语言。我们常见的SQL就是QL的一种，这是一个很常见的概念。而.QL是什么呢？Wiki上的解释是，一种面向对象的查询语言，用于从关系数据库中检索数据。而.QL又和静态分析有什么关系呢？我们需要理解一个概念叫做SCID。SCID: Source Code in Database 是指一种将代码语法解析并储存进代码中的操作方法。而这种数据库我们可以简单的称之为CodeDB。当我们通过一种方案生成了CodeDB之后，我们就需要构造一种QL语言来处理它。当然CodeQL正是一种实现了CodeDB并设计好了相应的QL语言的平台。而Semmle QL设计的查询语言就是一种.QL，它同时符合了几种特点其中包括SQL、Datalog、Eindhoven Quantifier Notation、Classes are Predicates其中涵盖了针对代码的不同逻辑而使用的多种解决方案。当然，本文并不是要讨论CodeQL，所以这里我们并不深入解释Semmle QL中的解决方免费云主机域名案。.QL的概念最早在2007年被提出，详情可以参考：https://help.semmle.com/home/Resources/pdfs/scam07.pdf在《从0开始聊聊自动化静态代码审计工具》中我曾经把基于.QL的认为是未来白盒发展的主要趋势，其主要原因在于现代普遍使用的白盒核心技术存在许多的无解问题，在上一篇文章中，我主要用一些基于技术原理的角度解释了几种现代的扫描方案，今天我就从技术本身聊聊这其中的区别。其实我在前文中提到的两种分析方式，无论是基于AST的分析、还是基于IR/CFG的分析方式，他们的区别只是技术基础不同，但分析的理论差异不大，我们可以粗略的将它们统一叫做Data-flow analysis，也就是数据流分析（污点分析可以算作是数据流分析的变种）。数据流分析有很多种种类，其本质是流敏感的，且通常来说是路径不敏感的。当然，这并不是绝对的，我们可以按照敏感类型将其分类：流敏感分析：flow-sensitive，考虑语句的执行先后顺序，这种分析通常依赖CFG控制流图。路径敏感分析：path-sensitive，不仅考虑语句的执行顺序，还要分析路径的执行条件（比如if条件等），以确定是否存在可实际运行的执行路径。上下文敏感分析：context-sensitive，属于一种过程间分析，在分析函数调用目标时会考虑调用上下文。主要面向的的场景为同一个函数/方法在不同次调用/不同位置调用时上下文不同的情况。当然，需要注意的是，这里仅指的是数据流分析的分类方式，与基于的技术原理无关，如果你愿意，你当然也可以基于AST来完成流敏感的分析工具。在基于数据流的扫描方案中，如果能够完整的支持各种语法充足的分析逻辑，我们就可以针对每一种漏洞分析相应的数据流挖掘漏洞。可惜事实是，问题比想象的还要多。这里我举几个可能被解决、也可能被暂时解决、也可能没人能解决的问题作为例子。1、如何判断全局过滤方案？
2、如何处理专用的过滤函数未完全过滤的情况？
3、如何审计深度重构的框架？
4、如何扫描储存型xss？
5、如何扫描二次注入？
6、如何扫描eval中出现的伪代码逻辑？现代扫描方案不断进步的同时，或许许多问题都得到一定程度的解决，但可惜的是，这就像是扫描方案与开发人员的博弈一样，我们永远致力于降低误报率、漏报率却不能真正的解决，这样一来好像问题就变得又无解了起来……当然，.QL的概念的扫描方案并不是为了解决这些问题而诞生的，可幸运的是， 从我的视角来看，基于.QL概念的扫描方案将静态扫描走到了新的路中，让我们不再拘泥于探讨如何处理流敏感、约束方案等等。上次我简单解释了基于.QL扫描方式的原理。其核心的原理就在于通过把每一个操作具象化模板化，并储存到数据库中。比如这个语句被具象为然后这样的三元组我们可以作为数据库中的一条数据。而当我们想要在代码中寻找执行a函数的语句时，我们就可以直接通过这样的一条语句可以寻找到代码中所有的执行a函数的节点。当然，静态分析不可能仅靠这样的简单语句就找到漏洞，但事实就是，当我们针对CodeDB做分析的时候，我们既保证了强代码执行顺序，又可以跨越多重壁垒直接从sink点出发做分析，当相应的QL支持越来越多的高级查询又或者是自定义高级规则之后，或许可以直接实现。也正是因为如此，CodeQL的出现，被许多人认为是跨时代的出现，静态分析从底层的代码分析，需要深入到编译过程中的方式，变成了在平台上巧妙构思的规则语句，或许从现在来说，CodeQL这种先铺好底层的方式并不能直接的看到效果，可幸运的是，作为技术本身而言，我们又有了新的前进方向。下面的文章，我们就跟着我前段时间的一些短期研究成果，探索一下到底如何实现一个合理的CodeDB。在最早只有Semmle QL的时候我就翻看过一些paper，到后来的LGTM，再到后来的CodeQL我都有一些了解，后来CodeQL出来的时候，翻看过一些人写的规则都距离CodeQL想要达到的目标相去甚远，之后就一直想要自己试着写一个类似的玩具试试看。这次在更新KunLun-M的过程中我又多次受制于基于AST的数据流分析的种种困难，于是有了这次的计划诞生。为了践行我的想法，这次我花了几个星期的事件设计了一个简易版本的CodeDB，并基于CodeDB写了一个简单的寻找php反序列化链的工具，工具源码详见:https://github.com/LoRexxar/Kunlun-M/tree/master/core/plugins/phpunserializechain在聊具体的实现方案之前，我们需要想明白CodeDB到底需要记录什么？首先，每一行代码的执行顺序、所在文件是基本信息。其次当前代码所在的域环境、代码类型、代码相关的信息也是必要的条件。在这个基础上，我尝试使用域定位、执行顺序、源节点、节点类型、节点信息这5个维度作为五元组储存数据。举一个简单的例子：上面的代码转化的结果为由于这里我主要是一个尝试，所以我直接依赖SQL来做查询并将分析逻辑直接从代码实现，这里我们直接用sql语句做查询。用上述语句查询出echo语句，然后分析节点信息得到参数为$a。然后通过来获取if的条件信息，并判断为真。紧接着我们可以通过SQL语句为得到赋值语句，经过判断就可以得到变量来源于$_GET。当然，逻辑处理远比想像的要复杂，这里我们举了一个简单的例子做实例，通过sort为0记录参数信息和条件信息，如果出现同一个语句中的多条指令，可能会出现sort相同的多个节点，还需要sort和id共同处理…这里我尝试性的构造了基于五元组的CodeDB生成方案，并通过一些SQL语句配合代码逻辑分析，我们得到了想要扫描结果。事实上，虽然这种基于五元组的CodeDB仍不成熟，但我们的确通过这种方式构造了一种全新的扫描思路，如果CodeDB构造成熟，然后封装一些基础的查询逻辑，我们就可以大幅度解决我在KunLun-M中遇到的许多困境。看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注云编程开发博客行业资讯频道，感谢您对云编程开发博客的支持。

相关推荐: ECSHOP时间戳转换差8小时怎么办

这篇文章给大家分享的是有关ECSHOP时间戳转换差8小时怎么办的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。ecshop直接保存日期然后通过date()将时间戳转时年月日,会存在一个8小时误差问题,后台有设置时间,正常不二次开发时间…