cookie基礎，相關hacker攻防

cookie機制

cookie其實是一段文本信息，當web瀏覽器第一次訪問某個服務器時，服務器會給瀏覽器頒發一個cookie，瀏覽器將cookie保存，當瀏覽器再次請求該網站時，瀏覽器會把請求的網址和cookie一同提交給服務器。服務器檢查該cookie，得知該用戶狀態。服務器還能夠根據須要修改cookie內容。

session機制

session是服務器端保存的數據結構，用來跟蹤用戶的狀態，客戶端的cookie僅保存session ID,之後每次請求將cookie和網址發送，服務器根據session id,就知道該用戶是誰了

session和cookie機制的區別和聯繫

區別：

1. session將用戶信息保存在服務器端，前端只有session ID，cookie將用戶信息保持在前端瀏覽器中
2. session由於用戶接觸不到客戶信息因此更安全

聯繫：

1. cookie是實現session機制的一種方式，初次以外，還能夠直接在網址後面添加sid=xxxxx的方式（在用戶瀏覽器禁用cookie的狀況下）

若是用戶瀏覽器禁用了cookie怎麼辦？

如今的瀏覽器通常禁用cookie，不是徹底禁用，而是失去了「持久化」的做用，關閉窗口清楚cookie，因此依然能夠登錄網站

1. 使用session機制，首先使用URL重寫技術在url後面添加Session id,進行身份認證， 或者還有一種技術叫作表單隱藏字段。就是服務器會自動修改表單，添加一個隱藏字段，以便在表單提交時可以把session id傳遞迴服務器。 若是不容許添加參數，服務器依然發送Set-Cookie的Header，只是客戶端會忽略，則每次訪問建立一個新的session，以前狀態不會保留，登錄狀態沒法維持
2. 使用cookie機制，禁用cookie，會致使登錄狀態沒法維持

爲何須要cookie,session?

因爲HTTP是無狀態的協議，指協議對於事務沒有記憶能力，若是後續處理須要知道前面的信息，（例如某寶查詢該用戶以前的購買記錄），則它必須重傳，這樣致使可能每次鏈接的數據量增大。可是在數據量小的時候它的應答很快

可是客戶端和服務器端進行交互的Web應用程序出現後，應用要求須要知道用戶都作了什麼，例如登錄狀態、購物車買了什麼等信息，HTTP的無狀態嚴重阻礙了這些應用功能的實現。

爲何不直接將HTTP改爲有狀態的協議？

1. http在傳遞數據小的時候應答速度很快
2. 軟件工程角度講，http已是一個較爲成熟的協議，後面的修改應該是上層的封裝，即
   有狀態協議 = http + cookie 或 = http + session

盜竊cookie的兩個場景

1. 場景描述
   在公司的一臺機器上，職員A登錄了網上銀行進行了轉帳操做，以後他刪除了cookie，刪除了瀏覽器自動保存的密碼，刪除了全部的臨時文件，而後退出了機器。幾分鐘後，職員B來使用這臺機器，B檢查了瀏覽歷史，發現有人曾經登錄過網上銀行而且，url裏面含有參數JSESSIONID,B隨後使用和A相同的JSESSIONID建立了一個cookie，成功登錄進去了A的銀行帳戶
   存在的漏洞
   session的ID用來追蹤一個會話，暴露在url裏面做爲請求參數很容易就會被利用
   防禦措施
   • 不要將JSESSIONID暴露在url中
   • 爲每一個會話建立一個時間戳，表明會話有效期，超過這個有效期，會話無效。
   • 最好的方法是將JSESIONID和時間戳time-stamp保存在一個超級cookie裏面，而後對這個cookie進行加密處理，每次請求都須要對cookie解密使用裏面的信息。
   • 用戶方面能夠在每次登錄後經過點擊退出按鈕登錄使得JSESSIONID無效。
2. 場景描述
   和第一個場景相似，可是此次銀行將JSESSIONID和time-stamp封裝在了超級cookie中並進行了加密處理，職員A在退出時點擊了退出按鈕，可是hacker依然竊取了他的帳戶。 （黑客中途截斷了用戶的請求進而竊取了cookie）
   存在的漏洞
   時間戳保留時間爲了用戶能夠完成相應的操做，可是hacker只要竊取了用戶的cookie即可以同時登錄其帳戶。
   防禦措施 cookie再添加一個值叫作Counter/Nonce,一串隨機的二進制數字， 每一次請求後，服務器就會修改Counter/Nonce的值以保證同一個超級cookie不會發起二次請求。