1.Դ?源码?վ????
2.为什么成品网站源码入口有风险？
3.常见的Web源码泄漏及其利用
4.如何应对源码泄密风险问题
5.安全风险是指什么

Դ??վ????

       截至年3月，绿盟科技创新研究院监测到上万个互联网中暴露的站风DevOps资产存在未授权访问情况，源代码仓库成为“重灾区”。源码这些暴露的站风源代码仓库包含了境内多家机构的重要系统源代码，部分源代码中硬编码了数据存储服务配置信息，源码存在敏感信息意外泄露的站风轻阅源码风险。事件敏感，源码以下仅示例部分脱敏案例，站风并已上报给相关监管机构。源码

       案例1：某沿海地区的站风科技公司使用Gitblit维护多个医疗IT系统源代码时配置错误，导致这些系统存在未经授权的源码访问漏洞。结果，站风包括某大学附属医院的源码排班系统在内的多个平台源代码被公开暴露在互联网上。暴露源代码中包含数据库连接详细信息，站风导致约万名病人的源码姓名、身份证号、住址等信息以及近1万名医护人员的姓名、****、学历和身份证等个人隐私信息暴露，存在严重隐私泄露风险。

       案例2：某互联网科技有限公司使用Gogs维护开发系统的源代码时配置错误，系统被暴露在互联网中并允许未经授权访问。暴露源代码中含有详细的数据库连接信息，导致大约万公民的姓名、手机号、身份证号码等个人隐私信息暴露，存在严重隐私数据泄露风险。

       案例3：某教育科技有限公司使用Gitea维护开发系统的源代码时配置错误，系统存在未经授权的访问漏洞。暴露源代码中包含数据库连接详细信息，php 病历管理 源码导致大约万学员姓名、手机、QQ号等个人隐私信息暴露，存在严重隐私数据泄露风险。

       此类安全事件不仅暴露了系统的源代码，还暴露了公民的个人隐私信息及敏感数据。这些泄露可能带来数据被不法分子出售、公民面临电诈风险、安全漏洞暴露以及关键基础设施单位存在安全隐患等严重后果。案例显示，数据泄露风险来源于配置错误，导致源代码、敏感信息被不安全方式暴露在互联网上。

       云计算技术广泛应用，但带来了安全风险问题。DevOps流程在提升开发、测试和部署效率的同时，也引入了云上安全风险，尤其是源代码、敏感信息的不当管理。绿盟科技创新研究院通过云上网络空间的测绘，揭示云组件暴露面，识别攻击面，以深入了解可能隐藏的安全风险。

       针对此类事件，监管部门开始采取行动。如衡阳市网信办对某开发应用网站数据库存在未授权访问漏洞、泄露公民个人信息的公司进行了行政处罚。企业可通过利用绿盟公有云测绘技术、php上传漏洞 源码敏感泄露发现服务以及EASM服务，加强自身风险暴露面的发现与防护。定期对内外部和上下游供应链人员进行安全培训，也能有效减少数据泄露事件。

       综上，源代码暴露事件对国家安全、关键基础设施单位、企业和公民隐私构成严重威胁。应加强技术监控、提高安全意识、定期进行安全培训，以有效应对云上安全风险。

为什么成品网站源码入口有风险？

       互联网已经成为人们获取信息、娱乐放松的主要途径。成品网站源码入口隐藏通道正是其中一个引人瞩目的话题。尽管许多人认为成品网站源码入口应该是公开透明的，但实际上存在一些充满神秘感的隐藏通道，通过这些通道，用户可以免费访问和享受各类成品网站的资源。

       通常，这些通道通过技术手段将成品网站的入口隐藏，需要用户通过特定的方法和工具才能找到。而这些方法和工具往往是非常巧妙的，不为大众所熟知。通过这些隐藏通道，用户可以绕过正常的访问渠道，直接进入成品网站，免费获取各种资源。

       然而，物体的识别 源码虽然这些隐藏通道为用户提供了便利，但也存在一些潜在的风险。一方面，这些通道的稳定性并不总是可靠，可能会受到限制。另一方面，一些隐藏通道可能被利用，因此，使用这些通道的用户需要谨慎对待，确保自己的网络安全。

常见的Web源码泄漏及其利用

       Web源码泄漏漏洞及利用方法

       Git源码泄露是由于在执行git init初始化目录时，会在当前目录下自动创建一个.git目录，用于记录代码变更等信息。若未将.git目录删除即发布到服务器，攻击者可通过此目录恢复源代码。修复建议：删除.git目录或修改中间件配置以隐藏.git隐藏文件夹。

       SVN源码泄露源于其使用过程中自动生成的.svn隐藏文件夹，包含重要源代码信息。若网站管理员直接复制代码文件夹至WEB服务器，暴露.svn隐藏文件夹，攻击者可利用.svn/entries文件获取服务器源码。修复方法：删除web目录中的所有.svn隐藏文件夹，严格使用SVN导出功能，避免直接复制代码。

       Mercurial（hg）源码泄露通过生成的.hg文件暴露，漏洞利用工具为dvcs-ripper。运行示例需具体说明。

       CVS泄露主要针对CVS/Root和CVS/Entries目录，直接暴露泄露信息。pcre源码包下载修复工具为dvcs-ripper，运行示例同样需具体说明。

       Bazaar/bzr泄露为版本控制工具泄露问题，因其不常见但多平台支持，同样存在通过特定目录暴露源码的风险。具体修复方法与运行示例需进一步说明。

       网站备份压缩文件泄露是管理员将备份文件直接存放于Web目录，攻击者通过猜测文件路径下载，导致源代码泄露。常见备份文件后缀需具体列出，利用工具御剑用于这类漏洞的利用。

       WEB-INF/web.xml泄露暴露了Java WEB应用的安全目录，若直接访问其中文件需通过web.xml文件映射。WEB-INF目录主要包括文件或目录，通过web.xml文件推断类文件路径，最后直接访问类文件，通过反编译得到网站源码。

       .DS_Store文件泄露源于Mac系统中Finder保存文件展示数据的文件，每个文件夹下对应一个。若上传部署到服务器，可能造成文件目录结构泄漏，特别是备份文件、源代码文件的泄露。利用工具为github.com/lijiejie/ds_...

       SWP文件泄露为编辑文件时产生的临时文件，是隐藏文件，若程序意外退出则保留。直接访问并下载.swp文件，删除末尾的.swp后，可获得源码文件。

       GitHub源码泄露通过关键词搜索功能，容易找到目标站点的敏感信息，甚至下载网站源码。此类泄露源自代码托管平台，需注意个人代码管理安全。

       总结，Web源码泄漏涉及多个环节，从代码版本控制到备份存储，再到代码托管平台，每个环节都可能成为攻击点。修复策略包括删除隐藏文件、严格使用版本控制功能、加强代码备份安全措施以及提高代码托管平台安全意识。

如何应对源码泄密风险问题

       面对源码泄密的风险，企业采取了多种策略。首先，一些单位试图通过物理手段如禁用光驱和软驱、封锁USB接口，甚至限制员工的网络访问来阻止信息泄露。他们还倾向于安装监控软件，以监控员工行为，然而，这些做法往往带来诸多问题。它们降低了工作效率，可能导致员工不满，甚至触犯法律，因为它们牺牲了工作便利性，并不能完全阻止内部的恶意泄密行为，反而可能让员工产生反感。

       实践中，这些方法的效果并不理想，主要存在几个问题：首先，严格的限制措施容易引发员工情绪紧张，甚至引发法律纠纷；其次，它们增加了企业的运营成本，降低了整体工作效率；此外，对于关键的软件研发人员，这些措施可能无法有效防止他们有意或无意的泄密；最后，企业往往把大量精力集中在事后的追责和补救上，而非源头预防。

       因此，为了更有效地应对源码泄密风险，企业需要寻找更为平衡和智能的解决方案，既要保护代码安全，又要兼顾员工的工作环境和权益，实现真正的预防与管理相结合。

安全风险是指什么

       在上一篇文章十大 CI/CD 安全风险（二），我们了解了依赖链滥用和基于流水线的访问控制不足这两大安全风险，并给出缓解风险的安全建议。本篇文章将着重介绍 PPE 风险，并提供缓解相关风险的安全建议与实践。

       Poisoned Pipeline Execution (PPE) 风险指的是攻击者能够访问源代码控制系统，但无法访问构建环境，通过将恶意代码/命令注入构建流水线配置来操纵构建过程，本质上是“中毒的”流水线和运行恶意代码作为构建过程的一部分。

       PPE 风险通常存在代码仓库中，可控对应的 CI 管道配置文件，通过修改 CI 配置文件达到执行对应命令的目的。有权操作 CI 配置文件或 CI 流水线任务所依赖的其他文件的攻击者，可以将恶意命令置入这些文件，通过执行这些恶意命令，最终“毒化”执行这些命令的 CI 流水线。执行未经审查的代码的流水线，比如一些直接由拉取请求或提交到任意存储库分支触发的流水线，由于在设计上包含未经任何审查或批准的代码，更容易受到 PPE 风险的影响。一旦能够在 CI 流水线中执行恶意代码，攻击者就可以在流水线身份的上下文中进行各种恶意操作。

       直接 PPE（D-PPE）

       在 D-PPE 场景中，攻击者修改他们有权访问的存储库中的 CI 配置文件，通过直接将更改推送到存储库上未受保护的远程分支，在提交 PR 时随着分叉的更改而变化。由于 CI 流水线执行是由“push”或“PR”事件触发的，并且流水线执行是由修改后的 CI 配置文件中的命令定义的，一旦构建流水线被攻击，攻击者的恶意命令最终会在构建节点中运行触发。

       间接 PPE（I-PPE）

       在以下几种情况下，即便攻击者能够访问 SCM 存储库，也无法使用 D-PPE：

       在这几种情况下，攻击者就会选择向流水线配置文件引用的文件中注入恶意代码来破坏流水线：

       因此，在 I-PPE 中，不同于将恶意命令直接插入流水线定义文件来破坏流水线，攻击者通过将恶意代码注入到配置文件引用的文件中，一旦触发流水线并运行相关文件中声明的命令，恶意代码最终会在流水线节点上执行。

       公共 PPE（3PE）

       执行 PPE 攻击需要访问托管流水线配置文件的存储库或其引用的文件。大多数情况下，只有开发人员拥有此类许可，也就是说攻击者必须要获得开发工程师对存储库的许可和权限才能执行直接或间接 PPE 攻击。

       然而，在一些情况下，互联网上的匿名攻击者可以使用“中毒的” CI 流水线：公共存储库（例如开源项目）通常允许任何用户做出贡献，通过创建拉取请求，建议对代码进行更改。这些项目通常使用 CI 解决方案自动测试和构建，与私有项目类似。如果公共存储库的 CI 流水线运行匿名用户建议的未经审查的代码，它很容易受到公共 PPE 攻击，或者简称为 3PE。如果易受攻击的公共存储库的流水线在与私有存储库相同的 CI 实例上运行，这也会暴露例如私有项目的敏感信息这类的内部资产。

       通过 D-PPE (GitHub Actions) 窃取凭据

       在以下示例中，GitHub 存储库与 GitHub Actions 工作流程连接，该工作流程获取代码、构建代码、运行测试并最终将工件部署到 AWS。当新代码被推送到存储库中的远程分支时，代码（包括流水线配置文件）由运行程序（工作流节点）获取。

       在这种情况下，D-PPE 攻击将按如下方式进行：

       3. 流水线基于被攻击者“毒化”的配置文件运行。根据攻击者的恶意命令，存储为存储库机密的 AWS 凭证被加载到内存中。

       4. 流水线继续执行攻击者的命令，将 AWS 凭证发送到攻击者控制的服务器。

       5. 攻击者随后能够使用窃取的凭证访问 AWS 生产环境。

       通过 Indirect-PPE (Jenkins) 窃取凭证

       这个例子展示的是 Jenkins 流水线从存储库中获取代码、构建、运行测试并最终部署到 AWS。在此流水线中，Jenkinsfile 是受保护的，因为是从存储库中的主分支中获取的。因此，攻击者无法操纵构建定义，也无法获取存储在 Jenkins 凭证存储中的机密或在其他节点上运行任务。

       然而这并不代表流水线没有风险。在流水线的构建阶段，AWS 凭证作为环境变量加载，使其仅可用于在此阶段运行的命令。在下面的示例中，基于 Makefile 的内容（也存储在存储库中）的make命令作为此阶段的一部分运行。

       The Jenkinsfile：

       在这种情况下，I-PPE 攻击将按如下方式进行：

       在成功的 PPE 攻击中，攻击者在 CI 中执行未经审查的恶意代码。这为攻击者提供了与构建任务相同的能力和访问级别，包括：

       预防和缓解 PPE 攻击，涉及跨 SCM 和 CI 系统的多项措施：