無法理解重新生成的會話ID

Question

我剛剛從這個小提琴學習會話固定攻擊
http://shiflett.org/articles/session-fixation
但是為了防御這種攻擊，我不了解session_regenerate_id（）的用途是什么？
當攻擊者在URL中包含會話ID並告訴服務器我要使用此會話時，與該會話相關的所有會話變量都對他有用，那么為什么重新生成ID有用呢？
謝謝

Answer 1

在網站的整個生命周期中，都會有許多“會話”。 這些會話中的每一個都由一個ID標識，這是網站如何知道誰是誰並能夠保持不同請求之間狀態的方式。

會話固定攻擊實際上只有在獲得會話ID的情況下才可能發生。 一些站點允許會話在不同的實際瀏覽會話之間持久存在（也稱為“記住我”功能），如果使用相同的會話ID，則更容易受到此攻擊。

如果我掌握了您的會話ID，那么只有該會話ID有效時，我才能模擬您。 使用session_regenerate_id ，舊的ID變得無效，從而使它對於可能被其攔截的任何人都無效。 如果您在用戶成功進行身份驗證之后生成了一個新ID，則任何捕獲會話標識符的嘗試都將不再為已身份驗證的用戶產生有效的標識符（僅是用戶在進行身份驗證之前所擁有的“匿名”會話） ，這意味着攻擊者只能“模擬”匿名用戶。

一些更具安全意識的框架實際上是在瀏覽會話中重新生成會話ID（使用低至2-3分鍾的超時），而不是僅在用戶登錄時才幫助防止人們通過網絡上的數據包嗅探獲取會話ID。 只能響應請求重新生成會話ID。

Answer 2

要記住的關鍵點是，為了保持會話狀態， 客戶端在每次請求時都會向服務器報告其當前會話ID 。 報告機制本身（例如，通過cookie或URL參數）在這里並不重要。

從服務器的角度來看，並且不采取任何高級預防措施¹，客戶端報告的會話ID是權威的：服務器沒有針對任何特定客戶端的“正確”或“真實”會話ID的概念。 客戶就是他們所說的。

當然，這引發了一個問題：是什么使我無法宣布我是一個有權對您的應用程序執行任何操作的站點管理員？ 只有我不知道真實管理員的會話ID的事實（假設真實管理員確實有一個會話）。 如果這樣做，我可以冒充管理員，並盡他們所能。

因此，現在從攻擊者的角度來看：我如何學習管理員的會話ID？ 誘使管理員自行選擇向服務器報告特定的會話ID會起作用！ 這是會話固定攻擊的本質。

有幾種方法可以防止或減輕此攻擊的影響，其中一種方法是使服務器告訴客戶端“我更改了您的會話ID；從現在開始，請使用此方法”。 當然，不會強迫客戶端遵守，但是友好的客戶端當然會這樣做（並且服務器可以拒絕識別客戶端，即使它們是敵對的）。 因此，即使攻擊者設法誘騙管理員使用攻擊者已知的特定會話ID，只要服務器不指示客戶端切換到其他會話ID，攻擊也將起作用。

而這正是session_regenerate_id所做的。

---

¹先進的預防措施：例如，服務器可能會跟蹤客戶端為每個會話ID使用的最后一個IP地址。 如果服務器看到具有給定會話ID的請求來自其他IP地址，則該請求可疑。 當然，這個簡單的例子不能說明現代互聯網基礎設施的復雜性，但是這個想法很明確。 高安全性服務（例如Gmail）使用相同類型的復雜技術來檢測和防止可疑活動。

Answer 3

如果會話ID在URL中，並且攻擊者以某種方式使另一個用戶訪問此URL，則攻擊者將知道該會話ID。

例如，假設攻擊者將此代碼段放置在自己的網站“ evil.com ”上（為簡潔起見，對會話ID進行了修剪）

<a href="https://www.example.com/login.php?PHPSESSID=a123">Login to site to continue</a>

然后誘使受害者訪問他們的網站（例如，向他們發送包含指向“ evil.com ”鏈接的電子郵件）。 如果用戶訪問攻擊者的網站，然后單擊“ example.com ”的鏈接，然后登錄，則攻擊者可能會單擊相同的鏈接並劫持當前已登錄的會話（因為ID將匹配）。 例如，該鏈接可能指向Facebook上的有趣視頻，但該鏈接將在URL中包含會話ID，而不僅僅是直接登錄頁面。

但是，如果在登錄過程中調用了session_regenerate_id（）（僅在驗證用戶名和密碼之后），則會話ID現在將是新的，攻擊者將無法使用此方法劫持會話。

這不是限於URL中的會話ID的漏洞。 假設網站的其余部分為HTTP，並且在登錄后將會話移至HTTPS，則明智的做法是重新生成會話ID，因為在HTTP上訪問流量時可能已經攔截了現有的會話ID。