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