如何建立一個安全的“記住我”功能
有這樣一個場景——有個用戶初訪并登錄了你的網(wǎng)站，然而第二天他又來了，卻必須再次登錄。于是就有了“記住我”這樣的功能來方便用戶使用，然而有一件不言自明的事情，那就是這種認證狀態(tài)的”曠日持久“早已超出了用戶原本所需要的使用范圍。這意味著，他們可以關(guān)閉瀏覽器，然后再關(guān)閉電腦，下周或者下個月，乃至更久以后再回來，只要這間隔時間不要太離譜，該網(wǎng)站總會知道誰是誰，并一如既往的為他們提供所有相同的功能和服務(wù)——與許久前他們離開的時候別無二致。
我在談?wù)摰木褪沁@個“小家伙”：
看上去是不是很巧很好用?那是當(dāng)然，但你也將看到，即便使用得當(dāng)，它能引發(fā)的那一茶幾悲劇也絕非偶然，少說能有一車皮的人準(zhǔn)備告訴你它是如何把事情搞糟的。那就讓我們從問題的根源出發(fā)吧。
反模式
這事情乍一看似乎很明顯，就是說“記住我”功能的應(yīng)用其實是非常基本的，不是那種很玄乎的東西，可事實上呢?顯然不是。
下面我會講解兩個反模式案例和問題的所在，以及談?wù)撊绾巫鍪钦_的。第一個例子，如圖所示，當(dāng)你登錄的時候：
這一切都非常符合標(biāo)準(zhǔn)，但有趣的事情發(fā)生在登錄之后，讓我們來看看cookies：
這個cookie相當(dāng)?shù)慕o力吧，尤其是被選中的黃色高亮部分。如果你沒勾選“記住我”的話，這些要命的信息是不會被cookie記錄的，所以那個功能原本也只是單純?yōu)榱朔奖阌脩粼僭L的。在圖中，我的郵箱地址是赤裸裸的，但密碼并非明文。然而不要高興得太早，對著那串似乎堅不可摧的加密字符定睛一看……咦?等一下，這不是Base64編碼嗎!關(guān)于Base64編碼，這是一種可以被完整解碼的編碼，這意味著你可以隨便去哪個編碼轉(zhuǎn)換網(wǎng)站比如base64decode.org來做下面這件事：
并不是所有人都把Base64當(dāng)做“加密”(當(dāng)然，有的人真會用它來加密重要信息)，雖說它確實是一種合理代替ASCII的方法，但事實上這種編碼的密碼僅僅在剛一進入瀏覽器后就會立即轉(zhuǎn)變?yōu)槊魑摹Ｄ憧赡軙|(zhì)疑道 - 這能有多大問題?無論如何它只是存儲在自己的瀏覽器里，它能怎樣?那到底黑客能不能得到它呢?
下面我會介紹兩個非常簡單的方法，首先提及的內(nèi)容會和上面說的那種情況有關(guān)。Black&Decker暴露了ELMAH日志，在這些日志中存在著完全未經(jīng)配置的內(nèi)部服務(wù)器錯誤，而被排除的內(nèi)容是被記錄的內(nèi)容的幾萬倍。可是當(dāng)ELMAH記錄了一個異常，在執(zhí)行處理之前系統(tǒng)也會記錄所有的請求頭，這意味著這些內(nèi)容全都進入了cookies。試想那數(shù)量龐大的被過濾掉的內(nèi)容其實全被轉(zhuǎn)存了起來，這簡直就等于有了一個用戶憑據(jù)的數(shù)據(jù)庫。當(dāng)然他們應(yīng)該已經(jīng)修補了這個問題，但它是一個很好的例子，如何輕而易舉的利用一個非常簡單的配置失誤。
接下來是另一個問題：
這個網(wǎng)站是Aussie Farmers Direct(以下統(tǒng)稱為AFD網(wǎng))，是一個相當(dāng)?shù)湫偷谋韱蔚顷憽Ｄ蔷偷卿浛纯矗⑶易尵W(wǎng)站“記住我”，接著就來看cookies吧：
好家伙，還是同樣的狀況，甚至連Base64編碼都沒加。要說這一點有多糟糕，來看你可以做這個：
XSS自己的JSON cookie?當(dāng)然可以這么玩，這樣一來，如果你的密碼改了但cookie還不變，等你再次登錄的時候，它就試圖用舊密碼登錄。嗯?
AFD網(wǎng)并沒有暴露他們的ELMAH日志(PHP好樣的!)但他們還有其他風(fēng)險，如XSS。有關(guān)上述網(wǎng)站的另一件事是，這些存儲在Cookie中的密碼并沒有被標(biāo)記成HttpOnly，你可以在右邊的cookie列表中看到。這意味著，客戶端腳本可以訪問這些cookies，這就等于是只要你能讓XSS成功，就可以通過讓其他用戶加載XSS payload，竊取包含密碼的cookie，(這樣做的有效方法很多)。缺少了HttpOnly屬性或許是一時馬虎，但問題的核心在于存儲在cookie中的密碼會很容易地通過其他途徑疏漏出去。
還有一個更根本的原因，為什么這些網(wǎng)站會同時在這點上疏忽大意，盡管他們都在保護自己客戶在其網(wǎng)站上使用的憑據(jù)。每當(dāng)上述網(wǎng)站的客戶勾選了“記住我”功能并向網(wǎng)站上發(fā)出請求時，當(dāng)他們的用戶名和密碼被網(wǎng)站發(fā)送到他們的郵箱時，當(dāng)他們操作eBay或網(wǎng)銀時。要么密碼是明文，要么可以通過客戶端腳本獲取，總之密碼總會一絲不掛的躺在瀏覽器里。大量的人有密碼復(fù)用(通用)的習(xí)慣 ，然而為那些熱愛作死的用戶承擔(dān)責(zé)任的，卻是我們開發(fā)者。我不得不說，當(dāng)我們應(yīng)對那些用戶憑據(jù)威脅的時候，需要實施的保護措施要遠遠超過網(wǎng)站本身。
因此，應(yīng)該意識到對于如何建立“記住我”功能上的真正誤解，下面我們再來看看良性實踐。#p#
樣本基于實操
實例
在安全界混，有句話你應(yīng)該會很熟悉，“不用你自己試 - 就用那個公認最給力的就行”。這類話在加密和認證計劃中非常容易聽到，亦可應(yīng)用在本文課題，借鑒過來深入研究細節(jié)。
在一個用Visual Studio 2012建設(shè)的ASP.NET MVC 4網(wǎng)站中，你會看到這個：
其他框架有其他的標(biāo)準(zhǔn)模式來實現(xiàn)此功能，但這個更容易作為參考。當(dāng)我們通過提交上面的表單進行登錄時，并且不要求“記住我”，以下的cookie被成功驗證，結(jié)果返回：
Set-Cookie:.ASPXAUTH=6891A5EAF17A9C35B51C4ED3C473FBA29418 7C97B758880F9A56E3D335E2F020B86A85E1D0074BDAB2E1C9DBE590A F67895C0F989BA137E292035A3093A702DEC9D0D8089E1D007089F75 77D1B2A79CAA800E8F62D3D807CBB86779DB52F012; path=/; HttpOnly
這是一個簡單的身份驗證cookie，并捆綁了所有HTTP的數(shù)據(jù)。這種我專屬的cookie被發(fā)送后，網(wǎng)站就每次都能知道這是我而且我已經(jīng)被驗證了。我們還能看得更清楚，比如當(dāng)我們用Chrome’s Cookies collection的時候：
另外，第二個cookie是一個防偽標(biāo)記，以防止CSRF攻擊，并且與我們的認證狀態(tài)無關(guān)。除此之外，有沒有其他的cookie。
現(xiàn)在，讓我們勾選上“記住我”然后再次登錄看看cookie的響應(yīng)：
Set-Cookie:.ASPXAUTH=3A92DAC7EFF4EE5B2027A13DD8ABEA8254 F0A16D8059FCAF60F5533F1B7D99462DDF57320D069A49348197875 0526DF952D5C9EA0371C84F5CF1BFC0CCA024C2052824D4BA09670A 42B85AEC7FFCB4088FC744C6C0A22749F07AF6E65E674A4A; expires=Tue, 02-Jul-2013 00:27:05 GMT; path=/; HttpOnly
來了你看到?jīng)]?來用Chrome解剖一下看看：
我們現(xiàn)在有了一個有效期為48小時的cookie，如果當(dāng)它過了期限，它在瀏覽器關(guān)閉時，將被丟棄。讓我們來仔細看看。
尋找身份驗證Cookie的時限部分
其實，這是一個簡單得略顯荒謬的安全構(gòu)造，我都甚至認為它沒有寫出來的價值，來看一下這里：在這個例子中，“記住我”功能可以簡單地歸結(jié)為，它控制了cookie的時限并且決定某個人能夠持續(xù)登錄多久。
在上面的例子中，ASP.NET默認使用一個會話cookie，或者換句話說，一個cookie，而且沒有一個明確的截止日期，因此將在瀏覽器關(guān)閉時強行過期。這是一種方法，另一種是直接置入短保質(zhì)期，即使瀏覽器繼續(xù)使用該cookie，用戶也將被自動注銷。當(dāng)然，你也可以在服務(wù)器上控制這種行為，你也可以讓身份驗證cookie的時限不斷延長，如果系統(tǒng)正在積極使用由服務(wù)器響應(yīng)增加的時限。
只要保持這個驗證cookie有效，特定的人就會被記住。那多久的時效才合適呢?上面的例子中默認為2天，但這對于合法的使用者顯然有些過短。而Facebook的cookie卻能持續(xù)一年。持續(xù)時間較短，意味著更少的風(fēng)險，但更多的不便，持續(xù)時間較長，使得它更容易為用戶增加潛在的風(fēng)險。讓我們更進一步的看看這個風(fēng)險。#p#
長期認證狀態(tài)的利用
當(dāng)在被認證之前，你的會話無法被劫持。廢話，這是當(dāng)然的!但認真看的話，像在上面AFD網(wǎng)的那種情況下，該cookie將在6個月后到期，與此同時它沒有HTTP only的標(biāo)記，這樣一來他們網(wǎng)站的XSS漏洞可以為攻擊者提供半年的時間去獲取并使用用戶的憑證。同樣的情況，如果時限為1個月，他們?nèi)詴幸恍﹪乐氐穆┒矗鲜龉舻臋C會實實在在地得到了削減。
另一方面，Black&Decker網(wǎng)有一個相對短的——一周的期限。在他們暴露著ELMAH日志的情況下，依然有一系列的重大疏漏，但除非有人在一周前已經(jīng)用“記住我”登錄了網(wǎng)站，并且觸發(fā)了那個默認配置的漏洞，否則憑據(jù)不會被泄露。如果你想找個網(wǎng)站自己試試看的話，就算是一個你已經(jīng)登錄過的網(wǎng)站，也可以看到存在時限風(fēng)險的cookie。
所以說一切有關(guān)身份驗證的cookie如果想要保護好用戶憑據(jù)的話，HttpOnly的安全屬性是和嚴謹?shù)陌踩珣B(tài)度必須的。雖然所有經(jīng)典的劫持威脅仍然存在，不過，解決這些cookie上的問題也是絕不容忽視的。
歸根結(jié)底，這是一個權(quán)衡，需要考慮的因素如攻擊者要取得的數(shù)據(jù)的價值，在加強驗證安全性時對于用戶使用的便捷性和網(wǎng)站安全配置所造成的負面影響。例如，F(xiàn)acebook中存在著一些非常有用的社會性的用戶數(shù)據(jù)，而用戶又非常希望無延時般的響應(yīng)速度，在此之上他們還對自己的賬戶安全上進行了大筆的投資。而對于AFD網(wǎng)，在持有用戶個人身份數(shù)據(jù)以及財務(wù)信息的同時，提供了用戶所要求的安全驗證服務(wù)，能看出用戶本身也是有相關(guān)安全意識的。他們有著迥然不同的風(fēng)險，這兩個網(wǎng)站對于身份驗證cookie的時限策略應(yīng)該是完全不同的。
強化
或許有些同學(xué)會覺得AUTH cookie很無解，有關(guān)安全性的東西總會有一種更好的解決方案，但這是有代價的，安全性取決于你愿意付出的的時間、金錢、便利性，而且也總會有人告訴你，你做錯了!讓我們來看看關(guān)于使用AUTH cookie時限的一些可能的加強方法。
對于一個長期有效的AUTH cookie，問題在于他們需要有效地保持用戶身份的驗證和面對如CSRF或clickjacking等攻擊風(fēng)險。當(dāng)然，還有很多需要利用長期cookie的風(fēng)險并沒有列出，但這并不影響圍繞防范方法的討論。還有一點就是當(dāng)一個專用cookie為用戶在服務(wù)器上提供過有效認證之后，在返回時它還可以重新開啟另一個認證會話。雖然最初的會話會迅速到期，但關(guān)鍵是重啟的新會話，它會因為用戶勾選了“記住我”并再次登錄而進行另外的驗證。
一種驗證方式包括利用用戶的IP地址/用戶代理/其他顯著特點來限制“記住我”的cookie。這能提供一些對cookie劫持的防御。當(dāng)然，要在合法使用的情況下進行這些變更。特別是在移動網(wǎng)絡(luò)中這類的情況并不少見——用不同的IP回訪一個網(wǎng)站。你的ISP不一定總會提供靜態(tài)的IP地址。至于用戶代理，還有瀏覽器差異，如Chrome和Firefox的更新簡直恍如隔日。然而除非你刻意去挑選某些優(yōu)質(zhì)的代理，否則使用代理將是一個危險的做法。
還有一種程序化的手段，就是保持“記住我”cookie和身份驗證cookie的分離，并使用前者重新驗證用戶的身份，但要額外施加一些限制。實際情況是，某個身份的自動認證狀態(tài)的過程，一定會遵循安全模型。緩和措施的結(jié)果就是，它會在自動重新驗證之前，向用戶再次索要憑據(jù)。這并非創(chuàng)新之舉，你或許會在進行例如網(wǎng)銀匯款時遇到過此類功能。在這里，我們說身份驗證的用戶面臨的風(fēng)險很大，因為這種方式很容易被劫持和欺騙。
至于其他加強方法，我們可以在“記住我”cookie被使用后進行復(fù)位。這也等于讓它在服務(wù)器端無效，而需要一個獨特且持久的cookie值，例如存在于數(shù)據(jù)庫和cookie間的一個隨機數(shù)。這樣有利于確保cookie不會被攻擊者用下面的方式獲得。在這里的文章中，作者談?wù)摿艘恍╆P(guān)于這類模式的緩解方法。但你需要付出一些額外的工作，并在某種程度上給正常的用戶帶來不便(例如用戶無法跨越多個電腦使用并“記住”自己的憑據(jù))。
最后一件值得提一句的是，同一帳戶下的管理原則，它需要我們?nèi)リP(guān)注并且和“記住我”功能有關(guān)。例如，允許單一用戶的多個會話同時驗證?或者用戶一旦更改了密碼要不要將會話斷開?管理員可不可以結(jié)束驗證會話?出現(xiàn)了各種各樣的問題，不過這里要討論的僅僅是關(guān)于如何復(fù)原。#p#
什么時候不該用“記住我”功能?(以及一些替代功能)
有時候，允許一個經(jīng)過認證的用戶保持認證狀態(tài)很長一段時間是毫無意義的。例如銀行，在常規(guī)的使用情況下，當(dāng)你想圖省事非要進行自動登錄時，在你走人以后留在那里的是一個未登出的瀏覽器，風(fēng)險多大不用我說了吧。
但其實還是有一些中間地帶可以采取下面這種做法：
這個登陸框并不是看上去的那么弱，當(dāng)你用“記住我”登錄過后，再次回訪的時候，網(wǎng)站的會話就過期了，你會看到：
用戶名這個樣子可不是我起的，是因為它連同其他一些數(shù)據(jù)在cookie中存了三個月。坦白地說，這么做沒有意義，因為記住用戶名不難啊!
但是，這種情況既不能全否也不能全部肯定，這是個灰色的中間地帶。例如，假設(shè)在通過“記住我”功能恢復(fù)會話時，重新認證是在主進程之前啟動的。這或許是一個兩全齊美的做法。
總結(jié)
這個也不例外，總會有些功能看上去似乎是一個好主意，而且它通常是很容易做好的，至少可以適合大多數(shù)的項目。坦率來講，前面兩個例子仍然莫名其妙的讓人頭疼，特別是當(dāng)你考慮到它本來只是用于延長cookie時限的。
另外，這篇文章的重點并不局限于分解“記住我”功能的安全結(jié)構(gòu)，你可能能夠自行解決自己的cookie憑據(jù)問題，但結(jié)合起ELMAH和缺少HTTP only屬性以及XSS漏洞的情況考慮，時刻警惕一個不經(jīng)意的行為，(行為)雖然看似無害但卻很可能造成一個嚴重的安全風(fēng)險。
本文來自微軟安全專家Troy Hunt的博客，由IDF成員張俊翻譯，章典校對。
