当前位置: 首页 > 技术干货 > [实战]API防护破解之签名验签

[实战]API防护破解之签名验签

发表于:2024-03-13 16:39 作者: 小广同学 阅读数(1437人)

前言:

传统的接口在传输的过程中,是非常容易被抓包进行篡改,从而进行中间人攻击。

这时候我们可以通过对参数进行签名验证,如果参数与签名值不匹配,则请求不通过,直接返回错误信息,从而防止黑客攻击或者大大增加了黑客攻击的成本。

白帽子在挖洞的时候也经常会遇到这种情况,大多数不会逆向的白帽子则会放弃这些有着攻击成本的接口。大多数也会有这样子的想法,这些个接口都加了防护了,说明厂商对这个接口挺重视的,肯定做了安全检测,自然是不可能有洞可捡了。反过来想,厂商正是因为加了防护从而对代码疏忽了,所以这些地方恰好就是挖逻辑漏洞的突破口。

平台: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是代码生成的,其余都是发包里面携带的明文。

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)

sign参数

有了appSignKey参数,就可以与发包参数拼接传进s函数。

appSignKey=4bTogwpz7RzNO2VTFtW7zcfRkAE97ox6ZSgcQi7FgYdqrHqKB7aGqEZ4o7yssa2aEXoV3bQwh12FFgVNlpyYk2Yjm9d2EZGeGu3&keyword=A型胸腺瘤&noncestr=20565646&serverTimestamp=1706072080923&source=1&timestamp=1706081268690

看一眼就知道是md5加密,完结撒花。

结尾:

部分数据代码已做脱敏处理。