`
weifly
  • 浏览: 235195 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

会话串号

 
阅读更多

最近碰到了串号问题,即A登录后,进入某个功能时,看到了B的页面。困扰了很多时间。查看http响应头内容如下:

 

Age:1762
Content-Language:zh-CN
Content-Length:25035
Content-Type:text/html;charset=UTF-8
Date:Mon, 28 Mar 2016 01:11:45 GMT

 

“Age”http头?查看http协议定义如下:

 

The Age response-header field conveys the sender's estimate of the amount of time since the response (or its revalidation) was generated at the origin server. A cached response is “fresh” if its age does not exceed its freshness lifetime.

 

这个页面被缓存了?否则的话,不会产生Age头啊。最终发现web防火墙中开启了站点加速功能,关闭加速功能并清空缓存后,问题解决。

 

转一篇文章:http://it.taocms.org/06/791.htm

 

说起淘宝网用户串号,我的印象里技术bug原因的有两起。2010年,这个串号持续的时间比较长,我估计应该存在几年时间了。从淘宝的论坛里隔三差五会爆出案例来,xxx突然在访问我的淘宝页面时进入了别人家的账号,第一感觉是发现“所有已买到的,或者已卖出的商品”都不是自己的,并且可以对这些信息进行任意的操作,比如删除,下架。
    另一起是,淘宝2012年11的时候爆出来的串号,突然有个卖家告诉我他进入了别人的店铺,并且可以进行任意的操作。
    另外还有一种串号的场景,不过不是由于系统bug引起的,主要是因为数据被缓存引起的串号,这种串号不是真正意义上的串号,因为页面被isv或者某个局域网缓存了,导致看到了别人的商品或者店铺,这种场景用户是不能对看到的页面和数据进行任何管理操作的。
一般这种串号场景我们会在url的后缀上加上一个时间戳,让每个用户的url都不一样,以防止缓存,比如在生成菜单等超链接的时候统一增加时间戳。
    淘宝因为历史原因,所有页面的url都是以htm结尾,这样容易被误认为是静态页面,所以被缓存了也不奇怪。这种类型的串号排查起来也比较简单,问题比较容易被确定,主要判断标准就是只看到了别人的页面,但是没有任何操作权限,并且在url后面加个&id=111之类的参数,页面立马就正常了。
重点说说前两期串号
    第一起称为“request异常引起的串号”,原因是和jboss的tomcat在实现request的时候对异常处理不够准确
Request.java的方法:protected void parseParameters()存在bug,request解析参数存在读取脏数据的可能,这样如果用户在login的时候,出现了这个bug,就有可能login成别人的账号。
http://anonsvn.jboss.org/repos/jbossweb/tags/JBOSSWEB_2_0_1_GA/src/share/classes/org/apache/catalina/connector/Request.java
    第二起称为“非法缓存引起的串号”,原因是店铺系统“shopsystem”在做静态化改造的时候,前置了一个缓存服务器,这个服务器错误的把http的头也给缓存了(头里包含setcookie),因为sessionID是由session框架的客户端在每个系统里创建的,如果http的头被缓存了,那么这个sessionID就会串成了别人的sessionID 。(这里有个疑问,之前cookie里有个签名用来比较和服务端加密出来的值是否一致,如果不一致会清空cookie和session信息,让用户退出登录,为什么这个行为没有被触发呢?按照这个场景,并没有把cookie信息进行修改,而只是修改了sessionID一个cookie,理论上客户端的关键cookie信息和服务端的信息应该是不一致的)
    这两起问题的排查周期都比较长,因为没有一个很好的办法可以识别这种串号问题,而且重现比较困难。既然有第二次串号,相信还会有第三次,第四次。那需要做一些什么事情来杜绝呢?或者有一些可以比较快速就能定位问题的方案。
为了解决串号做过的一些事情:
cookie里增加一个值,用来记录通过关键cookie生产的签名,这个签名是算法非常简单。每次请求到服务端的时候session框架代码里会对此签名进行匹配,如果和服务端获取的数据签名出来的值是一致的,则认为合法,否则清空session信息和cookie信息,让用户重新登录。
思考:session串号
1、能不能杜绝?
2、排查问题能不能更加快速?期望做到一旦发生串号可以被方便的发现,并且定位到是哪个系统导致的。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics