謹防隱私洩露,乙個鏈結就能了解你的一切

2021-12-29 21:16:38 字數 2044 閱讀 8195

謹防隱私洩露,乙個鏈結就能了解你的一切。

000 前言

某日表哥丟過來乙個鏈結,說可以查到手機號或者郵箱號下面註冊過的賬號,於是有了下面的分析。由於涉及隱私,以下文章中涉及**號碼的部分我已作了隱藏,還有批量利用指令碼就不放出來了,敬請見諒。

001 收集資訊

首先開啟表哥給的**看看,和表哥描述的一樣,輸入我的手機號看看。

因為沒有註冊,所以只能檢視有限的條數,但我確實註冊過途牛旅遊,我換了朋友的手機號和郵箱,把反饋結果給他們看,結果也是準確的。這就很有意思了,激發起來我探索的興趣。

002 利用思路

基於現有的資訊,這麼準確的結果,我們不難分析出其中的奧妙。

1、各大**提供給資料介面的api給它

2、自己強大的社工庫

先分析第一條:各大**一般不會輕易把資料介面的api給第三方使用,使用者基數越大,使用者資料一旦洩漏,企業所承擔的責任也越大,最近facebook的資料洩漏事件就是乙個很好例子,成本遠大於收益,這條pass掉。

再分析第二條:在網路安全法沒有出來之前,這個還有可能,之前能用的社工庫都死的差不多了,要不就是架設在內網,通過隧道去訪問,這是其一。其二是這麼準確的資料,是社工庫的話資料得源源不斷的更新,並且肯定會有查不全的情況,這與我們所掌握的資訊矛盾,也得pass掉。

至此思緒又陷入僵局,思路全部都被pass掉,難道我們就此停下了腳步?不存在的。靈感這東西,就和女人的第六感一樣神秘又難以琢磨,有時候還真的挺準。

一條合理的解釋:我們在註冊乙個賬號時,伺服器都要檢測我們將要註冊的使用者名稱是否被註冊過,現在基本都是ajax,我們輸入使用者名稱,可以在不提交表單的情況下返回使用者名稱的狀態,此舉很大程度上方便了正常業務需求的使用者,如果使用者名稱存在,使用者不用在提交表單時發現,而重新輸入之前所填寫的資訊。但在方便使用者但同時,也方便了「其他人」。

003 驗證思路

首先開啟途牛註冊介面,抓包看看請求資訊。

可以看出確實可行,在乙個樣本得到驗證後,我們不難想到:如果抓到其它app或者**驗證註冊的請求,修改其中引數為所查詢的賬號/郵箱,並且把結果總結呈現到前端,不就是我們之前所看到的結果了嗎。

這個推論成立的前提是其它一些**/app也是這樣的業務邏輯,於是我們再選乙個有說服力的例子來看看。

我們來到163郵箱的註冊頁面,重複之前的操作,來看看抓包的內容及響應。

可以看到也是可以實現的。至此,我們所掌握的資訊和事實可以大致的相互印證,使用者提交查詢的資料—>伺服器呼叫封裝好的方法來查詢—>生成結果—>是否為會員?呈現結果:有限制的展示

接下來就是實踐了,看看這種思路,用指令碼是否可以實現。

004 exploit

這裡因為可能會造成不良的影響,就不放**了,放一張批量驗證的圖,驗證了10組號碼,有趣的是,通過指令碼可以看到手機號繫結過的使用者還會返回這個手機所繫結郵箱

005 後記

乙個點,很不穩定,但三個點組成三角形,卻很牢固。雖然這些操作所得到的結果完全可以乙個個的手動試驗,單個來看沒什麼,但如果加以自動化,資料收集涉及**/app面很廣的話,那就可以刻畫出使用者某種畫像,使用者的隱私難以得到保證。假設你女朋友有一天閒的無聊,查你手機號,恰好你註冊了什麼交友**(此處手動滑稽),還是各大酒店的註冊會員……

你必須了解的第乙個python程式

學習一門語言,最開始需要了解的乙個程式是hello world,而我們迫不及待需要完成乙個程式,僅僅用print乙個還是感覺啥都不知道,但是下面這個實現hello的程式通過完成的書寫,可以讓你對python的基本情況有乙個了解,其中涉及 這裡是以內建的sys模組為例,編寫的乙個hello的模組 以上...

乙個詭異的C 記憶體洩露問題。

delet被編譯成了兩個步驟 調相應析構函式,p指向的記憶體塊 即使父類沒宣告虛析構函式,第二步還是生效的,所以你derived的記憶體區是被正確 的,但derived的記憶體區域 std string 並不是連續區間,可能是這樣的東東 64byte ptr delet的第二步 的就只是這 64by...

OpenGL乙個鏈結錯誤的排除

今天在除錯乙個opengl控制台程式的例程時,總是出現 linking.main.obj error lnk2001 unresolved external symbol glutinitwithexit 12 main.obj error lnk2001 unresolved external s...