松哥最近在研究 Spring Security 源碼，發(fā)現(xiàn)了很多好玩的代碼，抽空寫幾篇文章和小伙伴們分享一下。
很多人吐槽 Spring Security 比 Shiro 重量級，這個重量級不是憑空來的，重量有重量的好處，就是它提供了更為強大的防護功能。
比如松哥最近看到的一段代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
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 類中，為了方便大家理解，我來簡單說下這段代碼的上下文環(huán)境。
當用戶提交用戶名密碼登錄之后，Spring Security 需要根據(jù)用戶提交的用戶名去數(shù)據(jù)庫中查詢用戶，這塊如果大家不熟悉，可以參考松哥之前的文章：
- Spring Security 如何將用戶數(shù)據(jù)存入數(shù)據(jù)庫？
- Spring Security+Spring Data Jpa 強強聯(lián)手，安全管理只有更簡單！
查到用戶對象之后，再去比對從數(shù)據(jù)庫中查到的用戶密碼和用戶提交的密碼之間的差異。具體的比對工作，可以參考 Spring Boot 中密碼加密的兩種姿勢！ 一文。
而上面這段代碼就是 Spring Security 根據(jù)用戶登錄時傳入的用戶名去數(shù)據(jù)庫中查詢用戶，并將查到的用戶返回。方法中還有一個 authentication 參數(shù)，這個參數(shù)里邊保存了用戶登錄時傳入的用戶名/密碼信息。
那么這段代碼有什么神奇之處呢？
我們來一行一行分析。
源碼梳理
1
首先方法一進來調(diào)用了 prepareTimingAttackProtection 方法，從方法名字上可以看出，這個是為計時攻擊的防御做準備，那么什么又是計時攻擊呢？別急，松哥一會來解釋。我們先來吧流程走完。prepareTimingAttackProtection 方法的執(zhí)行很簡單，如下：
|
1
2
3
4
5
|
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
接下來調(diào)用 loadUserByUsername 方法，根據(jù)登錄用戶傳入的用戶名去數(shù)據(jù)庫中查詢用戶，如果查到了，就將查到的對象返回。
3
如果查詢過程中拋出 UsernameNotFoundException 異常，按理說直接拋出異常，接下來的密碼比對也不用做了，因為根據(jù)用戶名都沒查到用戶，這次登錄肯定是失敗的，沒有必要進行密碼比對操作！
但是大家注意，在拋出異常之前調(diào)用了 mitigateAgainstTimingAttack 方法。這個方法從名字上來看，有緩解計時攻擊的意思。
我們來看下該方法的執(zhí)行流程：
|
1
2
3
4
5
6
|
private void mitigateAgainstTimingAttack(UsernamePasswordAuthenticationToken authentication) { if (authentication.getCredentials() != null) { String presentedPassword = authentication.getCredentials().toString(); this.passwordEncoder.matches(presentedPassword, this.userNotFoundEncodedPassword); }} |
可以看到，這里首先獲取到登錄用戶傳入的密碼即 presentedPassword，然后調(diào)用 passwordEncoder.matches 方法進行密碼比對操作，本來該方法的第二個參數(shù)是數(shù)據(jù)庫查詢出來的用戶密碼，現(xiàn)在數(shù)據(jù)庫中沒有查到用戶，所以第二個參數(shù)用 userNotFoundEncodedPassword 代替了，userNotFoundEncodedPassword 就是我們一開始調(diào)用 prepareTimingAttackProtection 方法時賦值的變量。這個密碼比對，從一開始就注定了肯定會失敗，那為什么還要比對呢？
計時攻擊
這就引入了我們今天的主題--計時攻擊。
計時攻擊是旁路攻擊的一種，在密碼學中，旁道攻擊又稱側信道攻擊、邊信道攻擊（Side-channel attack）。
這種攻擊方式并非利用加密算法的理論弱點，也不是暴力破解，而是從密碼系統(tǒng)的物理實現(xiàn)中獲取的信息。例如：時間信息、功率消耗、電磁泄露等額外的信息源，這些信息可被用于對系統(tǒng)的進一步破解。
旁路攻擊有多種不同的分類：
- 緩存攻擊（Cache Side-Channel Attacks），通過獲取對緩存的訪問權而獲取緩存內(nèi)的一些敏感信息，例如攻擊者獲取云端主機物理主機的訪問權而獲取存儲器的訪問權。
- 計時攻擊（Timing attack），通過設備運算的用時來推斷出所使用的運算操作，或者通過對比運算的時間推定數(shù)據(jù)位于哪個存儲設備，或者利用通信的時間差進行數(shù)據(jù)竊取。
- 基于功耗監(jiān)控的旁路攻擊，同一設備不同的硬件電路單元的運作功耗也是不一樣的，因此一個程序運行時的功耗會隨著程序使用哪一種硬件電路單元而變動，據(jù)此推斷出數(shù)據(jù)輸出位于哪一個硬件單元，進而竊取數(shù)據(jù)。
- 電磁攻擊（Electromagnetic attack），設備運算時會泄漏電磁輻射，經(jīng)過得當分析的話可解析出這些泄漏的電磁輻射中包含的信息（比如文本、聲音、圖像等），這種攻擊方式除了用于密碼學攻擊以外也被用于非密碼學攻擊等竊聽行為，如TEMPEST 攻擊。
- 聲學密碼分析（Acoustic cryptanalysis），通過捕捉設備在運算時泄漏的聲學信號捉取信息（與功率分析類似）。
- 差別錯誤分析，隱密數(shù)據(jù)在程序運行發(fā)生錯誤并輸出錯誤信息時被發(fā)現(xiàn)。
- 數(shù)據(jù)殘留（Data remanence），可使理應被刪除的敏感數(shù)據(jù)被讀取出來（例如冷啟動攻擊）。
- 軟件初始化錯誤攻擊，現(xiàn)時較為少見，行錘攻擊（Row hammer）是該類攻擊方式的一個實例，在這種攻擊實現(xiàn)中，被禁止訪問的存儲器位置旁邊的存儲器空間如果被頻繁訪問將會有狀態(tài)保留丟失的風險。
- 光學方式，即隱密數(shù)據(jù)被一些視覺光學儀器（如高清晰度相機、高清晰度攝影機等設備）捕捉。
所有的攻擊類型都利用了加密/解密系統(tǒng)在進行加密/解密操作時算法邏輯沒有被發(fā)現(xiàn)缺陷，但是通過物理效應提供了有用的額外信息（這也是稱為“旁路”的緣由），而這些物理信息往往包含了密鑰、密碼、密文等隱密數(shù)據(jù)。
而上面 Spring Security 中的那段代碼就是為了防止計時攻擊。
具體是怎么做的呢？假設 Spring Security 從數(shù)據(jù)庫中沒有查到用戶信息就直接拋出異常了，沒有去執(zhí)行 mitigateAgainstTimingAttack 方法，那么黑客經(jīng)過大量的測試，再經(jīng)過統(tǒng)計分析，就會發(fā)現(xiàn)有一些登錄驗證耗時明顯少于其他登錄，進而推斷出登錄驗證時間較短的都是不存在的用戶，而登錄耗時較長的是數(shù)據(jù)庫中存在的用戶。
現(xiàn)在 Spring Security 中，通過執(zhí)行 mitigateAgainstTimingAttack 方法，無論用戶存在或者不存在，登錄校驗的耗時不會有明顯差別，這樣就避免了計時攻擊。
可能有小伙伴會說，passwordEncoder.matches 方法執(zhí)行能耗費多少時間呀？這要看你怎么計時了，時間單位越小，差異就越明顯：毫秒（ms）、微秒（µs）、奈秒（ns）、皮秒（ps）、飛秒（fs）、阿秒（as）、仄秒（zs）。
另外，Spring Security 為了安全，passwordEncoder 中引入了一個概念叫做自適應單向函數(shù)，這種函數(shù)故意執(zhí)行的很慢并且消耗大量系統(tǒng)資源，所以非常有必要進行計時攻擊防御。
關于自適應單向函數(shù)，這是另外一個故事了，松哥抽空再和小伙伴們聊～
好啦，今天就先和小伙伴們聊這么多，小伙伴們決定有收獲的話，記得點個在看鼓勵下松哥哦～
以上就是Spring Boot 中該如何防御計時攻擊的詳細內(nèi)容，更多關于Spring Boot 防御計時攻擊的資料請關注服務器之家其它相關文章！
原文鏈接：https://segmentfault.com/a/1190000023861902?utm_source=tuicool&utm_medium=referral
