Web服務器上“不小心”留下的隱藏目錄和文件可能是非常有價值的敏感信息來源。在Web應用程序根文件夾下面，可能隱藏着大量的寶貴信息，例如源代碼版本系統文件夾和文件(.git、.gitignore和.svn)、項目配置文件(.npmrc、Package.json以及.htaccess)、具有常見擴展名的自定義配置文件（如config.json、config.yml、config.xml等）。
一般而言，這些資源可分為如下所示的幾種類型:
- 源代碼版本控制系統
- IDE (集成開發環境)配置文件
- 特定於項目和/或技術的配置和設置文件
下面，我們將對其展開深入的介紹——在哪里可以找到它們，以及可以預期得到什么樣的信息。
源代碼版本控制系統
Git
Git是“(…)一個免費的開源分布式版本控制系統，旨在以快速和高效的方式處理各種規模的項目”。GitHub.com是目前最流行的源代碼版本控制系統之一，尤其是在開放源碼領域。此外，許多公司也會使用自己的GitLab以及GitHub Enterprise或BitBucket。
Git對象的基本信息
新創建的Git存儲庫包含一些默認的文件夾和文件，用於存儲所有的相關信息。下圖展示的是sample.git文件夾，其中已經完成了一次提交:
.git文件夾的基本結構
讓我們從攻擊者的角度來研究一番。Git存儲庫的內容都是以對象的形式來管理的，它們都被存儲在.git/objects文件夾中。
對象可以是以下三種類型之一：commit、tree和blob。
其中，Commit類型的對象存放的是提交操作方面的信息，具有當前tree（文件夾和文件結構）對象的哈希值。
Tree類型的對象用來存放文件夾和文件結構的信息——每個文件夾或文件都有自己的對象哈希值，它們都存儲在tree對象中。因此，它可能存放的是另一棵樹（文件夾，在文件夾結構中的下一級中）或文件的信息。
Blob是保存文件內容的Git對象類型。換句話說，如果您知道特定文件的對象哈希值，則可以使用git cat-file命令來讀取該文件的內容。
當您在Web服務器上找到.git文件夾時，可以通過一種簡單的方法來獲取任意文件的內容，這時，只需下載和讀取git對象。有時候，如果你足夠幸運，可以嘗試使用標准git clone命令克隆存儲庫，或者只運行帶有-r選項的wget命令，以遞歸方式下載所有.git文件夾。但由於某些原因（例如沒有必需的憑證或缺少wget命令），這種方法並不總是可行的。下面，讓我們假設所有這些選項都是不可能的。
為了確定.git文件夾可用，只需檢查是否收到HTTP 403響應（或類似的響應，但不是404，因為這意味着該服務器或該位置沒有.git文件夾）：
403響應表明服務器上存在.git文件夾
使用本地Git存儲庫反射遠程文件和文件夾
為此，我們必須創建自己的、具有框架文件夾結構的本地“dummy”.git存儲庫，並從遠程服務器下載Git對象。
首先，創建dummy Git文件夾：
$ git init
該命令將使用所有必需的文件和文件夾初始化空的Git存儲庫。
檢索和讀取有關對象的信息
要開始從Git存儲庫中檢索信息，首先必須找到出發點。Git將所有信息都保存在日志文件中，該文件位於.git/logs/head下面。
.git/logs/head示例文件中的內容
如果.git/logs/head無法正常使用，同時.git返回Forbidden 403的話，這意味着它就在該位置，請嘗試.git/logs/HEAD。
下圖展示的是這個文件的示例行:
0000000000000000000000000000000000000000 07603070376d63d911f608120eb4b5489b507692
bloorq@gmail.com <bloorq@gmail.com> 1452195279 +0000 commit (initial): index.php initial commit
前兩個字符串是（上次和當前提交的）對象哈希值——這正是我們要尋找的。因為這是第一次提交，所以，第一個哈希值只包含0（因為很明顯，之前還沒有提交過），第二個哈希值包含的是當前提交的相關信息。
首先，我們必須創建對象的有效路徑。該路徑包含到存儲庫中所有對象的公共路徑，即.git/objects，后面還跟有通過哈希值構建的兩部分，一個是目錄名（哈希值的前兩個字符），另一個是文件名（哈希值的其余部分，從第三個字符開始）。因此，要獲得哈希值為07603070376D63D911F608120EB4B5489B507692的對象，應嘗試打開以下URL:
localhost/testapp/.git/objects/07/603070376d63d911f608120eb4b5489b507692
這時，將彈出文件下載窗口:
請記住——您必須將該文件保存在之前創建的dummy Git文件夾中——這是能夠讀取Git對象內容的最簡單方法，因為默認情況下，Git（程序）將在那里查找它們。因此，請確保將其保存在如下完全相同的位置:
path-to-your-dummy-git-repository/.git/objects/07/603070376d63d911f608120eb4b5489b507692
現在，git cat-file應該是您最得力的助手了。為了檢查對象的類型，可以使用以下命令:
$ git cat-file -t <hash>
為了顯示對象的內容，可以使用如下所示的命令:
$ git cat-file -p <hash>
現在，我們可以檢查以前保存的對象的類型並讀取其內容了（我是在本地主機上創建的存儲庫中執行的該操作，但是對於任何Git存儲庫，您在計算機上都會得到完全相同的結果——只有哈希值會有所不同）。
當您查看提交描述時，您可以找到有關實際tree對象哈希值的信息——正如我前面提到的，tree對象中存放了當前文件夾結構（更准確地說:完成提交時的文件夾結構）的信息。使用上面的方法，可以看到:
正如您所看到的，目前只有一個文件，即index.php，而且，我們還知道它的對象哈希值和類型，即blob。這就是我們需要使用與以前讀取commit對象和tree對象的內容相同的方法來查看文件內容的原因（首先，您必須從Web服務器下載該對象，具體如上所述）:
看到了吧！
需要注意的是，這是index.php的內容，正如對象07603070376D63D911F608120EB4B5489B507692所描述的提交信息那樣。如果查看日志文件，可以看到有第二次提交（由對象哈希值4db7a14eee2cd3ff529278b75e1653e677fe1d02可以看出），最后一次提交時，它包含了所有最后的更改，難道index.php的內容與我們到目前為止看到的有所不同？
執行相關的步驟（讀取提交內容以查找tree對象的哈希值，然后讀取tree對象以查找index.php的哈希值等）后，我們將看到index.php的實際內容:
bl4de on Rafals-MacBook in /Library/WebServer/Documents/testapp $ git cat-file -p a4215057b6545240452087ad4d015bf9b5b817c5
<?php
echo "Hello testapp!"; $i = 100; echo "Value of i is $i"; bl4de on Rafals-MacBook in /Library/WebServer/Documents/testapp $
因為手動對象檢索的效率不高，而且非常耗時，所以，我用Python創建了一個簡單的控制台工具來自動化這個過程，具體代碼可以從這里下載。
.gitignore文件
如果我們發現Web服務器上的.git文件夾被刪除了，那么，我們不妨看看.gitignore文件。這個文件的用途很單純——保存不應該提交到存儲庫中的那些文件夾和文件的名稱（但這並不意味着它們不存在——它們只是不作為Git存儲庫的一部分存在而已）。因此，這是找到所有無法以上述方式“透露”的內容的最簡單的方法。
gitignore文件表明存在一些讓人感興趣的文件和文件夾。
Subversion (SVN)
Subversion（或SVN）是Apache Software Foundation創建的源代碼版本控制系統，到目前為止，它仍然非常流行，並且具有廣泛的應用，特別是在擁有大量遺留代碼庫的企業環境中。
SVN文件夾和文件的示例結構如下所示:
含有svn存儲庫的示例.svn文件夾
在我們看來，最重要的是SQLite數據庫的wc.db文件以及pristine/目錄中的內容。在wc.db中，我們能夠找到用於pristine/目錄中的文件名的哈希值，因此，我們必須從這個文件開始入手。
要從Subversion獲取信息，我們首先需要確保wc.db文件可用。為此，我們可以嘗試在Web瀏覽器中打開以下路徑：
http://server/path_to_vulnerable_site/.svn/wc.db
如果出現彈出式的下載窗口，則意味着其余的.svn文件都有可能存在。首先，我們需要閱讀wc.db的內容以獲取有關文件的哈希值信息（這里沒有.logs目錄，就像上面描述的Git倉庫一樣）。
為了閱讀wc.db的內容，我們可以借助於SQLite控制台客戶端（或任何其他管理SQLite數據庫的工具）：
$ sqlite3 wc.db
SQLite version 3.8.10.2 2015-05-20 18:17:19 Enter ".help" for usage hints. sqlite> .databases seq name file --- --------------- ---------------------------------------------------------- 0 main /Users/bl4de/hacking/playground/wc.db sqlite> .dump PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE REPOSITORY ( id INTEGER PRIMARY KEY AUTOINCREMENT, root TEXT UNIQUE NOT NULL, uuid TEXT NOT NULL ); INSERT INTO "REPOSITORY" VALUES(1,'svn+ssh://192.168.1.4/var/svn-repos/project_wombat','88dcec91-39c3-4b86-8627-702dd82cfa09'); (...) INSERT INTO "NODES" VALUES(1,'trunk',0,'',1,'trunk',1,'normal',NULL,NULL,'dir',X'2829','infinity',NULL,NULL,1,1456055578790922,'bl4de',NULL,NULL,NULL,NULL); INSERT INTO "NODES" VALUES(1,'',0,NULL,1,'',1,'normal',NULL,NULL,'dir',X'2829','infinity',NULL,NULL,1,1456055578790922,'bl4de',NULL,NULL,NULL,NULL); INSERT INTO "NODES" VALUES(1,'trunk/test.txt',0,'trunk',1,'trunk/test.txt',2,'normal',NULL,NULL,'file',X'2829',NULL,'$sha1$945a60e68acc693fcb74abadb588aac1a9135f62',NULL,2,1456056344886288,'bl4de',38,1456056261000000,NULL,NULL); INSERT INTO "NODES" VALUES(1,'trunk/test2.txt',0,'trunk',1,'trunk/test2.txt',3,'normal',NULL,NULL,'file',NULL,NULL,'$sha1$6f3fb98418f14f293f7ad55e2cc468ba692b23ce',NULL,3,1456056740296578,'bl4de',27,1456056696000000,NULL,NULL); (...)
看到針對NODES表的INSERT操作了嗎？ 其中，每個操作都包含文件名和SHA1哈希值，它們對應於pristine/文件夾中的相關條目：
$ ls -lA pristine/94/
total 8
-rw-r--r--@ 1 bl4de staff 38 Feb 21 12:05 945a60e68acc693fcb74abadb588aac1a9135f62.svn-base
要將NODES中的值映射為文件名，我們需要執行下列步驟：
- 刪除$sha1$前綴
- 添加.svn-base后綴
- 使用哈希值中的前兩個符號作為pristine/目錄中的文件夾名稱（在本例中為94）
- 創建完整路徑，在本示例中為：
http://server/path_to_vulnerable_site/.svn/pristine/94/945a60e68acc693fcb74abadb588aac1a9135f62.svn-base
當我們嘗試在瀏覽器中打開該路徑時，應該能夠直接在瀏覽器中下載文件或顯示其內容：
如何從.svn存儲庫中讀取特定文件內容
此外，REPOSITORIES表中的相關條目指向原始存儲庫路徑，即：
svn+ssh://192.168.1.4/var/svn-repos/project_wombat
這里有很多信息。實際上，在Web服務器上保留.svn文件夾是一個巨大的錯誤，因為這樣做非常危險，有可能導致Web應用程序源代碼被完全泄露。
IDE項目文件
許多開發人員使用的IDE（集成開發環境）有一個共同點——它們會將項目的設置和大量附加信息保存在自己的文件中，並且會為每個項目單獨創建相應的文件。如果該類文件夾還保留在Web服務器上，那么，這就是Web應用程序的另一個重要的信息來源。
下面，讓我們先考察一下JetBrains公司的各種產品（https://www.jetbrains.com/）。
JetBrains公司的IDE產品：IntelliJ IDEA、WebStorm、PHPStorm以及RubyMine
使用JetBrains產品開發的每個項目都會創建自己的隱藏目錄.idea/，該目錄中保存有當前項目、其文件、目錄和IDE設置的所有信息。
.idea JetBrains文件夾的示例內容
從安全研究人員的角度來看，其中一個文件非常有價值，它就是workspace.xml，其中包含許多有用的信息，例如用來枚舉應用程序的所有文件和文件夾、源版本控制系統信息以及其他信息。
我們將逐一考察這些信息：
<?xml version="1.0" encoding="UTF-8"?> (...) <component name="FileEditorManager"> <leaf> <file leaf-file-name="README.md" pinned="false" current-in-tab="false"> <entry file="file://$PROJECT_DIR$/README.md"> (...) </component> (...)
組件名稱為“FileEditorManager”的所有節點都包含全部的文件及其相對路徑（相對於該項目的根目錄）。簡單來說，這些就是將要在主項目文件夾中執行的Bash命令ls的XML包裝的產物:)
如果仔細查看每個組件節點，您將找到已使用的控件版本系統的信息，具體如下例所示：
<component name="Git.Settings"> <option name="UPDATE_TYPE" value="MERGE" /> <option name="RECENT_GIT_ROOT_PATH" value="$PROJECT_DIR$" /> </component>
此外，在組件名稱為"TaskManager"的節點中，還有關於提交操作以及在項目文件上執行的其他任務的相關信息：
(...) <task id="LOCAL-00211" summary="change WebSocket port to 1099"> <created>1436206418000</created> <option name="number" value="00211" /> <option name="project" value="LOCAL" /> <updated>1436206418000</updated> </task> (...)
另一個讓我們感興趣的東東就是變更的歷史記錄，它們都存儲在組件名稱為“ChangeListManager”的節點中：
<component name="ChangeListManager"> (...) <change type="DELETED" beforePath="$PROJECT_DIR$/chat/node_modules/socket.io/node_modules/socket.io-adapter/node_modules/debug/Makefile" afterPath="" /> (...) </component>
同時，還存儲在組件名稱為“editorHistoryManager”節點中：
(...)
<entry file="file://$PROJECT_DIR$/public_html/vendor/angular/angular.js"> <provider editor-type-id="text-editor" selected="true"> <state vertical-scroll-proportion="0.0"> <caret column="29" line="3233" selection-end-column="29" selection-end-line="3233" selection-start-column="29" selection-start-line="3233"> </caret></state> </provider> </entry>
(...)
如果開發人員曾經使用集成數據庫管理器來管理數據庫，那么，還會有另一個非常有趣的文件，即dataSources.ids，我們可以在其中找到數據庫結構、dataSource.xml、dataSources.xml、dataSources.local.xml和dbnavigator.xml包含的示例信息：
<database>
<name value="database_name" /> <description value="" /> <database-type value="MYSQL" /> <config-type value="BASIC" /> <database-version value="5.7" /> <driver-source value="BUILTIN" /> <driver-library value="" /> <driver value="" /> <host value="localhost" /> <port value="3306" /> <database value="mywebapp" /> <url-type value="DATABASE" /> <os-authentication value="false" /> <empty-password value="false" /> <user value="root" /> <password value="cm9vdA==" /> <!-- Base64 encoded --> </database>
甚至更多，比如dataSources.local.xml：
<?xml version="1.0" encoding="UTF-8"?> <project version="4"> <component name="dataSourceStorageLocal"> <data-source name="MySQL - mywebapp@localhost" uuid="8681098b-fc96-4258-8b4f-bfbd00012e2b"> <secret-storage>master_key</secret-storage> <user-name>root</user-name> <schema-pattern>mywebapp.*</schema-pattern> <default-schemas>mywebapp.*</default-schemas> </data-source> </component> </project>
當然，這一切都取決於項目本身，以及使用的IDE插件（如調試器、源版本控制或數據庫管理器）。通常，到處搜索一下還是非常值得的，並且要仔細考察每個組件節點。
如您所見，這是非常有趣的信息來源。我建議大家下載任意一款JetBrains IDE產品（該公司的所有產品幾乎都提供了為期30天的試用期——大家可以下載IntelliJ Idea社區版或PyCharm社區版並免費使用它們），然后創建示例項目，添加文件夾和文件，並嘗試Git或SVN管理操作，創建示例數據庫連接並使用數據庫管理器——然后深入考察.idea/文件夾，看看能夠從中找到哪些內容。
NetBeans IDE
NetBeans（https://netbeans.org/）是另一款非常流行的免費IDE，適用於Java、C/C++、PHP、HTML5和JavaScript等開發語言。目前，NetBeans隸屬於Oracle公司，它已經成為Java應用程序的官方IDE，自然是免費和開源的。
NetBeans會在項目的根文件夾中創建自己的文件夾，用以存放所有的項目設置信息；具體來說，這個根文件目錄為nbproject/。
雖然NetBeans並不像IntelliJ、PHPStorm或WebStorm那樣“不利索”，但我們仍然可以找到一些有趣的信息，這些信息在針對易受攻擊的Web應用程序中尋找特定的攻擊向量時可能會有所裨益。實際上，project.xml就是一個着手考察NetBeans項目配置的一個不錯的出發點。
示例.nbproject目錄的內容
其他配置文件
NodeJS/JavaScript特有的配置文件
如果您曾經使用過JavaScript來構建現代項目的話，那么可能會驚訝於該類應用程序的根文件夾中含有的 .json和.rc 文件的數量之多。
實際上，這里有很多這樣的配置文件，其中含有很多使用過的庫的相關信息。雖然有些目錄無法直接從瀏覽器中獲得，甚至無法被用於文件夾和文件枚舉的工具檢測到，但是，仍然有幾個目錄是無處不在的，例如NPM配置文件（package.json、package-lock.json），其中含有全部應用程序的依賴項；以及linters JavaScript的配置文件，比如eslint或jshint或Bower的包管理器bower.json，等等。
下面，讓我們來考察bower.json示例文件，其中存放有Bower的配置信息，以及Web應用程序（前端）中使用的包列表:
{
"name": "testapp", "version": "2.1.0", "authors": [ "Rafal 'bl4de' Janicki <email@gmail.com>" ], "description": "test application", "main": "index.html", "moduleType": [ "globals" ], "license": "MIT", "dependencies": { "angular": "1.4", "pure": "~0.5.0", "angular-route": "~1.2.26", "angular-ui-router": "~0.2.11", "angular-bootstrap-datetimepicker": "latest", "angular-translate": "~2.6.1" }, "devDependencies": {} }
從安全角度來看，更有趣的是Node.js或io.js后端應用之類的程序，即package.json。由於它提供了服務器端詳細的信息列表——使用的包，數據庫連接器，中間件組件等，所以，該文件可能含有大量與潛在易受攻擊軟件相關的高價值信息。
如果您可以從服務器下載package.json，則可以通過簡單的方法來識別應用程序使用的、可能存在漏洞的npm軟件包，具體如下所示：
- 確保安裝了NodeJS，其中npm的版本為6或更高
- 保存下載的package.json，並在保存目錄中運行以下命令：
$ npm install
- 完成上述操作后，您將獲得類似如下所示的信息：
audited 9307 packages in 8.417s found 9 vulnerabilities (4 low, 1 moderate, 4 high) run `npm audit fix` to fix them, or `npm audit` for details
- 現在，運行audit命令（當然，您可能需要先在npmjs.org網站上注冊一個帳戶才能執行該操作）：
$ npm audit
- 執行上述命令時，您將獲得一個報告，其中包含該工具所找到的所有安全漏洞：
$ npm audit
=== npm audit security report === # Run npm install gulp@4.0.0 to resolve 5 vulnerabilities SEMVER WARNING: Recommended action is a potentially breaking change ┌───────────────┬──────────────────────────────────────────────────────────────┐ │ High │ Regular Expression Denial of Service │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Package │ minimatch │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Dependency of │ gulp │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Path │ gulp > vinyl-fs > glob-stream > glob > minimatch │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ More info │ https://nodesecurity.io/advisories/118 │ └───────────────┴──────────────────────────────────────────────────────────────┘ (...more dtails about every vulnerability...) found 9 vulnerabilities (4 low, 1 moderate, 4 high) in 9307 scanned packages run `npm audit fix` to fix 1 of them. 6 vulnerabilities require semver-major dependency updates. 2 vulnerabilities require manual review. See the full report for details.
實際上，我們最好將該輸出保存到單獨的文件中，因為有時會在幾個NPM模塊中發現多達數百個已識別的弱點。最重要的是不要陷入“兔子洞”——其中一些安全問題更多的是理論上的漏洞，而不是可利用的漏洞，有些模塊甚至可能根本就沒有被項目所使用。
下面是一個示例包。JSON內容表明這里可能使用了MySQL數據庫，並且通過WebSockets進行了一些客戶機-服務器通信:
{
"name": "Test application server dependencies", "version": "1.0.0", "author": "bl4de", "dependencies": { "socket.io": "^1.3.5", "mysql": "^2.9.0" } }
這種信息能夠助我們快速意識到，嘗試常見的NoSQL注入可能不是最好的主意，因為應用程序使用的是標准的關系SQL數據庫，也許，我們應該嘗試檢查應用程序是否容易受到SQL注入攻擊。
此外，還有諸如.bowerrc、.eslintrc以及.jshintrc等文件。即使它們不包含非常敏感的信息，也總是有可能從中找到有關Web應用程序體系結構、使用的庫和/或框架方面的一些細節信息，甚至是注釋中的一些有價值的信息。如果我們在偵察階段發現了它們，還是值得研究一番的。
GitLab CI/CD .gitlab-ci.yml配置文件
當項目使用GitLab Continous Integration (GitLab CI/CD)時，項目根文件夾中會含有一個非常特殊且脆弱的文件：.gitlab-ci.yml。該文件可能包含大量非常敏感的信息：有關測試和構建過程的詳細信息，其中含有在此過程的每個步驟中執行的命令的詳細信息，以及其他方面的關鍵信息。
您可以在此處找到.gitlab-ci.yml文件的示例
Ruby on Rails database.yml文件
如果您足夠幸運的貨，則會發現這個文件是可讀的，那么，對於RoR（Ruby on Rails）應用程序來說，通常則意味着“game over”。它是主數據庫的配置文件，其中包含連接到數據庫所需的一切信息：用戶名、密碼以及其他配置方面的詳細信息。
macOS .DS_Store文件
對於macOS系統來說，它的一個特殊之處在於，有一個名為.DS_Store的文件。該文件是由macOS文件資源管理器Finder（但不僅限於它）創建的，並且經常被錯誤地提交到源版本控制存儲庫中。
使.DS_Store文件非常有用的原因在於，它們通常保存有關Finder窗口配置的信息，包括代表文件和文件夾的圖標的布局信息，這些圖標通常在特定Finder窗口中顯示，也就是說，我們獲得了該窗口中的文件和文件夾的名稱。如果您在Web服務器上找到了.DS_Store文件，則有可能在其中顯示這些信息，並允許您通過“枚舉”方式獲得無法以任何其他方式找到的資源。當然，我們需要確保所使用的Dirb、Dirbuster、wfuzz或任何其他工具的字典中包含.DS_Store這一條目。
示例.DS_Store文件。我們不僅可以找到config、LICENSE、loader或package.json文件，也可以找到node_modules/、pages/、utils/和wrappers/文件夾——NodeJS應用程序的典型結構。
.DS_Store文件的主要問題在於，它們使用了Apple特定格式，並且難以閱讀，盡管可以在網上找到解析內容的一些相關工具。描述這種格式的最佳資源之一（以及用於解析的Python庫）是由Sebastian Neef撰寫的Parsing the .DS_Store file format文章。
實際上，我們可以借助自己喜愛的工具，通過現成的字典來探索隱藏的文件夾和文件:)
最常用的查找隱藏文件夾和文件的方法之一是使用枚舉工具（例如Dirbuster、Dirb以及本人最喜歡的WFuzz，當然，這只是其中的幾個例子而已），其中的字典包含數十萬個最流行的文件夾和文件名、robots.txt公共條目等。不久前，我根據其他幾個在線字典自己打造了一個這樣的字典（例如:http://github.com/danielmessler/seclists，或:https://github.com/danielmessler/robotsdisallow，這里要特別感謝Daniel Miessler為我們維護這兩個優秀的存儲庫），同時，我自己還為其添加了幾個條目。
目前，這本字典包含大約80K個條目，我發現用它來對付典型的公共Web服務器時非常有效。如果您希望親自嘗試一下的話，可以自行下載該字典，並與您喜歡的工具結合使用。
需要提醒的是，永遠不要忘了檢查Web服務器上是否存在本文介紹的文件夾中描述的任何內容。公開的Git或SVN存儲庫簡直就是一個災難，因為它允許下載Web應用程序的源代碼，以及IntelliJ IDE項目配置文件夾。有時候，我們只需要找到這類資源，就能搞定整個Web應用程序（以及Web服務器本身）。
如果您有任何問題或反饋，請隨時通過Twitter與我聯系。