精华内容
下载资源
问答
  • 代码安全审计规范
    2020-06-03 10:42:43

          代码审计专家服务团队,除了提供网络、现场的源代码审计服务外,为了帮助企业建立代码安全审计平台、Devops/DevSecOps平台、代码扫描基线、安全和质量编码规范、制度流程,打通企业研发的各个管理环节,实现自动化等企业级源代码安全审计咨询服务。

          企业要建立代码安全审计平台,实现高效的自动化代码安全审计,需要打通企业研发生命周期的各个环节,让自动化检测工具融入现有开发、测试环境,并真正被接受和充分利用,需要从工具选型、扫描基线、编码规范到制度流程等各个环节进行评估和设计。包括但不限于下面所要完成的工作。

    1. 源代码安全检测工具选型建议
    2. 源代码安全基线分析与制定
    3. 软件安全编码规范制定及实施
    4. 源代码检测自动化流程实现
    5. 软件安全开发技术培训
    6. 项目试点和推广

    企业级的代码安全审计建设后可实现:企业关注的风险,例如安全漏洞、运行时缺陷、合规性,都有编码规范要求;编码规范要求的,都会在检测或审计环节被检测;检测出的问题,都有详细的问题剖析和修复说明可查。

    主要工作如下:

    1、源代码安全检测分析工具选型建议

    代码安全审计专家制定调研表,由开发团队填写提交,根据反馈内容进行访谈,了解企业常用语言、架构、合规要求等特征,并对比业内各种源代码安全扫描工具的优缺点及企业特点,分析企业应用系统代码安全扫描最适合的工具,为企业选择扫描工具提供依据,或提出工具定制化方案。

    2、源代码安全基线分析与制定

    代码安全审计专家通过对调研结果的分析,与客户开发团队共同制定源代码安全基线。也就是团队可以接受的安全漏洞、运行时缺陷等类型和级别,形成一个门限。不达到这个门限软件就不能进入下一个流程,当然不同阶段可以设定不同的门限。

    3、软件安全编码规范制定及实施

    代码安全审计专家能够根据设定的门限,定制出安全编码规范,并能够在团队落地。选型工具能够支持安全编码规范的落地。

    4、源代码检测自动化流程实现

    根据企业开发、测试环境,将代码检测工具与源码版本管理工具(SVN、GIT等)、邮件服务器、IDE、缺陷跟踪、持续集成CI/CD等集成,实现自动高效的代码检测和管理。

    5、软件安全开发技术培训

    代码安全审计专家会根据制定的安全编码规范、制度等设计培训课程,对研发团队进行管理和技术上的培训。便于让代码安全审计能够推广落实。

    6、项目试点和推广

     

    6.1 试点项目选择与调查

    根据历史项目扫描结果中各系统漏洞覆盖情况,以及系统的重要性等方面,从中选取若干试点系统作为试点扫描目标,调查系统的各项技术特征和业务特征,由代码审计专家进行详细分析。

    6.2 试点项目扫描与扫描结果分析

    审计专家根据调查结果,优化工具策略,对试点系统代码进行进一步扫描,以会议等形式为开发团队详细解读发现的各类安全漏洞、运行时缺陷以及违反合规要求的原因、危害、代码中的路径溯源,并编写试点项目代码风险评估报告,提供切实可行的修复建议指导开发人员的修复工作。并总结试点项目的成功和失败经验,为后续推广做准备。

    6.3 推广

    在试点项目结束并对研发团队做了培训之后,就可以开展推广了。在正式推广之前,是需要做一个推广方案,而不是一刀切方式。

     (完)

    更多相关内容
  • 本标准规定了源代码安全审计过程及方法,描述了软件源代码安全弱点的典型审计指标。本标准的审计活动主要对象是源代码,主要针对于源代码层面的安全问题,不包含需求分析、设计、测试、部署配置、运维等方面的安全...
  • 文档属于信息安全行业的国家推荐标准,该标准还暂未正式实施,目前只是征求意见稿,分享给大家,以便在工作中参考。
  • 2020-信息安全技术 代码安全审计规范.docx
  • 2020-信息安全技术 代码安全审计规范.zip
  • 代码安全审计之道

    2021-11-02 21:53:35
    代码审计是每个安全研究员都应该掌握的技能。但是网上对于代码审计的介绍文章却比较匮乏。因此本文一方面作为 *The Art of Software Security Assessment* 一书的阅读笔记,另一方面也结合自己日常工作的经验总结,...

    代码安全审计之道

    代码审计是每个安全研究员都应该掌握的技能。但是网上对于代码审计的介绍文章却比较匮乏。因此本文一方面作为 The Art of Software Security Assessment 一书的阅读笔记,另一方面也结合自己日常工作的经验总结,希望能国内的安全研究员有个抛砖引玉的帮助。

    前言

    对于许多安全研究人员而言,Fuzzing 是一个重要的漏洞挖掘方法,但每个方法都有其局限性。首先,为了有效地进行 Fuzz,需要准确找到攻击面并在此基础上进行自动化测试,寻找攻击面的过程离不开代码审计;其次,在自动化测试找到 crash 之后,分析和写报告的过程需要人工审计理解代码逻辑和漏洞的 root cause;最后,对于 Java 或者 Go 这类内存安全的语言而言,Fuzzing 的应用场景更是受限,只能通过代码审计去发现复杂的逻辑设计问题。

    本文算是对代码审计的一个方法论式的总结,对具体代码的所属语言并无限制,可以是 C/C++,也可以是 Java、PHP。对于具体语言所独有的 Source、Sink 以及自动化分析辅助工具不在本文范围,感兴趣的朋友可以关注后续的代码安全审计之术篇。

    谋定而后动

    孙子兵法有云: 谋定而后动。在现代管理学中也有一句名言: “If you can’t measure it, you can’t manage it.”

    可见凡事在开始之前,都需要先确定好自己的目标和计划,这样才能确保自己不会偏离方向或者误入歧途。 对于安全审计亦是如此。工作时经常会发现一些同事一头扎进某个项目的代码中,眨眼就是几个月,一问进展如何不知,还有多久不知,有何计划也不知,代码审计全凭感觉,有无收获全靠运气。……

    为了避免这种情况,在开始前我们不妨先问一下自己的目标是什么。这乍看起来是个很简单的问题,但对于不同的场景可能有不同的回答。通常安全研究人员的目标是在最短的时间内找到最有价值的漏洞;对于商业安全顾问而言,其目标是在项目预算允许的范围内尽可能达到更高的审计覆盖率;另外对于开发者或者安全架构师而言,则会花费更长的时间周期进行内部安全评审。

    对于商业环境中的代码安全审计,通常甲方更关心的是容易检测的安全问题,而不甚考虑其复杂性和技术难度。因为他们的目标是避免漏洞被公开或者利用造成负面舆情影响。如果此时你将时间都花在了某些复杂问题中而忽略了浅显的漏洞,那显然是拿不到甲方好评的。将时间花费在没有 “技术含量” 的简单漏洞中对于很多安全从业人员而言似乎有点羞耻,但却是一个合理的商业决定。

    这并不是说我们应该忽略复杂的安全问题而只去看简单的漏洞,关键是要提前明确自己的审计目标。对于一项审计任务要分成两面看,一面是审计人员自己的时间投入成本,另一面是待审计应用的复杂度。二者结合起来才能有效评估此次审计的产出预期。

    待审计应用根据访问权限划分一般有以下几种情况:

    • 仅源码: 我们仅拥有目标的源代码,通常不包含完整的编译和测试环境,而且由于缺乏必须的关键依赖组件,往往无法构建出可运行的程序。这种情况一般只能使用静态分析的方式去进行审计;
    • 仅二进制程序: 我们仅拥有目标应用的二进制文件,比如 APK、EXE、jar 包或者 IoT 的系统固件等。这种情况下通常通过动态分析以及逆向工程的方式进行审计;
    • 有源码及二进制程序: 我们既能够访问目标应用的源代码,也拥有一个可运行的二进制程序,这给安全审计提供了最为有利的访问权限,通常目标是开源软件,包含了完整的构建环境和依赖。
    • 完全黑盒: 我们既没有目标的源代码,也没有可运行的二进制程序,因此只能通过外部接口去进行盲测。这在 Web 应用中较为常见。

    本文主要针对的是有源码情况下的代码安全审计,当然源码审计中使用的一些策略和方法同样适用于其他类型的应用。在能够访问源码的情况下,一个明显的计量标准是通过代码行数去评估工作量,尽管这个指标并不能完美代表应用的复杂度,毕竟 1000 行业务代码和 1000 行编译器代码的复杂性是不同的。

    一个代码审计人员一个小时大概可以审计 100 行到 1000 行代码不等,取决于该审计人员的经验能力和对代码的理解程度。对于个人而言,评估审计效率的最好方式就是坚持记录自己对不同组件的审计时间,这既能更好的了解自己的节奏,也能为后续代码审计计划提供时间参考。

    影响代码审计速度的原因有很多,比如:

    • 代码语言: 对于 C/C++ 这种内存不安全的语言需要更多关注底层细节;而 Java、Python 等内存安全的语言则更多关注上层逻辑实现;
    • 代码风格: 代码风格整洁、注释清晰的项目通常比其他项目花费更少时间去审计;

    值得一提的是,虽然代码量和审计时间有正相关的关系,但随着对某个项目的审计代码量增加,审计的效率也会提高,因为此时已经对项目有了更加深入的理解,审计十万行代码的时间通常也不会是五万行代码的两倍。因此在制定审计计划和时间投入时,需要仔细考虑上述相关因素。

    知止而有得

    在一个完美的代码安全审计项目中,每个模块的每一行代码都会被尽可能彻底的评估,但这个目标在现实世界中几乎是不可行的。时间和预算的限制会迫使你忽略一些代码模块,或者对每个模块的审计深度和覆盖率做出取舍。因此我们需要通过不断练习来提高自身敏感度,在屡次的失败或成功中吸取教训,作为下一次取舍和抉择的养料和经验。

    在下节中将会介绍一些具体的代码安全审计的策略和技巧。在实践中也许某些方法比另外一些方法要高效,但经验告诉我们最好还是使用多种审计策略,并周期性的切换审计方法,这有多种原因:

    • 你只能在有限的时间内保持精神高度集中;
    • 多样性能帮助你保持纪律和激情;
    • 不同的漏洞类型在其他视角下可能更容易被发现;
    • 不同的人拥有不同的思考方式;
    • ……

    从全局来看,代码安全审计的方法是一个简单的三步循环流程:

    1. Plan: 审计规划,根据现有信息,确定这一阶段要使用的代码审计策略,以及审计的小目标,比如完成某个模块或者文件(目录)的审计、了解某个结构体的功能等;
    2. Work: 执行审计,根据前面制定的审计策略去执行,重点是做好这一过程中的审计记录;
    3. Reflect: 审计回顾,在完成该阶段审计后,反思一下自己在这一阶段是否有效利用时间,是否偏离了方向。然后根据前面审计学习到的经验去调整下一阶段的审计规划,比如重新划分结构、专注于安全相关的子模块等;

    loop

    在实践中,每天大概会经历两到三次上述审计循环。在制定审计规划的时候,我们需要尽可能利用现有的信息,比如开发文档、接口文档等资料;在没有文档的情况下,就只能通过不断的审计循环去推断出代码设计结构。在审计初期也许会觉得狗啃泰山无从下口,一叶障目不见森林;但到了审计后期时走进代码就会像走进自己家一样,知道哪个模块的开发者刚刚学习了设计模式想要秀一秀技巧,知道哪些代码已经经过激烈的攻防对抗,做了许多防御性编程,也知道了哪些代码是上古屎山,为开发者避而远之。……

    因此,往往我们在代码审计初期可以找到一些简单的安全问题,而在后期随着对应用的理解深入,可以发现更为复杂的逻辑漏洞,甚至设计上的缺陷。

    万物皆有法

    本节介绍一些具体的代码审计策略。如果说代码审计是一场战争,那么必然要讲究战略和战术。这也许只是前人的经验之谈,但确实是一种行之有效的方法论。

    代码审计策略有多种,但是每每种策略都类似的属性,代表这种策略的特征。例如:

    • 起点: 代码跟踪的起点;
    • 终点: 该策略的目标,或者跟踪代码的终止点;
    • 方法: 代码跟踪方法,跟踪数据流、控制流,跟踪方向是前向跟踪还是反向跟踪;
    • 目标: 该审计策略所针对的是什么类型的漏洞;
    • 难度: 表示该审计策略的执行难度,一般从 1 星到 5 星表示难度递增;
    • 速度: 表示该审计策略的执行速度,也是从 1 星到 5 星表示从慢到快;
    • 理解: 表示该审计策略所带来的代码理解。通常能带来更多理解的策略难度都会更大一些,但同时也能帮助研究人员发现更加复杂的漏洞;

    还有对应优缺点等,下面是一些具体的审计策略。

    策略一: 自顶向下

    第一种代码审计策略就是通过直接分析代码去挖掘漏洞,这种方式通常要阅读代码并理解代码,需要更加集中注意力,但同时也带来对代码更加深入的理解。当然正面交锋也不是抡起膀子就干,可以进一步细分为以下执行策略。

    数据分析

    首先是数据流分析,通过跟踪用户的(恶意)输入数据去找到潜在的漏洞点。

    keyval
    起点数据入口点,比如函数的参数、环境变量等
    终点最终的漏洞触发点,比如越权、注入、内存破坏等
    方法前向分析,数据流敏感、控制流敏感
    目标发现可被恶意输入触发的安全漏洞
    难度★★★★
    速度
    理解★★★★

    数据分析可能是大部分人所认为的代码审计方法,其核心是从恶意输入为起点,在代码中通过控制流进行前向审计,通常辅以有限的数据流分析。在审计过程中通过记录一系列传播的数据并进行跟踪,并配合安全边界分析和常用的漏洞类型去定位漏洞。

    该方法是分析代码的有效方法,但是需要一些额外的经验用于判断应该跟进哪些模块和函数,否则路径会在短时间内分支爆炸。而且在一段时间的审计很容易走神并错失一些重要分支,然后和漏洞擦肩而过。

    在面对类似于 Java 或者 C++ 等语言的项目时候,数据分析方法往往更加困难,因为通常跟踪原始输入会经过多个中间类,导致你打开了十几个文件之后还没有到达真正处理数据的代码。在这种情况下最好有设计文档的帮助,用以构建相对完备的威胁模型,否则最好还是先采用其他策略去理解系统。

    模块分析

    模块分析的一个隐含假设是代码模块以文件进行划分,因此实际上分析一个模块就是分析对应的源文件。

    keyval
    起点文件开头
    终点文件末尾
    方法前向分析,数据流不敏感、控制流不敏感
    目标阅读模块中的每个函数,只记录潜在问题
    难度★★★★★
    速度★★
    理解★★★★★

    模块分析的过程基本上就是从头到尾阅读一个源码文件,并且不跟踪其中调用到的外部函数,也不关心当前函数的引用情况,只将目前遇到的问题记录下来。也许你会觉得这个策略比较粗暴,但实际上许多资深的代码审计人员都很喜欢这种方法。比如前 NSA 的某安全顾问在审计新的代码仓库时都会先使用该策略,找到类似 util 的工具目录并逐行阅读其中的胶水代码,以对该项目的代码风格形成初步了解。

    模块分析的优点是快速了解应用的的代码风格,对于高内聚的模块分析可以不走出文件,可以对模块内部实现有个初步理解。但缺点也很明显,这种分析方法比较费力,而且在长时间的持续分析后大脑很容易感到疲劳;另外在审计过程中记录所有的潜在问题也是个繁琐的工作,在若干小时的记录后很难有激情去继续坚持下去。因此,如果在执行此策略的过程中感到精神涣散的话,最好先休息一下,或者切换到其他不那么紧张的审计策略中。

    引用分析

    引用分析和模块分析类似,主要区别在于我们聚焦的是面向对象代码中的类或者结构体实现。

    keyval
    起点某个对象实现
    终点所有对该对象的引用 (xref)
    方法前向分析,数据流不敏感、控制流不敏感
    目标学习重要对象的接口和实现,并且寻找接口使用导致的错误
    难度★★★★
    速度★★
    理解★★★★★

    对于面向对象的语言来说,该审计策略比单纯的模块分析要更为高效,因为往往对象本身是高内聚的。同时该分析过程也更不容易导致审计过程中出现方向偏离。但是和模块分析的特点一样,在审计过程中我们同样需要保持注意力集中,不然也可能会出现漏看的情况。

    算法分析

    在对应用的系统设计和数据结构有了足够的理解后,我们就可以选择一些安全相关的算法并分析其实现。

    keyval
    起点算法的开始
    终点算法的结束
    方法前向分析,数据流不敏感、控制流不敏感
    目标分析算法实现,并找到潜在的设计和实现问题
    难度★★★★★
    速度★★
    理解★★★★★

    这个审计策略的有效性依赖于我们所选算法的的相关性,因此需要在对审计目标有一定理解之后才能确定哪些是关键的算法和代码。这些关键算法通常涉及到应用安全模型的设计或者密码学实现,比如 Web 应用中的 sessionId 实现算法或者应用开发者自定义的加密校验算法等。

    策略二: 自底向上

    这一大类策略和上述的正面策略正好相反,主要从可能导致漏洞的底层代码着手。这类策略通常会使用一些自动化分析工具作为辅助,然后反向追踪去验证漏洞的触发路径。

    敏感调用

    指定一系列的敏感调用,反向分析这些调用是否构成可利用的漏洞。最简单的方式是通过正则表达式去指定敏感函数或者语句,通过文本搜索工具去查找潜在漏洞并进行验证。

    keyval
    起点潜在的漏洞点
    终点任意用户可控的输入
    方法反向分析,数据流敏感、控制流敏感
    目标给定一系列潜在漏洞点,分析它们是否可以触发和利用
    难度★★
    速度★★★★
    理解★★

    这个策略的优点是针对已知的漏洞类型可以达到较高的覆盖率,比如格式化字符串、命令注入等;而且该审计方法不是非常掉 san,可以有效节省和恢复注意力,由于漏洞列表的存在也不容易走偏,也可以稳步推进审计工作。

    漏扫工具

    除了手动指定敏感调用,我们还可以通过自动化静态分析工具去获取潜在漏洞点,比如 Sonar、Fortify 等都有较为完善的漏洞分类列表。

    keyval
    起点潜在的漏洞点
    终点任意用户可控的输入
    方法反向分析,数据流敏感、控制流敏感
    目标给定一系列潜在漏洞点,分析它们是否可以触发和利用
    难度
    速度★★★★
    理解

    该策略的分析和敏感调用分析过程类似,早期的静态分析工具只是简单的文本匹配,但当前已经有许多静态分析工具可以进行比较精确的数据流和上下文分析,有的需要依赖完整构建环境支持,比如 CodeQL,有的则可以在仅有源码的情况下进行分析,比如 weggli、semgrep 等。

    这类静态分析工具的一大弊端是通常存在误报,如果在一千个扫描结果中只有几个是真正的漏洞,那么它们也往往很容易会被安全审计人员忽略。

    接口分析

    有时候漏洞并不单独产生在敏感的函数调用中,而是实现在某个类或者应用函数的代码中,比如一些命令执行中间函数或者 ORM 的数据库封装接口。

    keyval
    起点应用对象接口或者函数的调用
    终点任意用户可控的输入
    方法反向分析,数据流敏感、控制流敏感
    目标给定一系列潜在漏洞点,分析它们是否可以触发和利用
    难度
    速度★★★★
    理解

    有部分自动化分析工具可以编写自定义规则去进行扫描,但更多情况下只需要一个简单的 grep/findstr 命令就可以实现漏洞点查找和过滤。该方法需要对待审计代码有一定程度的理解才能知道哪些是潜在的安全敏感函数,而且由于我们只是不断在一个浅层的上下文中进行搜索跳转,所以这种审计策略只能帮助我们验证漏洞路径,对代码的理解几乎没有更多帮助。

    除了针对源码的分析,对于二进制应用的逆向分析我们也可以运用类似的策略,在汇编代码中定位潜在的漏洞模式。比如对于 x86 的程序可以通过 MOVSX 指令去搜索潜在的整数溢出漏洞等,当然这是题外话了。

    策略三: 见微知著

    在我们经过前两类策略的审计后,已经对代码本身有了一定程度的理解,这时候就可以后退一步,纵观全局去审计应用整体的设计和实现。这类策略主要关注关注上层的设计缺陷逻辑问题,因此往往可以找到隐藏较深的严重漏洞。

    系统建模

    一般开发的过程是先完成顶层设计和排期,然后再分模块去进行具体编码实现。但对于安全审计而言这个过程可以反过来,即完成具体实现的分析后再反向推断整体的的设计思路,然后根据这个推测的思路去找到一些未曾触及的组件实现。

    keyval
    起点待审计模块的起点
    终点安全漏洞
    方法随机应变
    目标通过行为建模还原模块的抽象行为,并寻找潜在的逻辑和功能漏洞
    难度★★★★
    速度★★
    理解★★★★★

    如果想要对目标系统有更加深入的理解,那么该审计策略是一个极好的选择;但同时这也表示该方法的审计速度不会太快,因为基本上我们是从实现细节开始逆向还原出原始的设计架构。

    值得一提的是,通常我们只需要对一些核心模块进行反向建模,比如应用的安全子系统、输入过滤模块或者其他广泛使用的核心组件等。在建模的过程中,我们实际上是把自己放在开发者或者架构师的位置去重新考虑模块的设计,因此这也是通过具体代码去挖掘逻辑漏洞的最佳策略。

    在面对大型代码时,我们的大脑几乎不可能一次性把整个应用结构消化掉,因此就需要进行减枝。具体做法就是先对待审计代码做出一些猜测的假设,然后在实际测试中验证这些假设。不论假设是否正确,最终都能通过测试去加深自己对该系统的理解和认识。

    安全边界

    该审计策略的目标是从代码实现去还原开发者或者安全架构师预设的安全边界,从而对还原后安全边界进行进一步审计,构建实际攻击的威胁模型。

    keyval
    起点所有安全相关的校验和检查代码
    终点安全漏洞
    方法随机应变
    目标通过已知的安全相关代码去推测还原目标的设计的安全边界
    难度★★★★
    速度★★★
    理解★★★★★

    一个具体的方法是通过收集整理代码中的安全校验相关代码片段进行记录,然后对这些针对安全边界的检查进行分类整理,最后归纳出原始的安全层级划分。这些原始的安全验证是我们对应用安全边界建模的重要信息来源,该策略的优点是可以让我们专注于安全相关的代码区域,并且构建更为完整的设计架构。

    设计验证

    如果我们手中有目标应用的设计文档或者规范手册,那么一个直观的审计策略就是通过对比规范和实现代码来查找其中的未定义行为或者冲突之处。

    keyval
    起点模块的起点
    终点模块的末尾
    方法前向分析,控制流敏感、数据流敏感
    目标挖掘代码实现中和设计有出入的漏洞点
    难度★★★
    速度★★★
    理解★★★

    虽然大部分时候我们并没有那么详细的文档,但同样可以使用该策略来发现一些设计实现中的漏洞。通过重点关注代码实现中的灰色地带,或者说一些条件分支的临界处理,我们也可以大致推断出哪些是文档中所未定义的行为。简单来说,我们的目标是先推测和还原目标模块的主要功能和正常行为,然后再针对其中的临界情况进行重点审计。

    审计技巧

    前面已经介绍了代码安全审计常见的一些策略,主要用于为代码审计提供大致的战略方向。本节主要介绍一些实际代码审计工作中用到的小技巧,作为上述代码审计策略的补充。

    阅读顺序

    在审计某个模块代码时,我们可以通过跟踪数据流或者跟踪控制流的方式去阅读,那么那种方法比较好呢?答案是既不关心数据流也不关心控制流,而是只关注本模块的实现。因为多年的经验告诉我们,精神力是影响代码审计效率的重要原因,而在不同模块中来回跳转往往形成了精神的消耗。比如在某些复杂的项目代码中,查找某个函数的实现会不断地打开新文件,从而不断地涌出需要解决的新问题,在不断追踪的过程中,往往会迷失在好奇的海洋中,从而忘记了原来的审计任务。

    如果确实要打破砂锅问到底,那么也建议在审计记录上先做个标记,等完成当前模块的审计后再对其进行深入分析。

    故地重游

    叔本华曾经说过,重要的书都应该连着读两遍。因为第二遍读的时候,你已经知道结局了,这样才能真正理解开头。另一个原因是第二遍阅读时,你有不一样的心情,可能会从另一种角度看待问题。

    代码审计亦是如此,通常对于一段代码我们通常需要阅读多次才能找到其中所有类型的漏洞。比如在第一遍审计中,可能主要关心整数溢出、内存管理或者格式化字符串相关的安全漏洞;而第二遍的审计则主要关心功能性的实现,比如返回值检查和一些容易理解错误的 API 调用(如 strncpy、strlcpy);第三遍则主要关心线程间潜在的同步、竞争问题或者 TOCTOU 的资源访问管理,……诸如此类。

    没有一个标准说对于某段代码应该审计阅读多少遍,具体情况需要根据代码具体的运行上下文进行判断,比如对于单线程代码就不需要关心线程同步问题了。但是无论如何,对于关键代码至少也要阅读两次,因为如果只看一次过的话很容易遗漏重要的代码路径。

    审计笔记

    在审计过程中是否要记录笔记其实因人而异,但是经验表明坚持记录大有裨益。

    审计审计,审而不计则惘,计而不审则殆。结构化的笔记一方面可以帮助自己评估代码审计覆盖率,沉淀审计心得;另一方面也可以方便以后继续深入审计时可以快速回顾之前的工作。此外,不论作为打工人还是独立安全顾问,我们都需要对老板或甲方输出审计报告或者漏洞报告,这些资料就是重要的数据来源。

    想法列表

    我们可能在代码审计过程中会出现很多想法,比如在审计某个状态机时会想到可能引入一些异常的状态切换导致处理异常,或者某些用户可控的数据进入了其他模块的分支中可能导致对应模块校验出错等等。这些想法在审计过程中无法逐一去验证,否则就偏离了初始的审计规划。因此,我们还需要维护一个潜在漏洞列表,记录上述想法,表示系统中”可能“出现漏洞或者被攻击者利用的点。这个列表不需要非常详细,可能只是一个猜测或者灵感。将其记录下来之后可以等到后续有时间继续深入分析和验证,这样既能保证审计工作有序推进,也能保证自己的想法不被遗忘。

    总结

    代码安全审计的前期重点之一是评估自己的审计速度(知己)和代码量和复杂度(知彼),这样才能让自己的审计工作可量化、可管理,从而稳步推进审计进度;在代码审计过程中,使用三步循环流程不断增加审计覆盖率以及提高自己对代码结构的理解,在每一阶段的审计后,要及时记录所得所想,让工作落到实处。同时在此过程中也需要适时切换审计策略,合理使用和回复自己有限的注意力和意志力。


    版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
    原文地址: https://evilpan.com/2022/01/22/code-audit/
    微信订阅: 有价值炮灰
    TO BE CONTINUED.

    展开全文
  • 第三部分主要介绍PHP安全编程规范,从攻击者的角度来告诉你应该怎么写出更安全代码,包括第9~12章,第9章介绍参数的安全过滤;第10章介绍PHP中常用的加密算法;第11章从设计安全功能的角度出发,从攻击者的角度...
  • 1、新增目录、文件命名需规范.... 2 2、必要的代码注释.... 3 3、做好文件备份.... 3 4、公共文件修改要谨慎.... 3 5、 数据库修改要申请.... 3 6、保持文件目录整洁,及时清理垃圾文件.... 3 7、对工作最终...
    展开全文
  • 代码安全审计实践

    2021-01-13 14:27:24
    代码安全审计实践代码安全审计的内容代码安全审计的工具源码安全检查第三方依赖包安全代码安全审计的落地参考文档 2020年安全相关的事务变多了,也因此更注重安全合规相关的工作了。其中代码安全审计是安全开发生命...

    2020年安全相关的事务变多了,也因此更注重安全合规相关的工作了。其中代码安全审计是安全开发生命周期(SDL)中重要的内容,这一年中也正好负责这块的相关工作,这边做个小结。

    代码安全审计的内容

    通常关于代码的安全问题有两类:

    • 源码安全分析:通过对源代码进行审查,找出并修复代码中的各种可能影响系统安全的潜在风险,通过提高代码的自身质量,达到降低系统风险的目的。往往由于代码量大,代码安全审计一般会借助静态分析类工具,对代码进行自动检测,产生代码安全审计报告。

    • 第三方依赖包安全:扫描应用程序(及其依赖库),执行检查时会将漏洞数据库下载到本地,再通过核心引擎中的一系列分析器检查项目依赖性,收集有关依赖项的信息,然后根据收集的依赖项信息与本地的CPE&NPM库数据进行对比,如果检查发现扫描的组件存在已知的易受攻击的漏洞则标识,最后生成报告进行展示。

    常见漏洞库

    • 美国
      • 赛门铁克的漏洞库 https://www.securityfocus.com/
      • 美国国家信息安全漏洞库 https://nvd.nist.gov/
      • 全球信息安全漏洞指纹库与文件检测服务 http://cvescan.com
      • 美国著名安全公司Offensive Security的漏洞库https://www.exploit-db.com/
      • CVE(美国国土安全资助的MITRE公司负责维护) https://cve.mitre.org/
    • 工控类
      • 美国国家工控系统行业漏洞库 https://ics-cert.us-cert.gov/advisories
      • 中国国家工控系统行业漏洞:http://ics.cnvd.org.cn/
    • 国内:
      • 中国国家信息安全漏洞共享平台(由CNCERT维护): http://www.cnvd.org.cn
      • 国家信息安全漏洞库(由中国信息安全评测中心维护):http://www.cnnvd.org.cn/
      • 绿盟科技-安全漏洞:http://www.nsfocus.net/index.php?act=sec_bug

    代码安全审计的工具

    源代码安全分析

    源代码安全分析的核心在于分析挖掘代码中的内部逻辑关系,从而发现其存在的漏洞;同时进一步尽力发掘设计、运行时逻辑中存在的问题。其主要的思路为:

    代码原始信息提取
    代码内部逻辑关系分析
    漏洞特征分析
    漏洞检测判定

    源代码安全分析应有两个方向:

    • 针对源代码的审计:
      基于源代码的静态扫描,没有中间文件生成。主要通过收集数据流,生成dom节点,根据上下语义进行分析。
      针对源代码的审计的主要特点为可以不需要编译,直接分析出源代码的漏洞。主要的代表为:Checkmax。
    • 针对二进制代码的审计:
      依赖构建编译的文件,主要的分析技术为:内存建模,符号执行,数据流,路径裁剪等。
      针对二进制代码的审计需要依赖构建环境。主要的代表为:Sonar。

    当然也有厂商采用两者结合的方案,比如:Fortify。

    第三方依赖包安全分析

    第三方依赖包安全检查用于扫描应用程序(及其依赖库),执行检查时会将 Common Platform Enumeration (CPE)美帝国家漏洞数据库及NPM Public Advisories库下载到本地,再通过核心引擎中的一系列分析器检查项目依赖性,收集有关依赖项的信息,然后根据收集的依赖项信息与本地的CPE&NPM库数据进行对比,如果检查发现扫描的组件存在已知的易受攻击的漏洞则标识,最后生成报告进行展示。

    对于第三方依赖包的检测,比较常用的是OWASP(Open WebApplication Security Project)的开源项目,主要有两个:

    • DependencyCheck:
      开发团队使用的工具,用于识别项目依赖项并检查是否存在任何已知的,公开披露的漏洞。主要针对单个项目。支持Java、.NET、Ruby、PHP、Node.js、Python等语言编写的程序,并为C/C++构建系统(autoconf和cmake)提供了有限的支持。同时支持和许多主流的软件进行集成,比如:命令行、Ant、Maven、Gradle、Jenkins、Sonar等。
      官网:https://owasp.org/www-project-dependency-check/
    • DependencyTrack:
      安全团队使用的工具,实现第三方组件的安全统一管理。
      官网:https://dependencytrack.org/

    代码安全审计的落地

    关于代码安全审计,主要的问题在于:误报、漏报。一般情况下,代码审计工具采用清洗、以及自定义规则的方式,应对上述问题。

    自定义漏洞规则
    自定义清洗规则
    代码
    初步漏洞报告
    漏洞报告

    因此,在实际代码安全审计操作过程中,主要在于在实践中不断的:

    1. 调整自定义漏洞规则,以完善漏洞库;
    2. 调整自定义清洗规则,以减少误报率;

    通常在初步引入代码安全审计时,通常:

    • 先适当的选择部分的工程,能过这批次的工程,调整漏洞规则、清洗规则,得到可接受的工程落地结果;
    • 而后适当的增加工程,不断重复上述的步骤,直到所有的工程都进行代码审计为止;

    按介绍经验,预计上述步骤需要经历半年到一年的时间,才能完成代码审计工具的引入。

    参考文档

    • https://github.com/dependency-check-team/dependency-check
    • https://www.microfocus.com/zh-cn/products/static-code-analysis-sast/overview
    • https://docs.sonarqube.org/latest/
    展开全文
  • 代码审计手册.docx

    2021-12-01 10:53:42
    代码审计实施技术手册
  • 代码审计与Web安全实验,适用于大学生期末大作业,期末复习,实验模板
  • WEB安全审计

    2021-02-20 23:29:04
    白盒方面,谈谈从代码级做好防御,这方面的攻击往往不太容易,但也要防范于未然。Web入侵分为两个步骤,首先是前期的渗透工作,而后是提权工作。渗透程度有深浅,要看Web服务器的安全程度。浅则窃取一些用户账号相关...
  • PHP源代码审计工具RIPS RIPS简介、RIPS的安装和使用、典型漏洞分析 rips安装 rips介绍 rips扫描的过程和结果
  • 代码安全审计大全

    千次阅读 2018-08-09 10:29:08
     企业安全规划建设过程中,往往会涉及到开发的代码安全,而更多可以实现落地的是源代码安全审计中,使用自动化工具代替人工漏洞挖掘,并且可以交付给研发人员直接进行安全自查,同时也更符合SDL的原则,此外可以...
  • python 安全编码&代码审计

    千次阅读 2022-04-21 09:43:28
    现在一般的web开发框架安全已经做的挺好的了,比如大家常用的django,但是一些不规范的开发方式还是会导致一些常用的安全问题,下面就针对这些常用问题做一些总结。代码审计准备部分见《php代码审计》,这篇文档主要...
  • 近期很多读者询问关于《JAVA代码安全审计》一书的出版进展,统一回复下,目前新书《JAVA代码安全审计(入门篇)》11月底已经完成全部书稿并交付出版社,全书分为九章460页,共计...
  • 代码审计流程

    千次阅读 2021-12-15 15:06:05
    代码审计的两种方式 敏感函数回溯参数调用过程 ## 关注程序敏感函数点: SQL语句拼合出,call_user_func,eval,unserialize,HTTP_CLIENT_IP等 ## 回溯参数调用过程查看是否全部过滤或过滤补全: 程序可能开启magic_...
  • 在软件项目开发过程中,应用系统设计人员和开发人员必须面对一系列复杂的...通过安全编码规范的落地实施,开发人员能够养成良好的编程习惯,可以使得系统安全性得到切实改善,有效提升系统健壮性,保障业务有效开展。
  • 究其原因是因为开发人员对所使用的语言与技术的安全特性不了解,写出的代码符合功能上的需求,但缺乏安全上的考虑。青穗软件联合国内外专家编写了各种主流语言的标准安全编码规范。根据不同的需求,能够为客户定制...
  • 【Web安全】Web安全Java代码审计总结

    千次阅读 2022-04-17 14:49:23
    《网络安全Java代码审计实战》笔记。 一、SQL注入 1.1 常见的sql注入场景 1.预编译错误编程方式 String username = ""; String id = "2"; String sql = "SELECT * FROM user where id = ?"; if(!CommonUtils....
  • 00×0 前言 最近也是边挖src边审计代码,总结下最近的php代码审计的一些思路,我一般按照顺序往下做,限于能力水平,可能会有不对或者欠缺的地方,...xcheck| Xcheck 是一款静态应用安全测试工具,旨在及时发现业务代码
  • 代码审计流程步骤

    千次阅读 2021-01-13 10:08:10
    1、配置审计分析环境 2、熟悉业务流程 3、分析程序架构 4、工具自动化分析 5、人工审计结果 6、整理审计报告
  • 代码审计步骤

    2020-12-11 07:19:33
    代码审计步骤 漏洞产生的原因 1、变量控制不严,一切输入都是有害的 2、变量到达有利用价值的函数(一切进入函数的变量都是有害的),漏洞的利用效果取决于最终函数的功能 步骤 1、通读代码 2、利用工具查找漏洞...
  • 这边给大家介绍一款可在本地使用的代码安全扫描插件,方便在开发阶段自动化安全检查,降低漏洞修复时间和减少漏洞出现的概率。插件简介插件介绍:Find-Sec-Bugs是一款本地 bug 扫描插件 “FindBugs-IDEA” 的 Java ...
  • 为了从根本上杜绝安全漏洞与业务逻辑漏洞,路印协议与专注智能合约安全研究的安比...安比(SECBIT)实验室于北京时间2018年12月15日完成对路印协议2.0智能合约和数字货币钱包(iOS+安卓)的代码安全审计。点击链接...
  • 代码审计基础流程及常见漏洞

    千次阅读 2022-01-17 18:20:32
    辅助工具:nodepad++ seay源代码审计系统 编辑器:ultraedit 代码审计工具:RIPS(能根据漏洞自动生成payload) 前期准备:本地搭建网站,一边审计一边调试
  • 随着软件规模的日益增大,系统的逻辑结构越来越复杂,从起初几万行的代码数量,发展至今几十万...源代码审计是通过静态分析程序源代码,找出代码中存在的安全性问题,常用于由安全厂商或企业的安全部门发起的代码安全
  • 代码 审计

    2022-04-30 14:55:17
    一、代码审计 1.1什么是代码审计? 软件代码审计是对软件解决方案或产品中的源代码的全面分析。它被认为是安全过程中最关键的阶段之一,因为它用于验证代码的成熟度和可维护性,同时确保产品已准备好进行无缝切换...
  • 本书详细介绍代码审计的设计思路以及所需要的工具和方法,不仅用大量案例介绍了实用方法,而且剖析了各种代码安全问题的成因与预防方案。无论是应用开发人员还是安全技术人员都能从本书获益。本书共分为三个部分。第...
  • 代码审计普及

    2021-02-01 10:34:49
    代码审计服务的目的在于充分挖掘当前代码中存在的安全缺陷以及规范性缺陷,从而让开发人员了解其开发的应用系统可能会面临的威胁,并指导开发人员正确修复程序缺陷。 一、 源代码审计与模糊测试 在漏洞挖掘过程中...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 14,585
精华内容 5,834
关键字:

代码安全审计规范