揭露一個幾年前發現的巧妙網站漏洞

多個漏洞合併引起的網站資安問題

$Photo by [Tarik Haiga](https://unsplash.com/@tar1k?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText){:target="_blank"}$

Photo by Tarik Haiga

前言

幾年前還有在邊支援網頁開發的時候；被指派任務要為公司內部工程組舉辦 CTF 競賽；一開始初想是依照公司產品分組互相攻防入侵，但身為主辦，為了想先瞭解掌握程度就先對公司旗下各產品進行入侵測試；看看我自己能找到幾個漏洞，確保活動流程不會出問題。

但最後因為比賽時間有限、工程區別差異太大；所以最後以工程共通基礎知識及有趣的方向出題，有興趣的朋友可參考我之前的文章「 如何打造一場有趣的工程CTF競賽 」；裡面有很多腦洞大開的題目！

找到的漏洞

一共在三個產品中找到四個漏洞，除了本文準備提及的問題之外還有以下三個常見網站漏洞被我發現：

Never Trust The Client! 問題很入門，就是前端直接將 ID 送給後端，而且後端還直接認了；這邊應該要改成認 Token。
重設密碼設計缺陷 實際有點忘了，只記得是程式設計有缺陷；導致重設密碼步驟可以繞過信箱驗證。
XSS 問題
本文將介紹的漏洞

查找方式一律以黑箱測試，其中只有發現 XSS 問題的產品是我有參與過程式開發，其他都沒有也沒看過程式碼。

漏洞現況

身為白帽駭客，所有找到的問題都已在第一時間回報工程團隊和修復了；目前也過了兩年，想想是時候可以公開了；但顧及前公司立場，本文不會提到是哪個產品出現此漏洞，大家就只要參考這個漏洞發現的歷程及原因就好！

漏洞後果

此漏洞可讓入侵者隨意變更目標使用者密碼，並使用新密碼登入目標使用者帳號，盜取個人資料、從事非法操作。

漏洞主因

如同標題所述，此漏洞是由多個原因組合觸發；包含以下因素：

帳號登入未支援兩階段驗證、設備綁定
重設密碼驗證使用流水號
網站資料加密功能存在解密漏洞
加解密功能濫用
驗證令牌設計錯誤
後端未二次驗證欄位正確性
平台上使用者信箱為公開資訊

漏洞重現方式

因平台上使用者信箱為公開資訊，所以我們先在平台上瀏覽目標入侵帳號；知道信箱後前往重設密碼頁。

首先先輸入自己的信箱進行重設密碼操作
再輸入想入侵帳號的信箱，一樣進行重設密碼操作

以上兩個操作都會寄出重設密碼驗證信。

進到自己的信箱去收自己那一封重設密碼驗證信。

變更密碼連結為以下網址格式：

https://zhgchg.li/resetPassword.php?auth=PvrrbQWBGDQ3LeSBByd

PvrrbQWBGDQ3LeSBByd 就是此次重設密碼操作的驗證令牌。

但我在觀察網站上驗證碼圖片時發現驗證碼圖片的連結格式也是類似：

https://zhgchg.li/captchaImage.php?auth=6EqfSZLqDc

6EqfSZLqDc 顯示出 5136 。

那把我們的密碼重設 Token 塞進去會怎樣？管他的！ 塞塞看！

Bingo!

但驗證碼圖片太小，無法得到完整的資訊。

我們繼續找可利用的點…

剛好網站為了防止爬蟲侵擾，會將用戶的公開個人資料信箱，用 圖片呈現 ，關鍵字： 圖片呈現！圖片呈現！圖片呈現！

立刻打開來看看：

個人資料頁

網頁原始碼部分

我們也得到了類似的網址格式結果：

https://zhgchg.li/mailImage.php?mail=V3sDblZgDGdUOOBlBjpRblMTDGwMbwFmUT10bFN6DDlVbAVt

V3sDblZgDGdUOOBlBjpRblMTDGwMbwFmUT10bFN6DDlVbAVt 顯示出 zhgchgli@gmail.com

一樣管他的！塞爆！

Bingo!🥳🥳🥳

PvrrbQWBGDQ3LeSBByd = 2395656

反解出重設密碼令牌，發現是數字之後

我想了該不會是流水號吧。。。

於是再輸入一次信箱請求重設密碼，將新收到的信的 Token 解出來，得到 2395657 … what the fxck…還真的是

知道是流水後之後就好辦事了，所以一開始的操作才會是先請求自己帳號的重設密碼信，再請求要入侵的目標；因為已經可以預測到下一個請求密碼的 id 了。

再來只需要想辦法將 2395657 換回 Token 令牌即可！

好巧不巧又發現個問題

網站在編輯資料時的信箱格式驗證只有前端驗證，後端並未二次驗證格式是否正確…

繞過前端驗證後，將信箱改為下一位目標

Fire in the hole!

我們得到：

https://zhgchg.li/mailImage.php?mail=UTVRZwZuDjMNPLZhBGI

這時候將此密碼重設令牌，帶回密碼重設頁面：

入侵成功！繞過驗證重設他人密碼！

最後因為沒有二階段登入保護、設備綁定功能；所以密碼被覆蓋掉之後就能直接登入冒用了。

事出有因

重新梳理一下整件事的流程。

一開始我們要重設密碼，但發現重設密碼的令牌實際上是一個流水號，而非真正的唯一識別 Token
網站濫用加解密功能，沒有區分功能使用；全站幾乎都用同一組
網站存在線上任意加解密入口（等於密鑰報廢）
後端未二次驗證使用者輸入
沒有二階段登入保護、設備綁定功能

修正方式

最根本的是重設密碼的令牌應該要是隨機產生的唯一識別 Token
網站加解密部分，應該區分功能使用不同密鑰
避免外部可以任意操作資料加解密
後端應該要驗證使用者輸入
以防萬一，增加二階段登入保護、設備綁定功能

總結

整個漏洞發現之路令我驚訝，因為很多都是基本的設計問題；雖然功能上單看來說是可以運作，有小洞洞也還算安全；但多個破洞組合起來就會變成一個大洞，在開發上真的要小心謹慎為妙。

===

View the English version of this article here.

本文首次發表於 Medium ➡️ 前往查看

揭露一個幾年前發現的巧妙網站漏洞