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 編碼之后，將編碼結果賦值給 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 中引入了一個概念叫做自適應單向函數，這種函數故意執行的很慢并且消耗大量系統資源，所以非常有必要進行計時攻擊防御。
關于自適應單向函數，這是另外一個故事了，松哥抽空再和小伙伴們聊～
