动态性代码审计对下层及其hook对策依靠较强,因为动态性代码审计的系统漏洞辨别首要依

靠Hook恶意变量，那麼对于不一样的语种、不一样的网络平台而言，动态性代码审计通常要对

于设计构思不一样的hook实施方案。假如Hook的深层不足，1个深层架构很有可能就没办法扫

描了。拿tp框架举个例子而言，较为完善的Hook实施方案便是根据tp框架扩展程序完成，实际

的完成实施方案能够参考资料。

 

 

因为这一因素危害，通常的动态性代码审计非常少能够与此同时扫描多语种，通常情况下全是

对于某一类语种。次之，Hook的对策也须要很多不一样的限定及其处理。就拿tp框架的跨站脚

本攻击来举个例子，并不是说1个要求开启了echo变量就应当辨别为跨站脚本攻击。一样的，

为了更好地不危害正常情况下基本功能，并没有echo函数调用中包括就可以算跨站脚本攻击系

统漏洞。在动态性代码审计的对策中，须要有更科学合理的前端开发->Hook对策辨别实施方案

，不然会发生很多的乱报。

 

 

除开前边的现象之外，对环境的强依靠、对实行高效率的要求、无法和业务源代码融合的各类

现象也准确的存有着。当动态性代码审计的缺点连续不断被曝露出来后，从小编的视角来说，

动态性代码审计存有着工作原理自身与现象的矛盾，因此 在智能化软件的快速发展环节中，愈

来愈多的关注都放进了静态数据代码审计上(SAST).静态数据代码审计软件的快速发展,静态数

据代码审计主要是根据深入分析目标源代码，根据纯静态数据的方式开展深入分析处理，并发

掘相对应的系统漏洞.

 

与动态性不一样，静态数据代码审计软件经历了长久的快速发展与演化环节，下边我们就一块

儿回望一下下（下边的每一个阶段首要意味着的相对性的增长期，并并非较为肯定的问世前后

左右）：

 

 

假如请你告诉我“如果让你设计构思1个智能化代码审计软件，你可能会怎么设计？”，我坚信，

你肯定会回复我，能够试着根据配对关键词。随后你也会快速意识到根据关键词配对的现象。

这儿我们拿tp框架做下简洁的事例。但现象不言而喻，高附着性和可扩展性是这类完成方式始

终没办法处理的缺陷，不仅维护保养成本费极大，并且漏报率和少报率也是持续上升。因此

被时代所取代也是历史时间的肯定。