# cookie https://ithelp.ithome.com.tw/articles/10217955 Cookie一般可分为两类，即会话Cookie和持久Cookie。会话Cookie 一般用于临时应用，当用户退出浏览器后，Cookie就会被删除；持久 Cookie生存时间更长，即使退出浏览器、计算机重启依然存在。持久 Cookie一般需要通过Expires或Max-Age参数进行特殊设置。 在 1997 年，有了 RFC 2109 出爐，接著 2000 年發布了 RFC 2965 取代 RFC 2109，最後才是 2011 年發布大家目前所熟知的 RFC 6265。三個 RFC 標題都叫 HTTP State Management Mechanism，在定義 HTTP 如何管理狀態的機制。 ## 介紹 簡單來說，服務器若想在保存某個 HTTP 的狀態時，就在回應的 Header 加入 Set-Cookie 的值裡；客戶端取得回應，可以把這個值保存下來，當想繼續使用這個狀態時，就在請求的 Header 加入 Cookie 的值。 ![](https://i.imgur.com/e91995c.png) ## Cookie 存取限制 Path 與 Domain RFC 下一個範例即跟 Cookie 存取限制有關，首先先來看 lang 這個 Cookie。它多了兩個屬性為 Domain 與 Path。 ``` == Server -> User Agent == Set-Cookie: lang=en-US; Path=/; Domain=example.com == User Agent -> Server == Cookie: lang=en-US ``` **Domain 屬性的限制規則為：** ``` 請求的 Domain 與 Cookie Domain 一樣 請求的 Domain 是 Cookie Domain 的子網域 ``` 當 User Agent 收到 Set-Cookie 帶有 Domain 屬性時，會把這個屬性跟請求的 Host 比對。當符合上述條件時 User Agent 才會將 Cookie 保存起來；相同地，當符合上述條件時，User Agent 才會將此 Cookie 帶入 HTTP 請求裡發送給服務器。 只要適當的設置 Domain 為 example.com，攻擊者就無法使用 attacker.com 來指向同服務器，然後利用瀏覽器信任的特性去取得使用者的 Cookie 狀態。 **Path 屬性的限制跟 Domain 類似，規則為：** ``` 請求的 Path 與 Cookie Path 一樣 請求的 Path 是 Cookie Path 的子目錄 ``` 符合條件時，User Agent 才會將 Cookie 保存起來；相同地，Path 符合條件的話，User Agent 才會將 Cookie 帶入 HTTP 請求裡發送給服務器。 規範有提到，雖然 Path 屬性用來隔離 Cookie，但不能依賴 Path 屬性來保證安全性。 **上面兩個都過確定之後 會給他set id** 最後來個簡單的舉一反三：如果寫了一個 Path=/ 與 Domain=google.com 的 Cookie，則在 drive.google.com 或 mail.google.com 後續的 HTTP 請求都能取得 SID=31d4d96e407aad42 的資料： ``` == Server -> User Agent == Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=google.com == User Agent -> Server == Cookie: SID=31d4d96e407aad42 ``` **比較特別的兩個屬性** ``` == Server -> User Agent == Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly == User Agent -> Server == Cookie: SID=31d4d96e407aad42 ``` 這兩個屬性比較單純：設置了 Secure 的話，代表只有 HTTPS 才能讀與寫；設置了 HttpOnly 則表示禁止 Javascript 讀取此 Cookie。 ## 小結 看完以上的範例，可以大概知道一般身分驗證會全部採用，如： `Set-Cookie: SID=31d4d96e407aad42; Domain=example.com; Expires=Sat, 19-Oct-2019 17:53:50 GMT; Path=/; Secure; HttpOnly` Expires 為過期時間，指時間到該 Cookie 就會自我消毀。 這樣就能確保該 Cookie 能在正常的 Domain 與 Path 下寫入，同時也限制了 HTTPS 與 HttpOnly，駭客要能取得該 Cookie 的難度就會非常高。至於其他應該注意的安全事項，在 RFC 6265 section 8 有更多詳細的說明可以參考。 ## 安全隱患 https://ithelp.ithome.com.tw/articles/10218811 Cookie 固然方便，但畢竟它存在著安全隱患（security pitfalls），使得我們無法隨意地將極機密的資訊保存在 Cookie Cookie 是一種 Ambient Authority(環境權限) 的形式 ## Clear Text 除非有使用安全通道（secure channel），不然 Cookie 的內容會是用明文傳輸。如果明文傳輸就會有以下問題： 敏感資訊會暴露給竊聽者 中間人攻擊可以很輕易的竄改資訊 User Agent 也可以很輕易的竄改送出的表頭資訊 RFC 裡的建議是，服務器應該對 Cookie 做加密（encrypt）和簽章（sign），即便是使用安全通道也是。只是即便加密和簽章，也無法防止重送攻擊。 需注意的是，如果有使用安全通道的話，則 Cookie 就得加上 Secure 屬性，不然安全通道的保護就沒有意義了。RFC 舉的例子是，攻擊者只要攔截 HTTP 請求，然後重導向使用者到沒有 Secure 屬性站台，並使用 HTTP 協定。即便站台沒有開啟 HTTP 連接埠，User Agent 還是會將該 HTTPS 的 Cookie 夾帶到 HTTP 的請求裡，攻擊者再攔截下來重送到該服務器上，就能偽造該使用者身分進入服務了。時序圖如下： ![](https://i.imgur.com/vDH4jof.png) ## Reliance on DNS 簡介 Cookie 提了許多設定的例子，以及上面討論的某些問題，都是在 domain 上設定 Cookie，代表 Cookie 協定對 DNS 有某種程度的依賴關係。因此 DNS 只要被攻破，Cookie 的資料將會傳送到攻擊者的服務器裡。 ###### tags: `觀念重點區`