涛哥，我ssh老大，级联技术经理

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问题等等

分享：