前言：在之前章节里，我们介绍了基于前端绕过的几种常见思路分享，也了解了前端绕过的思路，及可能造成的安全隐患等等，当然，更多是来源于前端的程序设计缺陷所导致，今天我们将继续介绍其他的前端绕过方法，思路仅供参考
绕过思路1：基于Authorization绕过查询思路
我们都知道，Authorization认证是基于用户的口令令牌的一种方式，通过口令令牌进行查询数据的一种相对安全的传输数据的方法，必须需要用户和密码的验证后，调用Authorization认证可查询其他接口的数据，必须是授权情况下，才能进行查询，否则则查询失败，那么他生成的Authorization令牌，就等于内部方法的token了，那我们今天要介绍的就是基于基于Authorization绕过查询思路，利用内部生成好的方法去尝试查询同类系统的数据。
漏洞需要具备两个条件才能成立：
-
1. Authorization认证短时间不过期 -
2. Authorization认证的token没有去判断用户的身份，可导致利用生成的token去查询其他同类的越权数据，可以理解为Authorization认证绕过查询，使用内部方法查询到数据，造成用户数据敏感信息泄露，这个方法相对通用，可以用在很多通用系统中进行测试（Authorization内部安全生成方法也存在隐患，需要加入条件判断，去判断用户身份）
如这样一个后台
我们需要尝试拿到一个用户的口令，或者是弱密码，去调用查询接口，比如管理员身份的查询接口， 然后拿到他的Authorization认证，相当于在接口处，加入一个Authorization认证，那么这个Authorization认证如何获得呢？当然是登录获取了
所以这里需要分成两步:
-
1. 先尝试去找可以登录的系统，拿到token -
2. 调用查询API接口，去加入Authorization认证进行查询绕过其他同类系统
先拿到登录的token，如果手工去搞，需要使用抓包工具去拿到回显包，然后再次调用Authorization进行查询绕过，这里相当于有两个请求，但是手工这样做会比较费时间，为了利用的方便，我们我们采取工具自动化的思路去实现该思路
登录这一步在编程中应该这样实现
使用HttpsURLConnection对目标发起POST请求，然后去读数据（成功登录的用户密码）
接下来，查询回显，发现accessToken的认证数据，这里可以取个正则去取accessToken的值
拿到accessToken的值然后去调用新的请求查用户管理信息自动覆盖拿到的token
这里通过正则抓到token赋给testds，接着调用FG函数
这里就是具体赋值了，这样做的好处就是每一次请求，都会自动覆盖新的请求，对于自动化来说，相对方便接着调用API接口，查询用户信息在不用登录情况的情况下，使用Authorization生成的token，去查询其他同类站的用户信息
实现如下：
可以发现，Authorization认证被绕过了，没判断Authorization的具体身份，可以在不用登录的情况下，导致查询到其他任意网站的管理员信息。
绕过思路2：基于user-key的通用KEY绕过查询管理员漏洞
user-key通用key的安全隐患绕过，这里是指如果一个网站采用通用固定的KEY进行认证，没有采取随机方法，比如：user-key：adsassadjsafjsafjsafsa,那这个是指向管理员身份的，我们只需要拿到了user-key了进行查询，那可能会造成同类系统的查询
当你访问接口会提升跳转到登录，但是你利用user-key则可以查询到数据，那么问题来了，我们怎么去拿到通用user-key的呢
这里有几种方法：
-
1. 找一个可以成功登录的，查看回显包 -
2. 去源代码去找开发的测试token(虽然有，但是相对较少） -
3. 爆破user-key的实现规则
比如一个后台登录系统
先看看源代码，定位到sunccessReturn函数，可以看到这里(这里传入了data)
这里进行了data的status判断，注意这里.
localStorage.setItem("ucode", data.data.user_key); 这里会取到data.user_key的值进行本地存储,我们尝试进行登录测试
这里就取到了user-key，这里的KEY经过测试，有两个很大的安全隐患
-
1. user-key不过期 可以无限次使用 -
2. user-key是通用的key
这里还获取到了email,电话等，因为是成功的认证
但是我们要做的是拿到他的管理员查询接口,然后带入user-key认证，接着去尝试绕过查询其他同类的系统
通过python简单实现这个查询逻辑，定义一个input url输入，在header加入user-key:
然后只需要判断状态码等于200，然后读回显数据即可
实现如下:
当输入用户输入url,在不同登录情况下，直接查询管理员敏感信息，形成RCE，这里泄露了用户密码，直接使用泄露的用户密码成功登录后台
绕过思路3：调用JS的函数进行绕过验证
这里分成两种思路
-
1. 调用JS函数进行逃过验证（有加密数据，进行传参，危害性大），如果前端的JS函数未进行授权，导致可以调用JS函数进行查询，这需要前端认证的结合，加入这个JS函数使用接口，进行逃过测试，我们只需要拿到成功认证的用户信息，然后拿到JS函数进行查询，即可。 -
2. 调用JS函数进行逃过验证（无加密数据，无法进行传参，接口判断，危害性相对较小），在实际的渗透测试中，安全隐患都可以以白盒的方式进行交叉测试，这样能够确保，JS函数的隐患性，如果只是绕过了JS函数的检查，但是接口数据未正确定义，这里造成的安全隐患相对较小，但是一旦可以利用成功认证的登录信息，造成的隐患将会变大，所以需要前后端的结合）
我们来看下源代码
注意这里，打开后会是这样排列的
我们把&zWeaCQk1=b4c45d去掉，就可以正常显示了
注意这个函数，是否可以利用，这里是一个进行下拉选择的Dom元素，进行调用试试，在使用onclick事件进行绑定的时候，调试出错了
我们再看看其他函数
注意这里的initAttendanceOfficeData()函数，这里会调用一个init/data/init-attendance-office-data的接口
defaultAjax(url,data,"JSON",initAttendanceOfficeDataSuceess,initAttendanceOfficeDataError);，这里分别执行ajax请求，有initAttendanceOfficeDataSuceess回调函数，那么直接利用就是调用url:/init/data/init-attendance-office-data访问，我们先来看看他的
这里调用了回调函数，判断data，那么data从哪里来，进行跟进下
发现这里
看看前面获取cookie的操作，是如何进行获取的
可以看到在这里，这里有一个获取cookie的操作，对cookies 数组进行了遍历，使用decodeURIComponent进行解码，赋给 cookieValue对象，再跟进到initAttendanceOfficeData()函数var data={"day":val}; Data传入的day的值，那么我们来试试
调用init/data/init-attendance-office-data接口访问
显示404，那么我们调用URL+/接口进行访问
回显确实是404，我们再看看另外一个函数initAttendanceOutsideData()，访问看看init/data/init-attendance-outside-data
这样访问始终都是404，这里直接访问是不能成功的，因为没成功调用函数
我们要做的就是进JS调用绕过密码检查，看看这个接口是否鉴权，具体就是找一个，进行加载的onload
如：
使用 window.onload
window.onload = function () { initAttendanceOutsideData(); };加载完资源进行函数调用，场景可能需要鉴权。
或者onchange 事件，进行下拉选择，下拉选择加入，initAttendanceOutsideData()函数
实现如下:
<!DOCTYPE html><htmllang="en"><head><metacharset="UTF-8"></head><body><inputtype="text"id="myInput"><script>functioninitAttendanceOutsideData() {console.log('初始化'); }const input = document.getElementById('myInput'); input.onchange = function () {initAttendanceOutsideData(); 在这里进行调用 };</script></body></html>我们在要进行调用，也可以使用点击事件的javascript:// 或者href 调用即可
注意javascript这里调用了toFindPassword()函数，一个忘记密码的操作，我们把他修改成initAttendanceOutsideData()
这里可以使用抓包工具，在触发函数进行抓包即可
可以发现调用函数成功了，这个信息随便输入，截取数据包
可以看到我们抓取到day，实际上就是信息输入框了
接口则是：
可以发现这里传入了cookie了
通过回显可以看到这个接口是逃过了验证的，只是传输的数据不正确，接口是绕过的，回显是0，我们并没有进行登录操作，那么问题来了，这里场景就变成了无加密数据，他的危害看似小，但是如果能结合白盒的数据进行调用，危害就会变大，实际攻击场景视情况而定，仅提供绕过思路，如果有白盒的数据在initAttendanceOutsideData()，进行调用，查询了后端的数据，那么危害就是，在不用登录情况下，进行查询了，就不用进行登录了，因为initAttendanceOutsideData()函数可能存在接口未授权的问题
再发送一次请求，就变成了
202了，那么202状态码就是已接受该请求，只需要再次调用函数即可
JS函数判断思路（可以结合目录爬取）
那么介绍完之前三种绕过方法，我们就可以来针对这种函数的检查进行JS函数判断的思路了
具体实现思路：
-
1. 进行JS url目录爬取，提取，并进行正则区配
例如
http://www.com/ww/js/common/common.js?version=1.0.1
查找存在的
function函数，进行单方法和多方法判断，如function adsad()function adsad(data)
-
2. 找到 function函数，查看方法引用 -
3. 对于单函数的引用可以进行判断是是否可以调用 -
4. 对JS函数的接口进行拼接，进行自动化漏洞测试 -
5. JS对单函数进行审计分析 -
6. 比如java审计的JDBC注入，一般利用
搜createStatement()函数进行判断函数进行查找未过滤的参数漏洞，那么实现步骤就是，对于发现漏洞的点，进行语句拼接，(updatexml(1,if(1=1,1,user()),1))，进行拼接自动化测试等等
原文始发于微信公众号（君立渗透测试研究中心）：前端绕过的攻与防（中）
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论