代码审计思路经验谈

       软件漏洞概述

       漏洞是指在计算机系统安全方面存在的缺陷，可能导致系统或应用数据的码审保密性、完整性、码审可用性以及访问控制受到威胁。码审从另一个角度来看，码审漏洞可以被视为系统或软件安全策略的码审程序员该阅读哪些源码书籍缺失或不足。如果软件设计和开发过程中严格遵守并实现安全策略，码审则可以实现安全性。码审此时，码审代码审计便是码审基于安全策略原理，对策略的码审确立或不足进行审计。

       总体审计思路

       1. 代码审计思路

       在实际工作中，码审每个项目都有其预算，码审客户关注的码审点也各不相同。如何利用有限的码审资源，尽可能达到或超过客户预期，是项目成功与否的关键。通常，客户关注的点是容易检测出的代码安全问题。在审计上，按照/法则和推进先后顺序，需要将前中期审计重点放在常见安全风险点上，而不是技术难度和复杂度都高的风险点审计。

       此时，合理的审计思路显得尤为重要。首先，根据项目预算确定项目时间和投入资源，根据时间和资源制定项目可执行方案。审计层面的思路是先快速了解项目架构，就像浏览书本的目录，对项目中各个模块的功能有基本的了解即可。为了提高整体效率，前期可以使用人工和工具的方式，利用工具进行初步扫描，人工进行初步审计，达到发现大多数简单安全风险的水平。中后期则进行纯人工审计，利用敏感和危险函数、数据流回溯、功能模块、安全策略、黑白盒审计等方法进行交叉审计和验证，尽可能多而全部地挖掘源代码中的安全风险问题。

       2. 代码审计策略

       2.1 全文通读审计

       该策略是通过直接分析源代码去审计安全风险。这种方式对审计人员的能力要求较高，需要通读代码了解程序的答题结构，了解各个模块并理解代码各项功能。在阅读完整体代码之后，根据程序入口开始审计。

       该方式的优点在于深度了解项目代码架构和功能后可以审计出较为复杂的安全风险点。缺点在于对审计人员的要求度较高，审计较为耗时。

       示例（CMS）：

       我们可以先看源码文件中是否含有API、admin、system等关键字的目录，这些目录通常需要重点关注。

       接着就是掌上dnf助手源码查看关键代码，比如functions.php文件中有一些系统的关键函数和一些过滤规则。

       接下来可以再找一找其中的配置文件，我们可以去搜config等类型的文件名称，这些文件中会包含一些项目关键配置。

       2.2 功能模块审计

       功能模块的审计介于全文通读、敏感和危险函数审计的两种方式之间。在降低全文源码通读的难度的前提下，适当兼顾了代码审计的深度和广度，做到比起函数审计更为全面。

       在模块层面上，可以进一步进行数据类型分析、对象分析、接口分析、算法分析、函数间逻辑调用分析，针对模块功能常见的安全风险点进行逐一审计，比如用户认证、文件上传、文件管理和密码找回、支付逻辑等等功能点。

       示例（CMS）：

       首先我们需要在源码文件夹中查看upload、login、export等源码文件，然后根据相关的功能模块进行代码审计。

       导出表格相关功能：

       登录模块：

       2.3 敏感和危险函数审计

       敏感和危险函数审计，也是代码审计中最为常见及直接的审计方式。常见的安全风险大多数由于函数使用不当造成。根据审计经验，可以获知常见安全风险涉及的敏感和危险函数，全项目检索相关函数进行定位，通过函数前后调用关系进行审计，验证相关安全风险是否存在。

       该方式的优缺点也相对明显，优点在于可以快速上手进行审计，只需检索相应敏感和危险函数，快速定位到风险点，可定向审计同类型安全风险点，效果明显。缺点则是由于没有通读全文，对程序整体架构了解不够深入，在风险点的覆盖上不够全面，深度较为欠缺。

       示例：

       代码审计中常见的危险函数

       3. 基本概念和审计方式

       在进行代码审计之前，我们需要对代码审计的一些基本概念和审计方法有一定的了解。在软件开发过程中，代码审计是一种重要的安全实践，用于发现和纠正应用程序中的安全漏洞。它通过仔细检查应用程序的源代码来识别潜在的安全风险，确保应用程序在生产环境中的安全性和稳定性。

       常用的审计方式有以下几种：

       4. 代码审计方法

       根据敏感和危险函数回溯参数，查询可控变量，寻找敏感功能点进行数据流上的审计。在日常渗透测试过程中通常关注三点：输入点，数据流，输出点。首先可以通过系统功能来判断输入点的有钱还源码装位置，常见输入点为各种查询、用户登录界面、搜索功能、留言板或公告等参数。可以通过对应输入点的位置来追踪数据流，主要关注是否存在过滤代码对用户可控的参数做了合法性校验。

       以下有几种常见思路：

       1. 根据敏感和危险函数回溯参数传递过程因为大多数漏洞是由于函数的使用不当造成的。

       优点：只需要搜索相应的敏感和危险函数，即可快速地挖掘想要的漏洞，可定向挖掘、高效、高质量。

       缺点：由于没有了解整体代码，对项目的整体框架了解不够深入，不容易了解参数的完整传播过程，会存在误报，通常也比较难发现逻辑漏洞。

       2. 查找可控变量，正向追踪变量传递过程，查找可能存在安全漏洞的变量，从变量处发现安全问题。常见的可操控变量：username、id、password、File、url、path、search、MultipartFile等。

       3. 寻找敏感功能点，尤其关注于易出现漏洞的功能点，如：文件上传、留言板、登录认证功能、找回密码等通过从敏感功能点入手来查找安全问题。

       4. 第三方组件、中间件对比，检查Web应用所使用的第三方组件或中间件是否受到已知漏洞的影响。

       5. 检查开发框架是否存在已知漏洞，或者是否存在由于开发人员使用不当而引起的安全风险。

代码审计--youdiancms SQL注入

       友点企业网站管理系统（YouDianCMS）是一款集电脑站、手机站、微信、APP、小程序于一体的开源五站合一企业建站解决方案。其使用PHP开发，以其操作简单、功能强大、稳定性好、易扩展、安全性强、维护方便等特点，被广泛应用于企业网站建设。然而，该系统在实现过程中存在潜在的安全风险，如SQL注入漏洞。骑士cms se源码

       在友点CMS系统中，存在一个直接赋值的变量，主要在`App/Lib/Action/HomeBaseAction.class.php`文件中。如果GET请求中传递了一个`fu`参数，该参数值会被赋值给`cookie`方法，并随后添加前缀，最终赋值给`youdianfu`变量。这一过程允许开发人员在特定条件下控制`$this->_fromUser`变量的值。

       通过控制`youdianfu`变量，攻击者可以尝试注入SQL代码。主要的注入尝试发生在`App/Lib/Action/Home/ChannelAction.class.php`文件中的`voteAdd`方法。在该方法中，`$this->_fromUser`变量的值被检测和使用。攻击者可以通过设置`cookie`值，绕过一些基本的验证流程，进而触发SQL查询。在`App/Lib/Model/Admin/WxVoteModel.class.php`文件中，`$fromUser`值被存入`$where`数组，并通过`$this->where`方法集成到SQL查询中。

       尽管友点CMS系统使用了ThinkPHP3框架，该框架在某些版本中存在SQL注入风险，且未实施有效的防御机制，如`I()`函数。在执行SQL查询时，`$where`数组的内容直接被拼接到SQL语句中，为攻击者提供了一条注入路径。在`App/Core/Lib/Core/Db.class.php`文件中的`buildSelectSql`和`parseSql`方法中，SQL语句的构建和解析过程允许不安全的输入直接参与查询逻辑，从而可能导致SQL注入。

       对于攻击者而言，SQL注入攻击的实现方式多样，通常需要定位使用可控制变量进行SQL查询的代码段。在友点CMS系统中，只要调用包含`$this->_fromUser`变量的`where`方法的代码块，理论上都可能存在注入风险。因此，CMS系统中与`$this->_fromUser`相关的多个功能模块都可能成为攻击目标。

       总结起来，友点CMS系统中的安全漏洞主要源于其使用的框架存在已知的漏洞，以及系统中存在可控的变量。这为代码审计提供了重要启示：应重点关注通过Cookie控制的变量，因为这类变量的防护往往较弱。此外，积累不同框架的漏洞知识也是防范此类安全问题的关键，因为随时可能遇到利用这些漏洞的攻击尝试。在实际应用中，加强代码审查、更新到最新安全版本的框架、实施输入验证和输出清理等措施，都是有效防范SQL注入攻击的重要手段。

代码审计之某开源商城前台无条件Getshell

       本文作者：safe Team - Poacher

       本文仅供学习思路，请勿用于非法用途。

       0x 前言：

       搭建环境：使用Windows PHPstudy集成环境，方便审计，可任意切换PHP版本。

       0x CMS简介：

       xxxxxxx 1.，伊对社交源码基于ThinkPHP5.0与MySQL开发，面向对象设计，开源，适合企业与个人，支持多平台二次开发。

       0x 正文：

       审计流程：寻找入口文件，查看目录结构。

       目录内有PC版前台、WAP手机版及后台三个入口。

       漏洞文件：/niushop/application/shop/controller/Components.php（PC版）。

       漏洞代码：-行，用于判断文件扩展名。

       逻辑问题：$ext获取文件扩展名后，行代码仅检查最后三位是否为php，忽略了其他类型。若修改Content-type为非php类型（如image/jpg），则可绕过检查，成功上传PHP文件。

       成功上传：上传后返回文件路径，使用工具连接，实现Getshell。

       总结：通过修改Content-type参数，绕过代码限制，实现无条件Getshell。强调交流分享，欢迎指出错误或提供更好方法。

       原文链接：代码审计之NIUSHOP v1.开源商城前台无条件Getshell

记一次某CMS代码审计（三处phar rce)

       在冬至时节，深入探讨了一款基于thinkphp5.1.的CMS代码审计。此次审计是与前文所述的同一项目，审计过程中发现多个关键漏洞。在审计过程中，我们已将发现的漏洞提交至CNVD。以下为审计内容的核心要点。

       审计过程中的重点之一是利用phar rce（反序列化漏洞）。在`application/admin/controller/Template.php`的`filelist`函数中，我们发现`Admin.php`的`getTpl`函数存在文件操作漏洞，这为我们进一步利用phar rce提供了可能。

       通过分析，我们发现`application/admin/controller/Admin.php`的`scanFilesForTree`方法存在phar rce漏洞。此漏洞通过`is_dir`函数成功实现了phar反序列化，这为我们提供了攻击入口。

       我们制作了payload并上传，成功执行了phar攻击。为了防止直接利用，我们对payload进行了魔改。类似的方法在审计过程中多次被应用，包括但不限于`application/admin/controller/Admin.php`的`scanFiles`方法。

       另一处较为复杂的phar rce漏洞出现在`application/admin/controller/Upload.php`的`uploadFile`方法中。在这一环节，我们发现`$this->uploadHandler->upload($file)`这一部分可以利用phar rce。通过深入分析`app\common\model\upload\driver\local`的`upload`方法，我们发现`is_dir`函数可以实现phar反序列化，而`$uploadPath`则从数据库中获取，允许后台控制，因此成功执行phar。

       对于漏洞利用，我们采取了以下步骤：首先，在后台配置`$this->config['upload_path']`为phar路径，然后发送包含修改后的`upload_path`参数的POST请求，完成配置修改后，正常上传文件即可实现phar。

       通过此次审计，我们成功获得了4个shell，并已将其中的漏洞提交至CNVD。审计中发现的漏洞主要涉及phar rce，但审计团队认识到，为了全面评估CMS的安全性，还需深入挖掘逻辑漏洞等其他类型的问题。

       审计结果表明，虽然存在漏洞，但在非弱密码情况下，该CMS系统具有较高的安全性。对于实际应用中的安全评估，审计人员提醒，仅关注phar rce一类的漏洞可能不足以全面保障系统安全，需要综合考虑各种可能的安全风险。

代码审计Day6 - 正则使用不当导致的路径穿越问题

       本文由红日安全成员：水清云影 编写，如有不当，还望斧正。

       漏洞解析 ：

       正则表达式不严谨导致的任意文件删除漏洞，在代码的第行，使用了 preg_replace 函数。该函数中的正则表达式[\^a-z.-_]并未起到过滤目录路径字符的作用。此表达式匹配除了 a 到 z 字符、点和下划线字符之外的所有字符，因此攻击者仍可以通过点和斜杠符号进行路径穿越，最终删除任意文件。例如，使用 payload action = delete&data = ../../ config.php，即可删除config.php文件。

       函数 preg_replace 在 PHP 中用于执行正则表达式的搜索和替换。定义为 mixed preg_replace (mixed $pattern , mixed $replacement , mixed $subject [, int $limit = -1 [, int &$count]])。其功能是搜索主体 $subject 中匹配 $pattern 的部分，并将匹配部分替换成 $replacement。

       ##实例分析

       本次分析选取 WeEngine0.8 版本的漏洞入口文件 web/source/site/category.ctrl.php。在第行调用 file_delete 函数，用于删除文件。但未对文件名 $file 变量进行过滤，导致存在类似 ../ 的字符，引发任意文件删除漏洞。该函数定义在 framework/function/file.func.php 文件中。

       ##漏洞验证

       访问 xxx.xxx.xxx.xxx/WeEngine...，点击管理公众号。在分类设置中，选择添加文章分类。这里对应的 URL 是 xxx.xxx.xxx.xxx/WeEngine...，即为 site 控制器的 category 模块。在上传图标位置输入要删除文件的路径，建立 delete.txt 文件用于测试。点击删除时，会调用 file_delete 函数，删除数据库中插入的名。

       ##修复建议

       由于 $row['icon'] 参数未进行过滤，导致任意文件删除漏洞。修复建议是在传入的参数中过滤 "../" 等目录阶层字符，以避免目录穿越，防止删除其他文件夹下的文件。可引入自定义函数 checkstr 过滤字符。在修复中，过滤 $row['icon'] 中的目录穿越字符，确保安全。代码示例如下：

       结语

       通过上述分析，对路径穿越问题有了更深入的理解。可从提供的 CMS 中下载（密码：hgjm）进行实践学习。如对项目感兴趣，欢迎发送邮件至 hongrisec@gmail.com 联系我们。Day6 的分析文章至此结束，最后留了一道 CTF 题目供练习。题目如下：

某商城最新CMS从0day审计到漏洞利用

       吃个早餐，开始了新的一天。朋友分享了最新的商城CMS给我，我决定帮忙审计，并分享这次经历。

       首先，我部署了网站源码并查看了前台和后台页面。接着，使用工具进行了初步审计。我了解到，尽管多入口CMS有时工具难以发现漏洞，工具仍能提供半辅助作用。

       我分析了item.php中拼接参数的部分，使用Sublime Text3打开进行研究。在SQL语句中，发现id值直接拼接，随后分析了Req()、Qry()、Qra()函数，发现它们没有过滤。

       我进一步查看require引入的common.php文件，发现Qry和Qrc函数为正常数据库操作，而Req函数只是一种接受参数的方式。但函数内有Rpl函数，它进行了字符串替换，替换了加号、空格等字符。

       在SQL语句中，$n通过"."进行拼接，无需单引号或双引号闭合。我构造了payload进行注入尝试，发现可以成功绕过Rpl函数。

       为了验证，我使用了SQLMAP工具并找到了一个空格替换为/**/的tamper。通过运行sqlmap构造参数，我成功找到了数据库test2中的xxx_admin表及其字段Nm和Np的内容。

       最后，我总结了这次审计的经验，强调了使用过滤方法，如PDO预编译，来修复漏洞的重要性。文章源于微信公众号（米瑞尔信息安全），由作者啊giao撰写。

BlueCms代码审计

       对BlueCmsv1.6进行代码审计。审计中发现以下问题：

       全局配置分析：检查发现存在未对$_SERVER进行过滤的情况，可能受到单引号或者引号闭合的SQL注入攻击。同时，$_SERVER的遗漏可能通过其他方式被利用。

       审计过程：发现SQL注入漏洞存在于uploads/comment.php路径下，未对$_SERVER进行过滤，通过查找处理IP的方法并延时验证成功。另外，在uploads/ad_js.php路径下，未对输入内容过滤，可利用联合查询进行注入。存在XSS漏洞的路径有uploads/user.php和uploads/admin/ad.php，邮件地址和多个位置存在XSS攻击可能，配置文件未进行过滤。文件包含漏洞出现在uploads/user.php，需要PHP版本5.3.4以下才能利用，高版本已修复截断漏洞，使用include方式引入执行文件，配合文件上传可以获取shell。文件上传路径为/bluecms_1.6/uploads/user.php，未对内容进行过滤，使用phar打组合拳测试，发现大多数路径被BLUE_ROOT拼接，无法利用phar。构造poc成功触发phar后获取phpinfo页面。任意文件删除漏洞出现在uploads/user.php路径，利用条件苛刻，但可直接执行任意文件删除或phar反序列化。另一处删除漏洞在uploads/publish.php路径下，成功执行。代码执行漏洞在/uploads/include/smarty/Smarty.class.php路径，通过反向跟进_eval方法，跟进smarty_core_process_cached_inserts方法，通过跟进smarty_core_read_cache_file验证处理逻辑，确保返回True。

       总结：代码能力的强弱将直接影响安全行业的发展，CTF和HVV等需要深厚的代码审计能力。Go语言的代码审计也逐渐兴起，安全之路漫漫，持续探索与提升。

代码审计-无回显SSRF的奇妙审计之旅

       本文探讨了代码审计过程中遇到的一个无回显SSRF漏洞的奇妙审计之旅。此次审计始于一个PHP源码的深度挖掘，通过关注函数curl_exec()，最终定位到了MACCMS 8系统的某个潜在安全风险。

       在审计过程中，我们首先从函数curl_exec()出发，深入分析了maccms8\inc\common\function.php文件，发现利用此函数的潜在风险。经过细致的代码查找，我们发现调用getPage()函数的环节存在无过滤情况，这为漏洞的利用埋下了伏笔。

       通过追踪调用getPage()的源头，我们找到了一个可能利用的入口点，即在inc\common\function.php的行。这里，传入的$url参数经过了截断拼接，缺乏有效过滤，为我们提供了利用的机会。继续追踪，我们发现savepic()函数可能被利用，它在maccms8\admin\admin_interface.php的第行被调用，且传入参数d_pic可以通过be()函数接收。

       be()函数的实现细节在此不再赘述，但它允许通过get或post方式接收参数d_pic。通过分析，我们发现可以利用这一特性构造利用流程，最终定位到实现漏洞利用的关键步骤。

       在构造利用流程时，我们关注到在、行的判断条件，以及、行的空值判断，这指向了配置文件config/config.php。通过进一步分析，我们了解到可以通过get或post方式传入参数，实现对网站配置的修改，进而触发漏洞。

       通过这一系列操作，我们成功构造了利用流程，尝试访问DNS日志，发现数据新增成功，证实了SQL注入的存在，但未直接与SSRF漏洞相关联。经过多次尝试，我们最终利用了文件写入功能，通过构造文件并测试写入成功，揭示了目录与文件名的特殊关联，进而发现了条件竞争的机会。

       利用条件竞争，我们成功读取了文件内容，这一过程展示了深入思考和创新思维的重要性。在审计过程中，我们还发现了文件上传这一潜在利用点，通过构造PHP后缀的马，实现了文件解析和shell获取，进一步丰富了利用手段。

       总的来说，这次审计之旅充满了挑战与惊喜，强调了代码审计过程中细致观察、深入分析和灵活思考的重要性。通过这次探索，我们不仅发现了SSRF漏洞的利用途径，还拓宽了利用思路，展现了审计技巧与漏洞利用的紧密结合。

记一次较为详细的某CMS代码审计

       在本次审计中，Seay和昆仑镜被结合使用，以更高效地查找和确认漏洞。Seay提供文件浏览功能，而昆仑镜则能快速定位大量漏洞。审计对象是KKCMS，通过以下步骤深入分析：

       Seay与昆仑镜的结合使漏洞检测更为全面。审计过程涉及代码审计、XSS攻击、SQL注入等安全问题。

       在验证码重用部分，验证逻辑存在风险，通过深入分析前端代码，发现验证码生成和校验机制。利用bp抓包和爆破技术，成功验证出密码。

       对于XSS攻击，通过昆仑镜扫描和Seay查看代码，发现直接输出$_GET['fee']存在风险。构造xss payload成功触发XSS。

       在wap/seacher.php和wap/movie.php中，通过利用Seay，发现未过滤的参数直接输出，成功触发XSS。代码审计发现输出点和恶意代码注入位置。

       系统/pcon.php的XSS尝试失败，发现可控变量play，但条件限制阻止了xss语句的执行。全局搜索找到变量赋值点，确认不存在xss。

       在admin/cms_ad.php中，广告管理界面存在XSS，查看代码证实无过滤措施，构造xss恶意语句成功触发。同样，youlian.php存在xss风险。

       admin/cms_kamilist.php中，参数id无防护，通过尝试构造payload触发XSS。wx_api.php中，参$_GET['echostr']存在xss风险，验证发现token检验逻辑，尝试xss payload成功触发。

       SQLbplay.php中，SQL语句存在风险，通过检查特殊字符处理，发现防御机制失效，尝试SQL注入攻击成功。

       在wap/user.php和wap/login.php中，SQL注入防护机制有效，验证了代码的过滤和转义处理。尝试其他文件中的SQL注入尝试失败。

       总结审计过程，代码审计对漏洞的发现和修复至关重要。通过结合使用工具和深入代码理解，可以有效识别和解决安全问题。希望分享的经验能为代码审计学习者提供帮助。