SVN是Subversion的簡稱，是一個開放源代碼的版本控制系統，相較於RCS、CVS，它采用了分支管理系統，它的設計目標就是取代CVS。互聯網上很多版本控制服務已從CVS遷移到Subversion。
很多網站都使用了svn版本控制系統，但是很多網站安全意識不足，導致svn殘留，因此我們可以使用這個工具來下載網站源碼。
一旦網站出現SVN漏洞，其危害遠比SQL注入等其它常見網站漏洞更為致命，因為黑客獲取到網站源代碼后，一方面是掠奪了網站的技術知識資產，另一方面，黑客還可通過源代碼分析其它安全漏洞，從而對網站服務器及用戶數據造成持續威脅。
更嚴重的問題在於，SVN產生的.svn目錄下還包含了以.svn-base結尾的源代碼文件副本(低版本SVN具體路徑為text-base目錄，高版本SVN為pristine目錄)，如果服務器沒有對此類后綴做解析，黑客則可以直接獲得文件源代碼。
一、.svn 目錄
使用svn checkout后，項目目錄下會生成隱藏的.svn文件夾（Linux上用ls命令看不到，要用ls -al命令）。
svn1.6及以前版本會在項目的每個文件夾下都生成一個.svn文件夾，里面包含了所有文件的備份，文件名為 .svn/text-base/文件名.svn-base
svn1.7及以后版本則只在項目根目錄生成一個.svn文件夾，里面的pristine文件夾里包含了整個項目的所有文件備份
下面我以svn1.7及之后版本為例，講解如何利用此漏洞下載整個網站源代碼
二、分析.svn目錄內容
我們看到的是一個名為 wc.db 的文件，用文本編輯器打開看到第一行有寫 SQLite format 3 ，可以知道，這是一個SQLite數據庫的文件，后面包含的信息，文本編輯器就先不看了。我們下載一個正經的SQLite查看軟件來慢慢看－－SQLite Studio 。
在軟件下載完之前，再看看此文件夾里的其他內容：
entries和format文件里面，只有個數字12，沒什么參考意義；wc.db-journal文件是空的，也沒什么價值；tmp目錄里面也是空的；
pristine里面內容就多了，一堆00~ff的文件夾，每個文件夾里有若干個 .svn-base文件；用文本編輯器打開看一下，有些文件是代碼，有些文件是亂碼（大概是圖片文件吧）。看來這個文件夾是整個項目文件的一份備份，只是一堆哈希過的文件名，似乎有點難下手啊。
畢竟是無規律的這一堆文件名，40位的哈希（36^40）這樣的暴力窮舉下載的話，即便是N多線程，時間成本上也是非常大的啊。而且得到是一堆無序文件，要整理成原來代碼項目的樣子，還得費好一陣功夫。
這樣看來，是不是說.svn漏洞利用的價值很少？然而非也，少年，還記得剛才說的 wc.db 文件嗎。現在SQLite Studio軟件應該下載好了，我們就打開看看這里有什么來頭吧
三、wc.db文件，有你想要的一切
用SQLiteStudio軟件打開 wc.db文件，我們看到 NODES 表，看到 local relpath欄 和 checksum欄，明白了嗎（滑稽.jpg）。checksum欄里的$sha1$后面的那串數字就是pristine文件夾里的那堆文件的文件名，pristine里的00~ff文件夾，其實是文件名的前兩位，而local relpath就是原始的文件名。
現在，我們根據這個 wc.db 的NODES表，遍歷這個表里的每一行，就可以下載到整個項目里的代碼了，而且還能得到對應的真實文件名，可謂豈不快哉？
（下面截圖為我自己的項目，僅作參考）
除了NODES表以外，還可以看到一個 REPOSITORY表，里面存儲了svn的項目路徑和 uuid，如果沒有做訪問IP限制的話，你可以直接使用此信息取得此項目的SVN權限（下載、提交等）…
四、漏洞修復
方案一、不要使用svn checkout和svn up更新服務器上的代碼，使用svn export（導出）功能代替。
方案二、服務器軟件（Nginx、apache、tomcat、IIS等）設置目錄權限，禁止訪問.svn目錄
不只svn，git或者其他版本管理軟件也存在類似的問題