當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

idea创建maven程序_使用Maven程序集创建漏洞评估工件

發布時間：2023/12/3 编程问答 31 豆豆

生活随笔收集整理的這篇文章主要介紹了 idea创建maven程序_使用Maven程序集创建漏洞评估工件小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

idea創建maven程序

本文將討論如何使用Maven程序集創建可提供給第三方漏洞評估站點（例如Veracode ）進行審查的工件。

錯誤的靜態分析與漏洞評估

在這一點上，每個人都知道findbug并認真使用它，對嗎？

對？

Findbugs使用靜態分析來查找錯誤。更準確地說，它使用靜態分析來查找可以通過靜態分析發現的錯誤。例如，我看到了一種常見的模式

public void foo(Object obj) {if (obj != null) {obj.doSomething();}// lots of obscuring codeobj.doSomethingElse() }

我們應該第二次檢查null嗎？我們需要第一次檢查嗎？我們應該從“ if”子句中返回嗎？

為什么我們還需要漏洞評估？

什么是漏洞評估？它與錯誤有何不同？

關鍵概念是，易受攻擊的代碼表面上沒有錯誤，但是仍然容易受到濫用以攻擊該網站或其用戶。

易受攻擊的代碼的一個示例是使用未經消毒的用戶提供的值。從事前端工作的任何人都應該了解凈化這些價值的重要性。

但是，當用戶提供的數據從前端傳遞出去時（例如，將其寫入數據庫時??）會發生什么？每個從數據庫中提取數據的人都知道它可能包含未經消毒的用戶提供的數據嗎？如何通過SQL注入將惡意數據放入數據庫？

用于漏洞評估的靜態分析與靜態分析很像，可以發現漏洞，而且要經過很多檢查。而findbug可能需要5分鐘才能運行Veracode，可能需要幾個小時！

（動態分析使這一步驟更進一步，并針對實時系統運行了測試。您可以使用集成測試來進行簡化版。）

漏洞評估工件

我們需要提供什么來進行漏洞評估？簡短的答案是三件事：

我們的編譯代碼（例如，java或scala）
我們的腳本代碼（例如，jsp）
遞歸依賴的每個jar文件

我們不需要提供我們的源代碼或資源。編譯后的代碼確實需要包括調試系統，這樣它才能給出有意義的錯誤消息- 僅知道包含79個類的庫中有19個缺陷不是很有幫助！

一個好的格式是包含以下內容的壓縮包：

我們的jar和wars在頂層，沒有版本號
我們在“ / lib”下的依賴，帶有版本號

版本號被剝離或保留用于跟蹤目的。我們的代碼在多次運行中具有連續性。我們的依賴關系可以隨時更改，并且除了版本號中明確指出的內容之外，沒有任何連續性。

我們的war文件應該從嵌入式jar中刪除，因為它們將出現在“ lib”目錄下。 “較厚”的戰爭文件只會增加上傳的工件的大小。

我們可以使用兩個Maven程序集描述符來構建它。

va-war.xml（漏洞評估皮包骨頭的戰爭）

第一個程序集創建一個精簡的.war文件。我不想稱它為一場皮包骨頭的戰爭，因為預期的目的有所不同，但它們有很多共同點。

如果您具有敏感信息或大量大型工件，則可以排除其他文件：

<excludes><exclude>**/*.jar</exclude><exclude>**/*.jks</exclude><exclude>**/*.p12</exclude><exclude>**/*.jpg</exclude><exclude>**/db.properties</exclude></excludes>

但是，您需要注意–您需要包含腳本編寫的所有內容，例如jsp文件或Velocity模板。

va-artifact.xml（漏洞評估工件）

第二個工件收集所有依賴項，并將戰爭簡化為一個壓縮包。我們的jar和wars在tarball的頂層，所有依賴項都在“ lib”目錄中。這使得區分工件和依賴關系變得容易。

<assemblyxmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/plugins/maven/assembly-plugin/assembly/1.1.2http://maven.apache.org/xsd/assembly-1.1.2.xsd"><id>va-artifact</id><formats><format>tar.gz</format></formats><includeBaseDirectory>false</includeBaseDirectory><dependencySets><dependencySet><includes><include>${project.groupId}:*:jar</include><include>${project.groupId}:*:va-war</include><include>${project.groupId}.**:*:jar</include></includes><excludes><exclude>${project.groupId}:*-properties</exclude><excludes><outputFileNameMapping>${artifact.artifactId}${dashClassifier?}.${artifact.extension}</outputFileNameMapping></dependencySet><dependencySet><outputDirectory>lib</outputDirectory><includes /><excludes><exclude>${project.groupId}:*</exclude><exclude>*.pom</exclude><exclude>javax.*:*</exclude><exclude>dom4j:*</exclude><exclude>jaxen:*</exclude><exclude>jdom:*</exclude><exclude>xml-apis:*</exclude></excludes></dependencySet></dependencySets> </assembly>

構建工件

匯編描述符只是故事的一半。我們仍然需要調用maven程序集，我們不想在每個構建中都這樣做。

這是配置文件的理想時間–我們僅在指定了特定配置文件時才會構建工件。

pom.xml用于戰爭模塊

對于war模塊，pom.xml文件的必要附加內容很少。我們需要調用程序集描述符，但是不需要顯式添加依賴項。

pom.xml用于頂級模塊

頂級模塊的pom.xml文件的必要附加操作更為復雜，尤其是在分發程序集是在子模塊而不是根模塊中創建時。在這種情況下，我們需要顯式添加對pom文件和lite war文件的依賴。如果不指定前者，則將丟失大多數依賴項；如果不指定后者，則將丟失.war文件。

<profiles><profile><id>vulnerability-assessment</id><build><plugins><plugin><artifactId>maven-assembly-plugin</artifactId><configuration><descriptors><descriptor>src/main/assembly/va-artifact.xml</descriptor></descriptors></configuration><executions><execution><id>make-assembly</id><phase>package</phase><goals><goal>single</goal></goals></execution></executions></plugin></plugins></build><dependencies><dependency><groupId>${project.groupId}</groupId><artifactId>parent</artifactId> <version>${project.version}</version><type>pom</type></dependency><dependency><groupId>${project.groupId}</groupId><artifactId>webapp-1</artifactId> <version>${project.version}</version><type>war</type><classifier>va-war</classifier></dependency><dependency><groupId>${project.groupId}</groupId><artifactId>webapp-1</artifactId> <version>${project.version}</version><type>pom</type></dependency><dependency><groupId>${project.groupId}</groupId><artifactId>webapp-2</artifactId> <version>${project.version}</version><type>war</type><classifier>va-war</classifier></dependency><dependency><groupId>${project.groupId}</groupId><artifactId>webapp-2</artifactId> <version>${project.version}</version><type>pom</type></dependency></dependencies></profile> </profiles>

一個小陷阱！

有一個小陷阱！在這種特定方法中。各個Web模塊可能依賴于公共庫的不同版本。沒有人希望這樣做，但是一旦項目達到一定規模，您就無法承受使所有模塊保持同步所需的時間和精力。

當我們在公共位置進行依賴關系解析時，此信息將丟失。

我不認為這是一個問題，原因有兩個。首先，我們可以以更細的粒度執行漏洞評估–本質上是在.war級別而不是.ear文件下進行分析。這保證了庫將匹配，但是如果我們有大量的Web模塊，則將極大地增加我們的工作量。

其次，我們的主要重點是代碼中的漏洞，而不是特定版本的第三方庫中的漏洞。這些庫為評估工具提供了重要的提示，但我們只希望對代碼進行完整的分析。如果有必要，我們總是可以對我們依賴的庫進行單獨的評估。

Jenkins Veracode插件

最后，我想指出的是，有一個用于Veracode分析的Jenkins插件： Veracode Scanner Plugin 。它可用于定期計劃掃描，因此當您最終記得在發布前幾天運行掃描時，不會發現數百個缺陷。

參考： Invariant Properties博客中的JCG合作伙伴 Bear Giles 使用Maven程序集創建漏洞評估工件。

翻譯自: https://www.javacodegeeks.com/2013/10/creating-vulnerability-assessment-artifacts-using-maven-assembly.html