Spring Security有幾個區域，您定義的模式將針對傳入請求進行測試，以決定如何處理請求。 當`FilterChainProxy`決定應該傳遞請求的過濾器鏈以及`FilterSecurityInterceptor`何時決定哪些安全性約束適用于請求時，會發生這種情況。 在針對您定義的模式進行測試時，了解機制是什么以及使用什么URL值非常重要。 Servlet規范定義了`HttpServletRequest`的幾個屬性，這些屬性可以通過getter方法訪問，我們可能希望與之匹配。這些是`contextPath，servletPath，pathInfo和queryString`。 Spring Security只對保護應用程序中的路徑感興趣，因此將忽略`contextPath`。不幸的是，servlet規范沒有準確定義`servletPath和pathInfo`的值將包含在特定請求URI中的內容。例如，URL的每個路徑段可以包含參數，如RFC 2396 [8]中所定義。規范沒有明確說明這些是否應該包含在`servletPath和pathInfo`值中，并且不同servlet容器之間的行為也不同。存在這樣的危險：當應用程序部署在不從這些值中刪除路徑參數的容器中時，攻擊者可以將它們添加到請求的URL中，以使模式匹配成功或意外失敗。 [9]。傳入URL的其他變體也是可能的。例如，它可能包含路徑遍歷序列（如/../）或多個正斜杠（//），這也可能導致模式匹配失敗。一些容器在執行servlet映射之前將這些規范化，但其他容器則沒有。為了防止這些問題，`FilterChainProxy`使用`HttpFirewall`策略來檢查和包裝請求。默認情況下會自動拒絕未規范化的請求，并且會刪除路徑參數和重復斜杠以進行匹配。 [10]。因此，必須使用`FilterChainProxy`來管理安全過濾器鏈。請注意，`servletPath和pathInfo`值由容器解碼，因此您的應用程序不應包含任何包含分號的有效路徑，因為這些部分將被刪除以進行匹配。 如上所述，默認策略是使用Ant樣式路徑進行匹配，這可能是大多數用戶的最佳選擇。該策略在`AntPathRequestMatcher`類中實現，該類使用Spring的`AntPathMatcher`對連接的s`ervletPath和pathInfo`執行模式的不區分大小寫的匹配，忽略queryString。 如果由于某種原因，您需要更強大的匹配策略，則可以使用正則表達式。然后策略實現是`RegexRequestMatcher`。有關更多信息，請參閱此類的Javadoc。 實際上，我們建議您在服務層使用方法安全性，以控制對應用程序的訪問，而不是完全依賴于在Web應用程序級別定義的安全性約束。 URL發生變化，很難考慮應用程序可能支持的所有可能的URL以及如何操作請求。您應該嘗試限制自己使用一些簡單易懂的簡單螞蟻路徑。始終嘗試使用“默認拒絕”方法，其中您最后定義了一個全能通配符（/或）并拒絕訪問。 在服務層定義的安全性更強大，更難以繞過，因此您應該始終利用Spring Security的方法安全選項。 `HttpFirewall`還通過拒絕HTTP響應標頭中的新行字符來阻止HTTP響應拆分。 默認情況下使用`StrictHttpFirewall`。此實現拒絕看似惡意的請求。如果它對您的需求過于嚴格，那么您可以自定義拒絕的請求類型。但是，重要的是要知道這可以打開您的應用程序直至攻擊。例如，如果您希望利用Spring MVC的Matrix變量，可以在XML中使用以下配置： ~~~ <b:bean id="httpFirewall" class="org.springframework.security.web.firewall.StrictHttpFirewall" p:allowSemicolon="true"/> <http-firewall ref="httpFirewall"/> ~~~ java配置 ~~~ @Bean public StrictHttpFirewall httpFirewall() { StrictHttpFirewall firewall = new StrictHttpFirewall(); firewall.setAllowSemicolon(true); return firewall; } ~~~