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

编程问答

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

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

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

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

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

在這一點(diǎn)上，每個(gè)人都知道findbug并虔誠地使用它，對嗎？

對？

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”子句中返回嗎？

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

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

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

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

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

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

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

漏洞評估的工件

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

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

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

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

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

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

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

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

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

第一個(gè)程序集創(chuàng)建一個(gè)精簡的.war文件。我不想稱它為一場皮包骨頭的戰(zhàn)爭，因?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（漏洞評估工件）

第二個(gè)工件收集所有依賴項(xiàng)，并將戰(zhà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í)間–只有指定了特定的配置文件，我們才會構(gòu)建工件。

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

對于war模塊，pom.xml文件的必要添加是適度的。我們需要調(diào)用程序集描述符，但不需要顯式添加依賴項(xiàng)。

pom.xml用于頂級模塊

頂級模塊的pom.xml文件的必要附加操作更為復(fù)雜，尤其是在分發(fā)程序集是在子模塊而不是根模塊中創(chuàng)建時(shí)。在這種情況下，我們需要顯式添加對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模塊可能依賴于公共庫的不同版本。沒有人希望這樣做，但是一旦項(xiàng)目達(dá)到一定規(guī)模，您就無法承受使所有模塊保持同步所需的時(shí)間和精力。

當(dāng)我們在公共位置進(jìn)行依賴關(guān)系解析時(shí)，此信息將丟失。

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

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

Jenkins Veracode插件

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

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

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

總結(jié)

以上是生活随笔為你收集整理的使用Maven程序集创建漏洞评估工件的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

上一篇：安卓手机服务器（安卓手机服务）
下一篇： Apache Camel –从头开始开发