會話cookie中缺少HttpOnly屬性會導致攻擊者可以通過程序(JS腳本、Applet等)獲取到用戶的cookie信息，造成用戶cookie信息泄露，增加攻擊者的跨站腳本攻擊威脅。
HttpOnly是微軟對cookie做的擴展，該值指定cookie是否可通過客戶端腳本訪問。Microsoft Internet Explorer 版本 6 Service Pack 1 和更高版本支持cookie屬性HttpOnly。如果在Cookie中沒有設置HttpOnly屬性爲true，可能導致Cookie被竊取。竊取的Cookie可以包含標識站點用戶的敏感信息，攻擊者可以重播竊取的Cookie，以便僞裝成用戶或獲取敏感信息，進行跨站腳本攻擊等。如果在Cookie中設置HttpOnly屬性爲true，兼容瀏覽器接收到HttpOnly cookie，那麼客戶端通過程序(JS腳本、Applet等)將無法讀取到Cookie信息，這將有助於緩解跨站點腳本威脅。
百度推薦解決辦法：
正常百度這個漏洞，普遍的解決辦法是讓你添加過濾器，在過濾器中設置cookie(參見博客：https://blog.csdn.net/OliverQY/article/details/80846960)。但是小編在一個特殊的實際應用場景中發現，這種做法會存在一個隱藏問題，這種方式的確會在cookie中加上httponly的標識，但是會引發另一個問題。
特殊場景：
在單點登錄的情況下，還是登錄邏輯是調用第三方提供的登錄接口來實現登錄的情況下，就會出現一種現象：
第一步：正常登錄進去，然後重啓服務器
第二步：刷新界面，就會讓你重新登錄，但是你死活都停留在了登錄的界面
原因：
-
第一步只是爲了使客戶端服務器保存一個會話cookieA
-
第二步並不是沒有登錄成功，而是第一次發登錄請求req1的時候，cookie是第一步中的cooikeA。
-
服務端根據這個cookieA去session會話池中找不到這個sessionA，就重新打開了一個新的會話sessionB，將登錄成功的信息都寫在會話sessionB中
-
登錄成功，前端js根據請求req1返回的結果，成功跳轉到首頁，發起了第二個請求req2，這個請求req2依舊使用的還是本地緩存的cookieA
-
於是服務端根據這個cookieA去session會話池中找不到這個sessionA，就又重新打開了一個新的會話sessionC，發現sessionC中沒有任何信息，是個空的session，單點的過濾器就會把他轉到登錄界面，於是就又來到了登錄界面。
小編推薦解決方案：
理論上，按照推薦的方法添加寫cookie的過濾器應該把新會話的sessionID寫到cookie中替換掉本地緩存的cookie纔對，的確，如果替換掉了，也的確不會發生這個現象，但是他偏偏沒有替換掉。抓包的過程中發現，請求的sessionID和返回的sessionID已經不一樣了，但是他依然沒有替換掉客戶端緩存的cookie信息。
於是小編就在想，能不能從容器入手，去tomcat的官網一看，so easy，分分鐘解決這個httponly的漏洞。參考鏈接：http://tomcat.apache.org/tomcat-6.0-doc/config/context.html 搜索關鍵字“httponly”。只需要在tomcat/conf/content.xml中的content節點加一個屬性useHttpOnly=true即可。
<Context useHttpOnly="true">
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
</Context>
當然小編這裏使用的是tomcat容器，目前有很多容器，但是小編相信主流的容器都會有等同於這個設置屬性的，沒事多看看官方文檔。
在tomcat7以下的版本中這個屬性默認是false，需要手動的設置爲true，7及7以上版本中這個屬性已經默認爲false了。
