[[400681]]

之前有小伙伴表示，看 Spring Security 這么麻煩，不如自己寫一個(gè) Filter 攔截請求，簡單實(shí)用。

自己寫當(dāng)然也可以實(shí)現(xiàn)，但是大部分情況下，大家都不是專業(yè)的 Web 安全工程師，所以考慮問題也不過就是認(rèn)證和授權(quán)，這兩個(gè)問題處理好了，似乎系統(tǒng)就很安全了。

其實(shí)不是這樣的!

各種各樣的 Web 攻擊每天都在發(fā)生，什么固定會(huì)話攻擊、csrf 攻擊等等，如果不了解這些攻擊，那么做出來的系統(tǒng)肯定也不能防御這些攻擊。

使用 Spring Security 的好處就是，即使不了解這些攻擊，也不用擔(dān)心這些攻擊，因?yàn)?Spring Security 已經(jīng)幫你做好防御工作了。

我們常說相比于 Shiro，Spring Security 更加重量級(jí)，重量級(jí)有重量級(jí)的好處，比如功能全，安全管理更加完備。用了 Spring Security，你都不知道自己的系統(tǒng)有多安全!

今天我就來和大家聊一聊 Spring Security 中自帶的防火墻機(jī)制。

好了，不廢話了，我們來看文章。

1.HttpFirewall

在 Spring Security 中提供了一個(gè) HttpFirewall，看名字就知道這是一個(gè)請求防火墻，它可以自動(dòng)處理掉一些非法請求。

HttpFirewall 目前一共有兩個(gè)實(shí)現(xiàn)類：

一個(gè)是嚴(yán)格模式的防火墻設(shè)置，還有一個(gè)默認(rèn)防火墻設(shè)置。

DefaultHttpFirewall 的限制相對于 StrictHttpFirewall 要寬松一些，當(dāng)然也意味著安全性不如 StrictHttpFirewall。

Spring Security 中默認(rèn)使用的是 StrictHttpFirewall。

2.防護(hù)措施

那么 StrictHttpFirewall 都是從哪些方面來保護(hù)我們的應(yīng)用呢?我們來挨個(gè)看下。

2.1 只允許白名單中的方法

首先，對于請求的方法，只允許白名單中的方法，也就是說，不是所有的 HTTP 請求方法都可以執(zhí)行。

這點(diǎn)我們可以從 StrictHttpFirewall 的源碼中看出來：

public class StrictHttpFirewall implements HttpFirewall { 
 private Set<String> allowedHttpMethods = createDefaultAllowedHttpMethods(); 
 private static Set<String> createDefaultAllowedHttpMethods() { 
  Set<String> result = new HashSet<>(); 
  result.add(HttpMethod.DELETE.name()); 
  result.add(HttpMethod.GET.name()); 
  result.add(HttpMethod.HEAD.name()); 
  result.add(HttpMethod.OPTIONS.name()); 
  result.add(HttpMethod.PATCH.name()); 
  result.add(HttpMethod.POST.name()); 
  result.add(HttpMethod.PUT.name()); 
  return result; 
 } 
 private void rejectForbiddenHttpMethod(HttpServletRequest request) { 
  if (this.allowedHttpMethods == ALLOW_ANY_HTTP_METHOD) { 
   return; 
  } 
  if (!this.allowedHttpMethods.contains(request.getMethod())) { 
   throw new RequestRejectedException("The request was rejected because the HTTP method \"" + 
     request.getMethod() + 
     "\" was not included within the whitelist " + 
     this.allowedHttpMethods); 
  } 
 } 
} 

從這段代碼中我們看出來，你的 HTTP 請求方法必須是 DELETE、GET、HEAD、OPTIONS、PATCH、POST 以及 PUT 中的一個(gè)，請求才能發(fā)送成功，否則的話，就會(huì)拋出 RequestRejectedException 異常。

那如果你想發(fā)送其他 HTTP 請求方法，例如 TRACE ，該怎么辦呢?我們只需要自己重新提供一個(gè) StrictHttpFirewall 實(shí)例即可，如下：

@Bean 
HttpFirewall httpFirewall() { 
    StrictHttpFirewall firewall = new StrictHttpFirewall(); 
    firewall.setUnsafeAllowAnyHttpMethod(true); 
    return firewall; 
} 

其中，setUnsafeAllowAnyHttpMethod 方法表示不做 HTTP 請求方法校驗(yàn)，也就是什么方法都可以過。或者也可以通過 setAllowedHttpMethods 方法來重新定義可以通過的方法。

2.2 請求地址不能有分號(hào)

不知掉大家有沒有試過，如果你使用了 Spring Security，請求地址是不能有 ; 的，如果請求地址有 ; ，就會(huì)自動(dòng)跳轉(zhuǎn)到如下頁面：

可以看到，頁面的提示中已經(jīng)說了，因?yàn)槟愕恼埱蟮刂分邪?;，所以請求失敗。

什么時(shí)候請求地址中會(huì)包含 ; 呢?不知道小伙伴們在使用 Shiro 的時(shí)候，有沒有注意到，如果你禁用了 Cookie，那么 jsessionid 就會(huì)出現(xiàn)在地址欄里，像下面這樣：

http://localhost:8080/hello;jsessionid=xx 

這種傳遞 jsessionid 的方式實(shí)際上是非常不安全的(松哥后面的文章會(huì)和大家細(xì)聊這個(gè)問題)，所以在 Spring Security 中，這種傳參方式默認(rèn)就禁用了。

當(dāng)然，如果你希望地址欄能夠被允許出現(xiàn) ; ，那么可以按照如下方式設(shè)置：

@Bean 
HttpFirewall httpFirewall() { 
    StrictHttpFirewall firewall = new StrictHttpFirewall(); 
    firewall.setAllowSemicolon(true); 
    return firewall; 
} 

設(shè)置完成之后，再去訪問相同的接口，可以看到，此時(shí)雖然還是報(bào)錯(cuò)，但是錯(cuò)誤是 404 了，而不是一開始那個(gè)不允許 ; 的錯(cuò)了。

注意，在 URL 地址中，; 編碼之后是 %3b 或者 %3B，所以地址中同樣不能出現(xiàn) %3b 或者 %3B

題外話

有的小伙伴可能不知道或者沒用過，Spring3.2 開始，帶來了一種全新的傳參方式 @MatrixVariable。

@MatrixVariable 是 Spring3.2 中帶來的功能，這種方式拓展了請求參數(shù)的傳遞格式，使得參數(shù)之間可以用 ; 隔開，這種傳參方式真是哪壺不開提哪壺。因?yàn)?Spring Security 默認(rèn)就是禁止這種傳參方式，所以一般情況下，如果你需要使用 @MatrixVariable 來標(biāo)記參數(shù)，就得在 Spring Security 中額外放行。

接下來我通過一個(gè)簡單的例子來和大家演示一下 @MatrixVariable 的用法。

我們新建一個(gè) /hello 方法：

@RequestMapping(value = "/hello/{id}") 
public void hello(@PathVariable Integer id,@MatrixVariable String name) { 
    System.out.println("id = " + id); 
    System.out.println("name = " + name); 
} 

另外我們還需要配置一下 SpringMVC，使 ; 不要被自動(dòng)移除了：

@Configuration 
public class WebMvcConfig extends WebMvcConfigurationSupport { 
    @Override 
    protected void configurePathMatch(PathMatchConfigurer configurer) { 
        UrlPathHelper urlPathHelper = new UrlPathHelper(); 
        urlPathHelper.setRemoveSemicolonContent(false); 
        configurer.setUrlPathHelper(urlPathHelper); 
    } 
} 

然后啟動(dòng)項(xiàng)目(注意，Spring Security 中也已經(jīng)配置了允許 URL 中存在 ;)，瀏覽器發(fā)送如下請求：

http://localhost:8080/hello/123;name=javaboy 

控制臺(tái)打印信息如下：

id = 123 
name = javaboy 

可以看到，@MatrixVariable 注解已經(jīng)生效了。

2.3 必須是標(biāo)準(zhǔn)化 URL

請求地址必須是標(biāo)準(zhǔn)化 URL。

什么是標(biāo)準(zhǔn)化 URL?標(biāo)準(zhǔn)化 URL 主要從四個(gè)方面來判斷，我們來看下源碼：

StrictHttpFirewall#isNormalized：

private static boolean isNormalized(HttpServletRequest request) { 
 if (!isNormalized(request.getRequestURI())) { 
  return false; 
 } 
 if (!isNormalized(request.getContextPath())) { 
  return false; 
 } 
 if (!isNormalized(request.getServletPath())) { 
  return false; 
 } 
 if (!isNormalized(request.getPathInfo())) { 
  return false; 
 } 
 return true; 
} 

getRequestURI 就是獲取請求協(xié)議之外的字符;getContextPath 是獲取上下文路徑，相當(dāng)于是 project 的名字;getServletPath 這個(gè)就是請求的 servlet 路徑，getPathInfo 則是除過 contextPath 和 servletPath 之后剩余的部分。

這四種路徑中，都不能包含如下字符串：

"./", "/../" or "/." 

2.4 必須是可打印的 ASCII 字符

如果請求地址中包含不可打印的 ASCII 字符，請求則會(huì)被拒絕，我們可以從源碼中看出端倪：

StrictHttpFirewall#containsOnlyPrintableAsciiCharacters

private static boolean containsOnlyPrintableAsciiCharacters(String uri) { 
 int length = uri.length(); 
 for (int i = 0; i < length; i++) { 
  char c = uri.charAt(i); 
  if (c < '\u0020' || c > '\u007e') { 
   return false; 
  } 
 } 
 return true; 
} 

2.5 雙斜杠不被允許

如果請求地址中出現(xiàn)雙斜杠，這個(gè)請求也將被拒絕。雙斜杠 // 使用 URL 地址編碼之后，是 %2F%2F，其中 F 大小寫無所謂，所以請求地址中也能不出現(xiàn) "%2f%2f", "%2f%2F", "%2F%2f", "%2F%2F"。

如果你希望請求地址中可以出現(xiàn) // ，可以按照如下方式配置：

@Bean 
HttpFirewall httpFirewall() { 
    StrictHttpFirewall firewall = new StrictHttpFirewall(); 
    firewall.setAllowUrlEncodedDoubleSlash(true); 
    return firewall; 
} 

2.6 % 不被允許

如果請求地址中出現(xiàn) %，這個(gè)請求也將被拒絕。URL 編碼后的 % 是 %25，所以 %25 也不能出現(xiàn)在 URL 地址中。

如果希望請求地址中可以出現(xiàn) %，可以按照如下方式修改：

@Bean 
HttpFirewall httpFirewall() { 
    StrictHttpFirewall firewall = new StrictHttpFirewall(); 
    firewall.setAllowUrlEncodedPercent(true); 
    return firewall; 
} 

2.7 正反斜杠不被允許

如果請求地址中包含斜杠編碼后的字符 %2F 或者 %2f ，則請求將被拒絕。

如果請求地址中包含反斜杠 \ 或者反斜杠編碼后的字符 %5C 或者 %5c ，則請求將被拒絕。

如果希望去掉如上兩條限制，可以按照如下方式來配置：

@Bean 
HttpFirewall httpFirewall() { 
    StrictHttpFirewall firewall = new StrictHttpFirewall(); 
    firewall.setAllowBackSlash(true); 
    firewall.setAllowUrlEncodedSlash(true); 
    return firewall; 
} 

2.8 . 不被允許

如果請求地址中存在 . 編碼之后的字符 %2e、%2E，則請求將被拒絕。

如需支持，按照如下方式進(jìn)行配置：

@Bean 
HttpFirewall httpFirewall() { 
    StrictHttpFirewall firewall = new StrictHttpFirewall(); 
    firewall.setAllowUrlEncodedPeriod(true); 
    return firewall; 
} 

2.9 小結(jié)

需要強(qiáng)調(diào)一點(diǎn)，上面所說的這些限制，都是針對請求的 requestURI 進(jìn)行的限制，而不是針對請求參數(shù)。例如你的請求格式是：

http://localhost:8080/hello?param=aa%2ebb 

那么 2.7 小節(jié)說的限制和你沒關(guān)系。

這個(gè)大家從 StrictHttpFirewall 源碼中很容易看到：

public class StrictHttpFirewall implements HttpFirewall { 
 @Override 
 public FirewalledRequest getFirewalledRequest(HttpServletRequest request) throws RequestRejectedException { 
  rejectForbiddenHttpMethod(request); 
  rejectedBlacklistedUrls(request); 
  rejectedUntrustedHosts(request); 
 
  if (!isNormalized(request)) { 
   throw new RequestRejectedException("The request was rejected because the URL was not normalized."); 
  } 
 
  String requestUri = request.getRequestURI(); 
  if (!containsOnlyPrintableAsciiCharacters(requestUri)) { 
   throw new RequestRejectedException("The requestURI was rejected because it can only contain printable ASCII characters."); 
  } 
  return new FirewalledRequest(request) { 
   @Override 
   public void reset() { 
   } 
  }; 
 } 
 private void rejectedBlacklistedUrls(HttpServletRequest request) { 
  for (String forbidden : this.encodedUrlBlacklist) { 
   if (encodedUrlContains(request, forbidden)) { 
    throw new RequestRejectedException("The request was rejected because the URL contained a potentially malicious String \"" + forbidden + "\""); 
   } 
  } 
  for (String forbidden : this.decodedUrlBlacklist) { 
   if (decodedUrlContains(request, forbidden)) { 
    throw new RequestRejectedException("The request was rejected because the URL contained a potentially malicious String \"" + forbidden + "\""); 
   } 
  } 
 } 
 private static boolean encodedUrlContains(HttpServletRequest request, String value) { 
  if (valueContains(request.getContextPath(), value)) { 
   return true; 
  } 
  return valueContains(request.getRequestURI(), value); 
 } 
 
 private static boolean decodedUrlContains(HttpServletRequest request, String value) { 
  if (valueContains(request.getServletPath(), value)) { 
   return true; 
  } 
  if (valueContains(request.getPathInfo(), value)) { 
   return true; 
  } 
  return false; 
 } 
 private static boolean valueContains(String value, String contains) { 
  return value != null && value.contains(contains); 
 } 
} 

rejectedBlacklistedUrls 方法就是校驗(yàn) URL 的，該方法邏輯很簡單，我就不再贅述了。

注意：雖然我們可以手動(dòng)修改 Spring Security 中的這些限制，但是松哥不建議大家做任何修改，每一條限制都有它的原由，每放開一個(gè)限制，就會(huì)帶來未知的安全風(fēng)險(xiǎn)。后面松哥在和大家分享 Web 中的安全攻擊時(shí)，也會(huì)再次提到這些限制的作用，請小伙伴們保持關(guān)注哦。

3.總結(jié)

沒想到吧?Spring Security 竟然為你做了這么多事情!正好應(yīng)了那句雞湯：你所謂的歲月靜好,不過是有人在替你負(fù)重前行。