漏洞概要 关注数(24) 关注此漏洞
>
漏洞详情
披露状态：
2015-07-29： 积极联系厂商并且等待厂商认领中，细节不对外公开
2015-09-12： 厂商已经主动忽略漏洞，细节向公众公开
简要描述：
先说下什么是session覆盖漏洞？
session是存储在服务端 cookie是储存在客户端。cookie可以直接修改 但是session没有办法直接修改 因为储存在服务端。小子你能直接修改服务端存储的东西？
详细说明：
先说下什么是session覆盖漏洞？
session是存储在服务端 cookie是储存在客户端。cookie可以直接修改 但是session没有办法直接修改 因为储存在服务端。小子你能直接修改服务端存储的东西？
那么怎么办？首先如果session里面存储个 abc abc的值是123 那么如果我再次让服务端生成个 abc 里面的值是 456 那么456是不是就覆盖了123 那么现在服务端存储的abc的值不就是456了！
那么session覆盖所产生的漏洞会出现在哪里呢？我在找回密码的时候想到了 重置密码最后一步的时候 sql语句里面的条件肯定是根据session的值（正常程序员是不会存在cookie当然也会有些SB程序员存在cookie）
也就是 where xxx(某某字段)=(session里面的值)
如何覆盖呢？实现重置任意用户密码呢？ 那很简单 我们这么来弄！上图。
首先正常的流程必须先走一遍 输入我们自己的手机号码
输入自己收到的验证码
输入我们要重置的新密码，保留该页面，先别提交：
在这里重复声明一下 他在执行sql语句的时候条件是根据session里面的值 那么我们来覆盖一下 怎么覆盖呢？
打开一个新选项卡，在忘记密码处输入目标手机号，提交：
可以看到session覆盖成功 然后我们在提交那个重置密码的页面 成功修改目标手机号密码 重置任意用户密码（因为session里面存储的修改密码的条件值已经被我们修改了）
漏洞证明：
修复方案：
如何修复session覆盖漏洞呢 很简单 在开始往session里面赋值的时候做一个 if 判断 如果session存在值了 就不重新赋值 就可以避免该漏洞！
版权声明：转载请注明来源 星零@乌云
>
漏洞回应
厂商回应：
未能联系到厂商或者厂商积极拒绝
漏洞Rank：8 (WooYun评价)