前言
城堡總是從內部攻破的。再強大的系統，也得通過人來控制。如果將入侵直接從人這個環節發起，那麼再堅固的防線，也都成爲擺設。
下面分享一個例子，利用應用倉庫，滲透到開發人員的系統中。
應用倉庫
應用倉庫對於開發人員再熟悉不過了。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 外，其他一些無需審覈的應用倉庫，都有可能出現釣魚項目的風險。
因此平時安裝時，得格外小心。忘記了名字的項目，必須查證後再安裝。
同時對於一些來路不明的項目，也謹慎嘗試。畢竟，安裝一個項目和直接打開一個應用程序其實是一樣的！