[實戰]API防護破解之簽名驗籤

前言：

 

傳統的接口在傳輸的過程中，是非常容易被抓包進行篡改，從而進行中間人攻擊。

這時候我們可以通過對參數進行簽名驗證，如果參數與簽名值不匹配，則請求不通過，直接返回錯誤信息，從而防止黑客攻擊或者大大增加了黑客攻擊的成本。

白帽子在挖洞的時候也經常會遇到這種情況，大多數不會逆向的白帽子則會放棄這些有着攻擊成本的接口。大多數也會有這樣子的想法，這些個接口都加了防護了，說明廠商對這個接口挺重視的，肯定做了安全檢測，自然是不可能有洞可撿了。反過來想，廠商正是因爲加了防護從而對代碼疏忽了，所以這些地方恰好就是挖邏輯漏洞的突破口。

平臺：aHR0cHM6Ly93d3cudnVsYm94LmNvbS8=

 

廠商：某企業src

正文：

開局一個搜索框

輸入值抓包，接口攜帶了一個sign參數。

技巧

此處有兩種方法逆向找出對應的加密點

第一種是笨方法，直接搜索對應的sign值去找到其加密的關鍵位置。

第二種是找到發包的地方，一直跟棧到明文加密的地方。

搜索sign，網站裏面出現了很多sign關鍵詞，不利於我們進行逆向分析

從查看請求發起的相關進程(腳本)去進行發包跟棧

進入發包的地方打斷點。

回溯跟棧，找找有沒有比較顯眼的關鍵詞。

【---- 幫助網安學習，以下所有學習資料免費領！領取資料加 we~@x：dctintin，備註 “開源中國” 獲取！】

① 網安學習成長路徑思維導圖
② 60 + 網安經典常用工具包
③ 100+SRC 漏洞分析報告
④ 150 + 網安攻防實戰技術電子書
⑤ 最權威 CISSP 認證考試指南 + 題庫
⑥ 超 1800 頁 CTF 實戰技巧手冊
⑦ 最新網安大廠面試題合集（含答案）
⑧ APP 客戶端安全檢測指南（安卓 + IOS）

大概跟了幾個棧找到了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加密，完結撒花。

結尾：

部分數據代碼已做脫敏處理。