Web Security 101 - Cookie

由於 HTTP 的設計為 stateless，故如何管理並追蹤使用者的「session」，以得知前後不同的 requests 是由同一個使用者所進行的同一組 session，是一個需要想清楚的事
最早訂定的標準為 1997 年的「RFC 2109 - HTTP State Management Mechanism」，提出使用 Set-Cookie 與 Cookie 兩個 headers 來創建 stateful session 的方法
事後經過兩次的修訂：2000 年的 RFC 2965，與 2010 年的 RFC 6265，使得相關實作規範更加明確
我們需要 Cookie 的機制幫我們創造 stateful session，此機制係利用瀏覽器支援的 Set-Cookie 與 Cookie 兩個 headers 來達成
- 所謂的 Set-Cookie，是由伺服器 (server-side) 添加、包含在 HTTP Response 中的 header，瀏覽器作為用戶端收到後儲存下來的 stateful information
- 所謂的 Cookie，是由瀏覽器 (client-side) 添加、包含在 HTTP Request 中的 header，讓伺服器收到後從中解析出 stateful information

簡單的 cookie 設置例 (from server to user agent)
```
Set-Cookie: <cookie-name>=<cookie-value>
```

server 透過以下的 HTTP response 告訴 client 儲存這些 cookie pairs

HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[page content]

client 接著在後續的 requests 中帶上這些 cookie

GET /sample_page.html HTTP/2.0
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

See also

淺談 Session 與 Cookie：一起來讀 RFC

Using HTTP cookies - MDN

Browser 提供了儲存機制 (Web Storage or IndexedDB) 來儲存 cookie，且預設幫我們根據 「Origin」 來做隔離
而瀏覽器預設實作的機制
- 頁面可以替它的 domain 或是其 parent domain 設置 cookie
  - 只要 parent domain 不是 Public Suffix (i.e. TLD 的部分)
- cookie 在它原始的 domain 及 sub-domains 中可被取用 (無倫是 http/https 或不同的 port)

Image Not Showing Possible Reasons

但此預設的行為其實會造成潛在的(資安)問題，例如：

foo.example.com 可以對 example.com 設置 cookie
- 可能因此覆蓋掉 bar.example.com 對 example.com 的設置
- 故 foo.example.com 有了可以攻擊 bar.example.com 的破口
http://example.com 也可以將 https://example.com 的 cookie 蓋掉
- 故 HTTP 站點有了可以攻擊 HTTPS 站點的破口

✅ Good Attributes

Secure
- server 可指定 cookie pair 擁有 Secure 屬性。擁有此屬性的 cookie 會被限制只能透過安全連線來設置 (實務上，HTTPS 是一種安全連線)
- 又瀏覽器儲存的 cookie 若有 Secure 屬性，就不會在連向 un-encrypted server 時 (i.e. via HTTP)，帶上該 cookie
- e.g. Set-Cookie: key=value; Secure
- ⚠️ except on localhost
HttpOnly
- protect from XSS (to prevent cookie from being read from JavaSCript (document.cookie))
- e.g. Set-Cookie: key=value; Secure; HttpOnly

📛 Bad Attributes

Experiment List:

Secure, but why? cen we reproduce man-in-the-middle attack?
HttpOnly, have or not to show the JS capability
CSRF, third-party site embed your site to steal your cookie
- prevent it by SameSite cookie

important:

Cookies don't obey Same Origin Policy
This is why Stanford login is login.stanford.edu and not stanford.edu/login 😲

References:

Practical Discussions

See also

https://medium.com/4ing-的航海日誌/fetch-api-沒有傳送-cookies-fa0befaae40f