cookie的secure、httponly屬性設定

標籤：

cookie的secure、httponly屬性設定轉載自：http://www.cnblogs.com/alanzyy/archive/2011/10/14/2212484.html一、屬性說明：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。  （3）JBOSS的設定找到<myJBossServerInstancePath>/deploy/jbossweb.sar/context.xml
 Java代碼  

1. <Context cookies="true" crossContext="true">  
2.     <SessionCookie secure="true" httpOnly="true" />  
3.     ......  
4. </Context>  

 可以使用專門的工具(fiddler2，burp)對安全性進行測試。

cookie的secure、httponly屬性設定