首页 > 操作系统 >

[技术共享]甲方的代码审核方法和技术

电脑杂谈　发布时间：2020-06-12 11:20:31　来源：网络整理

代码审计平台_代码审计规则_php代码审计

甲方代码审核的特征

重要

漏洞的攻击和防御永远不平等. 这句话用来形容防御者捍卫整个面孔，而攻击者只需突破一个点就可以入侵. 但是就漏洞攻击和防御而言，防御者还具有攻击者无法拥有的优势: 他们拥有代码. 与黑盒测试相比，代码审核具有从代码实现逻辑的根源利用漏洞的自然优势. 与教条式修复指南相比，代码审核还可以提供更有针对性和可行性的方法来修复代码实现逻辑中的错误. 该解决方案甚至可以在此基础上发展安全开发组件和框架.

在SDLC和DevSecOps流行的时代代码审计规则，代码审核已成为甲方开发深度防御并将安全性集成到业务中的唯一途径. 在这种背景下，甲方必须实施代码审核.

此外，应注意代码审计规则，本文中描述的代码审核包括自动代码漏洞扫描和手动代码审核.

与漏洞挖掘的区别

（1）关注风险项目

与漏洞挖掘不同，代码审核还跟踪无法构成漏洞或请求或建议业务修复的风险项目，尤其是在强调深度防御的公司安全构造思想下.

（2）对软件供应链的担忧

代码审核还关注应用程序或开发组件的安全性，例如npm软件包中是否存在CVE漏洞以及pip源是否安全.

甲方代码审核与白帽代码审核之间的区别

目标和初衷导致覆盖和使用方法不仅挖掘漏洞，而且还发现风险，不仅提供强化的意见，而且结合研发系统为编码规范的制定和构建提供数据支持安全的开发组件，不仅在于人力，还在于自动化系统的构建. 此外，甲方的代码审核强调全面覆盖，而白帽可能只专注于单个要点，只要它们突破要入侵的要点即可.

审核代码不同: 甲方通常审核自己开发的代码，而白帽通常审核开放源代码. 两者在业务逻辑复杂性和代码可读性方面有很大的不同.

甲方的代码审核流程

代码审核是SDLC和DevSecOps的编码和测试阶段. 如下图所示，它对应于SDLC的实施/验证阶段和DevSecOps的开发/构建/测试阶段，其中可以在开发和编码构建阶段完成自动代码漏洞扫描，并且手动代码审核可以在业务测试阶段同时进行. 前者是所有企业上网之前必须经过的阶段. 后者可以从新业务，高风险业务和重要业务开始. 毕竟，对于甲方而言，在庞大的业务守则方面，手动审核的范围总是有限的.

代码审核流程

代码审核方法

痛苦点

甲方，特别是大型电信运营商，金融机构和互联网公司，它们的业务规模巨大，尽管市场上有很多SAST（Staic应用程序安全性），但随之而来的是代码和业务体系结构非常复杂的问题. 工具（静态应用程序安全工具）可以执行代码漏洞扫描，但其准确性和误报率很难达到预期. 此外，人事审计执行人员的不同熟练程度和不同的判断标准也将导致人员落地. 系列很难.

1，复杂的代码和体系结构

数十万，数百万行代码，分为数十个模块和数十个代码仓库的业务司空见惯；开发语言很多，各种自行开发的框架，流行的框架不胜枚举，架构非常复杂.

代码审计规则_代码审计平台_php代码审计

以上两个问题对于审计师和SAST工具无疑是巨大的挑战.

2. 工具调用率

没有工具是所谓的银弹. 官方规则和插件的准呼叫率很低，需要根据开发语言和编码风格进行定制；工具对逻辑漏洞的弱点以及暴露出大量业务逻辑漏洞的脆弱性之间的矛盾. 此外，工具和系统的操作还需要投入大量的人力来不断提高工具的准调用率.

3. 心态

新来审核的人会犯的一个错误是判断该代码是否根据自己的想法实施. 但是我忘记了数学问题可能有多种解决方案，尤其是在没有统一的编码标准或大家公认的最佳实践之前. 如果不遵循此规则，则在审核中会遇到很多麻烦.

考虑到KPI，审计师认为，由于花了很长时间进行代码审计，因此他们必须说些什么才能反映工作量. 如果系统没有问题，但棘手的话，开发人员将更加不信任. 您. 对于甲方的代码审核员来说，执行许多审核任务和庞大的代码是正常的. 如果仅提高速度而不考虑后果，则此方法将遗漏细节并导致全面审查.

我认为高级程序员编写的代码没有错，但是这匹马仍然走在前列，更不用说在巨大的开发压力下，我们如何确保高级开发人员不会进行一些安全编码错误？还是不相信新手编写的代码，实际上，只要新手对代码具有安全意识和良好的编码习惯，不一定要编写的代码就会有很大的问题. 简而言之，需要平等对待开发人员.

总体思路

以下将从7种方法开始，包括自动手动组合，黑白框组合，正向和反向跟踪，动态和静态组合，过去和现在的组合，清单和安全编码规范组合，通过阅读和日间阅读组合，介绍如何更好地开发代码审核.

1，自动和手动组合

代码扫描工具-> ast /正则表达式->查看

词法分析->语法分析->（语义分析->中间代码）-> AST

根据预定规则，将它们合并为令牌. 同时，它将删除空格，注释等. 最后，整个代码将被拆分为令牌列表（或一维数组）. 将经过词法分析的数组转换为树形表达式. 同时，验证语法，如果语法错误，则抛出语法错误. 解析器将删除一些不必要的标记（例如不完整的括号），因此AST与源代码不匹配100％. 解析器100％涵盖了所有代码结构生成树，称为CST（特定语法树）. 以下是主流Web开发语言的一些解析器:

·解析器

·php-parsesr

·python-parser

·解析器

·js解析器

·java-parser

与开源和商业sast工具相结合，执行漏洞和风险扫描并输出初步检测报告，然后手动检查准确性，持续优化sast扫描规则，并提高漏洞挖掘的速度.

2. 黑白框的组合

黑框覆盖->白框聚焦

代码审计规则_php代码审计_代码审计平台

通过黑盒覆盖所有业务cgi，并通过白盒测试，黑盒快速验证，白盒挖掘根本原因或研究绕过策略覆盖重要的业务cgi，以实现效率与重要性之间的平衡. 另外，建议使用无源扫描器进行快速的流量回放，以同时执行流量收集和漏洞测试，从而大大提高测试效率. 同时，还建议对cgi和功能进行分类，否则白盒审计在理解业务和代码逻辑方面的成本会很高.

3. 正向和反向跟踪

·前进: 变量->功能/敏感操作->输出

$ _ GET-> $ param-> eval（$ param）->返回$ param

从参数接收入口开始跟踪数据流是一种前向跟踪思想. 优点是易于理解程序的总体框架，并且相对容易定位逻辑漏洞. 但是，当代码量大且代码结构不牢固时，手动审核的成本很高，并且投资回报率可能不明显. 在这种情况下，结合使用SAST工具的审核效果会更好.

·反向: 功能/敏感操作回溯->输出

eval（$ param）-> $ param-> $ GET->返回$ param

基于敏感关键字回溯传入的参数是一种反向跟踪的方法. 好处是您只需要搜索相应的敏感关键字，就可以快速挖掘漏洞，可以直接进行挖掘，效率高，质量高，但是由于没有彻底阅读代码，因此您不熟悉该程序的总体框架需要花费时间才能找到，并且很难挖掘逻辑漏洞. . 同样，在这种情况下，也需要完成SAST工具，因为SAST工具对敏感功能的控制流具有良好的跟踪效果，这便于手动跟踪变量.

4. 动静结合

（1）静态审核

通过对源代码进行静态分析，发现源代码中的逻辑，数据处理和功能未正确用于确认源代码中可能存在的漏洞. 可以通过规则匹配和代码解析来执行，但这可以留给SAST工具进行.

（2）规则匹配

通过编写正则表达式以匹配开发语言或开发框架的默认变量以匹配高风险函数，例如php的默认变量$ GET，$ POST，高风险函数eval（），exec（）等

（3）代码分析方法

通过解析代码的语法，分析了代码执行过程. 如果此方法是自动化的，则它属于上述AST，因此不同的想法之间存在相似之处.

（4）动态审核

通过运行需要审核的代码，并使用断点调试方法来跟踪数据流，以确定系统中是否存在漏洞. 这件作品可以移交给DAST或IAST工具. 请注意，我们只需要关注我们一开始就关注的漏洞类型: 高风险文件，高风险功能和常规Web漏洞.

5. 过去与现在的结合

·是否使用易受攻击的框架版本；

·是来自具有不良编码习惯或较弱的安全意识的开发人员吗？

·是否存在可能无法完全修复的漏洞或其他业务存在类似问题；

·此功能，模块，类，功能的漏洞是否可能出现在其他功能模块，类功能中.

php代码审计_代码审计规则_代码审计平台

6. 清单和安全编码规范的组合

组合常见的漏洞方案，常见的漏洞类型和常见的功能安全编码模板. 比较实施方法. 有关编码规范，请参阅“ OWASP安全编码规范”，相关的清单可以作为下一部分.

7. 结合全读和全天阅读

阅读技巧类似于阅读英语文章，先进行粗略阅读，然后根据漏洞的类型和业务场景跳读.

·首先，它取决于程序的常规代码结构

例如，主目录中有哪些文件，模块目录中有哪些文件，插件目录中有哪些文件，除了注意文件之外，还注意文件大小和创建时间. 查看版本管理历史记录以获取整个代码更新迭代过程的概述.

·专注于框架文件和核心功能

功能集文件（公共库类函数），配置文件（请参见单引号，双引号，请参见全局协调或路由），安全过滤器文件（保护代码），索引文件（条目文件）以及身份验证，权限控制，操作和文件上传实现逻辑等核心功能.

覆盖

结合上述一般思想，下面将介绍业务中特定着陆代码审核的三个重要模块. 业务基本信息，代码逻辑是基础，平台手段是助推器，流程标准化是关键.

1. 依靠代码仓库和业务基本信息

（1）安全资产管理: 在进行代码审核之前，您必须具有全面的资产市场并了解业务，负责人员和组织结构之间的对应关系，以便可以根据以下内容选择代码审核的对象和优先级: 明确的安全状态，方法，手段；

（2）代码获取: 明确审计对象后，需要通过资产市场寻找开发团队，并通过代码仓库的许可申请流程获取代码；

（3）体系结构，cgi界面，业务逻辑审计之前，您需要了解业务体系结构才能初步评估审计范围. 了解cgi界面和业务逻辑可以加快审核速度，并快速定位漏洞和风险.

2. 平台建设

甲方业务的复杂性决定了代码审核必须走平台构建之路. 通过将SAST工具与CI系统链接，可以执行自动漏洞扫描. 发现漏洞后，可以自动创建漏洞工作单，并且现有的“审核”流程并进行手动审核.

（1）CI系统和SAST工具: 例如，sast工具sonarcube及其插件发斯是一套低成本的实现解决方案；

（2）漏洞管理系统: 进入代码审核阶段的企业通常已经具有相对完整的漏洞管理系统和工作订单处理流程，可以解析和过滤由sast生成的报告，然后将其推送到漏洞中. 管理系统；

（3）审计流程管理: 这部分主要阐明了审计流程的任务跟踪，检查范围和ROI评估.

这里的清单实际上是对审核过程的进一步完善，可以根据方案和漏洞，已完成的操作，已发现的问题，多少代码量，什么技术堆栈，花了多少工时来区分，并检查周期通话率的准确性.

3. 涵盖业务范围

代码审计规则_php代码审计_代码审计平台

高风险业务: 一个月内可以确定一个高风险漏洞或n个或更多漏洞.

新业务: 严格检查新业务的安全基准合规性，并要求统一的自动化代码漏洞扫描和手动审核.

重要业务: 筛选出重要业务的域名列表，统一提取代码和cgi信息以进行黑白框审核.

一些提示

以下是总体思路，下面将介绍一些技巧，这些技巧可帮助您快速阅读代码，挖掘业务思维的空缺并提高准呼叫率.

1，如何快速理解代码

简而言之，它将专注于开发模型和开发框架，尽可能少地阅读代码，从路由和cgi之间的映射关系开始，并与IDE一起阅读代码.

（1）使用mvc或mvvm架构思想来理解: 大多数Web系统是根据模型（模型）-视图（用户交互）-控制器（后台业务逻辑）架构设计和开发的. 在此基础上，越来越流行的mvmm（模型-视图-视图模型）架构也得到了发展. 两者的区别是mvvm的viewcontrol与mvc控制器中的业务逻辑分开，以实现业务逻辑组件的重用. 审核时，您可以直接进入控制器或视图模型中的相应业务逻辑；

（2）区分前端和后端世代: 前端和后端的分离也是近年来流行的开发模型. 前端部分通常仅具有xss漏洞. 通过区分前端代码和后端代码，可以避免在前端代码部分中浪费时间来定位SQL注入，这些漏洞仅出现在后端逻辑中，例如未授权的漏洞；

（3）首先找到路由和逻辑代码之间的对应关系: 路由通常出现在配置或mvc体系结构的控制器中，并且由文件目录或类函数的public属性定位，或者直接在网址路由表；

（4）关于IDE的重要性: IDE通常显示类或函数的定义和引用. 与命令行相比，您可以通过链接快速跟踪代码调用，也可以使用内置的搜索功能快速定位关键字. 查找关键字要容易得多.

2. 商业思维

这里的重点是业务思想，这意味着您对业务的了解越多，就越能从开发人员和用户的角度考虑设计和使用中可能存在的安全问题，这对于挖掘逻辑漏洞非常重要.

（1）让企业提供应用程序的设计文档和体系结构文档，以便从功能中快速了解业务逻辑；

（2）始终记住，用户可以控制请求的每个方面，可以按任何顺序访问多阶段功能，可以提交格式错误的数据，可以忽略某些参数，可以伪造某些参数，并且可以修改某些参数. 因此，您在设计时必须尽可能全面；

（3）从各个角度考虑两个因素: 应用程序如何处理用户的异常操作和输入，以及不同代码组件和应用程序功能之间的相互依赖关系可能会产生不利影响；

（4）考虑设计过程中做出的每个假设，并想象违反该假设的每种情况，并特别注意用户可以完全控制的假设.

3. 如何提高准通话率

主要介绍如何提高准确性和完整性.

（1）在现代编程中，对代码调度，脚手架，统一框架和高封装的关注: 在框架层或公共类/功能上可以忽略过滤和预编译以及其他安全保护；