[說明: 本文爲 http://www.smithfox.com/?e=32 原創, 轉載請註明原文, 謝謝]
session的安全有兩層意思:
1> 對最終客戶來說, 不會因爲session的share和造成混亂, 使end-user的信息泄漏以及其他安全問題
2> 對系統本身來說, 不會因爲有hacker通過模擬sessionid和cookie來獲取server信任進而進行惡意破壞
讓我們逐層解釋和展開問題:
1> 首先說明, 本文所有session專指Servlet HttpSession
2> 後臺Session和Browser之間通過JSESSIONID來關聯, JSESSIONID是Servlet標準,也是關鍵字, Servle規定Browser用Mem Cookie來存儲JSESSIONID, 注意並不是disk cookie.一旦瀏覽器關閉後JSESSIONID就從PC消失, 更加安全.
3> Session也是一種很好的安全認證機制, 後臺會標識session是不是已經被認證了, 如果是,就不會讓用戶再輸入password. JSESSIONID可以被理解成爲一個已經認證的key, 所以Session有安全問題.
4> Servlet容器不會構造相同的JSESSIONID, 客戶端也很難預期JSESSIONID
5> HTTPS SSL等技術可以防止網絡傳輸中有人惡意篡改JSESSIONID
6> 禁用Cookie的情況JSESSIONID就必須用URLRewrite. 我們可以通過對URL本身採用摘要算法，自認證來防止惡意篡改JSESSIONID.
比如: http://www.smithfox.com/abc?x=x&y=y&JSESSIONID=sdfdfsdfsdfsdfsdf&HWD=4FE23AD9892C
HWD的值是對整個URL的一個摘要算法, 如果有人改動了URL，這個HWD值就對不上了, 前提應該是這個算法別人不知道的.
7> 用戶在自己的PC上肯定是可以看到當前的JSESSIONID的, 就象就你在自己的日記中看到了自己備忘的password一樣, 這個不是技術安全問題.
8> 一臺機器有多個自然人在使用， 出現的JSESSIONID欺騙， 應該沒有技術辦法可以解決. 只能是end-user自己小心，用完就關閉Browser. 我想這應該是在情理之中的事, 你是合租被盜應該是怪不得小區保安的, 也是需要自己平時提高防盜意識，呵呵.
9> 最近看到Tomcat7有個新的特性說是支持"防JSESSIONID劫持", 這個需要更多瞭解.
10> User和Session的關係.
Session是隻認JSESSIONID不認人的, 包括自然人和系統Account. 這個問題比較搞.
我們用EndUser來表示自然人， User-Account表示系統帳號， 我們分析以下幾種情況
10.1> 兩個EndUser共用一個UserAccount並且在同一臺PC, 這個混亂不是技術問題， 大家都可以理解
10.2> 兩個EndUser分別使用不同的UserAccount在同一臺PC, 這個是合租情況， 造成混亂不一定是技術問題
10.3> 某EndUser有兩個UserAccount在同一臺PC上, 我們需要考慮JSESSIONID在client端可以會混亂的問題.
因爲不同的瀏覽器對於Cookie share的策略不同， 我們按程序設計必須按最容易出問題的Case想，比如IE8.
無論你是IE多窗口還是多TAB都是Share Cookie的. 所以總的指導方針是在client端做一些機制不允許用戶這麼做.
Google的gmail就是這麼做的, 你可以一臺機器上用IE打開兩個不同的gmail account(兩個窗口或是兩個TAB都行)，點新email或是其他需要和後臺交互的行爲時，gmail會退出一個，提示讓你重新login並且gmail account已經固定爲後輸入的User-Account.
具體在Client怎麼防止兩個Account還需高手指點.
10.4> 某EndUserA用自己的UserAccountA先已經login，再訪問另一個UserAccountB的資源，而且該資源是需要訪問密碼的.
這種情況，往往因爲後臺Session設計的層次不清晰，造成了UserAccountA無需Password就直接訪問到了UserAccountB的資源. 而且這個解決方案不能放在Client端， 因爲訪問UserAccountB的資源可能就是一個在Email中的Link，這個click動作客戶端程序JavaScript是無法攔截的.
10.5> 總結來說:
11> 從第10>點可以看出， session和自然人或是UserAccount有着千絲萬縷的聯繫，但不是所有的系統只有User這一層業務概念，所以我們需要理解後臺的Session分劃和設計好Session.Attribute層次.
我們以一個假設業務模型爲例說明問題: 這是一個只面向企業的圖片共享web服務, 可以爲多個公司(企業)提供服務, 用戶必須屬於某一個公司, 用戶可以創建"圖片分組", 圖片分組可以設置爲private(需要密碼訪問), 也可以直接公開. 圖片分組是公司財產, user可以創建"圖片分組", 但是圖片分組資源是歸屬公司, 同一公司內部的所有user可以直接訪問圖片分組(如果是公開), 也可以通過password(如果需要)訪問圖片分組.
這個業務模型中, 既有比User更高層的概念, 比如公司. 也有比User更底的概念, 比如用戶的上傳圖片分組(imageGroup).
11.1> 不同的war包部署在tomcat,不同的war包之間的session是不會混亂的, 這個是由tomcat架構決定的. 另他的沒有做過調查, 也有可能是Servlet標準, 有高手可以幫確認一下.
11.2> 多個公司又是運行在同一個tomcat application內, 怎麼防止不同公司之間的session混亂
可以採用類似於防止重複提交的技術, 首先做一個優先級很高的filter, 每次reqeust和response都需要經過這個filter
在所有login模塊, 設置一個ticket cookie,寫入當前company信息, 每個reqeust到達的第一步就是檢測client cookie和當前的URL信息, 以及session信息是否一致, 如果enduser是從一個company中click了一個其他company的link, 該filter就會發現ticket信息不一致, 然後就強制logout, 再次讓user login. 並且每次response時做ticket的改動, 使client無法模擬
11.3> 怎麼防止imageGroup信息混亂
Session本身是一個集合, 具體還是使用session.attribute["key"]
Session本身是User level的, 對於低於User level的信息, 需要好好規劃attribute key
想像這樣的case:
有兩個imageGroup, 一個是public的, 一個是需要password的,
http://www.smithfox.com/companyIBM/public_images/
http://www.smithfox.com/companyIBM/password_images/
後臺對imageGroup輸入密碼邏輯的僞代碼如下:
boolean needpasswd = true;
if(session.getAttribute("NEED_PASSWORD") == null){
session.setAttribute("NEED_PASSWORD", needpasswd);
boolean needpasswd = 一個很耗時很複雜的驗證函數(user, imageGroup, xxx);
} else{
needpasswd = session.getAttribute("NEED_PASSWORD");
}
if (needpasswd ){
showPasswordDialog() ;
}
看出什麼問題沒?
應該將上面的代碼中的所有attribute key改成 "NEED_PASSWORD"+{imageGroupID}
否則用戶只要先看了一個public後, 後面的所有圖片分組都無需passwd就可以訪問了, 即使這個imageGroup是private的.
13> 在用session之前一定需要檢查是否真的一定需要session來解決, 比如只是想傳value到JSP page， request.setAttribte()更適合
14> 比較小而多的業務對象，如果必須save在session一定要及時removeAttribute否則session用的內存會暴漲.
因爲Session不會因爲客戶端不用了，就會自動清理，而是必須到SessionTimeOut纔會，如果在SessionTimeOut期間內有很多的對象在Session內，就會有問題。所以需要即時清理已經不用的Session.Attribute
15> Cookie和Session一樣, 同樣需要注意 cookie key的層次問題，以及過期問題，domain, path問題等等
