3.四、路徑模式與後綴匹配

    這一部分是對 Spring 5 文檔的直接翻譯，鏈接是這個。這一部分的示例再也不貼代碼，請到這個項目的 mvc 分支下查看，本篇示例的控制器名稱是 PathPatternController。

---

1）路徑模式

    除了 URI 模板，註解 @RequestMapping 和全部的組合 @RequestMapping 變種也支持 Ant 式的路徑模式（例如：/myPath/*.do）。URI 模板變量和 Ant 式的標記組合使用也是支持的（例如：/owners/*/pets/{petId}）。

2）路徑模式比較

    當一個 URL 匹配多個模式時，會進行一次分類來尋找最佳匹配。

    擁有數量最少的 URI 變量和通配符的匹配的路徑模式被認爲是最佳匹配。好比「/hotels/{hotel}/*」有一個 URI 變量和一個通配符，而「/hotels/{hotel}/**」有一個URI變量和量個通配符，因此前者被認爲是最佳匹配。

    若是兩個模式有相同數量的通配符或URI變量，那麼最長的那個被認爲是最佳匹配。好比「/foo/bar*」比「/foo/*」長，因此前者是最佳匹配。

    若是兩個模式有相同數量的通配符或URI變量，且長度相同，那麼通配符最少的那個被認爲是最佳匹配。好比「/hotels/{hotel}」相對於「/hotels/*」是最佳匹配。

    還有一些額外的特殊規則：
    ① 默認的映射模式「/**」比任何其餘匹配模式的優先級都低。好比：「/api/{a}/{b}/{c}」的優先級高於「/**」
    ② 前綴模式好比「/public/**」的優先級低於任何其餘的不包含雙通配符的模式。好比「/public/path3/{a}/{b}/{c}」的優先級更高。
    所有的詳細信息參見AntPathMatcher中的AntPatternComparator。注意，PathMatcher能夠自定義（見「路徑匹配」）。

3）帶有佔位符的路徑模式

    註解 @RequestMapping 中的模式支持對本地屬性和/或系統屬性與環境變量使用${…​}佔位符。這在控制器映射到的路徑須要經過配置文件自定義的情形下會頗有用。佔位符的更多信息，能夠去類 PropertyPlaceholderConfigurer的 Javadoc 中查看。

4）後綴模式匹配

    Spring MVC 默認執行「.*」後綴匹配，因此一個映射到「/person」的控制器隱式地映射到「/person.*」。這讓請求經過URL路徑（好比/person.pdf，/person.xml）來獲取資源很簡單。

    後綴模式匹配能夠被關閉，或者把它限制到一組顯式註冊爲協商好內容的路徑擴展。這一般建議用於在普通請求映射中減小歧義，好比「/person/{id}」中的一個點可能不表明文件擴展名，如「/person/joe@email.com」和「/person/joe@email.com.json」。並且，就像下面解釋的那樣，後綴模式匹配和內容協商可能被用在一些情形中來企圖進行惡意攻擊，因此有很好的理由來限制它們。

    後綴匹配配置參見「路徑匹配」 ，內容協商配置參見「內容協商」。

5）後綴模式匹配和 RFD

    反射型文件下載（Reflected file download：RFD）攻擊在 2014 年最初由 Trustwave 在一篇論文中描述。這種襲擊是相似於 XSS，由於它依賴於反映在響應中的輸入（如查詢參數，URI 變量）。不像在 HTML 中插入 JavaScript，一次 RFD 攻擊依賴於瀏覽器執行一個下載並把響應看成可執行腳原本處理，就像雙擊了像擁有擴展名.bat、.cmd的文件。

    在 Spring MV C中 @ResponseBody 和 ResponseEntity 的方法面臨危險，由於它們能夠渲染客戶端可以經過 URL 路徑擴展請求的不一樣類型的內容。注意到即不由止後綴模式匹配也不單純爲內容協商目的禁止使用文件拓展名將有效防止 RFD 攻擊。

    爲了全面防範 RFD 攻擊，在渲染響應體以前，Spring MVC 添加了一個Content-Disposition:inline;filename=f.txt響應頭來暗示一個修正過的安全的下載文件。這僅在URL路徑包含一個文件拓展名既不在白名單中，又沒有因內容協商目的而顯式註冊時才這麼作。當直接在瀏覽器中鍵入 URL 時，它可能會有反作用。

    不少經常使用的路徑擴展名默認在白名單中。此外，REST API 調用一般不是直接在瀏覽器中用做 URL 。使用自定義 HttpMessageConverter 實現的應用能夠爲內容協商顯式註冊文件擴展名，響應頭 Content-Disposition 不會被添加到這樣的擴展名中。參見「內容協商」。

    這最初在CVE-2015-5211工做報告中引進。下面是這份報告的補充建議：

• 編寫而非避開JSON 響應。這也是 OWASP XSS 中的建議。怎樣用 Spring 這樣作的例子見 spring-jackson-owasp。

• 配置後綴模式匹配爲關閉的，或只限於使用顯式註冊的後綴。

• 配置內容協商時，設置屬性 「useJaf」 和 「ignoreUnknownPathExtensions」 爲 false，這樣的話，若是URL中包含未知的擴展名，就會返回一個406錯誤。注意，若是 URL 可能會有一個點在結尾的話，這不是一個好的選擇。

• Add X-Content-Type-Options: nosniff header to responses. Spring Security 4 does this by default.

---

    最後但一樣重要的是，若有不許確的地方，請告知；水平有限，最後一句沒有翻譯，若有你有正確的理解，也請告知。郵箱：rocketeers@163.com