【51CTO.com快譯】會話安全的重要性

在任何需要服務器和客戶端之間進行通信的系統(tǒng)設計中，會話的安全性總是需要重點考慮的因素之一。不當?shù)陌踩栽O計往往會導致用戶帳戶容易受到未經(jīng)授權的訪問攻擊。業(yè)界著名的OWASP(開放Web應用程序安全項目，請參見--

https://dzone.com/articles/continuous-security-using-owasp)將“認證與授權的不當實施”視為應用安全的第二大風險(請參見--

https://www.owasp.org/index.php/Top_10-2017_Top_10)。

[[328472]]

下面是近年來發(fā)生在網(wǎng)絡安全領域的典型案例：

• 今年早些時候，Docker的hub數(shù)據(jù)庫遭到了黑客攻擊，并導致了Github訪問令牌被盜。消息來源請參見-- https://www.theinquirer.net/inquirer/news/3074793/docker-hub-breach
• Gitlab的一個漏洞曾到導致其所有用戶的認證令牌在URL中被公開。它們不但沒有到期的時間，并且由于長度過短，極容易受到蠻力攻擊。消息來源請參見-- https://threatpost.com/session-hijacking-bug-exposed-gitlab-users-private-tokens/127747/
• 由于某個軟件的錯誤，影響并導致了9000萬個Facebook帳戶的訪問令牌被竊。消息來源請參見--https://newsroom.fb.com/news/2018/09/security-update/

在業(yè)界，許多CSO(首席安全官)都承認：在認證和授權方面的投入，向來都是企業(yè)安全預算中的燒錢大戶。而且，他們普遍認為正確地實施用戶會話管理可謂既耗時且昂貴。否則，自己乃至所在企業(yè)很可能會成為“下一個Jack和他的泰坦尼克號”。

值得注意的是：我們切勿將會話管理與OAuth(請參見-- https://dzone.com/articles/oauth2-tips-token-validation)相混淆。后者是一種僅用于委托目的的協(xié)議。而前者涉及到如何在有效會話期間處理、存儲和更改認證令牌。該處的令牌既可以是OAuth流，也可以是服務器與客戶端之間的會話流。

JWT和Opaque令牌

下面，我們將簡要地探討會話管理中兩種常用的主要令牌類型：

JSON Web令牌(JWT，請參見-- https://jwt.io/)

• 每個JWT都包含可用于解釋該令牌的任何持有方的特定信息。例如，頒發(fā)給了誰，及其用戶ID。
• 由于后端不需要為每個API的調(diào)用進行數(shù)據(jù)庫查詢，因此JWT的使用具有一定的可擴展性。
• 如果不使用黑名單(請參見-- https://auth0.com/blog/blacklist-json-web-token-api-keys/)之類的方法，我們很難在不影響可擴展性的情況下，按需、或在令牌過期之前吊銷單個令牌。當然，我們可以通過更改簽名的密鑰，來吊銷所有的令牌。

Opaque令牌

• 作為隨機字符串，它們可被視為僅由頒發(fā)系統(tǒng)保存的信息指針。
• 在每次使用它們時，都需要對數(shù)據(jù)庫或高速緩存進行查找。
• 此類令牌可以很容易地被按需吊銷。

盡管這兩種令牌類型的屬性不同，但是一旦被盜用，都可能導致未經(jīng)授權的帳戶訪問。

常見的會話攻擊

通常情況下，由于驗證令牌既可以被存儲在前端，又可以被存放在后端，而且往往需要通過會話流經(jīng)由網(wǎng)絡傳送，因此，它們很容易遭受到如下類型的攻擊：

• 中間人襲擊
• OAuth令牌盜用
• XSS(請參見--https://dzone.com/articles/the-cross-site-scripting-xss-vulnerability-definit)
• CSRF(請參見--https://dzone.com/articles/fixing-csrf-vulnerability)
• 數(shù)據(jù)庫/文件系統(tǒng)訪問
• 會話固定(請參見--https://dzone.com/articles/session-fixation-and-how-fix)
• 蠻力攻擊

面對上述攻擊，我們需要通過認真地考慮會話的安全性，部署適當?shù)拇胧瑏斫档陀捎谙到y(tǒng)自身漏洞，所積累的各種攻擊可能性。也就是說，系統(tǒng)架構師不僅要防止令牌被盜，還應當確保系統(tǒng)能夠盡快地檢測到令牌被盜的情況。

檢測與防止認證令牌被盜

由于令牌往往需要被應用程序的前端傳輸?shù)讲皇苄湃蔚牧硪环?，而且很容易被盜用，因此我們需要通過檢查來構建第一道防線?，F(xiàn)有的檢測方法主要依賴于啟發(fā)式算法(heuristic algorithms)。例如：跟蹤IP地址與瀏覽器(或移動端)指紋的突變，標記異常的用戶行為等。不過此類方法既難以實施，又準確性不高。下面讓我們來討論一些常見的會話管理方法。

實施會話管理的常用方法

最常用的會話管理設置方法包括如下五大類：

• 長期訪問令牌。
• 將短—中期有效的令牌，用于獲取新的訪問令牌。
• 短—中期訪問令牌，其使用期限會延長。
• 短期訪問令牌。
• 短期訪問令牌和長期刷新令牌。

1. 長期訪問令牌

在用戶主動注銷會話的時候，訪問令牌將被吊銷，并在前端被清除。

• 攻擊分析：:關鍵的認證令牌會永久性地暴露在前端、傳輸通道和后端，三個攻擊面上。
• 認證令牌被盜的影響：在令牌的到期之前，攻擊者可能會未經(jīng)授權地訪問到受害者的帳戶，并長達數(shù)周或數(shù)月之久。
• 盜用檢測：只能通過使用主動的啟發(fā)式算法、或被動地依靠用戶通知再實施檢測。如果該方法是使用JWT實現(xiàn)的，則很難吊銷令牌;如果使用的Opaque令牌，則比較容易吊銷。

2. 將短—中期有效的令牌，用于獲取新的訪問令牌

• 即使先前的令牌尚未過期，前端也可以使用新的訪問令牌。
• 在用戶主動注銷會話的時候，訪問令牌將在后端被吊銷，并從前端被清除。
• 如果訪問令牌僅短期有效，那么用戶就需要盡快注銷會話。

(1) 攻擊分析

關鍵的認證令牌會永久性地暴露在前端、傳輸通道和后端，三個攻擊面上。

(2) 認證令牌被盜的影響：

攻擊者必須不斷地更新其令牌，以維持其未經(jīng)授權的訪問狀態(tài)。

(3) 盜用檢測：

要保持登錄狀態(tài)，攻擊者和受害者都需要在當前(被盜)令牌過期之前，向服務器請求新的訪問令牌。如果同一令牌兩次被用于該請求，那么系統(tǒng)會根據(jù)前端的實現(xiàn)方式，推斷出發(fā)生了盜用行為。可見，短—中期有效的令牌雖然可以更快地被檢測出是否存在盜用，但是同樣由于壽命短暫，就算沒有被盜用，用戶的體驗也并不佳。當然，一旦盜用行為被檢測到，與該會話關聯(lián)的訪問令牌將會被立即吊銷。不過，如果訪問令牌是JWT，那么阻止此類攻擊可能會比較復雜。

3. 短—中期訪問令牌，其使用期限會延長

在用戶主動注銷會話的時候，訪問令牌將被吊銷，并在前端被清除。

• 攻擊分析：關鍵的認證令牌會永久性地暴露在前端、傳輸通道和后端，三個攻擊面上。
• 認證令牌被盜的影響：只要受害者的會話處于有效狀態(tài)，攻擊者就可以維持未經(jīng)授權的訪問。
• 盜用檢測：只能通過使用主動的啟發(fā)式算法、或被動地依靠用戶通知再實施檢測。一旦盜用行為被檢測到，與該會話關聯(lián)的訪問令牌將會被立即吊銷。不過，如果訪問令牌是JWT，那么阻止此類攻擊可能會比較復雜。

4. 短期訪問令牌

在用戶主動注銷會話的時候，訪問令牌將被吊銷，并在前端被清除。

• 攻擊分析：在這種情況下，雖然沒有關鍵的認證令牌，但是由于在傳輸過程中會公開用戶的憑據(jù)，因此同樣容易受到中間人的攻擊。
• 認證令牌被盜的影響：如果令牌被盜，攻擊者將只能在短時間內(nèi)實施未經(jīng)授權的訪問。
• 盜用檢測：只能通過使用主動的啟發(fā)式算法、或被動地依靠用戶通知再實施檢測。在檢測到攻擊時，由于訪問令牌壽命非常短，因此我們無需吊銷它們。不過，如果確實需要，我們可以通過從數(shù)據(jù)庫中刪除Opaque訪問令牌的方式，來吊銷它們。

5. 短期訪問令牌和長期刷新令牌

u 在用戶主動注銷會話的時候，訪問令牌和刷新令牌將被吊銷，并在前端被清除。

• 攻擊分析：關鍵的認證令牌(和刷新令牌)會永久性地暴露在前端和后端兩個攻擊面上，當然也偶爾會在傳輸過程中被暴露。
• 認證令牌被盜的影響：訪問令牌被盜：直到該令牌到期之前，攻擊者會在短時間內(nèi)擁有未經(jīng)授權的訪問權限。
• 刷新令牌被盜：攻擊者可以通過盜取刷新令牌，來獲取新的訪問令牌，并在較長一段時間內(nèi)，以未經(jīng)授權的方式訪問受害者的帳戶。
• 盜用檢測：訪問令牌被盜：只能通過使用主動的啟發(fā)式算法、或被動地依靠用戶通知再實施檢測。

刷新令牌被盜：只有在極少的情況下，我們能夠檢測到此類盜用行為，并將損失降至最低。例如：通過某種實現(xiàn)方式，讓先前的訪問令牌在生成新的令牌之后，立即被吊銷。據(jù)此，系統(tǒng)可以在攻擊者和受害者同時在線的情況下，識別出盜用的行為。也就是說，如果攻擊者使用了刷新令牌，那么受害者的訪問令牌將會被吊銷，也就導致了受害者需要去請求新的訪問令牌。而這將迫使攻擊者發(fā)出另一個請求，依此類推。因此，如果后端能夠檢測到在較短間隔內(nèi)，系統(tǒng)產(chǎn)生了大量對于新訪問令牌的請求，則可以推斷出盜用的狀況。

在檢測到攻擊時，由于訪問令牌的壽命非常短，因此我們無需吊銷它們。不過，如果確實需要，我們可以通過從數(shù)據(jù)庫中刪除Opaque訪問令牌，來吊銷它們。

下面，我們針對不同的會話攻擊類型，討論各種相應的應對方法。

應對攻擊的優(yōu)秀實踐

1. 中間人襲擊

當會話僅使用HTTP，或錯誤地實現(xiàn)了HTTPS時，如果應用程序并未啟用HTTPS、以及安全的cookie，那么攻擊者就可以通過與受害者同處一個網(wǎng)絡，來監(jiān)視網(wǎng)絡中的各種數(shù)據(jù)包，并在傳輸過程中以純文本格式，去查看到認證令牌。此外，即使某些應用程序帶有SSL證書，而錯誤的實現(xiàn)方式也可能導致中間人攻擊得逞。

正如前面提到的，預防此類攻擊的最簡單方法是：在整個應用程序中正確地使用HTTPS和安全的cookie。此外，我們還可以通過在每臺設備上使用公有、私有密鑰來增強額外的預防力度。也就是說，在用戶登錄之前，前端和后端將在初始化時交換此類公鑰。另外，為了后續(xù)通信的安全起見，我們也可以使用公鑰對令牌數(shù)據(jù)進行加密。

2. OAuth令牌盜用

如果某個應用程序是通過OAuth的方式，向其他應用程序提供訪問和刷新令牌。那么當其他應用程序的所在服務器受到威脅時，該應用本身的認證令牌也具有被盜的風險。前文提到的Docker Hub典型案例，就是屬于此類型。

那么預防此類攻擊的解決方法是：采取適當?shù)拇胧?，及時檢測處被盜的刷新令牌，并僅使用短期有效的訪問令牌類型。

3. XSS攻擊

在XSS中，攻擊者可以惡意地將Javascript注入到受害者的瀏覽器里，并運行在各種應用程序中。此類注入代碼會讀取認證令牌，并將其回傳給攻擊者。如果您想了解更多有關XSS攻擊的信息，請參見--https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)。

通過使用HttpOnly或各種Secure cookie來存儲認證令牌，我們可以很容易地防御此類攻擊的發(fā)生。不過，值得注意的是：請勿使用localStorage來存儲認證令牌，因為它們會被Javascript所訪問到。

4. CSRF

此類攻擊的目的并非竊取認證令牌，而是讓攻擊者可以跟蹤(piggyback)現(xiàn)有的活動會話。

為了防止CSRF攻擊，我們通常需要使用anti-CSRF令牌或SameSite cookie。當然，您也可以使用其他的方法，來與整個認證過程無縫地結合到一起，以解決此類問題。

5. 數(shù)據(jù)庫/文件系統(tǒng)訪問

如果攻擊者獲得了有效的認證令牌、或JWT/SSL私鑰(此類密鑰的盜用往往比密碼被盜更為糟糕)，就能夠設法通過數(shù)據(jù)庫的注入攻擊，來訪問到服務器，乃至數(shù)據(jù)庫和文件系統(tǒng)理的信息。據(jù)此，他們將能夠輕松地劫持會話，進而產(chǎn)生嚴重的安全后果。值得注意的是，攻擊者很可能是貴組織內(nèi)部的雇員，所以我們在對數(shù)據(jù)庫/服務器實施訪問控制時，需要注意如下兩個方面：

• 僅在數(shù)據(jù)庫中存儲刷新和訪問令牌的哈希值，以防止攻擊者劫持到任何實時的會話。
• 由于JWT需要將私鑰存儲在服務器上，因此一旦攻擊者獲得了私鑰，他們將能夠劫持當前、以及將來的會話。為了限制攻擊面，我們需要修改用于簽發(fā)JWT的私鑰，以便讓所有當前的JWT都立即失效。而由于刷新令牌將被用于生成一個帶有新的私鑰簽名的JWT，因此該更改私鑰的方法并不會影響到用戶的體驗。

6. 會話固定

此類攻擊“主打”Web應用程序里的匿名會話，而應對的最佳方法是：讓用戶每次登錄時，都生成一組新的認證令牌，并使舊的令牌(如果有的話)及時失效。注意，這是基于設備而不是基于用戶實現(xiàn)的。

7. 蠻力攻擊

那些具有足夠資源的攻擊者，經(jīng)常會不斷地去“猜測”認證令牌，直到其中的一種嘗試成功通過為止。據(jù)此，他們將獲得被盜令牌所授予的所有訪問權限。而抵御此類攻擊的最佳方法是：使用帶有高熵(high entropy)且位數(shù)較長的認證令牌。

總結

通過上述分析，我們了解到了會話管理的基本概念、常見的會話安全缺陷、各種攻擊類型、以及應對措施的最佳實踐。希望本文能夠給您在系統(tǒng)架構設計的實踐和安全管理中提供幫助。

原標題：All You Need to Know About User Session Security ，作者：Supertokens .io

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】