[原创]session的混乱与安全

[说明: 本文为 http://www.smithfox.com/?e=32 原创, 转载请注明原文, 谢谢]

session的安全有两层意思:

1> 对最终客户来说, 不会因为session的share和造成混乱, 使end-user的信息泄漏以及其他安全问题

2> 对系统本身来说, 不会因为有hacker通过模拟sessionid和cookie来获取server信任进而进行恶意破坏

在 xieyujun2006 * gmail.com 同学的提醒下,重新整理了这篇Blog,完善了User和Session关系一节.

欢迎大家指正我的错误.

让我们逐层解释和展开问题:

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

smithfox | Friday 19 November 2010 at 3:00 pm | | Java        | Used tags:

No comments

(optional field)
(optional field)
为阻止垃圾广告, 请在提交评论前, 回答一个简单问题(Please answer an simple question)
Remember personal info?
Notify
Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.