松哥最近在研究 Spring Security 源碼，發現了很多好玩的代碼，抽空寫幾篇文章和小伙伴們分享一下。
很多人吐槽 Spring Security 比 Shiro 重量級，這個重量級不是憑空來的，重量有重量的好處，就是它提供了更為強大的防護功能。
比如松哥最近看到的一段代碼：
protected final UserDetails retrieveUser(String username,
UsernamePasswordAuthenticationToken authentication)
throws AuthenticationException {
prepareTimingAttackProtection(); try {
UserDetails loadedUser = this.getUserDetailsService().loadUserByUsername(username);
if (loadedUser == null) {
throw new InternalAuthenticationServiceException(
"UserDetailsService returned null, which is an interface contract violation");
} return loadedUser;
} catch (UsernameNotFoundException ex) {
mitigateAgainstTimingAttack(authentication); throw ex;
} catch (InternalAuthenticationServiceException ex) {
throw ex;
} catch (Exception ex) {
throw new InternalAuthenticationServiceException(ex.getMessage(), ex);
}}
這段代碼位于 DaoAuthenticationProvider 類中，為了方便大家理解，我來簡單說下這段代碼的上下文環境。
當用戶提交用戶名密碼登錄之后，Spring Security 需要根據用戶提交的用戶名去數據庫中查詢用戶，這塊如果大家不熟悉，可以參考松哥之前的文章：
- Spring Security 如何將用戶數據存入數據庫？
- Spring Security+Spring Data Jpa 強強聯手，安全管理只有更簡單！
查到用戶對象之后，再去比對從數據庫中查到的用戶密碼和用戶提交的密碼之間的差異。具體的比對工作，可以參考Spring Boot 中密碼加密的兩種姿勢！一文。
而上面這段代碼就是 Spring Security 根據用戶登錄時傳入的用戶名去數據庫中查詢用戶，并將查到的用戶返回。方法中還有一個 authentication 參數，這個參數里邊保存了用戶登錄時傳入的用戶名/密碼信息。
那么這段代碼有什么神奇之處呢？
我們來一行一行分析。
源碼梳理
1
首先方法一進來調用了 prepareTimingAttackProtection 方法，從方法名字上可以看出，這個是為計時攻擊的防御做準備，那么什么又是計時攻擊呢？別急，松哥一會來解釋。我們先來吧流程走完。prepareTimingAttackProtection 方法的執行很簡單，如下：
private void prepareTimingAttackProtection() {
if (this.userNotFoundEncodedPassword == null) {
this.userNotFoundEncodedPassword = this.passwordEncoder.encode(USER_NOT_FOUND_PASSWORD);
}}
該方法就是將常量 USER_NOT_FOUND_PASSWORD 使用 passwordEncoder 編碼之后（如果不了解 passwordEncoder，可以參考 Spring Boot 中密碼加密的兩種姿勢！一文），將編碼結果賦值給 userNotFoundEncodedPassword 變量。
2
接下來調用 loadUserByUsername 方法，根據登錄用戶傳入的用戶名去數據庫中查詢用戶，如果查到了，就將查到的對象返回。
3
如果查詢過程中拋出 UsernameNotFoundException 異常，按理說直接拋出異常，接下來的密碼比對也不用做了，因為根據用戶名都沒查到用戶，這次登錄肯定是失敗的，沒有必要進行密碼比對操作！
但是大家注意，在拋出異常之前調用了 mitigateAgainstTimingAttack 方法。這個方法從名字上來看，有緩解計時攻擊的意思。
我們來看下該方法的執行流程：
private void mitigateAgainstTimingAttack(UsernamePasswordAuthenticationToken authentication) {
if (authentication.getCredentials() != null) {
String presentedPassword = authentication.getCredentials().toString(); this.passwordEncoder.matches(presentedPassword, this.userNotFoundEncodedPassword);
}}
可以看到，這里首先獲取到登錄用戶傳入的密碼即 presentedPassword，然后調用 passwordEncoder.matches 方法進行密碼比對操作，本來該方法的第二個參數是數據庫查詢出來的用戶密碼，現在數據庫中沒有查到用戶，所以第二個參數用 userNotFoundEncodedPassword 代替了，userNotFoundEncodedPassword 就是我們一開始調用 prepareTimingAttackProtection 方法時賦值的變量。這個密碼比對，從一開始就注定了肯定會失敗，那為什么還要比對呢？
計時攻擊
這就引入了我們今天的主題--計時攻擊。
計時攻擊是旁路攻擊的一種，在密碼學中，旁道攻擊又稱側信道攻擊、邊信道攻擊（Side-channel attack）。
這種攻擊方式并非利用加密算法的理論弱點，也不是暴力破解，而是從密碼系統的物理實現中獲取的信息。例如：時間信息、功率消耗、電磁泄露等額外的信息源，這些信息可被用于對系統的進一步破解。
旁路攻擊有多種不同的分類：
- 緩存攻擊（Cache Side-Channel Attacks），通過獲取對緩存的訪問權而獲取緩存內的一些敏感信息，例如攻擊者獲取云端主機物理主機的訪問權而獲取存儲器的訪問權。
- 計時攻擊（Timing attack），通過設備運算的用時來推斷出所使用的運算操作，或者通過對比運算的時間推定數據位于哪個存儲設備，或者利用通信的時間差進行數據竊取。
- 基于功耗監控的旁路攻擊，同一設備不同的硬件電路單元的運作功耗也是不一樣的，因此一個程序運行時的功耗會隨著程序使用哪一種硬件電路單元而變動，據此推斷出數據輸出位于哪一個硬件單元，進而竊取數據。
- 電磁攻擊（Electromagnetic attack），設備運算時會泄漏電磁輻射，經過得當分析的話可解析出這些泄漏的電磁輻射中包含的信息（比如文本、聲音、圖像等），這種攻擊方式除了用于密碼學攻擊以外也被用于非密碼學攻擊等竊聽行為，如TEMPEST 攻擊。
- 聲學密碼分析（Acoustic cryptanalysis），通過捕捉設備在運算時泄漏的聲學信號捉取信息（與功率分析類似）。
- 差別錯誤分析，隱密數據在程序運行發生錯誤并輸出錯誤信息時被發現。
- 數據殘留（Data remanence），可使理應被刪除的敏感數據被讀取出來（例如冷啟動攻擊）。
- 軟件初始化錯誤攻擊，現時較為少見，行錘攻擊（Row hammer）是該類攻擊方式的一個實例，在這種攻擊實現中，被禁止訪問的存儲器位置旁邊的存儲器空間如果被頻繁訪問將會有狀態保留丟失的風險。
- 光學方式，即隱密數據被一些視覺光學儀器（如高清晰度相機、高清晰度攝影機等設備）捕捉。
所有的攻擊類型都利用了加密/解密系統在進行加密/解密操作時算法邏輯沒有被發現缺陷，但是通過物理效應提供了有用的額外信息（這也是稱為“旁路”的緣由），而這些物理信息往往包含了密鑰、密碼、密文等隱密數據。
而上面 Spring Security 中的那段代碼就是為了防止計時攻擊。
具體是怎么做的呢？假設 Spring Security 從數據庫中沒有查到用戶信息就直接拋出異常了，沒有去執行 mitigateAgainstTimingAttack 方法，那么黑客經過大量的測試，再經過統計分析，就會發現有一些登錄驗證耗時明顯少于其他登錄，進而推斷出登錄驗證時間較短的都是不存在的用戶，而登錄耗時較長的是數據庫中存在的用戶。
現在 Spring Security 中，通過執行 mitigateAgainstTimingAttack 方法，無論用戶存在或者不存在，登錄校驗的耗時不會有明顯差別，這樣就避免了計時攻擊。
可能有小伙伴會說，passwordEncoder.matches 方法執行能耗費多少時間呀？這要看你怎么計時了，時間單位越小，差異就越明顯：毫秒（ms）、微秒（µs）、奈秒（ns）、皮秒（ps）、飛秒（fs）、阿秒（as）、仄秒（zs）。
另外，Spring Security 為了安全，passwordEncoder 中引入了一個概念叫做自適應單向函數，這種函數故意執行的很慢并且消耗大量系統資源，所以非常有必要進行計時攻擊防御。
關于自適應單向函數，這是另外一個故事了，松哥抽空再和小伙伴們聊～
好啦，今天就先和小伙伴們聊這么多，小伙伴們決定有收獲的話，記得點個在看鼓勵下松哥哦～
不知不覺，Spring Security 系列已經連載了 49 篇啦，感興趣的小伙伴也可以看看本系列其他文章哦：
- 挖一個大坑，Spring Security 開搞！
- 松哥手把手帶你入門 Spring Security，別再問密碼怎么解密了
- 手把手教你定制 Spring Security 中的表單登錄
- Spring Security 做前后端分離，咱就別做頁面跳轉了！統統 JSON 交互
- Spring Security 中的授權操作原來這么簡單
- Spring Security 如何將用戶數據存入數據庫？
- Spring Security+Spring Data Jpa 強強聯手，安全管理只有更簡單！
- Spring Boot + Spring Security 實現自動登錄功能
- Spring Boot 自動登錄，安全風險要怎么控制？
- 在微服務項目中，Spring Security 比 Shiro 強在哪？
- SpringSecurity 自定義認證邏輯的兩種方式(高級玩法)
- Spring Security 中如何快速查看登錄用戶 IP 地址等信息？
- Spring Security 自動踢掉前一個登錄用戶，一個配置搞定！
- Spring Boot + Vue 前后端分離項目，如何踢掉已登錄用戶？
- Spring Security 自帶防火墻！你都不知道自己的系統有多安全！
- 什么是會話固定攻擊？Spring Boot 中要如何防御會話固定攻擊？
- 集群化部署，Spring Security 要如何處理 session 共享？
- 松哥手把手教你在 SpringBoot 中防御 CSRF 攻擊！so easy！
- 要學就學透徹！Spring Security 中 CSRF 防御源碼解析
- Spring Boot 中密碼加密的兩種姿勢！
- Spring Security 要怎么學？為什么一定要成體系的學習？
- Spring Security 兩種資源放行策略，千萬別用錯了！
- 松哥手把手教你入門 Spring Boot + CAS 單點登錄
- Spring Boot 實現單點登錄的第三種方案！
- Spring Boot+CAS 單點登錄，如何對接數據庫？
- Spring Boot+CAS 默認登錄頁面太丑了，怎么辦？
- 用 Swagger 測試接口，怎么在請求頭中攜帶 Token？
- Spring Boot 中三種跨域場景總結
- Spring Boot 中如何實現 HTTP 認證？
- Spring Security 中的四種權限控制方式
- Spring Security 多種加密方案共存，老破舊系統整合利器！
- 神奇！自己 new 出來的對象一樣也可以被 Spring 容器管理！
- Spring Security 配置中的 and 到底該怎么理解？
- 一文搞定 Spring Security 異常處理機制！
- 寫了這么多年代碼，這樣的登錄方式還是頭一回見！
- Spring Security 竟然可以同時存在多個過濾器鏈？
- Spring Security 可以同時對接多個用戶表？
- 在 Spring Security 中，我就想從子線程獲取用戶登錄信息，怎么辦？
- 深入理解 FilterChainProxy【源碼篇】
- 深入理解 SecurityConfigurer 【源碼篇】
- 深入理解 HttpSecurity【源碼篇】
- 深入理解 AuthenticationManagerBuilder 【源碼篇】
- 花式玩 Spring Security ，這樣的用戶定義方式你可能沒見過！
- 深入理解 WebSecurityConfigurerAdapter【源碼篇】
- 盤點 Spring Security 框架中的八大經典設計模式
- Spring Security 初始化流程梳理
- 為什么你使用的 Spring Security OAuth 過期了？松哥來和大家捋一捋！
- 一個詭異的登錄問題
