當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

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

發(fā)布時(shí)間：2023/12/3 编程问答 49 豆豆

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

idea創(chuàng)建maven程序

本文將討論如何使用Maven程序集創(chuàng)建可提供給第三方漏洞評(píng)估站點(diǎn)（例如Veracode ）進(jìn)行審查的工件。

錯(cuò)誤的靜態(tài)分析與漏洞評(píng)估

在這一點(diǎn)上，每個(gè)人都知道findbug并認(rèn)真使用它，對(duì)嗎？

對(duì)？

Findbugs使用靜態(tài)分析來查找錯(cuò)誤。更準(zhǔn)確地說，它使用靜態(tài)分析來查找可以通過靜態(tài)分析發(fā)現(xiàn)的錯(cuò)誤。例如，我看到了一種常見的模式

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

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

為什么我們還需要漏洞評(píng)估？

什么是漏洞評(píng)估？它與錯(cuò)誤有何不同？

關(guān)鍵概念是，易受攻擊的代碼表面上沒有錯(cuò)誤，但是仍然容易受到濫用以攻擊該網(wǎng)站或其用戶。

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

但是，當(dāng)用戶提供的數(shù)據(jù)從前端傳遞出去時(shí)（例如，將其寫入數(shù)據(jù)庫(kù)時(shí)??）會(huì)發(fā)生什么？每個(gè)從數(shù)據(jù)庫(kù)中提取數(shù)據(jù)的人都知道它可能包含未經(jīng)消毒的用戶提供的數(shù)據(jù)嗎？如何通過SQL注入將惡意數(shù)據(jù)放入數(shù)據(jù)庫(kù)？

用于漏洞評(píng)估的靜態(tài)分析與靜態(tài)分析很像，可以發(fā)現(xiàn)漏洞，而且要經(jīng)過很多檢查。而findbug可能需要5分鐘才能運(yùn)行Veracode，可能需要幾個(gè)小時(shí)！

（動(dòng)態(tài)分析使這一步驟更進(jìn)一步，并針對(duì)實(shí)時(shí)系統(tǒng)運(yùn)行了測(cè)試。您可以使用集成測(cè)試來進(jìn)行簡(jiǎn)化版。）

漏洞評(píng)估工件

我們需要提供什么來進(jìn)行漏洞評(píng)估？簡(jiǎn)短的答案是三件事：

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

我們不需要提供我們的源代碼或資源。編譯后的代碼確實(shí)需要包括調(diào)試系統(tǒng)，這樣它才能給出有意義的錯(cuò)誤消息- 僅知道包含79個(gè)類的庫(kù)中有19個(gè)缺陷不是很有幫助！

一個(gè)好的格式是包含以下內(nèi)容的壓縮包：

我們的jar和wars在頂層，沒有版本號(hào)
我們?cè)凇?/ lib”下的依賴，帶有版本號(hào)

版本號(hào)被剝離或保留用于跟蹤目的。我們的代碼在多次運(yùn)行中具有連續(xù)性。我們的依賴關(guān)系可以隨時(shí)更改，并且除了版本號(hào)中明確指出的內(nèi)容之外，沒有任何連續(xù)性。

我們的war文件應(yīng)該從嵌入式j(luò)ar中刪除，因?yàn)樗鼈儗⒊霈F(xiàn)在“ lib”目錄下。 “較厚”的戰(zhàn)爭(zhēng)文件只會(huì)增加上傳的工件的大小。

我們可以使用兩個(gè)Maven程序集描述符來構(gòu)建它。

va-war.xml（漏洞評(píng)估皮包骨頭的戰(zhàn)爭(zhēng)）

第一個(gè)程序集創(chuàng)建一個(gè)精簡(jiǎn)的.war文件。我不想稱它為一場(chǎng)皮包骨頭的戰(zhàn)爭(zhēng)，因?yàn)轭A(yù)期的目的有所不同，但它們有很多共同點(diǎn)。

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

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

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

va-artifact.xml（漏洞評(píng)估工件）

第二個(gè)工件收集所有依賴項(xiàng)，并將戰(zhàn)爭(zhēng)簡(jiǎn)化為一個(gè)壓縮包。我們的jar和wars在tarball的頂層，所有依賴項(xiàng)都在“ lib”目錄中。這使得區(qū)分工件和依賴關(guān)系變得容易。

<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>

構(gòu)建工件

匯編描述符只是故事的一半。我們?nèi)匀恍枰{(diào)用maven程序集，我們不想在每個(gè)構(gòu)建中都這樣做。

這是配置文件的理想時(shí)間–我們僅在指定了特定配置文件時(shí)才會(huì)構(gòu)建工件。

pom.xml用于戰(zhàn)爭(zhēng)模塊

對(duì)于war模塊，pom.xml文件的必要附加內(nèi)容很少。我們需要調(diào)用程序集描述符，但是不需要顯式添加依賴項(xiàng)。

pom.xml用于頂級(jí)模塊

頂級(jí)模塊的pom.xml文件的必要附加操作更為復(fù)雜，尤其是在分發(fā)程序集是在子模塊而不是根模塊中創(chuàng)建時(shí)。在這種情況下，我們需要顯式添加對(duì)pom文件和lite war文件的依賴。如果不指定前者，則將丟失大多數(shù)依賴項(xiàng)；如果不指定后者，則將丟失.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>

一個(gè)小陷阱！

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

當(dāng)我們?cè)诠参恢眠M(jìn)行依賴關(guān)系解析時(shí)，此信息將丟失。

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

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

Jenkins Veracode插件

最后，我想指出的是，有一個(gè)用于Veracode分析的Jenkins插件： Veracode Scanner Plugin 。它可用于定期計(jì)劃掃描，因此當(dāng)您最終記得在發(fā)布前幾天運(yùn)行掃描時(shí)，不會(huì)發(fā)現(xiàn)數(shù)百個(gè)缺陷。

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

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