登录框之另类思考：来自客户端的欺骗
0×01 前言
前几天刚见人发了一个登录框引发的血案，而常规的爆破有风控和各种变态验证码，或者大型的电商都会用SSO实现登录，密码找回逻辑看似天衣无缝，又或者采用第三方的Oauth授权。往往这些常规的东西已经被人测了千万遍。怎么才能另寻奇辟，找寻新的大陆呢？分享一次SRC挖掘过程中，遇到一堆的登录框。通过对目录的fuzz发现了一些不正常的特征。通过这些不正常特性引发的思考（胡思乱想）和正确的防护措施。
0×02特征的发现
既然是登录的客户端欺骗方式，那么先请出我们的主角登录框！
通过Fuzz后台目录，发现了一个神奇的现象，返回的状态码都为200。而且返回的Size不同说明了返回了不同的页面。
当我对/system/user/index/页面进行访问时，又被弹到了首页。但是我的状态码明明是200呀。且还是Size不同的数据！从我的第六感来说，此处肯定存在猫腻。
0×03正常的场景
按照我以往的渗透经验,出现的应该是如下场景：
1. 首先客户端向服务端发起一次请求。
2. 进入服务端的全局过滤器，判断是否有权限对该url资源进行访问。
3. 如果权限不够：
1) 状态码200，返回统一的错误友好界面。
2) 状态码302，直接跳转至登录页面。
3) 状态码403，提示没有权限
4) 状态码500，抛出越权异常
4. 权限够的话，继续执行。访问后端的业务接口。
0×04结合分析
看似好像上面聊到的200的状态码是个正常现象，但是仔细一分析有很多矛盾的地方。
1. 返回的状态码是200，但是每一次的访问跳到了登录页面。
2. 返回的状态码是200，但是每个越权的url虽然都返回到了主页。但是Response 的Size都不相同。
由此可以猜想目前的流程：
1. Client发起一次请求
2. 请求直接被Server Interface接受，返回响应内容给Client.
3. 浏览器再拿上Reponse去解析。（鉴权过程发生此处）
4. 鉴权获取Cookie中的一些Flag,有则继续无则跳转登录页面。
0×05 脆弱点
1. 从分析来看，没有正确实现全局的拦截器，而是依赖前端做权限判断。也就是说我们直接向业务接口post数据，业务接口就会拿上数据去调用其中的一些方法，只要想办法拿到接口的url和参数名即可。（获得一些增删改的垂直权限）
2. 鉴权在前端利用JS去获取Cookie的一些Flag.大家都明白，前端的一切可更改。（此时的防护，已经晚了）
0×06 拉个实际的例子。
案例一：
1）为了方便就不FUZZ了，直接F12看他的源码
2）发现前端js中使用的Ajax异步的方式访问后端接口去登陆。如果返回的json的data字段为success就跳转至Default.aspx。很明显可以猜到这就是后台的首页了。
3）尝试访问，不出意外的又回到了登录页面。但是他的response的状态码为200.且Size并不和登录页面的Size的大小一样。情况奇特抓包分析。
4）抓包分析，当请求这个页面时会返回一个html源码。发现了他跳去首页的原因。
5）还发现他的RoleID和 一些区域名都是通过JS来获取的。前端的一切都是扯淡。我们是不是可以直接篡改了呢？
案例二（截胡式）：
1）直接越权访问，会返回一个html源码。经过鉴权处理后，他的处理方式只是仅仅加了location.href。来进行首页的跳转。
2）你想跳的话，就不让你跳。直接将其删除。在此我们就得到的接口的url和一些参数。
3）既然他们返回状态200，并没有出现403等阻断行为，且Size不同。说明个站的业务接口你是可以直接触碰。很显然查出了所有的信息，可做增删改的操作。
0×01 前言
前几天刚见人发了一个登录框引发的血案，而常规的爆破有风控和各种变态验证码，或者大型的电商都会用SSO实现登录，密码找回逻辑看似天衣无缝，又或者采用第三方的Oauth授权。往往这些常规的东西已经被人测了千万遍。怎么才能另寻奇辟，找寻新的大陆呢？分享一次SRC挖掘过程中，遇到一堆的登录框。通过对目录的fuzz发现了一些不正常的特征。通过这些不正常特性引发的思考（胡思乱想）和正确的防护措施。
0×02特征的发现
既然是登录的客户端欺骗方式，那么先请出我们的主角登录框！
通过Fuzz后台目录，发现了一个神奇的现象，返回的状态码都为200。而且返回的Size不同说明了返回了不同的页面。
copyright 无奈人生
当我对/system/user/index/页面进行访问时，又被弹到了首页。但是我的状态码明明是200呀。且还是Size不同的数据！从我的第六感来说，此处肯定存在猫腻。
0×03正常的场景
按照我以往的渗透经验,出现的应该是如下场景：
1. 首先客户端向服务端发起一次请求。
2. 进入服务端的全局过滤器，判断是否有权限对该url资源进行访问。
3. 如果权限不够：
1) 状态码200，返回统一的错误友好界面。
2) 状态码302，直接跳转至登录页面。
3) 状态码403，提示没有权限
4) 状态码500，抛出越权异常
4. 权限够的话，继续执行。访问后端的业务接口。
0×04结合分析
看似好像上面聊到的200的状态码是个正常现象，但是仔细一分析有很多矛盾的地方。
1. 返回的状态码是200，但是每一次的访问跳到了登录页面。
2. 返回的状态码是200，但是每个越权的url虽然都返回到了主页。但是Response 的Size都不相同。
由此可以猜想目前的流程：
1. Client发起一次请求
2. 请求直接被Server Interface接受，返回响应内容给Client.
3. 浏览器再拿上Reponse去解析。（鉴权过程发生此处）
4. 鉴权获取Cookie中的一些Flag,有则继续无则跳转登录页面。
0×05 脆弱点
1. 从分析来看，没有正确实现全局的拦截器，而是依赖前端做权限判断。也就是说我们直接向业务接口post数据，业务接口就会拿上数据去调用其中的一些方法，只要想办法拿到接口的url和参数名即可。（获得一些增删改的垂直权限）
2. 鉴权在前端利用JS去获取Cookie的一些Flag.大家都明白，前端的一切可更改。（此时的防护，已经晚了）
0×06 拉个实际的例子。
案例一：
内容来自无奈安全网
1）为了方便就不FUZZ了，直接F12看他的源码
2）发现前端js中使用的Ajax异步的方式访问后端接口去登陆。如果返回的json的data字段为success就跳转至Default.aspx。很明显可以猜到这就是后台的首页了。
3）尝试访问，不出意外的又回到了登录页面。但是他的response的状态码为200.且Size并不和登录页面的Size的大小一样。情况奇特抓包分析。
4）抓包分析，当请求这个页面时会返回一个html源码。发现了他跳去首页的原因。
5）还发现他的RoleID和 一些区域名都是通过JS来获取的。前端的一切都是扯淡。我们是不是可以直接篡改了呢？
本文来自无奈人生安全网 案例二（截胡式）：
1）直接越权访问，会返回一个html源码。经过鉴权处理后，他的处理方式只是仅仅加了location.href。来进行首页的跳转。
2）你想跳的话，就不让你跳。直接将其删除。在此我们就得到的接口的url和一些参数。
3）既然他们返回状态200，并没有出现403等阻断行为，且Size不同。说明个站的业务接口你是可以直接触碰。很显然查出了所有的信息，可做增删改的操作。
本文来自无奈人生安全网