摘要：如何建立一個(gè)安全的記住我功能有這樣一個(gè)場景有個(gè)用戶初訪并登錄了你的網(wǎng)站，然而第二天他又來了，卻必須再次登錄。因此，應(yīng)該意識到對于如何建立記住我功能上的真正誤解，下面我們再來看看良性實(shí)踐。

有這樣一個(gè)場景——有個(gè)用戶初訪并登錄了你的網(wǎng)站，然而第二天他又來了，卻必須再次登錄。于是就有了“記住我”這樣的功能來方便用戶使用，然而有一件不言自明的事情，那就是這種認(rèn)證狀態(tài)的”曠日持久“早已超出了用戶原本所需要的使用范圍。這意味著，他們可以關(guān)閉瀏覽器，然后再關(guān)閉電腦，下周或者下個(gè)月，乃至更久以后再回來，只要這間隔時(shí)間不要太離譜，該網(wǎng)站總會知道誰是誰，并一如既往的為他們提供所有相同的功能和服務(wù)——與許久前他們離開的時(shí)候別無二致。

我在談?wù)摰木褪沁@個(gè)“小家伙”：

看上去是不是很巧很好用？那是當(dāng)然，但你也將看到，即便使用得當(dāng)，它能引發(fā)的那一茶幾悲劇也絕非偶然，少說能有一車皮的人準(zhǔn)備告訴你它是如何把事情搞糟的。那就讓我們從問題的根源出發(fā)吧。

這事情乍一看似乎很明顯，就是說“記住我”功能的應(yīng)用其實(shí)是非常基本的，不是那種很玄乎的東西，可事實(shí)上呢？顯然不是。

下面我會講解兩個(gè)反模式案例和問題的所在，以及談?wù)撊绾巫鍪钦_的。第一個(gè)例子，如圖所示，當(dāng)你登錄的時(shí)候：

這一切都非常符合標(biāo)準(zhǔn)，但有趣的事情發(fā)生在登錄之后，讓我們來看看cookies：

這個(gè)cookie相當(dāng)?shù)慕o力吧，尤其是被選中的黃色高亮部分。如果你沒勾選“記住我”的話，這些要命的信息是不會被cookie記錄的，所以那個(gè)功能原本也只是單純?yōu)榱朔奖阌脩粼僭L的。在圖中，我的郵箱地址是赤裸裸的，但密碼并非明文。然而不要高興得太早，對著那串似乎堅(jiān)不可摧的加密字符定睛一看……咦？等一下，這不是Base64編碼嗎！關(guān)于Base64編碼，這是一種可以被完整解碼的編碼，這意味著你可以隨便去哪個(gè)編碼轉(zhuǎn)換網(wǎng)站比如base64decode.org來做下面這件事：

并不是所有人都把Base64當(dāng)做“加密”（當(dāng)然，有的人真會用它來加密重要信息），雖說它確實(shí)是一種合理代替ASCII的方法，但事實(shí)上這種編碼的密碼僅僅在剛一進(jìn)入瀏覽器后就會立即轉(zhuǎn)變?yōu)槊魑摹Ｄ憧赡軙|(zhì)疑道?-?這能有多大問題？無論如何它只是存儲在自己的瀏覽器里，它能怎樣？那到底黑客能不能得到它呢？

下面我會介紹兩個(gè)非常簡單的方法，首先提及的內(nèi)容會和上面說的那種情況有關(guān)。Black＆Decker暴露了ELMAH日志，在這些日志中存在著完全未經(jīng)配置的內(nèi)部服務(wù)器錯(cuò)誤，而被排除的內(nèi)容是被記錄的內(nèi)容的幾萬倍。可是當(dāng)ELMAH記錄了一個(gè)異常，在執(zhí)行處理之前系統(tǒng)也會記錄所有的請求頭，這意味著這些內(nèi)容全都進(jìn)入了cookies。試想那數(shù)量龐大的被過濾掉的內(nèi)容其實(shí)全被轉(zhuǎn)存了起來，這簡直就等于有了一個(gè)用戶憑據(jù)的數(shù)據(jù)庫。當(dāng)然他們應(yīng)該已經(jīng)修補(bǔ)了這個(gè)問題，但它是一個(gè)很好的例子，如何輕而易舉的利用一個(gè)非常簡單的配置失誤。

接下來是另一個(gè)問題：

這個(gè)網(wǎng)站是Aussie?Farmers?Direct（以下統(tǒng)稱為AFD網(wǎng)），是一個(gè)相當(dāng)?shù)湫偷谋韱蔚顷憽Ｄ蔷偷卿浛纯矗⑶易尵W(wǎng)站“記住我”，接著就來看cookies吧：

好家伙，還是同樣的狀況，甚至連Base64編碼都沒加。要說這一點(diǎn)有多糟糕，來看你可以做這個(gè)：

XSS自己的JSON?cookie？當(dāng)然可以這么玩，這樣一來，如果你的密碼改了但cookie還不變，等你再次登錄的時(shí)候，它就試圖用舊密碼登錄。嗯?

AFD網(wǎng)并沒有暴露他們的ELMAH日志（PHP好樣的！）但他們還有其他風(fēng)險(xiǎn)，如XSS。有關(guān)上述網(wǎng)站的另一件事是，這些存儲在Cookie中的密碼并沒有被標(biāo)記成HttpOnly，你可以在右邊的cookie列表中看到。這意味著，客戶端腳本可以訪問這些cookies，這就等于是只要你能讓XSS成功，就可以通過讓其他用戶加載XSS?payload，竊取包含密碼的cookie，（這樣做的有效方法很多）。缺少了HttpOnly屬性或許是一時(shí)馬虎，但問題的核心在于存儲在cookie中的密碼會很容易地通過其他途徑疏漏出去。

還有一個(gè)更根本的原因，為什么這些網(wǎng)站會同時(shí)在這點(diǎn)上疏忽大意，盡管他們都在保護(hù)自己客戶在其網(wǎng)站上使用的憑據(jù)。每當(dāng)上述網(wǎng)站的客戶勾選了“記住我”功能并向網(wǎng)站上發(fā)出請求時(shí)，當(dāng)他們的用戶名和密碼被網(wǎng)站發(fā)送到他們的郵箱時(shí)，當(dāng)他們操作eBay或網(wǎng)銀時(shí)。要么密碼是明文，要么可以通過客戶端腳本獲取，總之密碼總會一絲不掛的躺在瀏覽器里。大量的人有密碼復(fù)用（通用）的習(xí)慣?，然而為那些熱愛作死的用戶承擔(dān)責(zé)任的，卻是我們開發(fā)者。我不得不說，當(dāng)我們應(yīng)對那些用戶憑據(jù)威脅的時(shí)候，需要實(shí)施的保護(hù)措施要遠(yuǎn)遠(yuǎn)超過網(wǎng)站本身。

因此，應(yīng)該意識到對于如何建立“記住我”功能上的真正誤解，下面我們再來看看良性實(shí)踐。

在安全界混，有句話你應(yīng)該會很熟悉，“不用你自己試?-?就用那個(gè)公認(rèn)最給力的就行”。這類話在加密和認(rèn)證計(jì)劃中非常容易聽到，亦可應(yīng)用在本文課題，借鑒過來深入研究細(xì)節(jié)。

在一個(gè)用Visual?Studio?2012建設(shè)的ASP.NET?MVC?4網(wǎng)站中，你會看到這個(gè)：

其他框架有其他的標(biāo)準(zhǔn)模式來實(shí)現(xiàn)此功能，但這個(gè)更容易作為參考。當(dāng)我們通過提交上面的表單進(jìn)行登錄時(shí)，并且不要求“記住我”，以下的cookie被成功驗(yàn)證，結(jié)果返回：

Set-Cookie:.ASPXAUTH=6891A5EAF17A9C35B51C4ED3C473FBA294187C97B758880F9A56E3D335E2F020B86A85E1D0074BDAB2E1C9DBE590AF67895C0F989BA137E292035A3093A702DEC9D0D8089E1D007089F75A77D1B2A79CAA800E8F62D3D807CBB86779DB52F012;?path=/;?HttpOnly

這是一個(gè)簡單的身份驗(yàn)證cookie，并捆綁了所有HTTP的數(shù)據(jù)。這種我專屬的cookie被發(fā)送后，網(wǎng)站就每次都能知道這是我而且我已經(jīng)被驗(yàn)證了。我們還能看得更清楚，比如當(dāng)我們用Chrome’s?Cookies?collection的時(shí)候：

另外，第二個(gè)cookie是一個(gè)防偽標(biāo)記，以防止CSRF攻擊，并且與我們的認(rèn)證狀態(tài)無關(guān)。除此之外，有沒有其他的cookie。

現(xiàn)在，讓我們勾選上“記住我”然后再次登錄看看cookie的響應(yīng)：

Set-Cookie:.ASPXAUTH=3A92DAC7EFF4EE5B2027A13DD8ABEA8254F0A16D8059FCAF60F5533F1B7D99462DDF57320D069A493481978750526DF952D5C9EA0371C84F5CF1BFC0CCA024C2052824D4BA09670A42B85AEC7FFCB4088FC744C6C0A22749F07AF6E65E674A4A;?expires=Tue,?02-Jul-2013?00:27:05?GMT;?path=/;?HttpOnly

來了你看到?jīng)]？來用Chrome解剖一下看看：

我們現(xiàn)在有了一個(gè)有效期為48小時(shí)的cookie，如果當(dāng)它過了期限，它在瀏覽器關(guān)閉時(shí)，將被丟棄。讓我們來仔細(xì)看看。

其實(shí)，這是一個(gè)簡單得略顯荒謬的安全構(gòu)造，我都甚至認(rèn)為它沒有寫出來的價(jià)值，來看一下這里：在這個(gè)例子中，“記住我”功能可以簡單地歸結(jié)為，它控制了cookie的時(shí)限并且決定某個(gè)人能夠持續(xù)登錄多久。

在上面的例子中，ASP.NET默認(rèn)使用一個(gè)會話cookie，或者換句話說，一個(gè)cookie，而且沒有一個(gè)明確的截止日期，因此將在瀏覽器關(guān)閉時(shí)強(qiáng)行過期。這是一種方法，另一種是直接置入短保質(zhì)期，即使瀏覽器繼續(xù)使用該cookie，用戶也將被自動注銷。當(dāng)然，你也可以在服務(wù)器上控制這種行為，你也可以讓身份驗(yàn)證cookie的時(shí)限不斷延長，如果系統(tǒng)正在積極使用由服務(wù)器響應(yīng)增加的時(shí)限。

只要保持這個(gè)驗(yàn)證cookie有效，特定的人就會被記住。那多久的時(shí)效才合適呢？上面的例子中默認(rèn)為2天，但這對于合法的使用者顯然有些過短。而Facebook的cookie卻能持續(xù)一年。持續(xù)時(shí)間較短，意味著更少的風(fēng)險(xiǎn)，但更多的不便，持續(xù)時(shí)間較長，使得它更容易為用戶增加潛在的風(fēng)險(xiǎn)。讓我們更進(jìn)一步的看看這個(gè)風(fēng)險(xiǎn)。

當(dāng)在被認(rèn)證之前，你的會話無法被劫持。廢話，這是當(dāng)然的！但認(rèn)真看的話，像在上面AFD網(wǎng)的那種情況下，該cookie將在6個(gè)月后到期，與此同時(shí)它沒有HTTP?only的標(biāo)記，這樣一來他們網(wǎng)站的XSS漏洞可以為攻擊者提供半年的時(shí)間去獲取并使用用戶的憑證。同樣的情況，如果時(shí)限為1個(gè)月，他們?nèi)詴幸恍﹪?yán)重的漏洞，但上述攻擊的機(jī)會實(shí)實(shí)在在地得到了削減。

另一方面，Black＆Decker網(wǎng)有一個(gè)相對短的——一周的期限。在他們暴露著ELMAH日志的情況下，依然有一系列的重大疏漏，但除非有人在一周前已經(jīng)用“記住我”登錄了網(wǎng)站，并且觸發(fā)了那個(gè)默認(rèn)配置的漏洞，否則憑據(jù)不會被泄露。如果你想找個(gè)網(wǎng)站自己試試看的話，就算是一個(gè)你已經(jīng)登錄過的網(wǎng)站，也可以看到存在時(shí)限風(fēng)險(xiǎn)的cookie。

所以說一切有關(guān)身份驗(yàn)證的cookie如果想要保護(hù)好用戶憑據(jù)的話，HttpOnly的安全屬性是和嚴(yán)謹(jǐn)?shù)陌踩珣B(tài)度必須的。雖然所有經(jīng)典的劫持威脅仍然存在，不過，解決這些cookie上的問題也是絕不容忽視的。

歸根結(jié)底，這是一個(gè)權(quán)衡，需要考慮的因素如攻擊者要取得的數(shù)據(jù)的價(jià)值，在加強(qiáng)驗(yàn)證安全性時(shí)對于用戶使用的便捷性和網(wǎng)站安全配置所造成的負(fù)面影響。例如，F(xiàn)acebook中存在著一些非常有用的社會性的用戶數(shù)據(jù)，而用戶又非常希望無延時(shí)般的響應(yīng)速度，在此之上他們還對自己的賬戶安全上進(jìn)行了大筆的投資。而對于AFD網(wǎng)，在持有用戶個(gè)人身份數(shù)據(jù)以及財(cái)務(wù)信息的同時(shí)，提供了用戶所要求的安全驗(yàn)證服務(wù)，能看出用戶本身也是有相關(guān)安全意識的。他們有著迥然不同的風(fēng)險(xiǎn)，這兩個(gè)網(wǎng)站對于身份驗(yàn)證cookie的時(shí)限策略應(yīng)該是完全不同的。

或許有些同學(xué)會覺得AUTH?cookie很無解，有關(guān)安全性的東西總會有一種更好的解決方案，但這是有代價(jià)的，安全性取決于你愿意付出的的時(shí)間、金錢、便利性，而且也總會有人告訴你，你做錯(cuò)了！讓我們來看看關(guān)于使用AUTH?cookie時(shí)限的一些可能的加強(qiáng)方法。

對于一個(gè)長期有效的AUTH?cookie，問題在于他們需要有效地保持用戶身份的驗(yàn)證和面對如CSRF或clickjacking等攻擊風(fēng)險(xiǎn)。當(dāng)然，還有很多需要利用長期cookie的風(fēng)險(xiǎn)并沒有列出，但這并不影響圍繞防范方法的討論。還有一點(diǎn)就是當(dāng)一個(gè)專用cookie為用戶在服務(wù)器上提供過有效認(rèn)證之后，在返回時(shí)它還可以重新開啟另一個(gè)認(rèn)證會話。雖然最初的會話會迅速到期，但關(guān)鍵是重啟的新會話，它會因?yàn)橛脩艄催x了“記住我”并再次登錄而進(jìn)行另外的驗(yàn)證。

一種驗(yàn)證方式包括利用用戶的IP地址/用戶代理/其他顯著特點(diǎn)來限制“記住我”的cookie。這能提供一些對cookie劫持的防御。當(dāng)然，要在合法使用的情況下進(jìn)行這些變更。特別是在移動網(wǎng)絡(luò)中這類的情況并不少見——用不同的IP回訪一個(gè)網(wǎng)站。你的ISP不一定總會提供靜態(tài)的IP地址。至于用戶代理，還有瀏覽器差異，如Chrome和Firefox的更新簡直恍如隔日。然而除非你刻意去挑選某些優(yōu)質(zhì)的代理，否則使用代理將是一個(gè)危險(xiǎn)的做法。

還有一種程序化的手段，就是保持“記住我”cookie和身份驗(yàn)證cookie的分離，并使用前者重新驗(yàn)證用戶的身份，但要額外施加一些限制。實(shí)際情況是，某個(gè)身份的自動認(rèn)證狀態(tài)的過程，一定會遵循安全模型。緩和措施的結(jié)果就是，它會在自動重新驗(yàn)證之前，向用戶再次索要憑據(jù)。這并非創(chuàng)新之舉，你或許會在進(jìn)行例如網(wǎng)銀匯款時(shí)遇到過此類功能。在這里，我們說身份驗(yàn)證的用戶面臨的風(fēng)險(xiǎn)很大，因?yàn)檫@種方式很容易被劫持和欺騙。

至于其他加強(qiáng)方法，我們可以在“記住我”cookie被使用后進(jìn)行復(fù)位。這也等于讓它在服務(wù)器端無效，而需要一個(gè)獨(dú)特且持久的cookie值，例如存在于數(shù)據(jù)庫和cookie間的一個(gè)隨機(jī)數(shù)。這樣有利于確保cookie不會被攻擊者用下面的方式獲得。在這里的文章中，作者談?wù)摿艘恍╆P(guān)于這類模式的緩解方法。但你需要付出一些額外的工作，并在某種程度上給正常的用戶帶來不便（例如用戶無法跨越多個(gè)電腦使用并“記住”自己的憑據(jù)）。

最后一件值得提一句的是，同一帳戶下的管理原則，它需要我們?nèi)リP(guān)注并且和“記住我”功能有關(guān)。例如，允許單一用戶的多個(gè)會話同時(shí)驗(yàn)證？或者用戶一旦更改了密碼要不要將會話斷開？管理員可不可以結(jié)束驗(yàn)證會話？出現(xiàn)了各種各樣的問題，不過這里要討論的僅僅是關(guān)于如何復(fù)原。

什么時(shí)候不該用“記住我”功能？（以及一些替代功能）

有時(shí)候，允許一個(gè)經(jīng)過認(rèn)證的用戶保持認(rèn)證狀態(tài)很長一段時(shí)間是毫無意義的。例如銀行，在常規(guī)的使用情況下，當(dāng)你想圖省事非要進(jìn)行自動登錄時(shí)，在你走人以后留在那里的是一個(gè)未登出的瀏覽器，風(fēng)險(xiǎn)多大不用我說了吧。

但其實(shí)還是有一些中間地帶可以采取下面這種做法：

這個(gè)登陸框并不是看上去的那么弱，當(dāng)你用“記住我”登錄過后，再次回訪的時(shí)候，網(wǎng)站的會話就過期了，你會看到：

用戶名這個(gè)樣子可不是我起的，是因?yàn)樗B同其他一些數(shù)據(jù)在cookie中存了三個(gè)月。坦白地說，這么做沒有意義，因?yàn)橛涀∮脩裘浑y啊！

但是，這種情況既不能全否也不能全部肯定，這是個(gè)灰色的中間地帶。例如，假設(shè)在通過“記住我”功能恢復(fù)會話時(shí)，重新認(rèn)證是在主進(jìn)程之前啟動的。這或許是一個(gè)兩全齊美的做法。

這個(gè)也不例外，總會有些功能看上去似乎是一個(gè)好主意，而且它通常是很容易做好的，至少可以適合大多數(shù)的項(xiàng)目。坦率來講，前面兩個(gè)例子仍然莫名其妙的讓人頭疼，特別是當(dāng)你考慮到它本來只是用于延長cookie時(shí)限的。

另外，這篇文章的重點(diǎn)并不局限于分解“記住我”功能的安全結(jié)構(gòu)，你可能能夠自行解決自己的cookie憑據(jù)問題，但結(jié)合起ELMAH和缺少HTTP?only屬性以及XSS漏洞的情況考慮，時(shí)刻警惕一個(gè)不經(jīng)意的行為，（行為）雖然看似無害但卻很可能造成一個(gè)嚴(yán)重的安全風(fēng)險(xiǎn)。

原文 How to build (and how not to build) a secure “remember me” feature
翻譯 IDF實(shí)驗(yàn)室 張俊