前言
城堡總是從內部攻破的。再強大的系統，也得通過人來控制。如果將入侵直接從人這個環節發起，那麼再堅固的防線，也都成為擺設。
下面分享一個例子，利用應用倉庫，滲透到開發人員的系統中。
應用倉庫
應用倉庫對於開發人員再熟悉不過了。apt-get，brew，yum，npm … 無非就是個命令列版的 App Store，方便各種工具以及依賴庫的安裝。
他們大致原理都差不多。今天講解的是 NodeJS 應用倉庫 —— NPM 的安全試探。
NPM 平臺
如果 NodeJS 只能單機執行，那就和 WScript 差不多了。好在 NPM 平臺的出現，讓整個社群互動起來。
開發者可以通過 NPM 安裝需要的庫，使用者也可以通過它完成專案的安裝。以至於短短几年時間裡，數以萬計的 NodeJS 專案被髮布到 NPM 上，每天都有幾千萬次的下載量。如此大的使用者群體，是否會存在安全隱患？
倉庫篡改
最容易想到的，就是 NPM 賬號被盜。一旦密碼被洩露，攻擊者就可以釋出專案的新版本。正常使用者一旦更新，就安裝上了惡意指令碼程式。
不過，要獲取平臺賬號談何容易。而且活躍度高的專案被篡改，很快就會被發現。
倉庫釣魚
改人家的東西肯定不靠譜，那就只能用自己的。但自己憑空建立的專案是毫無人氣的，因此得設法引誘部分使用者過來。
攻擊者可以取一個和活躍專案差不多的名字。例如人氣很高的 uglify-js，可以山寨一個叫 uglifyjs 的李鬼。一旦使用者拼錯了單詞，就安裝上了冒牌的專案。
為了不讓使用者發現，可以直接克隆原版專案，讓使用者能和正常版本完全一樣的使用，很難發現其中的破綻。然後在某些隱蔽的模組裡做些手腳，一旦使用者執行了指令碼，其中的惡魔就釋放出來了！
相比傳統的惡意程式，NodeJS 這種興起不久、並且高度靈活的語言，防禦程式會少的多。
安裝時入侵
如果使用者發現裝錯了專案，還沒執行就解除安裝了，是否就無法入侵了？
事實上，NPM 提供了無比強大的功能，甚至可以在安裝時就能執行額外的命令。
在 scripts 欄位裡，可以定義各個階段的命令擴充套件。
例如 postinstall，即可在倉庫包安裝完成後執行。
這樣，只要使用者敲入 npm install xxx 時手一抖，系統就可能被入侵了。
這聽起來似乎有些天方夜譚。不過經測試，一個活躍專案的山寨版，每天也有幾十到上百的安裝量（誤裝量~）。雖然數量很少，還不到原版的一個零頭，但都是潛在的高質量使用者。
其中大多都是開發人員，一旦系統被控制，即可滲透到企業內網裡。
持續性入侵
一旦開發人員的系統被控制，產生的後果遠比想象中的嚴重。除了各種資訊被洩露外，還會有更恐怖的事。
以 uglify-js 為例，如果開發人員安裝了釣魚版本，那麼會出現什麼後果？
由於它本身就是一個類似編譯器的壓縮工具，把測試完畢的原始碼，轉成不可讀的黑盒程式 —— 這很有可能就是上線前的最後一步。如果這個環節被黑客操控，那麼即使已通過稽核的原始碼，也難逃魔掌了。
也許，釣魚工具會在壓縮後的指令碼里插入一段隱蔽的 XSS，開發者不仔細檢視很難發現。一旦指令碼被髮布，線上成千上萬的使用者就遭殃了。
攻擊者不費一兵一卒，直接從最源頭攻下這個堡壘。
當然，不僅僅可以感染 Web，其他客戶端的更有可能。一些很少關注的開源庫，或者標頭檔案程式碼，都可能是惡意程式碼的藏身之處。
釣魚推廣
畢竟手誤的使用者是有限的。為了能擴大感染量，不排除攻擊者會主動推廣自己的釣魚專案。
當然，這種推廣不會太明顯，旁人甚至根本完全感覺不到其中正真的意圖。
攻擊者可以轉載一些近期熱門的文章，然後將其中的演示地址替換成自己的釣魚專案。於是，前來圍觀的看客們就在毫無防備的情況下一試用，被悄悄控制了。
或者更加直接的，在論壇或社交圈裡推廣自己的專案，並配上一些亮瞎的文字和炫酷的圖片。於是一些好奇心強的人們，正好中了攻擊者的下懷。
總結
除了 NPM 外，其他一些無需稽核的應用倉庫，都有可能出現釣魚專案的風險。
因此平時安裝時，得格外小心。忘記了名字的專案，必須查證後再安裝。
同時對於一些來路不明的專案，也謹慎嘗試。畢竟，安裝一個專案和直接開啟一個應用程式其實是一樣的！