HTTP 協議是 stateless，所以想要【認證】使用者就必須加一些機制。

目前最常見的就是 Cookie，此機制原則上沒什麼問題，只是在某些場景會遇到潛在法規問題，例如 DNT (Do not track) 計劃，不過 Yahoo! 在 2014 年因某些原因宣布放棄遵守。

有些人會因為諸多因素，而改採用 Cookieless session。顧名思義，就是完全不使用軟體(如瀏覽器)內建的 Cookie 機制，而依賴 HTTP 協議其它方式以達到【認證】目的。這套手法又分為 100% 及非 100% 準確的實作 (非 100% 準確，意即認證機制有模糊容忍空間，可能會誤判 A 為 B)。

今天要談 100% 準確的 Cookieless session 其一實作手法，也是目前最多人用的帶 URL 的 Cookieless session 方式 (ASP.NET 直接內建此實作)。

為了 100% 認證/追蹤使用者，此手法必須讓使用者在該網站所有的連結 URL 後面，都加上獨一無二的【字串】。例如使用者登入網站後，原本網頁 URL 是 “http://example.com/" 要變成 “http://example.com/?sessionid=xxxxxx" ，而且之後所有網站需要認證該使用者的 URL 頁面都要加上同樣的 sessionid。

但這種實作手法安全嗎？原則上，只要 sessionid 的值被別人知道，那麼就有可利用的空間。因為網站只認這個 sessionid，而這個 sessionid 對網站來說就代表你，所以若有其它人取得同樣的 sessionid，在網站沒有其它額外的處理下，網站會認為他就是你。

情境一，社交網絡的分享。

很多網站內建【一鍵即分享到社交網絡】的功能，也就是把你所在該網頁的 URL 分享出去。

倘若分享機制沒有/或沒有辦法將該 URL 後面的 sessionid 抹除的話，那麼任何人點選你的分享出去【帶有 sessionid 的 URL】後，對該網站來說，權限就等同於你個人。

這將授權他人瀏覽你在該網站上留下的個人資訊、貼刪文、網路購物、交易清單、好友/封鎖清單等。

所幸，目前幾乎所有分享機制都有防護此招，我們可以不用太擔心。

情境二，Copy / Paste URL

若你不小心在網路論壇(Forum)、LINE、WhatsApp 等平台散播【帶有 sessionid 的 URL】時，他們可不會把敏感資訊抹除。(你可以試試在這些平台上貼上帶有 sessionid 的 URL)

則所有看到此訊息的人，都得以獲取你在該網站的權限。而更需要擔心的是，他們可能也不知道危險性，而將該 URL 轉貼至其它平台或他人，讓更多有心人得以利用。

情境三，社交工程獲取網址

很多人根本不知道將【帶有 sessionid 的 URL】分享出去會有多可怕。所以有心人很容易利用社交工程手法，以騙取到你的 sessionid。

例如，有心人騙你是網站客服，因為某些原因，請您登入網站後，將網址回報給他，那麼他就可依你的身份進入網站。

情境四，詐騙網址．線上監控

這是情境三的反轉。

有心人先登入該網站，然後將他自己【帶有 sessionid 的 URL】以任何可能成功的方式傳送給你。當你誤點選並操作時，因為你與他都有相同的 sessionid，所以你的所有操作結果，他都可以直接獲得，不需事後再騙你的 sessionid。

例如，當你誤點選並註冊填寫你的個人資料時，有心人就可以直接線上獲得；或者當你進行採購時，有心人也可以直接線上得知採購清單或收貨地址等。

結論

上述提到的 Cookieless session 手法，很大的安全問題在於 URL 漏露的風險高於 Cookie 失竊，畢竟光從瀏覽器中取得 Cookie 內容就不是一般使用者容易做到的。

而身為網站的開發者或經營者，採用 Cookieless session 手法時，確實需要再三思。