描述

這會影響 Spring Data JPA，版本直到且包括 2.1.5、2.0.13 和 1.11.19。當提供惡意製作的查詢參數值時，使用任何謂詞 ‘startingWith’、‘endingWith’ 或 ‘containing’ 的衍生查詢可能會傳回比預期更多的結果。此外，如果綁定的參數值沒有正確逸出保留字元，則手動定義查詢中的 LIKE 運算式可能會傳回非預期的結果。

受影響的 Spring 產品和版本

• Spring Data JPA 2.0 到 2.0.13
• Spring Data JPA 2.1 到 2.1.5
• Spring Data JPA 1.11 到 1.11.19
• 較舊的不支援版本也會受到影響

緩解措施

受影響版本的用戶應套用以下緩解措施

• 2.1.x 用戶應升級至 2.1.6（包含在 <a href="https://spring.dev.org.tw/blog/2019/04/04/spring-boot-2-1-4-released">Spring Boot 2.1.4</a>）
• 2.0.x 用戶應升級至 2.0.14（包含在 <a href="https://spring.dev.org.tw/blog/2019/04/03/spring-boot-2-0-9-released">Spring Boot 2.0.9</a>）
• 1.11.x 用戶應升級至 1.11.20（包含在 <a href="https://spring.dev.org.tw/blog/2019/04/03/spring-boot-1-5-20-available-now">Spring Boot 1.5.20</a>）
• 較舊版本應升級至支援的分支
• 沒有其他必要的緩解步驟。請注意，對於目前的版本，Spring Data 和 Spring Boot 的 2.0 分支都已 EOL，我們強烈建議升級

貢獻

此問題由 Maruthi Adithya G 發現並負責地回報

描述

Spring Security 版本 4.2.x 早於 4.2.12、5.0.x 早於 5.0.12 和 5.1.x 早於 5.1.5，在使用 SecureRandomFactoryBean#setSeed 來配置 SecureRandom 實例時，包含不安全的隨機性漏洞。 為了受到影響，誠實的應用程式必須提供種子，並使產生的隨機材料可供攻擊者檢查。

受影響的 Spring 產品和版本

• Spring Security 4.2 到 4.2.11
• Spring Security 5.0 到 5.0.11
• Spring Security 5.1 到 5.1.4

緩解措施

受影響版本的用戶應套用以下緩解措施

• 4.2.x 用戶應升級至 4.2.12
• 5.0.x 用戶應升級至 5.0.12
• 5.1.x 用戶應升級至 5.1.5

貢獻

此問題由 Thijs Alkemade 發現並負責地回報。

歷史記錄

2019-04-02：發布初始漏洞報告。

描述

Spring Security OAuth，版本 2.3 早於 2.3.5，且 2.2 早於 2.2.4，且 2.1 早於 2.1.4，且 2.0 早於 2.0.17，且較舊的不支援版本可能容易受到開放重新導向器攻擊，該攻擊可能會洩漏授權碼。惡意使用者或攻擊者可以使用授權碼授予類型製作對授權端點的請求，並透過 "redirect_uri" 參數指定經過操縱的重新導向 URI。這可能會導致授權伺服器將資源所有者使用者代理程式重新導向到攻擊者控制下的 URI，並洩漏授權碼。

此漏洞暴露了滿足以下所有要求的應用程式

• 充當授權伺服器的角色（例如 @EnableAuthorizationServer）
• 在 AuthorizationEndpoint 中使用 DefaultRedirectResolver

此漏洞 不會 暴露以下應用程式

• 充當授權伺服器的角色，並使用 DefaultRedirectResolver 以外的其他 RedirectResolver 實作
• 僅充當資源伺服器的角色（例如 @EnableResourceServer）
• 僅充當用戶端的角色（例如 @EnableOAuthClient）

受影響的 Spring 產品和版本

• Spring Security OAuth 2.3 到 2.3.4
• Spring Security OAuth 2.2 到 2.2.3
• Spring Security OAuth 2.1 到 2.1.3
• Spring Security OAuth 2.0 到 2.0.16
• 較舊的不支援版本也會受到影響

緩解措施

受影響版本的用戶應套用以下緩解措施

• <strong>2.3.x</strong> 用戶應升級至 <strong>2.3.5</strong>
• <strong>2.2.x</strong> 用戶應升級至 <strong>2.2.4</strong>
• <strong>2.1.x</strong> 用戶應升級至 <strong>2.1.4</strong>
• <strong>2.0.x</strong> 用戶應升級至 <strong>2.0.17</strong>
• 較舊版本應升級至支援的分支

沒有其他必要的緩解步驟。

對於 Spring Boot 1.5.x 和 Spring IO Platform Cairo 的用戶，強烈建議將 spring-security-oauth 版本覆寫為包含 CVE 修補程式的最新版本。為了覆寫版本，您需要宣告/設定屬性 spring-security-oauth.version。

以下是 Spring Boot 1.5.x 用戶的說明。

若要使用 Maven 覆寫屬性，請在 pom 的 區段中宣告該屬性


2.0.17.RELEASE


若要使用 Gradle 覆寫屬性，請在 build.gradle 腳本中設定該值

ext['spring-security-oauth.version'] = '2.0.17.RELEASE'

或在 gradle.properties 中

spring-security-oauth.version=2.0.17.RELEASE

注意： 相同的指示適用於 Spring IO Platform Cairo 的用戶。但是，要指定的版本是 2.2.4.RELEASE。

貢獻

此問題由來自 dotloop 的 Dirk Koehler (github.com/phrinx) 發現並負責地回報。 特別感謝來自 NTT、NTT Comware、NTT DATA 的 Macchinetta Framework Development Team…

描述

Spring Integration（spring-integration-xml 和 spring-integration-ws 模組），版本 4.3.18、5.0.10、5.1.1 和較舊的不支援版本，在從不受信任的來源接收 XML 資料時，容易受到 XML 外部實體注入 (XXE) 的攻擊。

受影響的 Spring 產品和版本

• Spring Integration 版本 5.1.1、5.0.10、4.3.18 和更舊版本

緩解措施

受影響版本的用戶應套用以下緩解措施

• 將 spring-integration-ws、spring-integration-xml 升級到 4.3.19、5.0.11、5.1.2 或更高版本。
• Spring Integration 元件顯示此漏洞現在預設會停用參考簡報 [1] 中建議的功能，但允許使用者配置元件，如果可以從受信任的來源收到 XML，則可以啟用該功能。

參考文獻

• https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet

歷史記錄

2019-01-14：首次發布漏洞報告。

描述

Spring Web Services 的 2.4.3、3.0.4 版本，以及所有三個專案中較舊的不支援版本，在接收來自不受信任來源的 XML 資料時，容易受到 XML 外部實體注入 (XXE) 的攻擊。

受影響的 Spring 產品和版本

• Spring Web Services 2.4.3、3.0.4 及更舊版本

緩解措施

受影響版本的用戶應套用以下緩解措施

• 將 spring-ws、spring-xml JAR 升級到 2.4.4、3.0.6 或更高版本
• Spring Web Services 中存在此漏洞的元件，現在預設會停用參考指南 [1] 中建議的功能，但允許使用者設定元件，以便在從受信任來源接收 XML 時啟用該功能。

參考文獻

• https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet

歷史記錄

2019-01-14：首次發布漏洞報告。

描述

Spring Batch 的 3.0.9、4.0.1、4.1.0 版本，以及較舊的不支援版本，在接收來自不受信任來源的 XML 資料時，容易受到 XML 外部實體注入 (XXE) 的攻擊。

受影響的 Spring 產品和版本

• Spring Batch 3.0.9、4.0.1、4.1.0 及更舊版本

緩解措施

受影響版本的用戶應套用以下緩解措施

• 將 spring-batch JAR 升級到 3.0.10、4.0.2、4.1.1 或更高版本
• Spring Batch 中存在此漏洞的元件，現在預設會停用參考指南 [1] 中建議的功能，但允許使用者設定元件，以便在從受信任來源接收 XML 時啟用該功能。

參考文獻

• https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet

歷史記錄

2019-01-14：首次發布漏洞報告。

描述

Spring Security 5.1.x 版本，在 5.1.2 之前的版本，在 JWT 發行者驗證期間存在授權繞過漏洞。為了受到影響，誠實發行者和惡意使用者在簽署 JWT 時必須使用相同的私鑰。在這種情況下，惡意使用者可以使用惡意發行者 URL 製作簽署的 JWT，該 URL 可能被授予給誠實的發行者。

受影響的 Spring 產品和版本

• Spring Framework 5.1 到 5.1.1

緩解措施

受影響版本的用戶應套用以下緩解措施

• 5.1.x 使用者應升級到 5.1.2

沒有其他必要的緩解步驟。

貢獻

此問題由 Björn Bilger 發現並負責地報告。

參考文獻

• 範例 <a href='https://spring-docs.dev.org.tw/spring-security/site/docs/5.1.1.RELEASE/reference/htmlsingle/#oauth2resourceserver-minimalconfiguration'&gt;config&lt;/a> 啟用了簡單的資源伺服器。
• <a href='https://spring-docs.dev.org.tw/spring-security/site/docs/5.1.1.RELEASE/reference/htmlsingle/#oauth2resourceserver'&gt;Spring…

描述

Spring Framework 5.1 版本、5.0.x 版本（在 5.0.10 之前的版本）、4.3.x 版本（在 4.3.20 之前的版本），以及 4.2.x 分支上較舊的不支援版本，在使用 ResourceHttpRequestHandler 提供靜態資源時，或從 5.0 開始，當註解的控制器返回一個 org.springframework.core.io.Resource 時，都支援範圍請求。惡意使用者（或攻擊者）可以添加一個具有大量範圍、或具有重疊的寬範圍、或兩者的範圍標頭，以進行阻斷服務攻擊。

此漏洞會影響依賴 spring-webmvc 或 spring-webflux 的應用程式。此類應用程式還必須註冊以提供靜態資源（例如 JS、CSS、圖像等），或具有返回 org.springframework.core.io.Resource 的註解控制器。

依賴 spring-boot-starter-web 或 spring-boot-starter-webflux 的 Spring Boot 應用程式已準備好提供靜態資源，因此容易受到攻擊。

受影響的 Spring 產品和版本

• Spring Framework 5.1
• Spring Framework 5.0.0 到 5.0.9
• Spring Framework 4.3 到 4.3.19
• 還可以影響追溯到 4.2 的較舊的不支援版本

緩解措施

受影響版本的用戶應套用以下緩解措施

• 5.1 使用者應升級到 5.1.1
• 5.0.x 使用者應升級到 5.0.10
• 4.3.x 使用者應升級到 4.3.20
• 4.2.x 使用者應升級到受支援的分支。

無需其他緩解措施。

在評估影響時，請注意以下事項

• 版本 4.2 中引入了對 Range 請求的支援。因此，早於 4.2 的版本不受此問題的影響。
• 從註解控制器返回一個 org.springfamework.core.io.Resource 的支援是在 5.0 中引入的。因此，早於 5.0 的版本只能通過註冊來提供靜態資源而受到影響。

貢獻

此問題由 Aruba Threat Labs 的 Nicholas Starke 發現並負責地報告。

歷史記錄

2018-10-16：首次發布漏洞報告。

描述

Spring Security OAuth 的 2.3 版本（在 2.3.4 之前的版本）、2.2 版本（在 2.2.3 之前的版本）、2.1 版本（在 2.1.3 之前的版本）、2.0 版本（在 2.0.16 之前的版本）以及較舊的不支援版本，在特定條件下可能容易受到權限提升的影響。惡意使用者或攻擊者可以製作針對核准端點的請求，該請求可以修改先前保存的授權請求，並導致後續核准的權限提升。如果應用程式配置為使用宣告 AuthorizationRequest 作為控制器方法參數的自定義核准端點，則可能會發生這種情況。

此漏洞暴露了滿足以下所有要求的應用程式

• 充當授權伺服器的角色（例如 @EnableAuthorizationServer）
• 使用宣告 AuthorizationRequest 作為控制器方法參數的自定義核准端點

此漏洞不會暴露以下應用程式：

• 擔任授權伺服器的角色並使用預設核准端點
• 僅充當資源伺服器的角色（例如 @EnableResourceServer）
• 僅充當用戶端的角色（例如 @EnableOAuthClient）

受影響的 Spring 產品和版本

• Spring Security OAuth 2.3 到 2.3.3
• Spring Security OAuth 2.2 到 2.2.2
• Spring Security OAuth 2.1 到 2.1.2
• Spring Security OAuth 2.0 到 2.0.15
• 較舊的不支援版本也會受到影響

緩解措施

受影響版本的用戶應套用以下緩解措施

• 2.3.x 使用者應升級到 2.3.4
• 2.2.x 使用者應升級到 2.2.3
• 2.1.x 使用者應升級到 2.1.3
• 2.0.x 使用者應升級到 2.0.16
• 較舊版本應升級至支援的分支

不需要其他緩解措施。

貢獻

此問題由 Micro Focus 的 Alvaro Muñoz (@pwntester) 發現並負責地報告。

參考文獻

• Spring Security OAuth <a href="http://projects.spring.io/spring-security-oauth/docs/oauth2.html"&gt;documentation&lt;/a&gt;，請參閱“授權伺服器配置”部分
• 範例配置 <a href="https://github.com/spring-projects/spring-security-oauth/blob/master/tests/annotation/approval/src/main/java/demo/Application.java#L36"&gt;&lt;code&gt;@EnableAuthorizationServer&lt;/code&gt;&lt;/a…

描述

spring-amqp，1.x 版本（在 1.7.10 之前的版本）、2.x 版本（在 2.0.6 之前的版本）暴露了中間人攻擊漏洞。

Spring RabbitMQ Java 客戶端不執行主機名稱驗證。

這意味著只要其他主機的 SSL 憑證是受信任的，就會被盲目地接受。

要利用此漏洞，攻擊者必須在使用 Spring RabbitMQ Java 客戶端的 Java 應用程式和它連接的 RabbitMQ 伺服器之間執行中間人 (MITM) 攻擊。

TLS 通常保護使用者和系統免受 MITM 攻擊，但如果客戶端接受來自其他受信任主機的憑證，則無法做到這一點。

Spring AMQP 使用 RabbitMQ amqp-client java 庫與 RabbitMQ 進行通訊。

它使用 RabbitConnectionFactoryBean 來建立/配置連線工廠。

受影響的 Spring 產品和版本

• Spring-AMQP 1.7.10 和 2.0.6 之前的版本
• RabbitMQ amqp-client 4.8.0 和 5.4.0 之前的版本

緩解措施

受影響版本的用戶應套用以下緩解措施

• 升級到 1.7.10.RELEASE 或 2.0.6.RELEASE，並將 enableHostnameValidation 屬性設定為 true。分別將傳遞的 amqp-client 版本覆蓋為至少 4.8.0 和 5.4.0
• 即將推出的 2.1.0.RELEASE 將預設將該屬性設定為 true。
• 如果您直接使用 amqp-client 庫來建立連線工廠，請參閱其 javadocs 以取得 enableHostnameValidation() 方法。

貢獻

此問題由瑞士 Alphabot Security 的 Peter Stöckli 發現並負責地報告。

歷史記錄

2018-09-11：首次發布漏洞報告。