運行着個簡單的demo后，打開login.jsp，使用firebug或chrome會發現，即使沒有登錄，我們也會有一個JSESSIONID,這是由服務器端在會話開始是通過set-cookie來設置的匿名SessionId
可以發現，登錄前和登錄后的JSESSIONID並沒有改變，那么這就是一個固定SessionID的漏洞（詳見《黑客攻防技術寶典-web實戰》第七章）
黑客登錄建設銀行，建設銀行會給黑客返回一個sessionIDA
然后黑客引誘用戶使用自己的正常的用戶和密碼去登錄建設銀行，登錄之后用戶的信息都放在了session之中，登錄之后回話的sessionIDA沒有發生變化
然后黑客使用sessionIDA操作，就可以操作用戶的信息了，偽造請求，訪問登錄后的資源。
在用戶登錄使該JSESSIONID稱為已登錄的ID后，攻擊者就可以利用這個ID偽造請求訪問登錄后的資源
漏洞分析處理
出現該問題的主要原因是登錄控制使用的固定的SessionID，登錄前與登錄后的SessionID是一樣的。這樣就使得攻擊者可以簡單的偽造一個SessionID誘使用戶使用該SessionID登錄，即可獲取登錄權限。如果配合XSS漏洞，則更加可以輕易獲取登錄權限。避免這一漏洞的方法主要有兩種：
1.在登錄后重置sessionID
在登錄驗證成功后，通過重置session，是之前的匿名sessionId失效，這樣可以避免使用偽造的sessionId進行攻擊。代碼如下
解決的辦法如下：
1.在登錄后重置sessionID
在登錄驗證成功后，通過重置session，是之前的匿名sessionId失效，這樣可以避免使用偽造的sessionId進行攻擊。代碼如下
s1：黑客登錄之后，首先判斷當前的session是否存在，現在getsession方法參數默認是true，表示通過jsessionID查找session是否存在，如果存在session存在就使用原來的session，如果不存在就創建一個session。黑客第一次登錄現在不存在session，就創建一個黑客session，在session中把黑客的用戶信息存儲到session中，並且新生成了一個cookerid為：sessionIDA，現在黑客就有了sessionIDA
s3：現在黑客誘導正常用戶使用正常的用戶名和密碼去登錄操作，正常用戶使用用戶名和密碼登錄的時候，攜帶的也是sessionIDA這個jsessionID，在后端通過過jsessionID查找session已經存在了，就把當前的用戶信息就存到了黑客的黑客session中，攻擊者就可以以用戶的信息進行操作了
s4：然后黑客攻擊者就可以利用這個sessionIDAID偽造請求訪問正常用戶登錄后的資源
如何解決上面問題了可以通過使用用戶登錄后充值sessionid，或者設置httponly屬性 來預防
s1：黑客登錄之后，首先判斷當前的session是否存在，現在參數設置成false，表示不存在session就不創建直接返回null，如果參數為true，如果當前session不存在重新創建一個session返回，如果存在session執行session.invalidate方法將原來的session銷毀掉。然后在重新創建一個session，重新生成一個jsessionID
正常用戶登錄成功之后，利用黑客的利用sessionIDA去查找session的時候發現黑客的session已經存在了，首先把黑客的session給消除了，然后自己在創建一個新的session，讓用戶登錄前和登錄后的jessionID不一樣，這樣黑客就無法進行攻擊了。
getSession(boolean create)意思是返回當前reqeust中的HttpSession ，如果當前reqeust中的HttpSession 為null，當create為true，就創建一個新的Session，否則返回null；
第二種解決辦法
2.設置httpOnly屬性
httponly是微軟對cookie做的擴展,該值指定 Cookie 是否可通過客戶端腳本訪問, 解決用戶的cookie可能被盜用的問題,減少跨站腳本攻擊
主流的大多數瀏覽器已經支持此屬性。httpOnly是cookie的擴展屬性，並不包含在servlet2.x的規范里，因此一些javaee應用服務器並不支持httpOnly，針對tomcat，>6.0.19或者>5.5.28的版本才支持httpOnly屬性，具體方法是在conf/context.xml添加httpOnly屬性設置