传统的接口在传输的过程中,是非常容易被抓包进行篡改,从而进行中间人攻击。
这时候我们可以通过对参数进行签名验证,如果参数与签名值不匹配,则请求不通过,直接返回错误信息,从而防止黑客攻击或者大大增加了黑客攻击的成本。
白帽子在挖洞的时候也经常会遇到这种情况,大多数不会逆向的白帽子则会放弃这些有着攻击成本的接口。大多数也会有这样子的想法,这些个接口都加了防护了,说明厂商对这个接口挺重视的,肯定做了安全检测,自然是不可能有洞可捡了。反过来想,厂商正是因为加了防护从而对代码疏忽了,所以这些地方恰好就是挖逻辑漏洞的突破口。
平台:aHR0cHM6Ly93d3cudnVsYm94LmNvbS8=
厂商:某企业src
开局一个搜索框
输入值抓包,接口携带了一个sign参数。
此处有两种方法逆向找出对应的加密点
第一种是笨方法,直接搜索对应的sign值去找到其加密的关键位置。
第二种是找到发包的地方,一直跟栈到明文加密的地方。
搜索sign,网站里面出现了很多sign关键词,不利于我们进行逆向分析
从查看请求发起的相关进程(脚本)去进行发包跟栈
进入发包的地方打断点。
回溯跟栈,找找有没有比较显眼的关键词。
大概跟了几个栈找到了sign关键词,但是并不确定这个地方的sign参数是不是我们发包的那个sign参数,打下断点盲测一下。
再次发包的时候,断点断住了。这个sign参数是一个f对象的一个函数,并不是一个sign参数值。而我们想要找到的是sign参数值,经过猜测,这个断点能够在携带sign参数的那个发包时断住,就肯定与sign参数有关。直接进入函数内部查看。
映入眼帘的是一个f函数,将断点断到返回值的地方,查看一下返回值是什么呢。
在控制台打印一下返回值。很眼熟,很像我们发包的时候携带的参数
分析一下f函数,看看sign参数在哪里生成的。
sign是在5790行被赋值的。
可以看出sign参数是appSignKey,keyword,noncestr,serverTimestamp,source,timestamp拼接之后传进了s函数生成的。除了appSignKey是代码生成的,其余都是发包里面携带的明文。
从f函数里面代码可以分析出,appSignKey是由n赋值的,n又是由c经过一段三元表达式生成的。c是一段字符串,直接上手扣代码。
生成n的三元表达式用到了arguments,直接到浏览器复制arguments
var c = "10f6cf80184377cd5487b4746a8a67da17540449fa40b408f13ccdd3d3059cb394c0e1569043eed2"
arguments = {
"0": {
"keyword": "A型胸腺瘤",
"source": 1,
"serverTimestamp": 1706072080923
},
"1": "4bTogwpz7RzNO2VTFtW7zcfRkAE97ox6ZSgcQi7FgYdqrHqKB7aGqEZ4o7yssa2aEXoV3bQwh12FFgVNlpyYk2Yjm9d2EZGeGu3"
}
var n = arguments.length > 1 && void 0 !== arguments[1] ? arguments[1] : c
console.log("appSignKey--->"+n)ole.log(n)
有了appSignKey参数,就可以与发包参数拼接传进s函数。
appSignKey=4bTogwpz7RzNO2VTFtW7zcfRkAE97ox6ZSgcQi7FgYdqrHqKB7aGqEZ4o7yssa2aEXoV3bQwh12FFgVNlpyYk2Yjm9d2EZGeGu3&keyword=A型胸腺瘤&noncestr=20565646&serverTimestamp=1706072080923&source=1×tamp=1706081268690
看一眼就知道是md5加密,完结撒花。
部分数据代码已做脱敏处理。