生命在于学习——代码审计基础

在这里插入图片描述
图片来源于安全客。
注意:本篇文章仅用于自我学习与交流,不会过多或不涉及具体操作,不得用于其他用途。

一、代码审计简介

顾名思义就是检查源代码中的安全缺陷,检查程序源代码是否存在安全隐患,或者有编码不规范的地方,通过自动化工具或者人工审查的方式,对程序源代码逐条进行检查和分析,发现这些源代码缺陷引发的安全漏洞,并提供代码修订措施和建议。——来自百度百科
代码审计就是从安全角度对代码进行的安全测试评估,结合丰富的安全知识、编程经验、测试技术、利用静态分析和人工审核的方法寻找代码在架构和编码上的安全缺陷,在代码形成软件产品前将业务软件的安全风险降到最低。
实际上感觉就是真正的给你一个网站源码,从网站去找漏洞,而不是按照漏洞去找网站。

二、代码审计测试方法

代码审计采用人工审计和静态分析工具辅助的方式进行。
人工审计:既能解决内部问题也能解决外部问题,这也是目前最有效率的解决方案,并且在理论上手工代码审计是非常有效的,但人工审计的效率不高,所以我们会采用自动化分析工具辅助人工的方式来提高审计的效率。
静态分析工具(也可以叫代码审计工具):通过一组全面规则,测试机制(里面是已经编写好的程序)和方针在软件开发过程、测试中发现软件的安全缺陷。
人工审计和工具最好是结合使用。

三、代码审计的通用思路

1、逆向追踪

逆向追踪,或叫回溯变量,一般是检查敏感函数的参数,然后回溯变量,判断变量是否可控并且没有经过严格的过滤,这是一个逆向追踪的过程。
优点:只需要搜索相应敏感关键字,即可以快速的挖掘想要的漏洞,具有可定向挖掘和高效优点。
缺点:由于没有通读代码,对程序的整体框架了解不够深入,在挖掘漏洞时定位利用点会花费一点时间,另外对逻辑漏洞挖掘覆盖不到。

2、正向追踪

正向追踪,或叫跟踪变量
先找出那些文件在接收外部传入的参数,然后跟踪变量的传递过程,观察是否有变量传入到高危函数里面,或者传递的过程中是否有代码逻辑漏洞,这是一种正向追踪的方式。
优点:挖掘方式比逆向挖掘更全。
缺点:可能没有逆向追踪快

3、直接挖掘功能点

根据自身的经验判断该类应用通常在哪些功能中会出现漏洞,直接阅读该部分功能代码。
优点:比较快速,准确
缺点:需要一定的经验,且可能会因为经验遗漏一点漏洞

4、通读全文

一般MVC设计的网站 , 或者一些框架 适合这种审计方法 , 可能还需要结合一下断点调试技术
index 文件, index是一个程序的入口文件, 所以通常我们只要读一读index文件就可以大致了解整个程序的架构, 运行的流程, 包含的文件, 建议最好先将几个核心目录的index文件都简单读一遍
函数集文件, 一般在index文件中都会包含函数集文件, 通常命名为functions, common等关键字, 这些文件里面都是一些公共的函数, 提供给其他文件统一调用。
配置文件, 通常命名中包括 config 关键字,里面包含一些功能性配置选项以及数据库配置信息, 还可以注意下参数值是用单引号还是双引号, 如果是双引号, 则很可能会存在代码执行漏洞; 还需要关注以下数据库编码。
安全过滤文件, 文件过滤文件对我们做代码审计至关重要, 关系到我们挖掘到的可疑点能不能利用, 通常命名中有 filter, safe, check 等关键字, 这类文件主要是对参数进行过滤。
优点:可以更好的了解程序的架构以及业务逻辑,能够挖掘到更多,更高质量的逻辑漏洞。
缺点:花费的时间比较多,如果程序比较大,读起来会比较累。
个人更喜欢通读一下,但前提是对基础代码运行和架构框架有一定的的基础。

四、漏洞产生的原因

1、配置不当,很多中间件框架都会有自己的配置文件,当配置文件中的某些设置配置不当时,很容易产生漏洞。
2、变量控制不严格 ,对前端传入的数据没有严格的过滤和限制。
3、变量到达有利用价值的函数,用户可以接触到这些变量并会被带入执行。

五、漏洞关键字

这就很多了。
SQL:简单的增删改查关键词。
文件上传漏洞:$_FILES 、move_uploaded_file
命令执行漏洞关键字: shell_exec、exec、passthru , system 、popen
包含漏洞关键字: include、include_once、require、require_once
xss漏洞关键字: echo、print、print_r、var_dump、var_export
ssrf漏洞关键字: curl_exec 、file_get_contents、fsockopen
代码执行:主要由 eval()、assert()、preg_replace()、call_user_func()、call_user_func_array()、array_map()等函数的参数过滤不严格导致
命令执行:shell_exec、exec、passthru , system 、popen

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
软件测试需求是开发测试用例的依据,测试需求分解的越详细精准,表明对所测软件的了解越深,对所要进行的任务内容就越清晰,对测试用例的设计质量的帮助越大。详细的测试需求还是衡量测试覆盖率的重要指标,测试需求是计算测试覆盖的分母,没有详细的测试需求就无法有效的进行测试覆盖计算。 软件测试执行阶段是由一系列不同的测试类型的执行过程组成的,每种测试类型都有其具体的测试目标和支持技术,每种测试类型都只侧重于对测试目标的一个或多个特征或属性进行测试,准确的测试类型可以给软件测试带事半功倍的效果。 现有的软件测试分析技术不太成熟,对测试需求和测试类型的分析,所采用的方法主要是根据经验进行收集、整理,该方法依赖于测试设计人员的测试经验,由此方法得出的测试需求、测试类型往往导致测试用例设计不充分,测试覆盖度低,测试目的性不强,容易遗漏等缺陷。 可见,如何对测试需求进行细致的整理分析,明确测试执行时的测试类型,是一个亟待解决的问题。 有鉴于此,本方法的主要目的在于提供一种软件测试需求的分析方法,可以方便、详尽的获取测试需求,明确测试执行时需要实施的测试类型。 为实现上述目的,本方法提供了一种软件测试需求分析的方法,包括以下步骤: a)列出软件开发需求中具有可测试性的开发需求; b)对步骤a)列出的每一条开发需求,形成可测试的分层描述的测试需求; c)对步骤b)形成的每一条测试需求,从GB/T 16260.1-2006《软件工程 产品质量 第1部分:质量模型》中定义的软件内部/外部质量模型来确定软件产品的质量需求; d)对步骤c)所确定的质量需求,分析测试执行时需要实施的测试类型; e)建立测试需求跟踪矩阵,对测试需求进行管理。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

易水哲

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值