我知道基于cookie的身份驗證。SSL和HttpOnly標志可以應用于保護來自MITM和XSS的基于cookie的身份驗證。但是，將需要采取更多特殊措施來保護它免受CSRF的侵害。它們只是有點復雜。（參考）最近，我發現JSON Web令牌（JWT）作為身份驗證的解決方案非常熱門。我知道有關編碼，解碼和驗證JWT的知識。但是，我不明白為什么某些網站/教程告訴您使用JWT不需要CSRF保護。我已經閱讀了很多，并嘗試總結以下問題。我只希望有人可以提供JWT的概況，并闡明我對JWT誤解的概念。如果JWT存儲在cookie中，則我認為它與基于cookie的身份驗證相同，只是服務器不需要會話來驗證cookie /令牌。如果不采取特殊措施，CSRF仍有風險。JWT是否存儲在cookie中？如果JWT存儲在localStorage / sessionStorage中，則沒有cookie，因此不需要防御CRSF。問題是如何將JWT發送到服務器。我在這里發現建議使用jQuery通過Ajax請求的HTTP標頭發送JWT。那么，只有ajax請求可以進行身份驗證嗎？此外，我還發現了另一個博客節目，使用“ Authorization header”和“ Bearer”發送JWT。我不了解博客談論的方法。有人可以解釋一下“授權標頭”和“承載者”嗎？這是否會使通過所有請求的HTTP標頭傳輸的JWT？如果是，CSRF怎么樣？
2 回答
陪伴而非守候
TA貢獻1757條經驗 獲得超8個贊
JWT令牌之所以受歡迎，是因為它們在OAuth 2.0和OpenID Connect等新的授權和身份驗證協議中用作默認令牌格式。
當令牌存儲在cookie中時，瀏覽器將自動將其與每個請求一起發送到同一域，這仍然容易受到CSRF攻擊。
承載身份驗證是HTTP中定義的身份驗證方案之一。這基本上意味著YOU將（JWT）令牌粘貼在請求的Authorization HTTP標頭中。瀏覽器將NOT自動為您執行此操作，因此它不適合保護您的網站。由于瀏覽器不會自動將標頭添加到您的請求中，因此它不會受到CSRF攻擊的影響，CSRF攻擊取決于將身份驗證信息自動提交到原始域。
承載方案通常用于保護通過AJAX調用或移動客戶端使用的Web API（REST服務）。
慕虎7371278
TA貢獻1802條經驗 獲得超4個贊
我們需要將JWT存儲在客戶端計算機上。如果我們將其存儲在LocalStorage / SessionStorage中，那么XSS攻擊很容易抓住它。如果我們將其存儲在Cookie中，則黑客可以在CSRF攻擊中使用它（無需閱讀）并假冒用戶并聯系我們的API，并發送代表用戶采取行動或獲取信息的請求。
但是，有幾種方法可以保護cookie中的JWT不易被盜（但仍有一些先進的技術可以竊取它們）。但是，如果您要依賴LocalStorage / SessionStorage，則可以通過簡單的XSS攻擊對其進行訪問。
因此，為了解決CSRF問題，我在應用程序中使用了Double Submit Cookies。
雙重提交Cookies方法
將JWT存儲在HttpOnly cookie中，并在安全模式下使用它來通過HTTPS進行傳輸。
大多數CSRF攻擊在其請求中具有與原始主機不同的來源或引薦來源標頭。因此，請檢查標頭中是否包含其中的任何一個，它們是否來自您的域！如果不拒絕他們。如果請求中沒有原始來源和引薦來源網址，則無需擔心。您可以依賴X-XSRF-TOKEN標頭驗證結果的結果，我將在下一步中進行解釋。
雖然瀏覽器將自動為請求的域提供cookie，但存在一個有用的限制：網站上運行的JavaScript代碼無法讀取其他網站的cookie。我們可以利用它來創建我們的CSRF解決方案。為防止CSRF攻擊，我們必須創建一個額外的Javascript可讀cookie，稱為：XSRF-TOKEN。該cookie必須在用戶登錄時創建，并且應包含一個不可猜測的隨機字符串。我們也將此數字保存在JWT本身中作為私人聲明。每當JavaScript應用程序想要發出請求時，它將需要讀取此令牌并將其發送到自定義HTTP標頭中。由于這些操作（讀取Cookie，設置標題）只能在JavaScript應用程序的同一域上進行，
Angular JS使您的生活更輕松
幸運的是，我在平臺上使用了Angular JS，并且Angular打包了CSRF令牌方法，這使我們更易于實現。對于我們的Angular應用程序對服務器的每個請求，Angular $http服務將自動執行以下操作：
在當前域中查找名為XSRF-TOKEN的cookie。
如果找到該cookie，它將讀取該值并將其作為X-XSRF-TOKEN標頭添加到請求中。
這樣，客戶端實現將自動為您處理！我們只需要XSRF-TOKEN在服務器端的當前域上設置一個名為cookie的cookie ，當我們的API收到來自客戶端的任何調用時，它必須檢查X-XSRF-TOKEN標頭并將其與XSRF-TOKENJWT中的進行比較。如果它們匹配，則用戶是真實的。否則，這是偽造的請求，您可以忽略它。此方法受“雙重提交Cookie”方法的啟發。
警告
實際上，您仍然容易受到XSS的攻擊，只是攻擊者無法竊取您的JWT令牌以供以后使用，但攻擊者仍然可以使用XSS代表您的用戶發出請求。
無論您將JWT存儲在中localStorage還是將XSRF令牌存儲在非HttpOnly cookie中，XSS都可以輕松地將它們兩者都捕獲。即使是HttpOnly cookie中的JWT，也可以通過高級XSS攻擊（例如XST方法）來捕獲。
因此，除了使用Double Submit Cookies方法之外，您還必須始終遵循針對XSS的最佳做法，包括轉義內容。這意味著刪除所有可能導致瀏覽器執行您不希望執行的操作的可執行代碼。通常，這意味著刪除// <![CDATA[導致JavaScript評估的標記和HTML屬性。
添加回答
舉報
0/150
提交
取消