会话固定漏洞¶
Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID, more specifically the vulnerable web application. When authenticating a user, it doesn’t assign a new session ID, making it possible to use an existent session ID. The attack consists of obtaining a valid session ID (e.g. by connecting to the application), inducing a user to authenticate himself with that session ID, and then hijacking the user-validated session by the knowledge of the used session ID. The attacker has to provide a legitimate Web application session ID and try to make the victim’s browser use it.
The session fixation attack is not a class of Session Hijacking, which steals the established session between the client and the Web Server after the user logs in. Instead, the Session Fixation attack fixes an established session on the victim’s browser, so the attack starts before the user logs in.
There are several techniques to execute the attack; it depends on how the Web application deals with session tokens. Below are some of the most common techniques:
-
Session token in the URL argument: The Session ID is sent to the victim in a hyperlink and the victim accesses the site through the malicious URL.
-
Session token in a hidden form field: In this method, the victim must be tricked to authenticate in the target Web Server, using a login form developed for the attacker. The form could be hosted in the evil web server or directly in html formatted e-mail.
-
Session ID in a cookie:
-
Client-side script
Most browsers support the execution of client-side scripting. In this case, the aggressor could use attacks of code injection as the XSS (Cross-site scripting) attack to insert a malicious code in the hyperlink sent to the victim and fix a Session ID in its cookie. Using the function document.cookie, the browser which executes the command becomes capable of fixing values inside of the cookie that it will use to keep a session between the client and the Web Application.
-
META Tag
Is considered a code injection attack, however, different from the XSS attack where undesirable scripts can be disabled, or the execution can be denied. The attack using this method becomes much more efficient because it’s impossible to disable the processing of these tags in the browsers.
-
HTTP header response-
This method explores the server response to fix the Session ID in the victim’s browser. Including the parameter Set-Cookie in the HTTP header response, the attacker is able to insert the value of Session ID in the cookie and sends it to the victim’s browser.
参考：
https://owasp.org/www-community/attacks/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。
例如：
網址看起來是正常的 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，就能直接以「已登入」的狀態進入網站。
駭客成功冒充受害者的身份，可以看到受害者的個人資料、進行交易、修改密碼等等。