从.svn文件夹到完整源码一次真实的内部渗透测试复盘那是一个普通的周二下午我正在对某企业内网进行授权渗透测试。常规的端口扫描和目录爆破并没有带来太多惊喜直到我在一个看似普通的Web目录下发现了那个熟悉的文件夹——.svn。这个意外的发现最终演变成了一次完整的源码泄露事件甚至差点获得了SVN服务器的完整控制权。下面我将详细还原这次渗透过程的技术细节希望能给安全从业者带来一些启发。1. 初探.svn目录从蛛丝马迹到确定漏洞在渗透测试中最令人兴奋的莫过于发现那些被遗忘的宝藏。.svn文件夹就是这样一个存在——它是Subversion版本控制系统在本地工作副本中创建的隐藏目录通常包含大量敏感信息。我使用dirsearch工具扫描目标网站时意外发现了http://target.com/.svn/的可访问目录。提示现代SVN客户端(1.7)只在项目根目录创建单个.svn文件夹而旧版本(1.6及以下)会在每个子目录都生成.svn文件夹。确认漏洞存在的几个关键步骤初步验证访问/.svn/entries文件如果返回数字12基本可以确认漏洞存在版本判断旧版本SVN检查/.svn/text-base/目录下是否存在.svn-base文件新版本SVN检查/.svn/pristine/目录下的文件结构关键文件定位无论版本如何wc.db文件都是最重要的目标它包含了完整的版本控制信息# 使用curl快速验证.svn目录是否存在 curl -I http://target.com/.svn/ curl http://target.com/.svn/entries2. 深入wc.dbSQLite数据库中的秘密获取到wc.db文件后真正的技术挑战才开始。这个SQLite数据库文件包含了项目的完整元数据使用SQLiteStudio打开后几个关键表尤为值得关注表名关键字段获取的信息NODESlocal_relpath, repos_path, checksum源代码文件路径和内容哈希REPOSITORYroot, uuidSVN仓库根路径和唯一标识WC_LOCKlocked, lock_token锁定状态信息分析NODES表的实际操作-- 查询所有文件路径和对应的仓库路径 SELECT local_relpath, repos_path FROM NODES; -- 获取特定文件的校验和 SELECT checksum FROM NODES WHERE local_relpath src/main.js;通过这些查询我不仅获得了完整的项目文件结构还能通过校验和与pristine目录中的文件进行匹配从而重建源代码。3. 从源码泄露到SVN权限获取分析REPOSITORY表时一个更严重的问题浮出水面——这个表包含了SVN仓库的根URL和UUID。结合这些信息理论上可以直接访问SVN服务器如果未做IP限制尝试使用默认或弱密码认证获取完整的版本历史记录甚至提交恶意代码到仓库中实际操作中我使用以下方法验证了这种可能性# 使用svn命令行工具尝试连接 svn ls http://svn.internal.company.com/repos/project --username guest --password guest # 如果成功可以检出完整项目历史 svn checkout http://svn.internal.company.com/repos/project注意未经授权的SVN访问可能涉及法律问题本文所有操作均在授权测试环境中进行。4. 防御措施与最佳实践经历这次渗透后我为客户整理了以下防护建议服务器端防护在Web服务器配置中禁止访问.svn目录使用svn export而非svn checkout部署代码定期扫描并清理遗留的版本控制目录开发流程优化在CI/CD管道中加入敏感文件检查对SVN仓库实施严格的访问控制考虑使用.gitignore类似的机制排除敏感文件监控与响应监控异常的.svn目录访问建立源码泄露应急响应流程定期进行安全审计和渗透测试这次渗透测试最让我印象深刻的是一个看似微小的配置疏忽未清理.svn目录竟能导致整个代码库的泄露。在后续的代码审计中我们还在泄露的源代码中发现了多个高危漏洞包括硬编码的数据库凭证和未修复的已知漏洞。这再次证明了防御纵深的重要性——即使一个漏洞被利用也不应该导致整个系统的沦陷。