你有沒有想過，當你登入一個網站時，網站是怎麼「記住」你是誰的？
答案是：Session（會話）。
Session 就像是你在飯店入住時拿到的房卡。
你拿著這張房卡，飯店就知道你是 302 號房的客人，可以讓你進出房間、使用設施。
但如果有人動了手腳呢？
想像一下這個情境：
你參加了一個旅行團，導遊說他會幫大家處理入住手續。
導遊發給你一張房卡，說：「這是你的房間，302 號房。」
你拿著房卡去房間，刷卡進門，一切正常。
但你不知道的是，導遊手上還有一張一模一樣的房卡。
當你入住後，他隨時可以進入你的房間。
這就是 Session Fixation（會話固定攻擊）的概念。
駭客預先準備好一個 Session ID，想辦法讓你使用這個 ID 登入。
登入成功後，駭客用同一個 Session ID 就能冒充你的身份。
這篇文章會帶你了解 Session Fixation 的攻擊原理、駭客如何發動攻擊，以及開發者該如何防範。
先來了解 Session 是什麼
在講攻擊之前，我們先搞懂 Session 的運作方式。
為什麼需要 Session？
網頁是「無狀態」的。
什麼意思呢？
每次你向網站發送請求，對網站來說都是一個「陌生人」。
網站不會自動記得「你剛才登入過」或「你剛才把商品加入購物車」。
你可能會覺得奇怪：「我明明剛剛才登入，網站怎麼會不記得？」
這是因為網頁的運作方式。
你的瀏覽器和網站之間的每一次溝通，都是「獨立」的。
第一次請求和第二次請求之間，沒有任何關聯。
所以如果沒有額外的機制，網站每次都會把你當成第一次來的訪客。
這樣很麻煩，對吧？
每換一個頁面就要重新登入一次，購物車的東西也會消失。
所以我們需要一個機制，讓網站能「記住」你是誰。
這個機制就是 Session。
Session 的運作流程
當你登入一個網站時，會發生以下流程：
第一步：你輸入帳號密碼，點擊登入
瀏覽器把你的帳號密碼送到伺服器。
第二步：伺服器驗證成功，產生 Session ID
伺服器確認你的帳號密碼正確後，會產生一個獨特的識別碼，叫做「Session ID」。
這個 Session ID 就像是你的「通行證號碼」。
伺服器會把這個號碼和你的身份資料配對，存在伺服器的記憶體裡。
第三步：伺服器把 Session ID 傳給你的瀏覽器
伺服器要怎麼把 Session ID 傳給你呢？
當伺服器回傳網頁給你時，會附帶一個「HTTP 回應標頭」（HTTP Response Header）。
在這個標頭裡面，有一個欄位叫做 Set-Cookie。
伺服器會把 Session ID 放在這個欄位裡，像這樣：
Set-Cookie: session_id=abc123xyz789
瀏覽器收到這個回應後，看到 Set-Cookie，就會自動把 session_id=abc123xyz789 存進 Cookie 裡面。
這個過程是自動的，你不需要做任何事情。
第四步：之後的每次請求，瀏覽器都會帶上 Session ID
當你瀏覽網站的其他頁面時，瀏覽器會自動把 Session ID 放在請求裡。
伺服器收到請求後，會檢查這個 Session ID，然後說：「喔，我認得這個號碼，這是小明！」
這樣，網站就能「記住」你是誰了。
Session Fixation 攻擊的運作原理
了解了 Session 的運作方式後，我們來看看 Session Fixation 攻擊是怎麼回事。
這個攻擊涉及三個角色：
攻擊情境：駭客如何發動 Session Fixation 攻擊
第一步：駭客取得一個 Session ID
駭客先造訪目標網站。
前面提到，Session ID 是在登入後產生的。
但有些網站的做法不太一樣：它們會在你「一進入網站」時就先給你一個 Session ID，不管你有沒有登入。
為什麼要這樣做呢？
因為有些功能不需要登入也能使用。
例如，你在電商網站瀏覽商品，把東西加入購物車。
這時候你還沒登入，但網站需要「記住」你的購物車裡有什麼。
所以網站會先給你一個 Session ID，用來追蹤你這次的瀏覽行為和購物車內容。
這個 Session ID 一開始只是一個「空的通行證」，還沒有綁定任何身份。
等你結帳時登入帳號，網站才會把你的身份和這個 Session ID 綁定在一起。
問題就出在這裡。
如果網站在登入後「沒有換一個新的 Session ID」，而是繼續沿用原本那個，就會有漏洞。
駭客正是利用這個漏洞。
駭客先造訪網站，拿到一個 Session ID，假設是 abc123。
這時候 abc123 還只是一個空的通行證，沒有綁定任何人。
駭客把這個 abc123 記下來。
第二步：駭客把這個 Session ID「塞給」受害者
接下來，駭客要想辦法讓受害者「使用」這個 Session ID。
駭客會發送一個特製的連結給受害者。
這個連結看起來像是正常的網站網址，但裡面藏著駭客指定的 Session ID。
例如：
https://example.com/login?sid=abc123網址看起來是正常的 example.com，但後面多了 ?sid=abc123。
這個 abc123 就是駭客事先拿到的 Session ID。
受害者可能會透過 Email、簡訊、或社群媒體收到這個連結。
例如：「您的帳戶有異常活動，請點擊此連結確認身份。」
第三步：受害者點擊連結，使用了駭客指定的 Session ID
受害者不疑有他，點擊了連結。
這時候會發生什麼事？
瀏覽器向網站發送請求，網址裡帶著 ?sid=abc123。
網站的伺服器收到這個請求後，看到網址裡有 sid=abc123。
前面提到，Session ID 是存在瀏覽器的 Cookie 裡。
當瀏覽器發送請求時，會自動從 Cookie 裡取出 Session ID，放進 HTTP 請求標頭（Request Header）的 Cookie 欄位，傳給伺服器。
這是最常見的做法。
但有些網站為了相容性，會設計成「同時接受多種來源的 Session ID」。
例如，早期有些瀏覽器不支援 Cookie，所以網站會改用網址來傳遞 Session ID。
這種設計讓 Session ID 可能來自：
- Cookie（最常見）
- 網址參數（例如
?sid=abc123） - 表單的隱藏欄位
如果網站有支援「從網址讀取 Session ID」這個功能，伺服器就會去檢查網址裡有沒有 sid 參數。
當伺服器讀到 sid=abc123 時，如果沒有做好防護，就會直接說「好，那你的 Session ID 就是 abc123」，然後拿這個 ID 來用。
伺服器沒有驗證這個 Session ID 是不是合法的，就直接接受了。
接著，伺服器在回應時，會透過 Set-Cookie 把 abc123 寫進受害者瀏覽器的 Cookie 裡。
所以流程是這樣的：
- Session ID 一開始放在「網址」裡
- 伺服器收到後，把它設定到「Cookie」裡
- 之後瀏覽器的每次請求，都會從 Cookie 帶上這個 Session ID
這就是「網址」和「Cookie」之間的關係。
駭客透過網址「塞」進去，伺服器再把它「存」到 Cookie。
受害者的瀏覽器就被「設定」成使用 abc123 這個 Session ID 了。
受害者看到登入頁面，輸入了自己的帳號密碼。
登入成功。
第四步：問題來了——Session ID 沒有更換
這是整個攻擊的關鍵。
回想一下前面說的：abc123 一開始只是一個「空的通行證」，沒有綁定任何身份。
當受害者輸入帳號密碼、登入成功後，伺服器會把受害者的身份和 abc123 綁定在一起。
現在 abc123 不再是空的了，它代表的是「受害者的登入狀態」。
正常情況下，網站應該在這個時候「換一個新的 Session ID」。
為什麼要換呢？
因為登入前和登入後，使用者的「權限」不一樣。
登入前，你只是一個訪客，只能瀏覽公開的內容。
登入後，你是一個會員，可以看到個人資料、進行交易、修改設定。
這是一個重要的權限變化。
為了安全起見，每當權限發生變化時，就應該換一個新的 Session ID。
這樣可以確保「登入後的 Session ID」不會被任何人事先知道。
但如果網站沒有這麼做，受害者登入後用的還是 abc123。
而這個 abc123，駭客早就知道了。
第五步：駭客用同一個 Session ID 冒充受害者
駭客手上也有 abc123 這個 Session ID。
現在，這個 Session ID 已經和「受害者的登入狀態」綁定了。
駭客要怎麼利用這個 Session ID 呢？
駭客只要把 abc123 放進自己瀏覽器的 Cookie 裡，然後訪問網站就可以了。
當駭客的瀏覽器發送請求時，會帶上 Cookie: session_id=abc123。
伺服器收到這個請求，檢查 Session ID，發現 abc123 對應的是「受害者的登入狀態」。
伺服器不知道這個請求是駭客發的，它只認 Session ID。
對伺服器來說，「誰拿著 abc123，誰就是那個登入的使用者」。
所以駭客完全不需要知道受害者的帳號密碼，也不需要登入。
他只要拿著這個 Session ID，就能直接以「已登入」的狀態進入網站。
駭客成功冒充受害者的身份，可以看到受害者的個人資料、進行交易、修改密碼等等。
Session Fixation 攻擊範例
讓我們用一個簡單的範例，把整個攻擊流程串起來。
假設有一個購物網站 shop.example.com，它的 Session 管理有漏洞。
駭客的準備工作：
駭客先造訪 shop.example.com，網站給了他一個 Session ID：abc123。
駭客製作了一個惡意連結：
https://shop.example.com/login?sid=abc123然後發送一封釣魚郵件給受害者：
「親愛的會員您好，您的帳戶有異常登入紀錄，請點擊以下連結確認身份。」
受害者中招：
受害者看到郵件，緊張地點擊了連結。
瀏覽器發送請求：
GET /login?sid=abc123 HTTP/1.1
Host: shop.example.com伺服器收到請求，看到網址有 sid=abc123，就把這個 Session ID 設定給受害者。
伺服器回應：
HTTP/1.1 200 OK
Set-Cookie: session_id=abc123受害者的瀏覽器收到回應，把 session_id=abc123 存進 Cookie。
受害者在登入頁面輸入帳號密碼，登入成功。
伺服器把「受害者的身份」和 abc123 綁定在一起。
駭客得手：
駭客把 session_id=abc123 設定到自己的瀏覽器 Cookie 裡。
然後訪問 shop.example.com，瀏覽器發送請求：
GET /account HTTP/1.1
Host: shop.example.com
Cookie: session_id=abc123伺服器檢查 abc123，發現它對應的是受害者的登入狀態。
駭客成功進入受害者的帳戶，看到了受害者的個人資料、訂單紀錄、信用卡資訊。
為什麼叫做 Session Fixation（會話固定）？
了解了攻擊原理後，我們來看看這個名字的意思。
Fixation（固定）
「固定」指的是駭客「預先設定」了 Session ID。
在正常情況下，Session ID 應該是由伺服器「隨機產生」並分配給使用者的。
但在這個攻擊中，駭客把 Session ID「固定」成自己知道的值。
受害者被迫使用這個被「固定」的 Session ID。
Session（會話）
「會話」指的是使用者和網站之間的互動過程。
從你登入到登出，這整個過程就是一個 Session。
組合起來：Session Fixation
- Session（會話）：使用者和網站之間的互動狀態
- Fixation（固定）：駭客預先指定了 Session ID
合在一起就是：駭客預先固定一個 Session ID，讓受害者使用這個 ID 登入，然後駭客用同一個 ID 冒充受害者。
Session Fixation 可以造成什麼危害？
一旦駭客成功冒充受害者的身份，他可以做很多事情。
存取個人資料
駭客可以看到受害者的個人資料、交易紀錄、私人訊息等敏感資訊。
進行未授權的操作
駭客可以用受害者的身份進行各種操作。
例如：在電商網站下單、在銀行網站轉帳、在社群網站發文等。
受害者可能完全不知情，直到收到帳單或被朋友詢問。
修改帳戶設定
駭客可以修改受害者的密碼、Email、手機號碼等。
這樣一來，受害者就會被「鎖在門外」，無法登入自己的帳戶。
而駭客則完全掌控了這個帳戶。
開發者如何防範 Session Fixation 攻擊？
Session Fixation 攻擊的核心問題在於：
使用者登入前後，使用了同一個 Session ID。
駭客正是利用這一點，才能用「預先知道」的 Session ID 冒充使用者。
所以防護的核心思路很簡單：
在使用者登入成功後，換一個新的 Session ID。
這樣一來，就算駭客事先知道舊的 Session ID，也沒有用了。
因為使用者登入後，用的是新的 Session ID，駭客手上的舊 ID 已經無效。
防護方式一：登入後重新產生 Session ID
這是最重要的防護措施。
當使用者成功登入後，伺服器應該要：
- 把舊的 Session ID 作廢
- 產生一個全新的 Session ID
- 把新的 Session ID 傳給使用者的瀏覽器
這個動作叫做「Session Regeneration」（Session 重新產生）。
大部分的網頁開發框架都有內建這個功能，開發者只需要在登入成功後呼叫對應的函式即可。
防護方式二：不接受從網址傳入的 Session ID
前面提到，有些網站為了相容性，會接受從網址參數傳入的 Session ID。
這是一個很大的安全漏洞。
因為駭客可以輕易地把 Session ID 放在網址裡，透過釣魚郵件發送給受害者。
正確的做法是：只接受從 Cookie 傳入的 Session ID，不接受從網址或表單傳入的。
這樣駭客就沒辦法透過惡意連結「塞」Session ID 給受害者了。
防護方式三：設定 Cookie 的安全屬性
Session ID 通常是透過 Cookie 傳遞的。
開發者可以設定 Cookie 的安全屬性，增加額外的保護：
這些屬性雖然不能直接防止 Session Fixation，但可以增加整體的安全性。
防護重點整理
最重要的一點：登入後一定要換新的 Session ID。
只要做到這一點，Session Fixation 攻擊就無法成功。
小結
讓我們回顧一下這篇文章的重點：
- Session 是什麼：網站用來「記住」使用者身份的機制，透過 Session ID 識別使用者
- Session Fixation 攻擊原理：駭客預先設定一個 Session ID，讓受害者使用這個 ID 登入，然後駭客用同一個 ID 冒充受害者
- 和 Session Hijacking 的差異：Fixation 是「給」你一張房卡，Hijacking 是「偷」你的房卡
- 可能的危害：存取個人資料、進行未授權操作、修改帳戶設定
- 防護方式：登入後重新產生 Session ID（最重要）、不接受來路不明的 Session ID、設定 Cookie 安全屬性
Session Fixation 是一種容易被忽略的攻擊，但只要在登入後重新產生 Session ID，就能有效防範。
身為開發者，請務必確保你的網站有做到這一點。