本文是i春秋论坛签约作家「精通linux开关机」分享的技术文章，所涉及的内容仅限用于学习和研究目的，不得将正文内容用于商业或者非法用途！
公众号旨在为大家提供更多的学习方法与技能技巧，文章仅供学习参考。该文章首发在i春秋论坛，欢迎各位师傅完成专业爱好者认证，可第一时间获取最新技术资讯和实战技能分享。
（识别二维码，快速完成认证）
文章主要介绍了源代码审计的重要性和方法，强调了其在软件开发安全中的作用。内容包括源代码审计的分类、工作性质、软件开发生命周期、安全生命周期、审计准备、工作原则、第三方组件安全检查、项目理解和checklist使用，以及关键字查找技术的优缺点。核心思想是源代码审计是提升软件安全性的关键，需要结合自动化工具和人工审查，同时强调安全应融入整个开发流程，通过有效的沟通、工具使用和持续学习来提高审计效率和质量。
源代码审计又叫白盒测试，源代码审计是识别源代码中隐藏安全问题最有效的方法，源代码审计既普遍又特殊，普遍在于建设研发安全体系必然要搞SAST质量门，特殊在于人工代码审计是安全中的细分领域，工程师的工作能力、工作经验等方面差距较为悬殊，比较明显地表现在代码审计适应能力、模块侧重点把握和接口全面覆盖率的不同。有一些比较好的通用审计做法，包括充分利用开发文档、选择适当的测试工具、制定checklist检查单、历史经验教训、工作原则、关键字查找等，使用这些技巧经验可以帮助工程师更高效、系统性、全面性地开展源代码审计工作。
源代码审计按工作性质分成两类：一类是甲方打造全方位应用安全，另一类是乙方给定CMS源码挖0day进内网刷分。通常后者常止步于个别高危风险点，这是指白帽子会优先关注无鉴权接口列表，只要突破一个前台点即可入侵拿shell。甲方源代码审计为了平衡效率通常不会每每进行远程代码调试，远程代码调试非常耗费时间精力，并且解决高危风险隐患比求证风险隐患更重要，甲方人员节省下来这部分时间精力可以用于提高覆盖面，但是坏处便是容易跌入成长性不足、重复常态化工作的误区。
学习理解开发项目组的一些常识(生命周期和工作流程)是安全人员融入研发组工作的第一步，甲方源代码审计不是单独的项目形式，源代码审计通常与开发需求任务相伴进行，熟悉开发任务的生命周期和工作流程很重要。
熟悉生命周期、工作流程有助于确保源代码审计与开发过程紧密集成，提高效率、增进理解、减少对开发流程的干扰。开发任务的生命周期通常包括规划、设计、实现、测试和部署等阶段，对这些阶段的理解有助于确保源代码审计及时进行和后续修复验证的时机。
软件开发生命周期 (SDLC) 是一个结构化的流程，用于指导软件团队制作高质量的应用程序。软件团队使用 SDLC 来降低成本、最大限度地减少错误，并确保软件始终与项目目标保持一致。软件开发生命周期每一阶段都是按“活动-结果-审核-再活动-直至结果正确”，下一阶段的输入是上一阶段的输出，循环往复进行。
软件开发生命周期（SDLC）通常包括以下六个主要阶段：
这个阶段是软件开发过程中的需求分析阶段。在这个阶段，团队会与客户进行沟通，以了解他们的需求和期望。然后，团队会将这些需求转化为详细的规格说明书，这些规格说明书将作为后续开发工作的基础。
团队会设计软件项目的架构和模块，并制定详细的设计文档。设计阶段的关键是确保软件项目的可扩展性、可维护性和安全性。
开发人员会根据设计文档编写软件代码。这个阶段的关键是确保代码质量，包括可读性、可维护性和可测试性等。
团队会对软件项目进行各种测试，包括单元测试、集成测试和系统测试等。这个阶段的目的是确保软件项目的质量和稳定性。
团队会将软件项目部署到生产环境中。关键是确保软件项目的部署流程是可靠和自动化的。
团队会对软件项目进行维护和支持。关键是及时发现和解决问题，确保软件项目始终保持高质量和可用性。
最经典的模型在进入下一阶段之前，团队需要完成项目的每个阶段。
主流的软件开发方法。每次迭代最有价值的部分，这有助于开发人员更快地完成工作，更轻松地进行更改。
每个cycle产生一个不完整的产品。每个cycle都会产生更多的需求，直到产品成型。
侧重于产品的特定风险模式，因为开发团队决定采用哪种其他流程模式。
开发人员同时运行验证和确认流程。每个开发阶段配套有独特的测试阶段。
精益模型与敏捷模型类似，但它侧重于减少重复劳动提高效率。
源代码审计对应SDLC中的开发编程&测试验证阶段，但在传统SDLC（软件开发生命周期）模型中，如瀑布模型等并不包括安全测试，安全团队只在构建软件后才介入。正因为传统SDLC模型存在许多不合理的地方，许多公司正在过渡到S-SDLC（安全软件开发生命周期）甚至是DevSecOps模型。
微软率先将安全融入开发进程提出了 Security Development Lifecycle (SDL)。
Security Development Lifecycle (SDL) 是一个软件开发安全保证过程，由七个阶段组成的安全实践分组：培训、需求、设计、实现、验证、发布和响应。
微软安全开发生命周期网站提供了关于该过程的整体资源和与每个阶段相关的工具。
对公司而言，SDL 可以：
减少总开发成本🔵
确定安全优先事项🔵
微软的SDL是一种理念、制度，虽然微软官网提供有配套的工具但是SDL更多强调人、文档、制度的推进，而后衍生出来的S-SDLC和DevSecOps是两种具体的解决方法。跟微软SDL的区别是它们更关注SDL的落地化。
OWASP的S-SDLC理念来源于微软SDL，提出S-SDLC是帮助用户减少安全问题，并使用该方法从软件开发的每个阶段去提升安全级别，以此来实现软件整体的安全级别。
Gartner提出的DevSecOps是一种更高级别的模型，不仅将安全流程整合为软件开发流程的一部分，还一并整合了运维流程。在DevSecOps模型中，安全团队、开发和运营团队紧密合作，在软件开发生命周期的所有阶段实施安全措施，这有助于提高软件安全性，减少安全风险，并提高软件交付速度和质量。
无论是S-SDLC还是DevSecOps，将安全整合到软件开发流程中都可以提高软件安全性、减少安全风险和促成网络攻击抵御能力的最佳实践。
将安全整合到软件开发流程中可以提高软件安全性，但是也会让安全人员变得极其忙碌。如何在忙碌中保持高效发挥自身价值，而不是完成一些琐事，需要制定一些原则来梳理优先顺序。以下是一些建议：
为了提高软件安全性，应该集中为开发人员提供检查工具，以便他们在开发过程中可以轻松地检查代码的安全性。这比通过工单流程逐个处理安全问题更高效。
在软件开发过程中，审计人员和开发人员之间的互动非常重要。应该鼓励审计人员与开发人员就安全问题进行交流，而不只是出具报告。这样可以确保安全问题得到及时解决，互动沟通也可以提高开发人员的安全意识。
在软件开发过程中，提供一则正确的简单编程示范比详细的教程更有助于提高开发人员的安全能力。示范应该简洁明了，易于理解，以便开发人员可以快速掌握安全编程技巧。
人工代码审计对于识别某些特定安全问题最为有效，在开始人工代码审计之前，先确认一下是否配套有以下材料，以便更好进行安全源代码审查。
明确拿到的源代码是不是完整可构建运行的源代码；如果不是完整可构建的源代码，发现特定安全问题后是否可以在测试服务器上自行Fuzz验证问题。
源代码是不是包含相关的导入模块的源码；当审计工程师在本地debug想要逐步调试某些 API 时，拥有依赖组件的源代码会有助于审查；如果没有完整的源代码，对于这样一个黑盒子可能需要进行逆向工程来理解内部输入与输出的转换关系。
例如，Spring MVC或Spring Security框架中的web.xml配置文件存在安全策略。可以看到web.xml配置文件指明了过滤器类所在的包路径filter-class，同时也定义了过滤器作用的对象url-pattern。
在进行白盒审查之前，需要先进行静态代码扫描SAST，然后通过DAST覆盖所有业务REST API，再通过人工源代码审计覆盖重要业务REST API。黑盒快速验证和源代码审计并举可以发现深层次的问题和研究绕过策略。
Checkmarx是一款非常优秀的SAST工具，在各类跑分评测中的表现稳定处于中上游水平。Checkmarx支持增量扫描，但代码改动量达到一个阈值时，会自动转成全量扫描。根据Checkmarx扫描结果，不仅可以让人工代码审计变得简单，还可以梳理思绪，提醒我们应该关注哪几个部分，从而不断优化SAST扫描规则，提高漏洞挖掘速度，实现效率与重要性的平衡。
阅读系统架构和设计文档可以很好地了解程序设计流程和模块关系，虽然文档的名字叫架构设计文档，但重点应该关注的是文档中的结构图、层次图。与PPT宣传中的技术架构图不同，软件结构图强调业务模块之间的关系，而软件层次图则用于更好地找到相同层级不同业务功能相似点进行知识迁移和简要概括。
阅读这类文档，需要先浏览目录再重点看与结构相关的章节(4.2 总体结构)
软件结构图又叫软件架构图、模块结构图，确定软件系统中每个过程是由哪些模块组成的，以及这些模块之间的连接，明确和相对细致地描述组件之间的通讯关系。
层次图帮助团队人员更好地理解软件系统在某个特定层次上的功能和结构，有助于相同层级的知识迁移。
查看项目上的API应用接口表，观察API应用接口和服务器通信端口，了解BS/CS客户端可以控制传入哪些参数，客户端传入方式是否是不安全的通信协议，服务器是否暴露了不应暴露的API接口。
威胁建模是通过结构化的方法，系统地识别、评估产品的安全风险级别，确认哪些级别的风险必须规避、哪些级别的风险可以消减后遗留，并针对这些风险、制定消减措施的一个过程。威胁建模最后的交付物是威胁建模报告（Threat Modeling Report），报告描述了软件系统可能面临的风险和相应的缓解措施。
威胁建模通常从新增业务、高危业务、重要业务开展，也可以根据典型业务情景复用一些威胁模型。
威胁模型预先识别了高风险模块和接口，这些风险信息可以为源代码审计提供很好的参考，对于海量的业务代码来说，通过已识别的威胁模型可以降低人工源代码审计覆盖面不足的问题。
|
威协ID
|
风险等级
|
威胁描述
|
威协分类
|
影响的资产
|
策略
|
修复方案
|
状态
|
负责人
|
排期
|
|
1
|
高
|
服务器同客户端通信采用http模式，可被中间人攻击窃取，破坏了保密性、完整性和抗重放性。
|
信息泄露
|
客户端所有动作行为、系统数据、用户数据
|
解决
|
互联网暴露面系统使用全站HTTPS功能
|
TO
DO
|
张三
|
20240601
|
|
2
|
|
login.do接口使用username+timestamp作为随机数种子产生token，存在生成随机性不足，攻击者可推算出有效种子，伪造用户进行登录的威协
|
欺骗
|
系统数据、用户数据
|
缓解
|
使用非对称加密算法随机生成key值
|
DO
NE
|
李四
|
20240201
|
|
3
|
低
|
服务器和客户端采用RESTful API访问，服务器岩机会导致服务离线
|
拒绝服务
|
服务
|
解决
|
通过统一容灾方式，多机方式部署。
|
TO
DO
|
王五
|
20241201
|
|
4
|
高
|
在供应链流转阶段源码被逆向或不慎泄露
|
信息泄露、拒绝服务
|
应用本身
|
接受
|
NA
|
赵六
|
在开发阶段，研发人员需要参考威胁建模报告，将这些安全需求实现，包括安全细节的实现，具体的认证方式、密码使用哪种安全算法存储，使用什么方法生成安全随机数等。
在验证阶段使用威胁建模报告也可以指导安全人员开展安全测试，对研发人员的安全需求实现情况进行正向和逆向测试。
开发人员通过引入引用外部依赖包和第三方组件极大提高开发效率，减少重复造轮子的时间。安全人员需要对二进制文件(组件)进行版本号排查、社区热度、信誉度、安全性等方面进行分析，进一步确定组件是否存在后门、弱加密或密码硬编码等风险。分析第三方组件安全需要采用逆向工程、动态运行时分析、云端大数据样本比对等多种方法。
Cuckoo Sandbox 是一个开源虚拟化环境，用于对任何二进制文件进行静态和动态分析、收集全面的分析结果。
网址：https://cuckoo-sandbox.readthedocs.io/zh-cn/latest/usage/web.html
一款基于云计算的动态恶意代码分析工具，能够对各类可疑文件进行自动化、深度的行为分析，生成详细的分析报告，帮助用户快速识别和应对网络威胁。
网址：https://s.threatbook.com/
腾讯反病毒实验室推出的一款安全工具集，包括Meltdown&Spectre检测、Allcry解密、CCleaner后门查杀、摄像头安全检测等多种功能。针对第三方组件的安全分析，可以使用哈勃分析系统中的相关功能，对组件进行深入的静态和动态分析，以确保其安全性。
函数调用关系图可以展示程序中函数之间的调用关系，帮助安全工程师更好地理解程序的执行流程，便于追踪和调试代码。通过函数调用关系图，可以清楚地看到函数之间的调用顺序和关系，有助于理解程序的执行过程。
Doxygen和GraphViz是两款强大的工具，它们分别用于生成代码文档和生成代码结构图。通过结合使用可以更加高效地理解和管理复杂的代码库。在实际应用中根据项目的需求，灵活运用这两个工具，提升代码的可读性和可维护性。
Doxygen 是一款文档生成工具，它可以从代码中提取相应的文档，并组织、输出成各种漂亮的文档（如 HTML，PDF，RTF 等）。有了 Doxygen 工具，程序员在写代码时，可以直接内嵌文档，再也不需要为某个功能代码单独写文档，从而保持了文档和代码的最大统一性。Doxygen 支持 C/C++，Objective-C, C#，PHP 等语言，支持多平台（Mac OS, Linux, Windows）。
网址：http://www.doxygen.nl/
Graphviz 可以从源代码生成文档，还可以使用 Graphviz 的 dot 工具自动可视化模块、依赖关系图和继承图之间的关系，可以帮助 Doxygen 生成图表。使用 Doxygen 调用 GrapViz 可以生成类图和函数调用关系图。
网址：http://www.graphviz.org/
-
使用 Visual Studio 的map插件，但前提是必须是专业版或企业版，社区版无法安装此插件。
https://docs.microsoft.com/en-us/visualstudio/modeling/map-dependencies-across-your-solutions?view=vs-2017
-
使用 CodeViz 和 Graphviz 结合的方案。
-
使用 Doxygen 和 GraphViz 结合自动生成。(主流)
如下图所示，使用第三种方案 Doxygen和GraphViz来生成 类图、函数调用关系图或依赖关系图，这有助于更轻松直观地分析源代码。
对项目整体有了大致了解就可以开始确定哪些模块、功能需要进一步人工代码审查。
确定模块的重要级别、优先顺序需要像黑客一样思考，哪些模块最先引起黑客的兴趣，如果登录模块沦陷后的下一个最可能受到风险威胁的模块是什么？
|
高风险模块
|
业务功能
|
|
验证
|
账户注册、 登录、验证码、找回密码、更改密码等；身份和密码存储以及访问控制；多次失败后的帐户锁定控制。
|
|
授权
|
敏感资源访问接口、 系统管理员接口
|
|
管理员配置
|
有web、数据库、服务配置需要注意；审核配置有两种：一种是默认配置值，另一种是应用程序如何更新配置值。
|
|
金融
|
支付功能、优惠券、订单和购物车
|
|
文件操作
|
上传、下载、重命名
|
|
数据库
|
涉及数据库查询操作、 数据库创建、添加、更新和删除选项。
|
|
API接口
|
Restful API接口、其他通信接口、第三方集成接口、越权使用危险的API
|
|
过时的接口
|
不支持安全的模块仍坚持使用、使用被禁止的API
|
|
加密
|
使用被禁止的加密算法、开发过程中在源代码中硬编码敏感信息或注释带敏感信息；注释带敏感信息有如：IP、电子邮件、密码。
|
根据同类型项目的历史经验教训进行归纳总结，比对CWE 通用缺陷列表找到一些共性，建立更有条例的checklist检查表。
CWE 通用缺陷列表来自MITRE 公司，MITRE 公司是一个非营利组织，通过美国联邦政府资助和与其他公私企业或部门合作而获取研发资金。
MITRE 公司创造了 CVE（定义了一个漏洞的专属命名编号，对信息安全行业影响深远，至今仍在广泛使用），MITRE 公司还创造了 CWE 通用缺陷列表、CWE 在野利用列表、ATT&CK 框架（引领国际网络安全攻防潮流的安全技术战术知识库框架）等众多成果。
参考CWE 通用缺陷列表建立更为全面有条例的checklist检查表，后续维护checklist检查表可以根据项目的历史数据、项目的编程语言、项目所属行业以及问题的缓解方法进行调整。
|
热点问题示例
|
针对主要安全问题的缓解方法
|
|
CWE-89 SQL注入
|
使用参数化查询可以有效防止 SQL注入。使用sqlmap快速检测注入漏洞是否存在。重点关注那些未使用参数化查询的语句或在 iBATIS 框架中使用$作为 SQL 参数的 SQL 语句。
|
|
CWE-78 OS命令注入
|
使用自动化代码审计工具可以检测到系统命令注入问题，重点关注getRuntime()这类函数调用。
|
|
CWE‑79 XSS
|
通常XSS漏洞与前端框架漏洞有关。
可以重点查找以下相关高危风险点位:
document.location
document.URL
document.write
document.open
eval
|
|
CWE-306 缺少关键功能的身份验证
|
远程调试filter来发现特定 URL 缺少身份验证的情况，或使用DAST路径扫描来发现此类问题，这类安全问题很难借助自动化代码审计工具检测到。
存在 URL 匹配机制被绕过时，可以使用 StartsWith()和 以 EndWith() 加强路径验证
验证身份之前，先进行参数检测，出现../ 这类可疑行为可以直接返回路径验证失败。
|
Nday（有些也称为1day）是网络安全领域的一个术语，用于描述已知但尚未修复的安全漏洞，Nday较为隐蔽，利用成本较低，对互联网上的系统危害极大。
治理Nday通常使用 SCA（软件成分分析）核对组件包散列值，可以检测到大部分 Nday（如 Struct2、Shiro-550、Log4j、APISIX-dashboard 等）。还有一部分反序列化接口、REST API 调用需要对Nday 进行变形后利用，这类需要代码审计人员花些精力研究。
为了更好地防范 Nday 漏洞，最好建立公司的 SBOM（软件物料清单）清单。好处是在下一轮 0day 漏洞爆发时便于快速排查存量资产受影响情况。
在公司内部建立可靠的制品库，查询是否为安全版本，将安全版本存入私有化部署的 Nexus，逐渐过渡到只允许使用受批准的私有仓库。
源代码关键字查找，又称基于特定模式匹配的技术，是一种屡试不爽的方法，通过定位关键语句然后阅读上下文参数过滤情况来判断漏洞是否存在。
|
安全问题类别
|
Java 代码匹配 / 关键字查找
|
|
命令注入
|
Runtime.exec、 ProcessBuilder
|
|
缓冲区溢出
风险
|
strcpy、strcat、sprint、sscanf、vscanf、gets
|
|
XML注入
|
SAXParser、DocumentBuilderFactory、BeanReader、XmlReader、DOMParser、SAXReader、XMLinputFactory
|
|
敏感信息
|
Backdoor, password, admin, root Cipher, getInstance MessageDigest.getInstance Encode, ciphers, shareKey, token URL, Email, IP address
|
|
HTTPS 中间人(MITM)
|
ALLOW_ALL_HOSTNAME_VERIFIER X509Certificate, X509TrustManager getAcceptedIssuers
|
|
不安全的加密
|
RC4, SSL, AES, DEC, ECB, MD5, SHA1 Java.util.Random Cipher.newInstance("DES Cipher.getInstance("ECB
|
|
跨站脚本
|
document.location, document.URL document.referrer, document.write, document.print document.body.innerHTML window.location, window.execScript window.setTimeout, window.open request.getParameter
|
|
反序列化问题
|
XMLDecoder XStream readObject, readResolve, readExternal
|
|
用户数据输入
|
getParameter, getQueryString, getRequest getCookies, getInputStream, getReader getInputSteam, getMethod, getReader getRemoteUser, getServerName
|
源代码关键字查找上手非常快，通过搜索潜在的高风险字符串来提供下一步思路进行代码审计。安全团队可以准备或预先定义一组可能导致安全问题的关键字或正则表达式字符串。项目团队有了一组搜索字符串，就可以使用任何搜索工具（例如 idea的全局查找）进行搜索并审计搜索结果。
源代码关键字查找对于同样类型的漏洞产出效率非常高，并且这种搜索可以针对部分源代码进行。源代码关键字查找最好是针对某一个问题进行，这种方法与编程语言近乎无关，通用性好。只要有明确定义的搜索字符串，发现特定问题基本是重复操作。
许多安全人员工作多年，仍停留在关键字查找刀耕火种的阶段。虽然源代码关键字对于发现特定问题非常高效，但过于依赖经验具有局限性，无法发现业务逻辑漏洞，也无法代替自动化代码扫描工具。
不同编程语言的关键字查找有些许差别，可以参考 OWASP 源代码审计指南 2.0.pdf 得到更多编程语言方面的细节。指引文档里详细介绍了各类常见安全风险，并以 .net、java、php 编程语言进行正确示范。
网址: https://owasp.org/www-project-code-review-guide/assets/OWASP_Code_Review_Guide_v2.pdf
甲方代码审计工程师要有较为全面的技能栈，不仅需要具备扎实的编程技能、熟悉各类安全技术、适应项目上的编程技术，还要具备良好的组织协调能力和沟通技巧。
要比开发人员理解更深，如果对安全隐患、缓解措施理解不够深刻，提出生搬硬套的解决方案，只会引起开发人员的对立情绪，开发人员感到无所适从甚至心生厌恶。
对于不熟悉的领域要主动沟通主动学习才能不卑不亢，对于熟悉的领域也要不骄不躁不能表现得咄咄逼人给开发人员带来不必要的焦虑和压抑。
用开放的心态接纳不同的观点，不要因为个人偏好某种解决方案限制开发人员的创造力，以解决问题为导向，坚持同一问题也可以有不同解决方案。
代码审计工程师只有不断学习保持活力，才能在工作中持续找到更优的解决方案。新的漏洞不断涌现既是挑战也是职业生涯的机遇，只有不断丰富专业领域的知识储备，才能在职场工作中游刃有余。若停下学习的脚步，日常工作就容易变得刻板枯燥乏善可陈。
无论何时何地学习都是代码审计工程师的核心竞争力，不断进取，才能在职场中立于不败之地。
以上是今天的分享内容，对安全技术感兴趣的小伙伴及时关注后续公众号推文，学习过程中难免会遇到疑问，推荐加入i春秋的学习交流群~
在这里，您将获得双重收获：一是接触尖端技术知识；二是与热爱技术、乐于分享的同行建立联系。群管理员会不定期组织福利活动，并邀请行业领袖和知识专家来分享他们的经验。此外，您还能获取丰富的人脉资源和学习资料。期待您的加入，共同成长！
原文始发于微信公众号（i春秋）：揭秘代码安全：甲方审计高手的心得与技巧大公开！
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
点赞
https://cn-sec.com/archives/2843150.html
复制链接
复制链接
-
左青龙
- 微信扫一扫
-
-
右白虎
- 微信扫一扫
-
评论