在默認的JSP、PHP配置中，SessionID是需要存儲在Cookie中的，默認Cookie名為：

PHPSESSIONID

JSESSIONID

以下以PHP為例：

你第一次訪問網(wǎng)站時，

服務端腳本中開啟了Sessionsession_start();，

服務器會生成一個不重復的 SESSIONID 的文件session_id();，比如在/var/lib/php/session目錄

并將返回(Response)如下的HTTP頭 Set-Cookie:PHPSESSIONID=xxxxxxx

客戶端接收到Set-Cookie的頭，將PHPSESSIONID寫入cookie

當你第二次訪問頁面時，所有Cookie會附帶的請求頭(Request)發(fā)送給服務器端

服務器識別PHPSESSIONID這個cookie，然后去session目錄查找對應session文件，

找到這個session文件后，檢查是否過期，如果沒有過期，去讀取Session文件中的配置；如果已經(jīng)過期，清空其中的配置

如果客戶端禁用了Cookie，那PHPSESSIONID都無法寫入客戶端，Session還能用？

答案顯而易見：不能

并且服務端因為沒有得到PHPSESSIONID的cookie，會不停的生成session_id文件

取巧傳遞session_id

但是這難不倒服務端程序，聰明的程序員想到，如果一個Cookie都沒接收到，基本上可以預判客戶端禁用了Cookie，那將session_id附帶在每個網(wǎng)址后面(包括POST)，
比如：

GET http://www.xx.com/index.php?session_id=xxxxx
POST http://www.xx.com/post.php?session_id=xxxxx

然后在每個頁面的開頭使用session_id($_GET['session_id'])，來強制指定當前session_id

這樣，答案就變成了：能

聰明的你肯定想到，那將這個網(wǎng)站發(fā)送給別人，那么他將會以你的身份登錄并做所有的事情
（目前很多訂閱公眾號就將openid附帶在網(wǎng)址后面，這是同樣的漏洞）。

其實不僅僅如此，cookie也可以被盜用，比如XSS注入，通過XSS漏洞獲取大量的Cookie，也就是控制了大量的用戶，騰訊有專門的XSS漏洞掃描機制，因為大量的QQ盜用，發(fā)廣告就是因為XSS漏洞

所以Laravel等框架中，內部實現(xiàn)了Session的所有邏輯，并將PHPSESSIONID設置為httponly并加密，這樣，前端JS就無法讀取和修改這些敏感信息，降低了被盜用的風險。

Cookie在現(xiàn)代

禁用Cookie是?IE6?那個年代的事情，現(xiàn)在的網(wǎng)站都非常的依賴Cookie，禁用Cookie會造成大量的麻煩。

在Flash還流行的年代，F(xiàn)lash在提交數(shù)據(jù)會經(jīng)常出現(xiàn)用戶無法找到的情況，其實是因為Flash在IE下是獨立的程序，無法得到IE下的Cookie。
所以在Flash的flash_var中，一般都會指定當前的session_id，讓Flash提交數(shù)據(jù)的時候，將這個session_id附帶著提交過去
Chrome中使用 Flash沙箱 已經(jīng)解決了cookie的問題，但是為了兼容IE，比如swfupload等flash程序都要求開發(fā)者附帶一個session_id