軟件供應鏈***（依賴關係混淆***）正在破壞你的系統安全

一位安全研究人員設法破壞了35家以上高科技公司的系統，這被稱爲一種新穎的軟件供應鏈***（依賴關係混淆***）。經過利用這種稱爲依賴性混淆或命名空間混淆的***方式，尤爲是npm Registry更容易受到供應鏈命名空間混淆的影響。

什麼是依賴關係混淆

咱們先來列舉一個例子：

想象一下，我說過，您正在從事一個很是祕密的項目，名爲Secret Almo。組件座標爲org.acme：secret-almo：1.0，而且您不但願競爭對手知道它。可是，若是您的一位同事不當心將org.acme：secret-almo：1.1或任何不存在的版本添加爲該庫的依賴項，並運行了構建該怎麼辦？這是將要發生的事情：

 

l 請求到達私服的組倉庫（group），首先檢查本地資源庫。若是您的同事沒有犯錯而且使用1.0做爲版本，則解決方案將在那裏中止，而且將檢索到正確的工件。可是找不到1.1，所以公司的依賴私服會繼續尋找。

l 私服會一對一地查看做爲組倉庫（group）一部分的遠程存儲庫（proxy），將包含您的祕密項目名稱的URL請求發送到外部第三方存儲庫！

在這種狀況下，依賴性混淆指的是您的開發環境沒法區分軟件構建中依賴的組件是內部私有建立的程序包，仍是公用軟件存儲庫中同名的程序包。

如何利用依賴關係混淆進行***呢

咱們繼續舉個例子：

讓咱們回到上一個場景，有關Secret Almo的工做仍在進行中。讓咱們看一下項目的另外一個組件， almo-common-utils，它是用Node編寫的，是web應用程序的全部依賴組件中一部分。而私服組倉庫（group），包括代理一組遠程倉庫（代理npm官方註冊表），本地（用於內部共享模塊）。

考慮如下：

1. npm Registry是一個集市。任何人都能夠在上面發佈一個未知範圍NPM組件，並隨心所欲的調用，即「almo-common-utils」。

2. npm註冊表中沒有名爲「 almo-common-utils 」的軟件包（好吧，由於它是一個內部公司庫），所以沒有名稱衝突。

3. 大多數npm依賴項都使用版本範圍聲明來請求最新的兼容版本。

***者想要***不受保護的組織的惟一信息是almo-common-utils的存在，使用中的該庫的主要版本（假設他們知道版本3在組織中被普遍使用），而且知道其中的源代碼。

他們能夠克隆和修改源代碼，將任何惡意軟件嵌入其中，但仍保持與原始代碼的兼容性，並將其做爲secret-almo：3.99.99 上載到npm Registry，沒有人能阻止它們這麼作。

如今讓咱們看看當請求secret-almo：^ 3.0.0時私服的工做模式：

1. 在本地存儲庫中尋找最新的兼容機密Almo。發現3.2.4。

2. 在npm-registry代理遠程存儲庫中查找最新的兼容secret-almo。發現3.99.99。

3. 來自npm註冊表的虛假secret-almo獲勝，供應鏈被劫持。

 

如何解決依賴混淆***呢

使用Artifactory，在您的遠程存儲庫上使用排除模式！

您知道在npm Registry中永遠找不到almo-common-utils的方法嗎？告訴你的倉庫管理員！在排除模式中添加您的私有依賴項，並保護本身免受嚴重供應鏈***。如此簡單，以致於幾乎能夠忽略不計。

 

同時也能夠在本地倉庫中排除掉第三方組件的座標，避免內部私人串改第三方的可信版本