---
# System prepended metadata

title: cookie
tags: [觀念重點區]

---

# 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: `觀念重點區`