你必須了解的Session的本質(2)

　　在客戶端的第二次請求中包含的Cookie頭部中，提供給了服務器端可以用來唯一標識客戶端身份的信息。這時，服務器端也就可以判斷客戶端是否啟用了cookies。盡管，用戶可能在和應用程序交互的過程中突然禁用cookies的使用，但是，這個情況基本是不太可能發生的，所以可以不加以考慮，這在實踐中也被證明是對的。

　　GET and POST Data

　　除了cookies,客戶端還可以將發送給服務器的數據包含在請求的url中，比如請求的參數或者請求的路徑中。 我們來看一個例子：

　　GET /index.php?foo=bar HTTP/1.1

　　Host: example.org

　　以上就是一個常規的http get 請求，該get請求發送到example.org域名對應的web 服務器下的index.php腳本, 在index.php腳本中，可以通過$_GET['foo']來獲取對應的url中foo參數的值，也就是’bar’。大多數php開發者都稱這樣的數據會GET數據，也有少數稱它為查詢數據或者url變量。但是大家需要注意一點，不是說GET數據就只能包含在HTTP GET類型的請求中，在HTTP POST類型的請求中同樣可以包含GET數據，只要將相關GET數據包含在請求的url中即可，也就是說GET數據的傳遞不依賴與具體請求的類型。

　　另外一種客戶端傳遞數據到服務器端的方式是將數據包含在http請求的內容區域內。 這種方式需要請求的類型是POST的，看下面一個例子：

　　POST /index.php HTTP/1.1

　　Host: example.org

　　Content-Type: application/x-www-form-urlencoded

　　Content-Length: 7

　　foo=bar

　　在這種情況下，在腳本index.php可以通過調用$_POST['foo']來獲取對應的值bar。開發者稱這個數據為POST數據,也就是大家熟知的form以post方式提交請求的方式。

　　在一個請求中，可以同時包含這兩種形式的數據：

　　POST /index.php?myget=foo HTTP/1.1

　　Host: example.orgContent-Type: application/x-www-form-urlencoded

　　Content-Length: 11

　　mypost=bar

　　這兩種傳遞數據的方式，比起用cookies來傳遞數據更穩定，因為cookie可能被禁用，但是以GET以及POST方式傳遞數據時，不存在這種情況。我們可以將PHPSESSID包含在http請求的url中，就像下面的例子一樣：

　　GET /index.php?PHPSESSID=12345 HTTP/1.1

　　Host: example.org

　　以這種方式傳遞session id的話，可以跟用cookie頭部傳遞session id一樣，達到同樣的效果， 但是，缺點就是需要開發者認為地將session id附加在url中或者作為隱藏字段加入到表單中。不像cookie一樣，只要服務器端指示客戶端創建cookie成功以后，客戶端在后續的請求中，會自動第將對應的沒有過期的cookie傳遞給服務器端。當然，php在開啟session.use_trans_sid后，也可以自動地將session id 附加在url中以及表單的隱藏字段中，但是這個選項不建議開啟，因為存在安全問題。這樣的話，容易泄露session id, 比如有的用戶會bookmark一個url或者分享一個url，那么session id也就暴露了，加入這個session id還沒有過期，那是有一定的安全問題存在的，除非服務器端，除了session id外，還附加了其它方式進行驗證用戶的合法性!

　　盡管以POST的方式來傳遞session id的話，相對GET的方式來說，會安全的多。但是，這種方式的缺點就是比較麻煩，因為這樣的話，在你的應用程序中比較將所有的請求都轉換成post的請求，這顯然是不太合適的。

　　Session的管理

　　直到現在，我只討論了如何維護應用程序的狀態，只是簡單地涉及到了如果保持請求之間的關系。接下來，我闡述下在實際中用到比較多的技術 - Session的管理。涉及到session的管理，就不是單單地維持各個請求之間的狀態，還需要維持會話期間針對每個特定用戶使用到的數據。我們常常把這種數據叫做session數據，因為這些數據是跟某個特定用戶與服務器之間的會話相關聯的。如果你使用php內置的session的管理機制，那么session數據一般是保存在/tmp這個服務器端的文件夾中，并且其中的session數據會被自動地保存到超級數組$_SESSION中。一個最簡單的使用session的例子，就是將相關的session數據從一個頁面傳遞(注意：實際傳遞的是session id)到另一個頁面。下面用示例代碼1, start.php, 對這個例子加以演示：

　　Listing 1 - start.php

　　session_start();

　　$_SESSION['foo'] = 'bar';

　　?>

　　continue.php

　　假如用戶點擊start.php中的鏈接訪問continue.php,那么在continue.php中就可以通過$_SESSION['foo']獲取在start.php中的定義的值’bar’?？聪旅娴氖纠a2:

　　Listing 2: - continue.php

　　session_start();

　　echo $_SESSION['foo']; /* bar */

　　?>

　　是不是非常簡單，但是我要指出的話，如果你真的這樣來寫代碼的話，說明你對php底層的對于session的實現機制還不是非常了解透徹。在不了解php內部給你自動做了多少事情的情況下，你會發現如果程序出錯的話，這樣的代碼將變的很難調試，事實上，這樣的代碼也完全沒有安全性可言。

　　Session的安全性問題

　　一直以來很多開發者都認為php內置的session管理機制是具有一定的安全性，可以對一般的session攻擊起到防御。事實上，這是一種誤解，php團隊只實現了一種方便有效的機制。具體的安全措施，應該有應用程序的開發團隊來實施。 就像開篇談到的，沒有最好的解決方案，只有最合適你的方案。

　　現在，我們來看下一個比較常規的針對session的攻擊：

　　用戶訪問http://www.example.org，并且登錄。

　　example.org的服務器設置指示客戶端設置相關cookie - PHPSESSID=12345

　　攻擊者這時訪問http://www.example.org/,并且在請求中攜帶了對應的cookie - PHPSESSID=12345

原文轉自：http://blogread.cn/it/article/6004?f=wb1