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

我所說的就是下面這個小東西：

看起來很簡單, 是吧? 也許是，但是你將會看到把它弄得一團糟的情況并不少見，而且，即使你做對了，也會有一大隊人等著告訴你，實際上你仍然不夠正確。讓我們從一些完全錯誤的做法開始我們的工作。

適得其反的模式

這看起來挺明顯的嗎，不是嗎？我是說關于“記住我”這個特性的模型還是挺基礎的，不是那種很容易搞錯的東西。你確定嗎？顯然不是。

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

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

這是cookies的一些相關屬性和值。但是高亮部分是真正值得關注的地方。假如用戶沒有選擇"記住我 "按鈕,這些cookies的信息不會存在,所以它們的功能純粹是為了用戶稍后登錄。我的用戶名是相當的清楚,我的密碼被加過密碼。注意看看這個密碼,那是Base64編碼!這就意味著密碼被實現由Base64編碼,你能攔截它在某些地方例 如 base64decode.org 這樣做：

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

我將要去討論兩種簡單的方式。第一種方式是涉及到前面鏈接的不安全的信息。Black & Decker 已經暴露了ElEMH日志和這些日志相關的未處理服務器異常。我會通知它們在 50,000的北方。當ELMAH日志發生異常,那么意味著cookies(所有請求頭信息)將會被記錄。系統將會拋出大量的錯誤信息,你會接受到一個用戶憑證。是的,他們應該開始恰當地保護ELMAH日志信息。但它是一個很好的例子,你怎么可以很容易地通過一個非常簡單的配置撤消錯誤信息。

這里有另外的一個：

這就是 Aussie Farmers Direct 。它的登錄界面看起來非常傳統。當我們開始登錄并打上"記住我"的標志的時候, 我們看一眼相關的cookies信息。

哇親愛的,相同的處理方式但是沒有任何Base64編碼。事實上,這樣是相當的不合理,因為你能夠操作像下面這樣。

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

#p#

Aussie Farmers Direct 沒有暴露出ELMAH日志信息 (因為PHP友好的處理了它) 。但是,它仍然有其它的風險例如XSS(順便說一下,它們多次負責任的關閉和處理了風險。)另外一件事情是上面2個網站的cookies處理密碼沒有標記作為HttpOnly, 你能看見它們在cookie列表的第二列。那就意味著客戶端腳本訪問這些cookies,那就意味著如果你能到網站上得到XSS。假如你能夠讓用戶去運行 XSS負載(現在有多種方式去做),你就能偷到包含的密碼的cookies信息,訪問Aussie Farmers 網站。缺少了HttpOnly屬性是代表這兩個網站上的馬虎,但是核心的問題用cookies存儲你的密碼,然后使他們很容易通過其他疏漏。

從根本上來說,最重要的原因主要是這兩個網站的疏忽。他們保護用戶的證書被用在網站。在網站上,用戶每一次使用"記住我"特征,用戶發送了一個請求。現在有一個好的選擇就是發送他們的用戶名和密碼到他們的郵箱,或者eBay,或者它們的銀行通過線路,有時候用文本,有時候訪問用客戶端腳本。總是放在瀏覽器中未受到保護。密碼重用是瘋狂,而這些該死的用戶該付出血淋淋的責任(我在這里轉述!),我們—作為開發者—當我們處理憑據時,我們必須認識到保護遠遠超過只是我們自己的網站。

因此，我們應該建立"記住我"的功能的真正誤區。讓我們開始走向正確的實踐道路。

一個參考的實現樣本

安全領域中你能經常聽到的箴言之一就是“不要使用你自己的——使用已經證實是安全的”。它被非常頻繁地應用于加密和身份驗證方案中，但是現在我們可以將這個擴展到“記住我”的特性，以便在我們深入細節之前，先從一個好的參考實現開始。

在一個由Visual Studio 2012新建的ASP.NET MVC 4網站中，你能得到這個開箱即用的登錄界面：

其它的框架有其它實現這個特性的標準模式，但這個參考起來很容易。當我們像上面這樣填寫字段登陸的時候（即不要讓它記住我），驗證成功則會返回如下cookie結果：

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

這只是個簡單的驗證cookie, 在無狀態的HTTP世界里, 一個用戶發送的所有請求若不是被這一小段數據關聯起來的話, 都將變成完全獨立的請求. 每一次這個對我唯一的cookie被發送后, 網站就會知道來訪的用戶是我而且我已經通過了驗證. 我們可以在Chrome的Cookie記錄下面看得更仔細一點兒:

順帶說一下, 第二個cookie是一個用于阻止CSRF攻擊的反偽造令牌, 這和我們的驗證狀態沒啥關系, 除此以外就沒有其他cookie了.

現在, 我們登錄并要求網站記住我, 下面是響應的cookie值:

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

啊哈 – 看到了吧?! 如果你在Chrome下面查看被分解開來的cookie值就會變得更加清楚:

現在, 我們有了一個從當前開始有效期為48小時的cookie, 相反的是不設置過期時間的cookie將會在瀏覽器被關閉之后被立即清除. 讓我們來近距離的看一看.

縱觀授權cookie的失效

事實上,這個一個可笑的安全結構和它僅僅只是前面的例子我感覺是值得寫出來,但是我們在這里。在實現當中,“記住我”功能簡單地歸結為當授權的cookie到期。這里做的事情是控制你想讓某人登入到你網站多久,它是簡單的。

在這里例子當中,ASP.NET 默認使用session cookie 或者換一句說話, a cookie 沒有明確的失效時間。當用戶瀏覽器一關閉,cookie就強制到期。 這是一種方法，另外一種就是明確一個簡短時間以至于瀏覽器是開著的,用戶自動退出的經過一段時間。當然,假如系統是運行順暢的,你也是能夠控制服務器的行為,由服務器響應增加失效時間,你也能夠擴展授權cookies信息的生命周期。

記住某個人是簡單的,保存授權cookie信息是激活的。多長時間讓它存活呢?在這個例子中默認是2天,這個可能是短暫的對一些合法的用戶來說。(盡管它可以簡單的在 ASP.NET中配置) ,Facebook 可以讓你的cookie信息存活持續一年。短暫的時間說明減少風險但是不方便,長時間使得用戶增加窗口的潛在攻擊可能。讓我們看一下風險更詳細。

利用長期運行的認證狀態

當你不認證的時候,你的會話不能被劫持。我知道那種情況。但嚴重的是類似Aussie Farmers Direct的情況。cookie有效的時間是6個月。由于這個事實,網站沒有標記為HttpOnly。因為網站里面有XSS缺陷并且cookie的有效時間是6個月,所以在這6個月當中,在你不經意訪問網站的時候,它會把鏈接相關的證書發送給攻擊者。假如有效時間是一個月,雖然他們在設計方面會有嚴重的缺陷,但是攻擊者攻擊窗口的機會將會減少。

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

當然所有這一切的基礎是需要仔細地保護認證cookie；HttpOnly和安全屬性是絕對必須要做的事情。不過古典的劫持威脅仍然要重視，然而要分離這些最終與cookie相關的特性，你就需要非常非常仔細地看看這些cookie。

最終需要考慮諸多因素，比如站點的用戶數據對于攻擊者的價值、返回給用戶的未通過認證的阻擋頁面和站點的其余安全配置等，然后再做權衡。例如，臉譜有一些有關社交方面的非常有用的數據，而且用戶期望在返回時得到低沖突（甚至沒有沖突）的處理，另外他們在安全方面已經給予大量的投資。另外，Aussie Framer站點用戶個人擁有識別用戶的數據和財務信息 而且人們認證后才獲得的所提供的服務（支付功能）仍然很少理解重要的安全理念。因此這兩個站點有著非常不同的風險配置，而且它們應當有非常不同的認證 cookie過期策略。

增強授權途徑

很多人在審視通過cookie進行授權的途徑的時候都會絕望地翻白眼, 對于安全這件事其實就是始終都有一種更好的方式(去實現), 這依賴于你愿意為之付出的時間/金錢/復雜度, 而且總會有那么一個人準備告訴你: 你搞錯了! 現在讓我們以授權cookie作為一個起始點, 來探尋一些可能的方式來增強這個途徑.

反對長期有效的授權cookie一個論據就是, 它們實際上會保證用戶處于已授權狀態并且處于被攻擊的風險之下, 類似于CSRF或者點擊劫持之類, 當然, 應用程序需要暴露其他的風險之處才能讓襲擊者利用長期性的cookie, 但是關于整體縱深防御的論證又再度出現了. 一個可選方式就是保持一個專用cookie來應對那些用戶 －他們在通過了服務器對會話真實性的驗證之后能夠在回來的時候發起一輪新的已授權會話, 這樣原始的會話就馬上失效了, 這里的技巧就是, 當用戶帶著專用的"記住我"cookie的返回的時候重新設置一個新的會話, 并在這個過程中包含進一些額外的驗證.

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

一個更為務實的緩解方案是：依然把認證cookie從一個專門的“記住我” cookie中分離出來，并使用后者來對用戶進行重新認證，但要施加一些限制。事實是，自動持久化某人的認證狀態的過程 – 不管是什么方式 – 都會要求安全模型做出妥協。一個緩解方案可以是這樣：在查看特定類型的數據或者執行特定操作之前，要求一個自動重新認證的用戶再次明確的輸入他們的憑證。在“記住我”特性之外，這種做法并不是聞所未聞的新做法，你應該在執行高價值的操作時見過，比如銀行轉賬。這種情形下，我們說認證用戶面臨著更高的風險，因為更有可能他們并不是他們所聲稱的那個人(也就是說，另外一個人已經坐在了電腦前并且有效的劫持了本次會話)。

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

#p#

最后一個值得提及的事情是：需要考慮已認證的活動會話的同一個賬戶的管理原則在“記住我”的上下文里是緊密相關的。例如，來自同一個用戶的多個同時已認證會話是否允許？如果用戶更改了它們的密碼的話，是否要斷開其余的會話？ 管理員是否結束已認證了的會話？這兒出現的所有問題實際上是有關如何驗證和管理已認證會話的一部分，這兒的討論僅僅關注在如何恢復哪個會話上。

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

有時允許一個認證用戶長時間保持認證態根本沒有意義。比如銀行業就是典型的案例，如果你想強制盡快的重新認證，卻將已認證的瀏覽器會話丟在一邊不用，就會使風險變得很大。

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

這不完全是你看到的樣子——當你選擇了“記住我”，又在會話過期以后返回，你將得到這個：

我沒有混淆用戶名，上面顯示的帶有星號的用戶名是存在于cookie中的，這個cookie會連同一些其他的必須被用來標識用戶的數據一起，保留3個月。坦率地說,在這里面我沒有覺得有很多的意義，記住你的用戶名并不總會成為問題！

但也不是說就一定是非此即彼，你會有中間的選擇。例如，我早些時候發表的觀點，如果會話由“記住我”功能繼續下去，就需要在關鍵過程執行之前再認證。這似乎有點兩全其美。

總的來說…

在某些方面下,這個特性是一個非常好的主意。它可以非常簡單的去實現大部分你需要的功能。坦率地說,當你去增加cookie的生命周期的時候,你仍然有一些困惑前面的兩個例子是怎么錯的。

通過這篇文章,另外一個關鍵的地方是理解"記住我"特性的安全機制,例如一個多層次,相互交互的系統。你可能能夠擺脫在cookies里面加入證書,但是結合ELMAH情況或者缺少HTTPOnly屬性和XSS缺陷是非常愚蠢的,將會是一個嚴重的風險。那么"縱深防御"是怎么一回事呢!

英文原文：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