另一起是，淘宝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成别人的账号。

   第二起称为“非法缓存引起的串号”，原因是店铺系统“shopsystem”在做静态化改造的时候，前置了一个缓存服务器，这个服务器错误的把http的头也给缓存了(头里包含setcookie)，因为sessionID是由session框架的客户端在每个系统里创建的，如果http的头被缓存了，那么这个sessionID就会串成了别人的sessionID 。(这里有个疑问，之前cookie里有个签名用来比较和服务端加密出来的值是否一致，如果不一致会清空cookie和session信息，让用户退出登录，为什么这个行为没有被触发呢？按照这个场景，并没有把cookie信息进行修改，而只是修改了sessionID一个cookie，理论上客户端的关键cookie信息和服务端的信息应该是不一致的)

   这两起问题的排查周期都比较长，因为没有一个很好的办法可以识别这种串号问题，而且重现比较困难。既然有第二次串号，相信还会有第三次，第四次。那需要做一些什么事情来杜绝呢？或者有一些可以比较快速就能定位问题的方案。

为了解决串号做过的一些事情：

cookie里增加一个值，用来记录通过关键cookie生产的签名，这个签名是算法非常简单。每次请求到服务端的时候session框架代码里会对此签名进行匹配，如果和服务端获取的数据签名出来的值是一致的，则认为合法，否则清空session信息和cookie信息，让用户重新登录。