在整個網路發展中，Cookie與Session都是不可或缺的技術，它們為使用者上網的體驗帶來顯著的提升。根據知名網站技術調查網站W3Tech統計，全球有超過40%的網站使用Cookie技術，其存在使得網站能夠提供使用者個性化的設定，並且在跨頁面操作時提升使用者體驗，例如維持登入狀態和保存購物車內容。但是很多人對這項技術的認識較為模糊，尤其對於其安全性及隱私風險方面的了解更是微乎其微。因此，歐盟於2016年起制定一般資料保護規範（GDPR），該規範講述要求一個網站在讓使用者清楚地知情並同意後，才能儲存非必要儲存的資料，這也是在很多的網站上都會出現類似是否接受Cookie的提示。
然而，第三方的Cookie尤其引人爭議，因為其允許廣告商進行跨網站的追蹤，建立使用者的喜好清單。但事實上，瀏覽器開發商也注意到隱私上的問題，如Chrome、Safari都開始限制第三方Cookie的存取，廣告和資料分析產業也慢慢進入「無Cookie時代」的轉型期，迫使業界找尋更注重隱私的替代追蹤方案。因此，了解Cookie與Session的原理，區分它們的類型與功能，對於現代網站的開發者或使用者都至關重要。
本文將會針對Cookie和Session的基礎原理、潛在風險進行詳細探討，並透過情境化演練與實際操作，使讀者更直觀地了解兩大機制運作原理。
相關背景知識說明
首先，介紹相關的背景知識。
首先要了解HTTP（Hyper Text Transfer Protocol）本身是無狀態的，這讓伺服器無法分辨是哪位使用者在瀏覽這個網頁，同時每次的請求都是獨立的，伺服器不會記得使用者之前的狀態，如圖1所示。這帶來了一個問題：假設有一個網站在使用者登入會員後，每次切換頁面時，由於伺服器都無法知道這位使用者已經登入，使得每次切換頁面時都要重新登入來驗證身分。
為了解決這個困擾，伺服器引入了Cookie機制，藉由在使用者瀏覽器上存放小文字檔案，使得伺服器能夠記住使用者的狀態。
| 種類 | 說明 |
|---|---|
| 第一方Cookie | 第一方Cookie是由使用者目前所造訪的網站網域（Domain）直接發行並設置的Cookie。它無法 被其他不同網域直接讀取，因此其跨站追蹤的隱私風險較低。主要用途為保存使用者的登入狀 態等。如果禁止使用這類的Cookie，可能會導致部分需要保存狀態的網站無法正常運作，降低 使用者體驗 |
| 第三方Cookie | 第三方Cookie是指與使用者主要瀏覽的網站網域不符，透過嵌入在該網站中的第三方資源（如 廣告代碼、追蹤像素或社群媒體插件）所設置的Cookie。它是實現「跨網站追蹤用戶紀錄」的 核心方式。這些Cookie用於追蹤使用者在不同網站之間的瀏覽行為，目的是建立精細的個人畫 像（Profiling），進而實現精準的目標廣告推送（Targeted Advertising）等商業優勢。例如，透 過嵌入在新聞網站上的Meta/Facebook追蹤像素或Google廣告代碼所設置的Cookie。然而，由 於隱私問題，瀏覽器正在經歷淘汰第三方Cookie的轉型期，主流的瀏覽器如Chrome、Safari也 可以選擇禁止第三方Cookie |
Cookie與Session的基本原理
接著，分別說明Cookie與Session的基本原理。
Cookie
Cookie是一種儲存在使用者瀏覽器的小型文字檔案。在基礎的Cookie運作中，當瀏覽器連接伺服器時，伺服器會回傳一個Set-Cookie的回應標頭，然後瀏覽器會儲存這個Cookie。之後，每次發送請求到同一個伺服器時，瀏覽器便會自動攜帶這Cookie。例如，使用者第一次登入後，伺服器會生成並回傳一個代表登入者身分的標頭。之後的每次請求中，瀏覽器會自動附帶該Cookie，伺服器藉此確認使用者的身分，Cookie運作原理如圖2所示。
Cookie的類別主要分為第一方Cookie和第三方Cookie兩類，說明整理如表1所示。
Session
Session是一種由伺服器端儲存客戶狀態的一種機制，常用於使用者與網站之間維持狀態，如登錄資訊、購物車內容等。通常與Cookie搭配使用。它在處理使用者敏感資料（如銀行系統或後台管理系統）時尤為重要。
Session與Cookie不同，它將使用者狀態儲存在伺服器端，透過唯一的Session ID標識使用者身分。Session ID通常存放於Cookie中，伺服器端透過比對Session ID驗證使用者身分，此機制能大幅減少敏感資料洩漏至客戶端的風險，運作原理如圖3所示。
| 類型 比較 | Cookie | Session |
|---|---|---|
| 儲存位置 | 客戶端（瀏覽器） | 伺服器端 |
| 資料安全性 | 資料存放在客戶端，用戶或惡意腳本可直接存 取（讀取），容易被竄改 | 資料存放在伺服器端，用戶無法直接存取和竄 改。主要安全風險是Session ID被劫持 |
| 用途 | 用於保存使用者偏好、登入狀態等。同時也儲 存Session ID，讓每次網頁請求時，伺服器能夠 識別身分 | 主要用於在伺服器端維持和管理使用者狀態。 專門儲存敏感、即時性的資料，如驗證後的登 入憑證、交易資訊或購物車的結構化內容 |
| 跨域限制 | 第一方Cookie僅限於發行它的網域讀取；第三 方Cookie的核心功能正是用於跨域追蹤，但目 前正被主流瀏覽器逐步限制 | Session本身不受域名限制，但Session ID通 常透過第一方Cookie傳輸，因此其作用域受到 Cookie屬性的間接限制 |
| 持續性 | 可以設定過期時間（Expires/Max-Age），用於 實現「保持登入」或長期記住使用者偏好 | 通常在使用者關閉瀏覽器時或達到伺服器設定 的閒置∕絕對過期時間後被清除 |
瀏覽器每次請求時攜帶這個Session ID，伺服器根據Session ID對應的資料判斷使用者狀態。使用者登出時，伺服器刪除這筆Session資料，Session ID即失效。如果Session規律明顯，容易被預測，這種容易被預測的Session ID產生方式被稱之為Weak Session ID。
Cookie與Session之差異
以表2來說明Cookie和Session的主要差異。
Cookie的主要安全問題
由於Cookie是儲存在瀏覽器端，且每次會將請求自動發送到伺服器，使其成為眾多攻擊的目標，特別用於儲存維持登入狀態之Session ID的Cookie。以表3整理Cookie常見的威脅攻擊。
防範Cookie安全問題
伺服器在回應請求，可以在回應中加入Set-Cookie標頭，該標頭會告知瀏覽器儲存Cookie，則Set-Cookie標頭中也細分成不同的屬性以實現Cookie的安全性，在表4中針對不同的屬性設定做介紹。
| 安全威脅 | 攻擊原理 |
|---|---|
| 跨網站指令碼攻擊（Cross-site Scripting，XSS） | 攻擊者利用此漏洞將惡意的JavaScript腳本植入。此腳本在瀏覽器上執行 並讀取document.cookie屬性，竊取Session ID |
| 跨站請求偽造（Cross-site Request Forgery，CSRF） | 攻擊者誘騙使用者瀏覽器向已登入的目標網站發送一個使用者非本意的 請求（例如點擊惡意連結或瀏覽惡意頁面）。瀏覽器會自動攜帶目標網 站的Session ID |
| 會話劫持（Session Hijacking） | 這是XSS、中間人攻擊（MITM）或弱Session ID預測等手段的最終目 的。一旦攻擊者獲得有效的Session ID，即可接管使用者會話 |
| 中間人攻擊（Man in the Middle， MitM） | 使用未加密的HTTP進行傳輸，攻擊者可以從中攔截並竊取Session ID等 機密資訊 |
| 隱私洩漏（第三方Cookie） | 第三方Cookie追蹤每個使用者的偏好設定、瀏覽行為等，外洩即表示個 人隱私一覽無遺 |
| 屬性 | 說明 |
|---|---|
| Secure | 若Set-Cookie的標頭上包含Secure的屬性，則Cookie只會被在有HTTPS加密的狀態下進行傳 輸，不會在HTTP中加入Cookie，有助於防範MitM攻擊 |
| HTTPOnly | 若Set-Cookie中有包含HTTPOnly的話，則無法使用JavaScript存取Cookie，例如無法使用 document.cookie等屬性方法。可以防範以Cookie為目標的特定攻擊 |
| Samesite | 如果請求的資源網站和造訪的網站為不同網域，那就是跨網站請求。Samesite屬性會控管請求 中是否包含第三方Cookie，其設定值可能包含Strict、Lax或None。 ‧Strict：只有在網頁位於Cookie的來源網站時，系統才會傳送Cookie以回應請求。 ‧Lax：預設為該選項，與Strict不同的地方在於，當使用者在非Cookie來源的網站點選連結前 往Cookie的來源網站時，瀏覽器也會一併傳送Cookie。 ‧None：無限制，無論是否為跨網站請求，系統都會在請求中加入Cookie。 |
| Partitioned | 這個屬性允許將Cookie存放在分割儲存空間。舉例來說，若網站B和網站G都含有網站P的 iframe，則網站B的iframe設定之分區Cookie無法由網站G的iframe存取 |
| Expires & Max- Age | 可以設定Cookie的Expire日期與時間，或是以秒為單位計算的Max-Age，只要時間一到就會刪 除Cookie並且不會再傳送 |
| Domain | 如果Set-Cookie的標頭含有Domain屬性，則系統會將Cookie納入到指定網域和所有的子網域。 因此，除非有需要納入到指定網域或子網域的需求，應不隨意將Domain屬性加入進去 |
| Path | 若Path屬性包含在Set-Cookie的標頭中，則設定的Cookie只會包含在符合Path值的網址要求中 |
DVWA之Weak Session ID實戰教學
接下來，以DVWA（Damn Vulnerable Web Application）之Weak Session ID的Low、Medium、High等三種難度的題目作為範例，了解錯誤的Weak Session ID產生方式是怎麼出現資安漏洞，以及有心人士可能會用什麼方法來破解。
級別：Low
從圖4中的程式碼可以看出last_session_id不存在時預設為0，反之則加1，並設置為dvwaSession。根據以上分析，可以推測出級別Low的Session ID產生方式是用+1做遞增。
級別：Medium
圖5中程式碼與上一題基本相同，差別在於為了產生Session單一性不重複，加上時間來運算。這個範例中的dvwaSession是透過時間戳來形成，可以透過線上的時間戳工具來破解，如timestamp工具，網址為「https://www.epochconverter.com/」。
級別：High
如圖6所示，當Session + 1後以使用MD5的方式轉換成雜湊值（Hash），使用線上Hash破解工具進行爆破（https://crackstation.net/），如圖7所示，觀察爆破後的結果，可以發現依舊是1, 2 ,3 ,4…，該值只不過是Session經過雜湊函數轉換後的結果。
實際情境演練
以下透過模擬使用者登入頁面，演示幾種網路技術的實際運作以及潛在風險。
無狀態HTTP
在無設置網站的模擬環境中，輸入正確的帳號密碼進行登入操作，登入畫面如圖8所示。成功登入後，如圖9所示，按下〔F12〕鍵可以觀察到Cookie中並未儲存任何資料。
這是因為HTTP是一種無狀態的協議，每次的請求都是獨立的。每當頁面重新整理時，伺服器無法記住使用者的登入狀態，因此將瀏覽器導回尚未登入的頁面，如圖10所示。
Cookie（無加密）
再次成功登入後進入使用者頁面，此時可以發現Cookie中儲存了使用者的基本資料。Cookie是在第一次請求後產生的記錄，後續請求只須攜帶該記錄，伺服器即可理解使用者的狀態，如圖11所示。
以生活實例來說，健忘的早餐店的老闆儘管記不住客人的習慣，但當你把要點的餐點寫在衣服上，老闆就能快速提供服務。然而，由於Cookie儲存在瀏覽器端，因此使用者可以直接修改其內容。
以下示範了修改Cookie中儲存使用者ID，成功登入其他人的使用者頁面，這是未加密Cookie所造成的重大資安漏洞，如圖12所示。
Session-Based Authentication
為解決上述問題，伺服器可將Session（如登入狀態）資料加密後儲存於Cookie中，如圖13所示，並由伺服器端負責解密。使用者登入後，伺服器將加密的Session資料回傳給瀏覽器。每次請求時，瀏覽器會攜帶這份加密的Cookie，而伺服器解密後檢查使用者狀態。
範例中，經過加密後的Cookie是一段亂碼，解密後可得到：
{"id": "1111727", "name": "王小明"}此方法雖提升了安全性，但加密與解密運算會增加伺服器負擔，加密後的Cookie也會占用更多傳輸空間，影響效率。
Session Data Storage
使用者在登入成功後，伺服器會在資料庫中建立一筆Session資料，並生成一個sid，回傳給瀏覽器並儲存於Cookie內，如圖14所示。
以生活實例來說，這相當於點餐後獲得號碼牌（sid）。該號碼牌只是用於查詢的編號，對應於使用者點的餐，但他人僅憑號碼牌無法獲知具體內容，因為資料存儲在店家內部。
然而，若sid的生成方式不夠隨機，例如直接以+1遞增，則會導致Session ID易被預測。例如，陳大明的sid是2，而根據王小明的sid是1，可推測ID是按遞增方式生成，如圖15所示。此類容易被預測的方式被稱為Weak Session ID，極易被攻擊者利用以盜取他人Session。
結語
隨著網際網路技術的發展，Cookie和Session在提升網站性能與使用者體驗方面發揮著至關重要作用。Cookie可以保存使用者的偏好設定、登入狀態等，然而Cookie儲存在客戶端（瀏覽器）中，若未經妥善管理或加密，可能會遭受竄改或盜用。另一方面，Session作為伺服器端的會話工具，具有更高的安全性，但仍存在Weak Session ID的風險，攻擊者可透過觀察Session ID產生的規律竊取Session ID來冒充使用者。使用者應該提高對Cookie和Session相關技術的認識，定期清理不必要的Cookie，爾後上網在碰到Cookie提示後，也可以思考其必要性，避免在不安全的網站上不慎將個人隱私外洩出去。