Session 管理及 Cookie 應用

       基於表單認證的標準規範尚未有定論，一般會使用Cookie來管理Session（會話）。

基於表單認證本身是通過伺服器端的Web應用，將客戶端傳送過來的使用者ID和密碼與之前登入過的資訊做匹配來進行認證的。但鑑於HTTP是無狀態協議，之前已認證成功的使用者狀態無法通過協議層面儲存下來，即，無法實現狀態管理，因此即使該使用者下一次繼續訪問，也無法區分他與其他的使用者。於是我們會使用Cookie來管理Session，以彌補HTTP協議中不存在的狀態管理功能。

      步驟1：客戶端把使用者ID和密碼等登入資訊放入報文的實體部分，通常是以POST方法把請求傳送給伺服器。而這時，會使用HTTPS通訊來進行HTML表單畫面的顯示和使用者輸入資料的傳送。 

      步驟2：伺服器會發放以識別使用者的SessionID。通過驗證從客戶端傳送過來的登入資訊進行身份認證，然後把使用者的認證狀態與SessionID繫結後記錄在伺服器端。

      向客戶端返回響應時，會在首部欄位Set-Cookie內寫入SessionID（如PHPSESSID=028a8c...）。

      你可以吧SessionID想象成一種用以區分不同使用者的等位號。然而，如果SessionID被第三方盜走，對方就可以偽裝成你的身份進行惡意操作了。因此必須防止SessionID被盜，或被猜出。為了做到這點，SessionID應使用難以推測的字串，且伺服器端也需要進行有效期的管理，保證其安全性。

       另外，為減輕跨站指令碼攻擊（XSS）造成的損失，建議事先在Cookie內加上httponly屬性。

      步驟3：客戶端接收到從伺服器端發來的SessionID後，會將其作為Cookie儲存在本地。下次向伺服器傳送請求時，瀏覽器會自動傳送Cookie，所以SessionID也隨之傳送到伺服器。伺服器端可通過驗證接收到的SessionID識別使用者和其認證狀態。

      不僅基於表單認證的登入資訊及認證過程都無標準化的方法，伺服器端應如何儲存使用者提交的密碼等登入資訊等也沒用標準化。通常，一種安全的儲存方法是，先利用給密碼加鹽（salt）的方式增加額外資訊，再使用雜湊（hash）函式計算出雜湊值後儲存。但是我們也經常看到直接儲存明文密碼的做法，而這一的做法具有導致密碼洩露的風險。

       salt其實就是由伺服器隨機生成的一個字串，但是要保證長度足夠長，並且是真正隨機生成的。然後把它和密碼字串相連線（前後都可以）生成雜湊值。當兩個使用者使用了同一個密碼時，由於隨機生成的salt值不同，對應的雜湊值也將是不同的。這樣一來，很大程度上減少了密碼特徵，攻擊者也就很難利用自己手中的密碼特徵庫進行破解