【状态值漏洞专题】回显值、Response值、Session值，原理、利用过程
【状态值漏洞专题】回显值、Response值、Session值，原理、利用过程
目录
一、客户端回显
1.1、介绍：
这种利用回显抓取数据包，再修改验证
我尝试的时候，有的网站会在你填写手机号后，点击发送验证码，会对你的手机号和ip进行验证，看是不是本地号码（这种针对于一些本地的有限制的网站）；还有的是对传输的信息都有加密……
1.2、原理：
在调用短信平台发送短信时,没有判断验证码和手机号是否绑定
把验证码校验的功能放到客户端来进行（返回数据包中、客户端页面中）,从而导致验证码在客户端回显
1.2、危害：
这个危害有一点小明显，登录、注册、绑定、重置任意用户密码
1.4、利用过程：
1.4.1、利用原理：
客户端回显，就是当注册或者绑定的时候，用户向网站系统发送一条验证码(短信验证码等)的请求,cookie中会包含验证码并直接回显在数据包中（mobile_code=）
通过抓包工具可截取真实验证码（mobile_code=），并修改自己提交的验证码（code）与真正验证码一致，（在repeater重发器中）并根据返回的状态码（例如0,1,2,3等这样的数字）进行判断
1.4.2、常规流程：
设置代理拦截-----填写要绑定的手机号-----点击发送验证码-----提交验证码-----客户端回显（重点：抓包修改）
①抓包
服务器端向手机发送的验证码在cookie中的"moblie_code="中会有显示
②判断正确回显规则
将抓到的回显到客户端的包发到repeater（重发器），然后一般会有特殊的回显数字，判断每种数字代表的含义
③修改
填写正确验证码的，在回显的时候，与填写错误的验证码的时候回显的不一样的数字，就是状态码，或者试试修改为正确的回显码
二、Response 状态值
2.1、原理：
Response状态值，就是在服务端发送某个密码重置的凭证请求后，出现特定的响应值（true、1、ok、success等，例如相应头中的HTTP/1.1 200 ok）
2.2、利用过程：
对Response状态值的修改后，如果存在校验不严（存在逻辑漏洞），并且回显值的校验是在客户端进行的，就能使相关操作成功的被执行。
就像密码重置中的验证码问题，如果回显值的校验是发送到客户端进行，通过对校验值的使用规则进行分析后，抓包后将Response状态值改为正确的，然后放包，从而达到重置密码的操作
三、session覆盖
3.1、session认证流程
第一步：（第一次）用户请求服务器，创建与用户对应的Session
第二步：将返回数据包中SessionID返回给浏览器
第三步：浏览器将SessionID存入Cookie中，并与网站对应
第四步：（第二次）用户请求服务器，会先判断是否有Cookie信息（对应网站），并将 Cookie 信息也发送给服务器
第五步：服务端器从 Cookie 中提取SessionID，并根据SessionID查找对应Session信息
找到 Session则证明用户已经登录，允许执行相关操作；
如果没有找到对应Session则未登录、登录失效，禁止再继续执行相关操作。
3.2、原理：
对于参数的可控不严格的话，第一次登录账号A执行重置等相关操作，获取凭证后，然后复制账号A重置操作阶段的URL（未完全实现重置），再打开一个窗口打开次链接（此时覆盖了原来的session），然后输入账号B的账号，从而实现账号的重置
3.3、利用过程
3.3.1、流程举例：
重置的逻辑流程（三个流程）：
（1）流程一（确认账号）：
输入要重置的账号
图片数字验证码（识图）
（2）流程二：（安全验证）：
发送短信验证码
（3）流程三：（重置密码）
填写新密码
确认新密码
3.3.2、利用思路：
1、获得凭证
①使用自己的账号A执行相关操作（比如重置密码），经过确认账号，安全验证，是为了在安全验证中获得执行相关操作的凭证（短信验证码）
②在获得凭证校验成功后，进入到流程三密码重置页面（然后停止继续操作）
2、session覆盖
③在浏览器新窗口中重现打开执行密码重置的相关操作，使用目标手机号完成流程一（然后停止操作）
④（此时 Session 账户已经被覆盖）再回到账号A的流程三密码重置页面（前端显示的还是前面操作的修改账号A），但是输入新密码确认后，最后提示账号B修改成功
- 点赞
- 收藏
- 关注作者
评论（0）