看下這個(gè)場(chǎng)景 – 一個(gè)用戶登錄了你的網(wǎng)站，第二天再次回來(lái)訪問(wèn)時(shí)...他必須再次登錄。“記住我”這種功能 – 讓我們關(guān)注下，我們之前都見(jiàn)過(guò)它 – 是指在立即使用之后把已認(rèn)證狀態(tài)進(jìn)行持久化。這意味著他們可以關(guān)閉瀏覽器，關(guān)掉電腦，然后過(guò)一天或者過(guò)一周或者過(guò)一個(gè)月或者無(wú)論多久之后再回來(lái)訪問(wèn)時(shí)，該網(wǎng)站依然能識(shí)別出來(lái)他們是誰(shuí)，并給他們提供和他們離開(kāi)時(shí)所擁有的一模一樣的功能。

我所說(shuō)的就是下面這個(gè)小東西：

看起來(lái)很簡(jiǎn)單, 是吧? 也許是，但是你將會(huì)看到把它弄得一團(tuán)糟的情況并不少見(jiàn)，而且，即使你做對(duì)了，也會(huì)有一大隊(duì)人等著告訴你，實(shí)際上你仍然不夠正確。讓我們從一些完全錯(cuò)誤的做法開(kāi)始我們的工作。

適得其反的模式

這看起來(lái)挺明顯的嗎，不是嗎？我是說(shuō)關(guān)于“記住我”這個(gè)特性的模型還是挺基礎(chǔ)的，不是那種很容易搞錯(cuò)的東西。你確定嗎？顯然不是。

在我們討論怎么做才能做對(duì)之前，我們先來(lái)分享幾個(gè)適得其反的模式的案例。第一個(gè)案例就是Black & Decker，就是我前段時(shí)間在Security is hard, insecurity is easy里寫到的那個(gè)B&D。這就是你準(zhǔn)備登錄時(shí)的樣子：

這還是挺中規(guī)中矩的，有意思的東西要等你登錄后才能看到。然我們來(lái)看下Cookie記錄：

這是cookies的一些相關(guān)屬性和值。但是高亮部分是真正值得關(guān)注的地方。假如用戶沒(méi)有選擇"記住我 "按鈕,這些cookies的信息不會(huì)存在,所以它們的功能純粹是為了用戶稍后登錄。我的用戶名是相當(dāng)?shù)那宄?我的密碼被加過(guò)密碼。注意看看這個(gè)密碼,那是Base64編碼!這就意味著密碼被實(shí)現(xiàn)由Base64編碼,你能攔截它在某些地方例 如 base64decode.org 這樣做：

現(xiàn)在并非所有人知道Base64這一門加密技術(shù) (是的,用戶可以真正地這樣做) 。它是相當(dāng)完美合法代替數(shù)據(jù)用ASCII格式, 這個(gè)真正的故事在這里是告訴我們的密碼在瀏覽器以文本方式。你可能會(huì)驚奇-為什么有問(wèn)題呢。它是在你的瀏覽器,真的?黑客怎么攻擊它呢?

我將要去討論兩種簡(jiǎn)單的方式。第一種方式是涉及到前面鏈接的不安全的信息。Black & Decker 已經(jīng)暴露了ElEMH日志和這些日志相關(guān)的未處理服務(wù)器異常。我會(huì)通知它們?cè)?50,000的北方。當(dāng)ELMAH日志發(fā)生異常,那么意味著cookies(所有請(qǐng)求頭信息)將會(huì)被記錄。系統(tǒng)將會(huì)拋出大量的錯(cuò)誤信息,你會(huì)接受到一個(gè)用戶憑證。是的,他們應(yīng)該開(kāi)始恰當(dāng)?shù)乇Ｗo(hù)ELMAH日志信息。但它是一個(gè)很好的例子,你怎么可以很容易地通過(guò)一個(gè)非常簡(jiǎn)單的配置撤消錯(cuò)誤信息。

這里有另外的一個(gè)：

這就是 Aussie Farmers Direct 。它的登錄界面看起來(lái)非常傳統(tǒng)。當(dāng)我們開(kāi)始登錄并打上"記住我"的標(biāo)志的時(shí)候, 我們看一眼相關(guān)的cookies信息。

哇親愛(ài)的,相同的處理方式但是沒(méi)有任何Base64編碼。事實(shí)上,這樣是相當(dāng)?shù)牟缓侠?因?yàn)槟隳軌虿僮飨裣旅孢@樣。

XSS 你自己的 JSON cookie? 確定不! 另外的方式是改變你的密碼而不要改變你的cookie。所以當(dāng)你下一次返回的時(shí)候,嘗試重新登入用舊的密碼。哎呀。

#p#

Aussie Farmers Direct 沒(méi)有暴露出ELMAH日志信息 (因?yàn)镻HP友好的處理了它) 。但是,它仍然有其它的風(fēng)險(xiǎn)例如XSS(順便說(shuō)一下,它們多次負(fù)責(zé)任的關(guān)閉和處理了風(fēng)險(xiǎn)。)另外一件事情是上面2個(gè)網(wǎng)站的cookies處理密碼沒(méi)有標(biāo)記作為HttpOnly, 你能看見(jiàn)它們?cè)赾ookie列表的第二列。那就意味著客戶端腳本訪問(wèn)這些cookies,那就意味著如果你能到網(wǎng)站上得到XSS。假如你能夠讓用戶去運(yùn)行 XSS負(fù)載(現(xiàn)在有多種方式去做),你就能偷到包含的密碼的cookies信息,訪問(wèn)Aussie Farmers 網(wǎng)站。缺少了HttpOnly屬性是代表這兩個(gè)網(wǎng)站上的馬虎,但是核心的問(wèn)題用cookies存儲(chǔ)你的密碼,然后使他們很容易通過(guò)其他疏漏。

從根本上來(lái)說(shuō),最重要的原因主要是這兩個(gè)網(wǎng)站的疏忽。他們保護(hù)用戶的證書被用在網(wǎng)站。在網(wǎng)站上,用戶每一次使用"記住我"特征,用戶發(fā)送了一個(gè)請(qǐng)求。現(xiàn)在有一個(gè)好的選擇就是發(fā)送他們的用戶名和密碼到他們的郵箱,或者eBay,或者它們的銀行通過(guò)線路,有時(shí)候用文本,有時(shí)候訪問(wèn)用客戶端腳本。總是放在瀏覽器中未受到保護(hù)。密碼重用是瘋狂,而這些該死的用戶該付出血淋淋的責(zé)任(我在這里轉(zhuǎn)述!),我們—作為開(kāi)發(fā)者—當(dāng)我們處理憑據(jù)時(shí),我們必須認(rèn)識(shí)到保護(hù)遠(yuǎn)遠(yuǎn)超過(guò)只是我們自己的網(wǎng)站。

因此，我們應(yīng)該建立"記住我"的功能的真正誤區(qū)。讓我們開(kāi)始走向正確的實(shí)踐道路。

一個(gè)參考的實(shí)現(xiàn)樣本

安全領(lǐng)域中你能經(jīng)常聽(tīng)到的箴言之一就是“不要使用你自己的——使用已經(jīng)證實(shí)是安全的”。它被非常頻繁地應(yīng)用于加密和身份驗(yàn)證方案中，但是現(xiàn)在我們可以將這個(gè)擴(kuò)展到“記住我”的特性，以便在我們深入細(xì)節(jié)之前，先從一個(gè)好的參考實(shí)現(xiàn)開(kāi)始。

在一個(gè)由Visual Studio 2012新建的ASP.NET MVC 4網(wǎng)站中，你能得到這個(gè)開(kāi)箱即用的登錄界面：

其它的框架有其它實(shí)現(xiàn)這個(gè)特性的標(biāo)準(zhǔn)模式，但這個(gè)參考起來(lái)很容易。當(dāng)我們像上面這樣填寫字段登陸的時(shí)候（即不要讓它記住我），驗(yàn)證成功則會(huì)返回如下cookie結(jié)果：

Set-Cookie:.ASPXAUTH=6891A5EAF17A9C35B51C4ED3C473FBA294187C97B758880F9A56E3D335E2F02
0B86A85E1D0074BDAB2E1C9DBE590AF67895C0F989BA137E292035A3093A702DEC9D0D8089E1D007089F
75A77D1B2A79CAA800E8F62D3D807CBB86779DB52F012;
path=/; HttpOnly 

這只是個(gè)簡(jiǎn)單的驗(yàn)證cookie, 在無(wú)狀態(tài)的HTTP世界里, 一個(gè)用戶發(fā)送的所有請(qǐng)求若不是被這一小段數(shù)據(jù)關(guān)聯(lián)起來(lái)的話, 都將變成完全獨(dú)立的請(qǐng)求. 每一次這個(gè)對(duì)我唯一的cookie被發(fā)送后, 網(wǎng)站就會(huì)知道來(lái)訪的用戶是我而且我已經(jīng)通過(guò)了驗(yàn)證. 我們可以在Chrome的Cookie記錄下面看得更仔細(xì)一點(diǎn)兒:

順帶說(shuō)一下, 第二個(gè)cookie是一個(gè)用于阻止CSRF攻擊的反偽造令牌, 這和我們的驗(yàn)證狀態(tài)沒(méi)啥關(guān)系, 除此以外就沒(méi)有其他cookie了.

現(xiàn)在, 我們登錄并要求網(wǎng)站記住我, 下面是響應(yīng)的cookie值:

Set-Cookie:.ASPXAUTH=3A92DAC7EFF4EE5B2027A13DD8ABEA8254F0A16D8059FCAF60F5533F1B7D994
62DDF57320D069A493481978750526DF952D5C9EA0371C84F5CF1BFC0CCA024C2052824D4BA09670A42B
85AEC7FFCB4088FC744C6C0A22749F07AF6E65E674A4A;
expires=Tue, 02-Jul-2013 00:27:05 GMT;
path=/; HttpOnly 

啊哈 – 看到了吧?! 如果你在Chrome下面查看被分解開(kāi)來(lái)的cookie值就會(huì)變得更加清楚:

現(xiàn)在, 我們有了一個(gè)從當(dāng)前開(kāi)始有效期為48小時(shí)的cookie, 相反的是不設(shè)置過(guò)期時(shí)間的cookie將會(huì)在瀏覽器被關(guān)閉之后被立即清除. 讓我們來(lái)近距離的看一看.

縱觀授權(quán)cookie的失效

事實(shí)上,這個(gè)一個(gè)可笑的安全結(jié)構(gòu)和它僅僅只是前面的例子我感覺(jué)是值得寫出來(lái),但是我們?cè)谶@里。在實(shí)現(xiàn)當(dāng)中,“記住我”功能簡(jiǎn)單地歸結(jié)為當(dāng)授權(quán)的cookie到期。這里做的事情是控制你想讓某人登入到你網(wǎng)站多久,它是簡(jiǎn)單的。

在這里例子當(dāng)中,ASP.NET 默認(rèn)使用session cookie 或者換一句說(shuō)話, a cookie 沒(méi)有明確的失效時(shí)間。當(dāng)用戶瀏覽器一關(guān)閉,cookie就強(qiáng)制到期。 這是一種方法，另外一種就是明確一個(gè)簡(jiǎn)短時(shí)間以至于瀏覽器是開(kāi)著的,用戶自動(dòng)退出的經(jīng)過(guò)一段時(shí)間。當(dāng)然,假如系統(tǒng)是運(yùn)行順暢的,你也是能夠控制服務(wù)器的行為,由服務(wù)器響應(yīng)增加失效時(shí)間,你也能夠擴(kuò)展授權(quán)cookies信息的生命周期。

記住某個(gè)人是簡(jiǎn)單的,保存授權(quán)cookie信息是激活的。多長(zhǎng)時(shí)間讓它存活呢?在這個(gè)例子中默認(rèn)是2天,這個(gè)可能是短暫的對(duì)一些合法的用戶來(lái)說(shuō)。(盡管它可以簡(jiǎn)單的在 ASP.NET中配置) ,Facebook 可以讓你的cookie信息存活持續(xù)一年。短暫的時(shí)間說(shuō)明減少風(fēng)險(xiǎn)但是不方便,長(zhǎng)時(shí)間使得用戶增加窗口的潛在攻擊可能。讓我們看一下風(fēng)險(xiǎn)更詳細(xì)。

利用長(zhǎng)期運(yùn)行的認(rèn)證狀態(tài)

當(dāng)你不認(rèn)證的時(shí)候,你的會(huì)話不能被劫持。我知道那種情況。但嚴(yán)重的是類似Aussie Farmers Direct的情況。cookie有效的時(shí)間是6個(gè)月。由于這個(gè)事實(shí),網(wǎng)站沒(méi)有標(biāo)記為HttpOnly。因?yàn)榫W(wǎng)站里面有XSS缺陷并且cookie的有效時(shí)間是6個(gè)月,所以在這6個(gè)月當(dāng)中,在你不經(jīng)意訪問(wèn)網(wǎng)站的時(shí)候,它會(huì)把鏈接相關(guān)的證書發(fā)送給攻擊者。假如有效時(shí)間是一個(gè)月,雖然他們?cè)谠O(shè)計(jì)方面會(huì)有嚴(yán)重的缺陷,但是攻擊者攻擊窗口的機(jī)會(huì)將會(huì)減少。

另一方面，Black＆Decker公司有一個(gè)相對(duì)短的一個(gè)星期的有效期，所以在他們的情況下，與外露的ELMAH日志。是的，有一系列壞的失敗對(duì)他們的一部分,但除非有人已經(jīng)記錄在“記住我”復(fù)選框打勾，在上周引起了未處理的異常,憑據(jù)不會(huì)被公開(kāi)展出。好吧,如果你是在網(wǎng)站上開(kāi)始有一個(gè)很好的機(jī)會(huì)(至少和Farmers例子比較,在那個(gè)網(wǎng)站上,你會(huì)不自覺(jué)地失去密碼在你的網(wǎng)站瀏覽過(guò)程中)但你可以看到，風(fēng)險(xiǎn)狀況如何變化在cookie的有效期間內(nèi)。

當(dāng)然所有這一切的基礎(chǔ)是需要仔細(xì)地保護(hù)認(rèn)證cookie；HttpOnly和安全屬性是絕對(duì)必須要做的事情。不過(guò)古典的劫持威脅仍然要重視，然而要分離這些最終與cookie相關(guān)的特性，你就需要非常非常仔細(xì)地看看這些cookie。

最終需要考慮諸多因素，比如站點(diǎn)的用戶數(shù)據(jù)對(duì)于攻擊者的價(jià)值、返回給用戶的未通過(guò)認(rèn)證的阻擋頁(yè)面和站點(diǎn)的其余安全配置等，然后再做權(quán)衡。例如，臉譜有一些有關(guān)社交方面的非常有用的數(shù)據(jù)，而且用戶期望在返回時(shí)得到低沖突（甚至沒(méi)有沖突）的處理，另外他們?cè)诎踩矫嬉呀?jīng)給予大量的投資。另外，Aussie Framer站點(diǎn)用戶個(gè)人擁有識(shí)別用戶的數(shù)據(jù)和財(cái)務(wù)信息 而且人們認(rèn)證后才獲得的所提供的服務(wù)（支付功能）仍然很少理解重要的安全理念。因此這兩個(gè)站點(diǎn)有著非常不同的風(fēng)險(xiǎn)配置，而且它們應(yīng)當(dāng)有非常不同的認(rèn)證 cookie過(guò)期策略。

增強(qiáng)授權(quán)途徑

很多人在審視通過(guò)cookie進(jìn)行授權(quán)的途徑的時(shí)候都會(huì)絕望地翻白眼, 對(duì)于安全這件事其實(shí)就是始終都有一種更好的方式(去實(shí)現(xiàn)), 這依賴于你愿意為之付出的時(shí)間/金錢/復(fù)雜度, 而且總會(huì)有那么一個(gè)人準(zhǔn)備告訴你: 你搞錯(cuò)了! 現(xiàn)在讓我們以授權(quán)cookie作為一個(gè)起始點(diǎn), 來(lái)探尋一些可能的方式來(lái)增強(qiáng)這個(gè)途徑.

反對(duì)長(zhǎng)期有效的授權(quán)cookie一個(gè)論據(jù)就是, 它們實(shí)際上會(huì)保證用戶處于已授權(quán)狀態(tài)并且處于被攻擊的風(fēng)險(xiǎn)之下, 類似于CSRF或者點(diǎn)擊劫持之類, 當(dāng)然, 應(yīng)用程序需要暴露其他的風(fēng)險(xiǎn)之處才能讓襲擊者利用長(zhǎng)期性的cookie, 但是關(guān)于整體縱深防御的論證又再度出現(xiàn)了. 一個(gè)可選方式就是保持一個(gè)專用cookie來(lái)應(yīng)對(duì)那些用戶 －他們?cè)谕ㄟ^(guò)了服務(wù)器對(duì)會(huì)話真實(shí)性的驗(yàn)證之后能夠在回來(lái)的時(shí)候發(fā)起一輪新的已授權(quán)會(huì)話, 這樣原始的會(huì)話就馬上失效了, 這里的技巧就是, 當(dāng)用戶帶著專用的"記住我"cookie的返回的時(shí)候重新設(shè)置一個(gè)新的會(huì)話, 并在這個(gè)過(guò)程中包含進(jìn)一些額外的驗(yàn)證.

提供額外的驗(yàn)證的一種方式是包含用戶的IP地址/用戶代理/等其他顯著特點(diǎn)的“記住我”的cookie。理由這樣的：這種方式提供了一些防御劫持的cookie。這樣也有個(gè)問(wèn)題，就是在正常使用的情況下這些也需要。在移動(dòng)世界中的情況更常見(jiàn)，許多終端常常共用一個(gè)IP，即使在平常的物理網(wǎng)絡(luò)中，你也不能完全信任ISP提供的靜態(tài)IP地址。至于用戶代理，如Chrome和Firefox這些 瀏覽器更新恍如隔日，你或許會(huì)認(rèn)定一個(gè)用戶代理中的字符串做 屬性進(jìn)行存儲(chǔ)和比較，但這將是一個(gè)有危險(xiǎn)的做法。 使用獨(dú)特的用戶屬性，在會(huì)話上下文間增加安全特性，cookie授權(quán)，我相信這都是有效的措施（再次回到銀行），我不能說(shuō)我已經(jīng)看過(guò)我測(cè)試過(guò)的網(wǎng)站已經(jīng)在使用，但使用是一個(gè)很好的理由…

一個(gè)更為務(wù)實(shí)的緩解方案是：依然把認(rèn)證cookie從一個(gè)專門的“記住我” cookie中分離出來(lái)，并使用后者來(lái)對(duì)用戶進(jìn)行重新認(rèn)證，但要施加一些限制。事實(shí)是，自動(dòng)持久化某人的認(rèn)證狀態(tài)的過(guò)程 – 不管是什么方式 – 都會(huì)要求安全模型做出妥協(xié)。一個(gè)緩解方案可以是這樣：在查看特定類型的數(shù)據(jù)或者執(zhí)行特定操作之前，要求一個(gè)自動(dòng)重新認(rèn)證的用戶再次明確的輸入他們的憑證。在“記住我”特性之外，這種做法并不是聞所未聞的新做法，你應(yīng)該在執(zhí)行高價(jià)值的操作時(shí)見(jiàn)過(guò)，比如銀行轉(zhuǎn)賬。這種情形下，我們說(shuō)認(rèn)證用戶面臨著更高的風(fēng)險(xiǎn)，因?yàn)楦锌赡芩麄儾⒉皇撬麄兯暦Q的那個(gè)人(也就是說(shuō)，另外一個(gè)人已經(jīng)坐在了電腦前并且有效的劫持了本次會(huì)話)。

我們可以應(yīng)用到這種方法的另一個(gè)強(qiáng)化措施是確保用來(lái)記住用戶的cookie在使用了以后要重置。這也意味著在服務(wù)器上使它失效，這就需要cookie的值既具有惟一性又具有持久性，例如在數(shù)據(jù)庫(kù)和cookie里保存的臨時(shí)變量。這有利于確保如果cookie被攻擊者獲得，那么它有僅僅只有一次單獨(dú)的使用機(jī)會(huì)---也就是如果用戶在它們失效之前不能合理的使用cookie才出現(xiàn)這樣的情形。這兒有一片很好的小小文章，它再次談?wù)摿诉@種方法的某些緩解措施，有些使用情形可能是有幫助的，不過(guò)你將需要投入更多地努力構(gòu)建cookie，還有些情形是cookie困擾著合法用戶（即試圖在橫跨多個(gè)服務(wù)器的同一個(gè)站點(diǎn)上記住你自己）。

#p#

最后一個(gè)值得提及的事情是：需要考慮已認(rèn)證的活動(dòng)會(huì)話的同一個(gè)賬戶的管理原則在“記住我”的上下文里是緊密相關(guān)的。例如，來(lái)自同一個(gè)用戶的多個(gè)同時(shí)已認(rèn)證會(huì)話是否允許？如果用戶更改了它們的密碼的話，是否要斷開(kāi)其余的會(huì)話？ 管理員是否結(jié)束已認(rèn)證了的會(huì)話？這兒出現(xiàn)的所有問(wèn)題實(shí)際上是有關(guān)如何驗(yàn)證和管理已認(rèn)證會(huì)話的一部分，這兒的討論僅僅關(guān)注在如何恢復(fù)哪個(gè)會(huì)話上。

什么時(shí)候不應(yīng)該允許“記住我”？ (以及一些中間路線選擇)

有時(shí)允許一個(gè)認(rèn)證用戶長(zhǎng)時(shí)間保持認(rèn)證態(tài)根本沒(méi)有意義。比如銀行業(yè)就是典型的案例，如果你想強(qiáng)制盡快的重新認(rèn)證，卻將已認(rèn)證的瀏覽器會(huì)話丟在一邊不用，就會(huì)使風(fēng)險(xiǎn)變得很大。

但實(shí)際上在這里可以采取一些中間路線：

這不完全是你看到的樣子——當(dāng)你選擇了“記住我”，又在會(huì)話過(guò)期以后返回，你將得到這個(gè)：

我沒(méi)有混淆用戶名，上面顯示的帶有星號(hào)的用戶名是存在于cookie中的，這個(gè)cookie會(huì)連同一些其他的必須被用來(lái)標(biāo)識(shí)用戶的數(shù)據(jù)一起，保留3個(gè)月。坦率地說(shuō),在這里面我沒(méi)有覺(jué)得有很多的意義，記住你的用戶名并不總會(huì)成為問(wèn)題！

但也不是說(shuō)就一定是非此即彼，你會(huì)有中間的選擇。例如，我早些時(shí)候發(fā)表的觀點(diǎn)，如果會(huì)話由“記住我”功能繼續(xù)下去，就需要在關(guān)鍵過(guò)程執(zhí)行之前再認(rèn)證。這似乎有點(diǎn)兩全其美。

總的來(lái)說(shuō)…

在某些方面下,這個(gè)特性是一個(gè)非常好的主意。它可以非常簡(jiǎn)單的去實(shí)現(xiàn)大部分你需要的功能。坦率地說(shuō),當(dāng)你去增加cookie的生命周期的時(shí)候,你仍然有一些困惑前面的兩個(gè)例子是怎么錯(cuò)的。

通過(guò)這篇文章,另外一個(gè)關(guān)鍵的地方是理解"記住我"特性的安全機(jī)制,例如一個(gè)多層次,相互交互的系統(tǒng)。你可能能夠擺脫在cookies里面加入證書,但是結(jié)合ELMAH情況或者缺少HTTPOnly屬性和XSS缺陷是非常愚蠢的,將會(huì)是一個(gè)嚴(yán)重的風(fēng)險(xiǎn)。那么"縱深防御"是怎么一回事呢!

英文原文：How to build (and how not to build) a secure “remember me” feature

譯文鏈接：http://www.oschina.net/translate/how-to-build-and-how-not-to-build