2013-01-08 22 views
3

我想執行一個嚴格的Maven依賴策略,它超出了基本的checksumPolicy=fail方法。如何執行一個嚴格的Maven依賴策略(依賴鏈攻擊)

這是爲提供針對仍具有有效摘要值(也稱爲「依賴鏈攻擊」)的修改釋放依賴關係的保護。

這種情況可能由下列情況下出現:

  • 的依賴已經更新,但筆者一直沒有更新的版本號和管理,以覆蓋早期版本(或它們的回購帳戶已被盜用)
  • 一箇中間人攻擊到位(與即時重寫/哈希)
  • 庫本身已經失密

我n與其他開發人員的討論一種解決上述問題的方法是在pom.xml中有一個已知的MD5/SHA摘要列表,並讓Maven驗證下載的依賴關係具有相同的摘要。這確保了只要源代碼存儲庫保持安全,就會檢測到任何包含的已被入侵的依賴關係。

因此,我的問題是雙重的:

  1. 有什麼會更有效地工作的替代方法?
  2. 是否有任何現有的執行此插件?
+0

你知道你已經在maven倉庫中有校驗和(md5,sha1)嗎?如果其中一個校驗和不正確,只需更改settings.xml(checksumpolicy?)以使構建失敗。 – khmarbaise

+0

這不是關於校驗和不正確的 - 而是關於他們改變了。請仔細閱讀該問題。 –

+0

我看過這個問題。你在談論Maven Central嗎? – khmarbaise

回答

5

如果有人正在自己摔跤這個問題,我已經創建了一個Maven Enforcer Plugin規則來處理它。您可以指定包含預期SHA1散列值的工件URN列表,並讓執行者驗證這確實是構建中使用的內容。

它可以通過Maven的中央在MIT許可,並在GitHub的源代碼在這裏:https://github.com/gary-rowe/BitcoinjEnforcerRules

雖然該項目表明,它是爲Bitcoinj庫,它實際上是可以被包括在一個通用的解決方案任何安全意識的構建過程。它還將掃描您現有的項目並識別任何問題區域,同時爲您自動構建白名單。

下面是您在項目中需要使用的配置示例。

<build> 
    <plugins> 
    ... 
     <!-- Use the Enforcer to verify build integrity --> 
     <plugin> 
     <groupId>org.apache.maven.plugins</groupId> 
     <artifactId>maven-enforcer-plugin</artifactId> 
     <version>1.2</version> 
     <executions> 
      <execution> 
      <id>enforce</id> 
      <phase>verify</phase> 
      <goals> 
       <goal>enforce</goal> 
      </goals> 
      <configuration> 
       <rules> 
       <digestRule implementation="uk.co.froot.maven.enforcer.DigestRule"> 

        <!-- Create a snapshot to build the list of URNs below --> 
        <buildSnapshot>true</buildSnapshot> 

        <!-- List of required hashes --> 
        <!-- Format is URN of groupId:artifactId:version:type:classifier:scope:hash --> 
        <!-- classifier is "null" if not present --> 
        <urns> 

        <urn>antlr:antlr:2.7.7:jar:null:compile:83cd2cd674a217ade95a4bb83a8a14f351f48bd0</urn> 
        <urn>dom4j:dom4j:1.6.1:jar:null:compile:5d3ccc056b6f056dbf0dddfdf43894b9065a8f94</urn> 
        <urn>org.bouncycastle:bcprov-jdk15:1.46:jar:null:compile:d726ceb2dcc711ef066cc639c12d856128ea1ef1</urn> 
        <urn>org.hibernate.common:hibernate-commons-annotations:4.0.1.Final:jar:null:compile:78bcf608d997d0529be2f4f781fdc89e801c9e88</urn> 
        <urn>org.hibernate.javax.persistence:hibernate-jpa-2.0-api:1.0.1.Final:jar:null:compile:3306a165afa81938fc3d8a0948e891de9f6b192b</urn> 
        <urn>org.hibernate:hibernate-core:4.1.8.Final:jar:null:compile:82b420eaf9f34f94ed5295454b068e62a9a58320</urn> 
        <urn>org.hibernate:hibernate-entitymanager:4.1.8.Final:jar:null:compile:70a29cc959862b975647f9a03145274afb15fc3a</urn> 
        <urn>org.javassist:javassist:3.15.0-GA:jar:null:compile:79907309ca4bb4e5e51d4086cc4179b2611358d7</urn> 
        <urn>org.jboss.logging:jboss-logging:3.1.0.GA:jar:null:compile:c71f2856e7b60efe485db39b37a31811e6c84365</urn> 
        <urn>org.jboss.spec.javax.transaction:jboss-transaction-api_1.1_spec:1.0.0.Final:jar:null:compile:2ab6236535e085d86f37fd97ddfdd35c88c1a419</urn> 

        <!-- A check for the rules themselves --> 
        <urn>uk.co.froot.maven.enforcer:digest-enforcer-rules:0.0.1:jar:null:runtime:16a9e04f3fe4bb143c42782d07d5faf65b32106f</urn> 

        </urns> 

       </digestRule> 
       </rules> 
      </configuration> 
      </execution> 
     </executions> 

     <!-- Ensure we download the enforcer rules --> 
     <dependencies> 
      <dependency> 
      <groupId>uk.co.froot.maven.enforcer</groupId> 
      <artifactId>digest-enforcer-rules</artifactId> 
      <version>0.0.1</version> 
      </dependency> 
     </dependencies> 

     </plugin> 
    ... 
    </plugins> 
</build> 
2

聽起來像倉庫本身的好工作。看看這個其他thread關於類似的問題。

我對Nexus中的PGP簽名方案並不熟悉,但這聽起來像一個好的開始?

+0

我確實看了一下這個線程,看起來簽名JAR是一個很好的前進方向。不幸的是,我不能保證作者將簽署他們的JAR。另外,我更喜歡使用像Maven Central這樣的repo,並檢測變化,而不是依靠自己的內部回購,因爲這是一個開源項目。 –