1. 程式人生 > >JWT一些雜談(雖然譁眾取寵,但講的東西挺通俗易懂的)

JWT一些雜談(雖然譁眾取寵,但講的東西挺通俗易懂的)

摘要:

  • 在Web應用中,使用JWT替代session並不是個好主意
  • 適合JWT的使用場景

抱歉,當了回標題黨。我並不否認JWT的價值,只是它經常被誤用。

什麼是JWT

根據維基百科的定義,JSON WEB TokenJWT,讀作 [/dʒɒt/]),是一種基於JSON的、用於在網路上宣告某種主張的令牌(token)。JWT通常由三部分組成: 頭資訊(header), 訊息體(payload)和簽名(signature)。

頭資訊指定了該JWT使用的簽名演算法:

header = '{"alg":"HS256","typ":"JWT"}'

HS256 表示使用了 HMAC-SHA256 來生成簽名。

訊息體包含了JWT的意圖:

payload = '{"loggedInAs":"admin","iat":1422779638}'//iat表示令牌生成的時間

未簽名的令牌由base64url編碼的頭資訊和訊息體拼接而成(使用"."分隔),簽名則通過私有的key計算而成:

key = 'secretkey'  
unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload)  
signature = HMAC-SHA256(key, unsignedToken) 

最後在未簽名的令牌尾部拼接上base64url編碼的簽名(同樣使用"."分隔)就是JWT了:

token = encodeBase64(header) + '.' + encodeBase64(payload) + '.' + encodeBase64(signature) 

# token看起來像這樣: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

JWT常常被用作保護服務端的資源(resource),客戶端通常將JWT通過HTTP的Authorization

header傳送給服務端,服務端使用自己儲存的key計算、驗證簽名以判斷該JWT是否可信:

Authorization: Bearer eyJhbGci*...<snip>...*yu5CSpyHI

那怎麼就誤用了呢

近年來RESTful API開始風靡,使用HTTP header來傳遞認證令牌似乎變得理所應當,而單頁應用(SPA)、前後端分離架構似乎正在促成越來越多的WEB應用放棄歷史悠久的cookie-session認證機制,轉而使用JWT來管理使用者session。支援該方案的人認為:

1.該方案更易於水平擴充套件

在cookie-session方案中,cookie內僅包含一個session識別符號,而諸如使用者資訊、授權列表等都儲存在服務端的session中。如果把session中的認證資訊都儲存在JWT中,在服務端就沒有session存在的必要了。當服務端水平擴充套件的時候,就不用處理session複製(session replication)/ session黏連(sticky session)或是引入外部session儲存了。

從這個角度來說,這個優點確實存在,但實際上外部session儲存方案已經非常成熟了(比如Redis),在一些Framework的幫助下(比如spring-sessionhazelcast),session複製也並沒有想象中的麻煩。所以除非你的應用訪問量非常非常非常(此處省略N個非常)大,使用cookie-session配合外部session儲存完全夠用了。

2.該方案可防護CSRF攻擊

跨站請求偽造Cross-site request forgery(簡稱CSRF, 讀作 [sea-surf])是一種典型的利用cookie-session漏洞的攻擊,這裡借用spring-security的一個例子來解釋CSRF:

假設你經常使用bank.example.com進行網上轉賬,在你提交轉賬請求時bank.example.com的前端程式碼會提交一個HTTP請求:

POST /transfer HTTP/1.1
Host: bank.example.com
cookie: JsessionID=randomid; Domain=bank.example.com; Secure; HttpOnly
Content-Type: application/x-www-form-urlencoded

amount=100.00&routingNumber=1234&account=9876

你圖方便沒有登出bank.example.com,隨後又訪問了一個惡意網站,該網站的HTML頁面包含了這樣一個表單:

<form action="https://bank.example.com/transfer" method="post">
    <input type="hidden" name="amount" value="100.00"/>
    <input type="hidden" name="routingNumber" value="evilsRoutingNumber"/>
    <input type="hidden" name="account" value="evilsAccountNumber"/>
    <input type="submit" value="點選就送!"/>
</form>

你被“點選就送”吸引了,當你點了提交按鈕時你已經向攻擊者的賬號轉了100元。現實中的攻擊可能更隱蔽,惡意網站的頁面可能使用Javascript自動完成提交。儘管惡意網站沒有辦法盜取你的session cookie(從而假冒你的身份),但惡意網站向bank.example.com發起請求時,你的cookie會被自動傳送過去。

因此,有些人認為前端程式碼將JWT通過HTTP header傳送給服務端(而不是通過cookie自動傳送)可以有效防護CSRF。在這種方案中,服務端程式碼在完成認證後,會在HTTP response的header中返回JWT,前端程式碼將該JWT存放到Local Storage裡待用,或是服務端直接在cookie中儲存HttpOnly=false的JWT。

在向服務端發起請求時,用Javascript取出JWT(否則前端Javascript程式碼無權從cookie中獲取資料),再通過header傳送回服務端通過認證。由於惡意網站的程式碼無法獲取bank.example.com的cookie/Local Storage中的JWT,這種方式確實能防護CSRF,但將JWT儲存在cookie/Local Storage中可能會給另一種攻擊可乘之機,我們一會詳細討論它:跨站指令碼攻擊——XSS。

3.該方案更安全

由於JWT要求有一個祕鑰,還有一個演算法,生成的令牌看上去不可讀,不少人誤認為該令牌是被加密的。但實際上祕鑰和演算法是用來生成簽名的,令牌本身不可讀僅是因為base64url編碼,可以直接解碼,所以如果JWT中如果儲存了敏感的資訊,相對cookie-session將資料放在服務端來說,更不安全。

除了以上這些誤解外,使用JWT管理session還有如下缺點:

  1. 更多的空間佔用。如果將原存在服務端session中的各類資訊都放在JWT中儲存在客戶端,可能造成JWT佔用的空間變大,需要考慮cookie的空間限制等因素,如果放在Local Storage,則可能受到XSS攻擊。

  2. 更不安全。這裡是特指將JWT儲存在Local Storage中,然後使用Javascript取出後作為HTTP header傳送給服務端的方案。在Local Storage中儲存敏感資訊並不安全,容易受到跨站指令碼攻擊,跨站指令碼(Cross site script,簡稱xss)是一種“HTML注入”,由於攻擊的指令碼多數時候是跨域的,所以稱之為“跨域指令碼”,這些指令碼程式碼可以盜取cookie或是Local Storage中的資料。可以從這篇文章檢視XSS攻擊的原理解釋。

  3. 無法作廢已頒佈的令牌。所有的認證資訊都在JWT中,由於在服務端沒有狀態,即使你知道了某個JWT被盜取了,你也沒有辦法將其作廢。在JWT過期之前(你絕對應該設定過期時間),你無能為力。

  4. 不易應對資料過期。與上一條類似,JWT有點類似快取,由於無法作廢已頒佈的令牌,在其過期前,你只能忍受“過期”的資料。

看到這裡後,你可能發現,將JWT儲存在Local Storage中,並使用JWT來管理session並不是一個好主意,那有沒有可能“正確”地使用JWT來管理session呢?比如:

  • 不再使用Local Storage儲存JWT,使用cookie,並且設定HttpOnly=true,這意味著只能由服務端儲存以及通過自動回傳的cookie取得JWT,以便防禦XSS攻擊
  • 在JWT的內容中加入一個隨機值作為CSRF令牌,由服務端將該CSRF令牌也儲存在cookie中,但設定HttpOnly=false,這樣前端Javascript程式碼就可以取得該CSRF令牌,並在請求API時作為HTTP header傳回。服務端在認證時,從JWT中取出CSRF令牌與header中獲得CSRF令牌比較,從而實現對CSRF攻擊的防護
  • 考慮到cookie的空間限制(大約4k左右),在JWT中儘可能只放“夠用”的認證資訊,其他資訊放在資料庫,需要時再獲取,同時也解決之前提到的資料過期問題

這個方案看上去是挺不錯的,恭喜你,你重新發明了cookie-session,可能實現還不一定有現有的好。

那究竟JWT可以用來做什麼

我的同事做過一個形象的解釋:

JWT(其實還有SAML)最適合的應用場景就是“開票”,或者“簽字”。

在有紙化辦公時代,多部門、多組織之間的協同工作往往會需要拿著A部門領導的“簽字”或者“蓋章”去B部門“使用”或者“訪問”對應的資源,其實這種“領導簽字/蓋章”就是JWT,都是一種由具有一定權力的實體“簽發”並“授權”的“票據”。一般的,這種票據具有可驗證性(領導簽名/蓋章可以被驗證,且難於模仿),不可篡改性(塗改過的檔案不被接受,除非在塗改處再次簽字確認);並且這種票據一般都是“一次性”使用的,在訪問到對應的資源後,該票據一般會被資源持有方收回留底,用於後續的審計、追溯等用途。

舉兩個例子:

  1. 員工李雷需要請假一天,於是填寫請假申請單,李雷在獲得其主管部門領導簽字後,將請假單交給HR部門韓梅梅,韓梅梅確認領導簽字無誤後,將請假單收回,並在公司考勤表中做相應記錄。
  2. 員工李雷和韓梅梅因工外出需要使用公司汽車一天,於是填寫用車申請單,簽字後李雷將申請單交給車隊司機老王,乘坐老王駕駛的車輛外出辦事,同時老王將用車申請單收回並存檔。

在以上的兩個例子中,“請假申請單”和“用車申請單”就是JWT中的payload,領導簽字就是base64後的數字簽名,領導是issuer,“HR部門的韓梅梅”和“司機老王”即為JWT的audience,audience需要驗證領導簽名是否合法,驗證合法後根據payload中請求的資源給予相應的許可權,同時將JWT收回。

放到系統整合的場景中,JWT更適合一次性操作的認證:

服務B你好, 服務A告訴我,我可以操作<JWT內容>, 這是我的憑證(即JWT)

在這裡,服務A負責認證使用者身份(相當於上例中領導批准請假),並頒佈一個很短過期時間的JWT給瀏覽器(相當於上例中的請假單),瀏覽器(相當於上例中的請假員工)在向服務B的請求中帶上該JWT,則服務B(相當於上例中的HR員工)可以通過驗證該JWT來判斷使用者是否有權執行該操作。這樣,服務B就成為一個安全的無狀態的服務了。

總結

  1. 在Web應用中,別再把JWT當做session使用,絕大多數情況下,傳統的cookie-session機制工作得更好
  2. JWT適合一次性的命令認證,頒發一個有效期極短的JWT,即使暴露了危險也很小,由於每次操作都會生成新的JWT,因此也沒必要儲存JWT,真正實現無狀態。

文/ThoughtWorks 周宇剛

      </div>