Session Cookie的HttpOnly和secure屬性
一、屬性說明： 1 secure屬性
當設置為true時，表示創建的 Cookie 會被以安全的形式向服務器傳輸，也就是只能在 HTTPS 連接中被瀏覽器傳遞到服務器端進行會話驗證，如果是 HTTP 連接則不會傳遞該信息，所以不會被竊取到Cookie 的具體內容。
2 HttpOnly屬性
如果在Cookie中設置了"HttpOnly"屬性，那么通過程序(JS腳本、Applet等)將無法讀取到Cookie信息，這樣能有效的防止XSS攻擊。
對於以上兩個屬性， 首先，secure屬性是防止信息在傳遞的過程中被監聽捕獲后信息泄漏，HttpOnly屬性的目的是防止程序獲取cookie后進行攻擊。
其次，GlassFish2.x支持的是servlet2.5，而servlet2.5不支持Session Cookie的"HttpOnly"屬性。不過使用Filter做一定的處理可以簡單的實現HttpOnly屬性。GlashFish3.0(支持servlet3.0)默認開啟Session Cookie的HttpOnly屬性。
也就是說兩個屬性，並不能解決cookie在本機出現的信息泄漏的問題(FireFox的插件FireBug能直接看到cookie的相關信息)。
二、實例
項目架構環境：jsp+servlet+applet
1 添加HttpOnly和secure屬性
根據之前的說明，GlassFish2不支持Session Cookie的HttpOnly屬性，以及secure屬性也需要自己進行設置，所以最后的處理方法是：在工程各添加一個Filter，對請求的入口頁面(或者是請求后跳轉到的第一個客戶可見的頁面，一般是登陸頁面)，重新設置客戶端的session屬性。
(response.setHeader("SET-COOKIE", "JSESSIONID=" + sessionid + ";Path=/ccrl;secure;HttpOnly"); 可以看出，這句話的前提是這里只能使用Session Cookie這唯一一個Cookie，不能使用其他Cookie在瀏覽器和服務器之間交互，否則會清除其他Cookie信息，如果一定要支持其他的Cookie，可以在Header下功夫)
2 修改程序中不兼容的代碼(ccrl113)
（1）現象：在Session Cookie被設置為HttpOnly屬性后，因為程序再也取不到客戶端Session Cookie的內容，導致Applet發送URLConnection請求到服務器時，無法從瀏覽器中讀取到sessionID，致使一些依賴於session中內容的URLConnection無法返回正確的結果。
解決：在啟動Applet時先將SessionID信息傳入到applet中，然后在URLConnection發送請求時，重新設置Session Cookie信息。urlCon.setRequestProperty("Cookie", "JSESSIONID=" + ssid + ";Path=/ccrl113;secure;HttpOnly");
（2）現象：在Dynamic Analysis啟動時，在jsp頁面中存在使用
URLConnection訪問servlet的情況，可是在HTTPS的情況下，不允許jsp使用URLConnection訪問servlet(從現象推論)。
解決：將servlet中的內容重構抽取成工具類或是實體類供jsp頁面使用。因為jsp頁面和servlet都是服務器端，所以完全可以避免jsp頁面通過URLConnection訪問servlet。