普吉應用系統驗證機制的脆弱點以及驗證機制中的設計缺陷、執行缺陷

驗證機制

身份驗證是核心防御機制中最薄弱的環節，身份驗證機制也是攻擊者的主要攻擊目標之一。
驗證機制是應用程序防御惡意攻擊的中心機制。它處于防御未授權的最前沿，如果用戶能夠突破那些防御，他們通常能夠控制應用程序的全部功能，自由訪問其中的數據。缺乏安全穩定的驗證機制，其他核心安全機制（如會話管理和訪問控制）都無法有效實施。
驗證機制最常見的方式是信息系統要求用戶提交用戶名與密碼，正確則允許用戶登錄，錯誤則拒絕用戶登錄。

驗證機制問題主
要分為兩個方面：分
別為設計缺陷和執行
缺陷。

Web應用程序常用的驗證機制有：
基于HTML表單的驗證（最常用）
多元機制，如組合型密碼和物理令牌（多用于安全性要求較高的應用程序比如說提供進行巨額交易服務的私人銀行）
客戶端SSL證書或智能卡（成本非常昂貴，通常只有那些用戶不多的安全性極其重要的應用程序才會使用）
HTTP基本和摘要驗證（內網使用較多，建立在域環境及內網對用戶的訪問控制之上的）
使用NTLM或Kerberos整合windows的驗證
第三方驗證服務（尚未得到大量使用）

驗證機制設計缺陷

可預測的用戶名
有些應用程序需要用戶注冊時用戶名符合某一特定規則，比如需要滿足“姓名縮寫
數字”的這種形式，其中數字是為了防止用戶名重復，也就是說如果在存在姓名縮寫相
同的情況下后面要跟數字或者進行數字累加。這種在學校郵箱注冊時是比較常見的。通
過這種方式攻擊者可以很方便的獲得大量有效用戶名。

極少部分的應用程序不要求用戶名的唯一性，這就可能造成這樣的問題
在恰巧有兩名用戶使用相同的用戶名及密碼的情況下，應用程序要么阻止第二個用戶設置密碼，要么允許其設置相同的密碼。前者這種情況可能導致第一名用戶的密碼泄露給第二名用戶，這種情況下攻擊者如果想獲得某個已知用戶名對應的密碼則可以通過注冊功能針對于此用戶名使用不同的密碼注冊，如果應用程序返回禁止注冊，那么我們可以推測出此次注冊時的密碼就是這個用戶名對應的密碼。后者則可能導致第二名用戶可以訪問第一名用戶的狀態。

123456真的多。。。

密碼確認不完善
一些應用程序在用戶注冊設置密碼時，出于一些原因往往會對密碼進行如下處理
截斷前n個字符
大小寫不敏感
刪除特殊字符
上述操作均會減少應用程序的密碼空間，攻擊者通過仔細分析應用程序的密碼處理規則后，可以適當修改自己的暴破字典從而提高暴破的成功率。

可預測的密碼
在像學校，企業這種存在批量注冊大量用戶需求的應用程序中，經常會為批量用戶設置默認密碼，這種默認密碼可以是相同的也可以是與用戶名或者其身份證信息等有關系的。這種情況下攻擊者可以通過Googlehacking來在公開信息匯總收集大量初始密碼，也可以根據默認密碼規律推測出大量密碼。

暴力破解
????????????? 最常見的——暴力破解（BruteForce），也可稱為童力攻擊，指利用窮舉法將所有的可能性一一嘗試，理論上可以破解所有密碼問題。實際測試中，考慮到攻擊成本問題，通常使用字典攻擊（DictionaryAttack），即逐一嘗試用戶自定義詞典中的可能密碼（單詞或短語）的攻擊方式。

如果應用程序允許用戶在登錄失敗很多次后，仍能繼續嘗試登錄，那么這種情況下此應用可能存在暴破攻擊。為了防止暴破攻擊，應用程序應該設置用戶登錄失敗次數上限，當用戶失敗的登錄次數達到上限后應用程序應該阻止用戶進一步的登錄。但是通過前端腳本或者Cookie來統計用戶失敗的登錄次數是不可靠的，因為這些都是攻擊者可以接觸到并且可以修改的，如果服務器端使用Session來存儲用戶失敗登錄的次數這樣就可靠的多。除了用戶登錄次數的統計問題外，如何處理失敗登錄次數達到上限的用戶也是一個需要謹慎處理的問題，如果用戶在登錄失敗很多次后被鎖定，但是鎖定狀態下的用戶使用正確密碼登錄時和使用錯誤密碼登錄時Web應用程序的響應信息不同那么此時此應用還是存在暴破漏洞。

實驗：利用BurpSuite中lntruder模塊進行字典攻擊
一般步驟：
設置瀏覽器代理并抓取數據包
在Positions中，Clear目前payload，Add需測試payload位置
設置Payloadtype，選擇payload
設置線程等參數，并Startattack
根據Response狀態，判斷攻擊結果

驗證機制執行缺陷

可利用信息
多余的提示信息
登錄失敗后，不應該提示如“用戶不存在”、“密碼錯誤”、“用戶未注冊”
等詳細信息，通過這些信息可推斷出用戶名、密碼等其他信息
可預測信息
類似user100、user101的用戶名，手機號信息
類似于ABC123、123456的初始密碼

在暴力破解的時候，若擁有驗證碼還需要繞過驗證碼，驗證碼常見的有圖片驗證碼
和短信驗證碼。
圖片驗證碼
驗證碼不生效/不更新/不失效
驗證碼可預測/刪除/獲取
驗證碼可識別
短信驗證碼
4/6位驗證碼
算改手機號
算改Response

案例：繞過驗證碼
查看其中的isVerfi參數，第一次傳入1返回3沒有得到驗證碼，但是修改參數為0之后返回2，繞過了驗證碼的限制

案例：某OA系統設計缺陷導致可暴力破解賬戶大量敏感信息泄漏
其中yongping/12345為管理員，權限很大

?

密碼重置
在邏輯漏洞中密碼重置問題是比較常見的一種場景，常見于用戶修改密碼頁面、用戶找回密碼頁面等涉及到網站重置密碼功能的頁面。
修改密碼
目前的修改密碼的方式大概可以分為兩種，第一種是要求用戶鍵入用戶名、舊密碼、新密碼、確認新密碼四部分，一些Web應用程序會忽略修改密碼處舊密碼錯誤輸入次數過多的問題，這就容易被攻擊者利用來進行密碼暴破；還有一種最不安全的情況就是只需要用戶鍵入用戶名、新密碼、確認新密碼即可更改用戶名相應的密碼，這種情況下攻擊者無需暴破即可獲得正確的用戶名及密碼組合。

找回密碼
忘記密碼功能往往通過設置一組問題來驗證用戶身份，比如這些問題可以是“我最喜歡的顏色”，這些問題的答案組合次數相對于密碼來說小的多，并且可以通過信息收集工作來提供輔助。攻擊者可以收集一組用戶名并逐個遍歷然后記錄相應的問題在其中選擇最簡單的那個下手可以獲得更高的成功率忘記密碼處可能不會設置錯誤次數限制從而允許攻擊者猜測上述問題的答案通常Web應用程序也會設置密碼暗示來代替上述問題，這些密碼暗示往往能夠輔助攻擊者猜測密碼，有些用戶甚至直接把密碼設置為密碼暗示。攻擊者同樣可以通過枚舉收集到的用戶名然后獲得一組密碼暗示，從而尋找出最容易獲得的密碼

當Web應用程序可能通過向用戶郵箱發送密碼重置鏈接來幫助用戶修改密碼，這種鏈接是隨機的攻擊者很難對其進行猜解。但是有些應用在設計這個邏輯時可能允許Web應用程序將用戶密碼修復的郵件發送至攻擊者，有時郵箱地址并沒有直接顯示出來而是存儲在隱藏的表單中這時攻擊者可以將郵箱修改為自己的郵箱。在最差的情況下攻擊者可以嘗試推測密碼重置的URL來重置用戶密碼

常見密碼重置問題
用戶名枚舉：網站反饋多余信息，可猜測用戶信息
驗證碼返回前端處理：可截獲、修改
修改Request：用戶名、手機號、Cookie等信息可修改
修改Response：操作結果成功/失敗可修改
暴力破解驗證碼：驗證碼長度有限，或驗證碼未設置可靠的失效時間
拼凌密碼重置鏈接：重置密碼鏈接有規可循

案例：修改Respone
填寫驗證碼點擊下一步，利用Burpsuit進行抓包，需設置Burp攔截Response包
若返回包中具有明顯的參數字段，如yes/no、success/failed、0/1等字段，可以嘗試修改為成功，或是走一遍正確的流程，記錄成功的返回包

放包跳轉至更改密碼界面，可直接修改成功密碼

一些應用程序為了方便用戶訪問通常會提供“記住密碼”的功能，此功能通常僅通過cookie中的某個字段來實現。比如Cookie中會設置一個存儲用戶名的字段來實現基礎我的功能如果這樣的話攻擊者僅需要隨便注冊一個用戶然后將Cookie中用戶名修改為其想要訪問用戶的用戶名即可實現對目標用戶的訪問。Cookie中還可能通過存儲一個ID字段來唯一的標識用戶，這種情況下攻擊者可以遍歷ID從而實現遍歷訪問用戶。

證書分配不安全
目前很多應用程序在注冊時都會要求用戶填入郵箱信息，并在稍后發送給用戶一封激活郵件，如果郵件中保存有用戶的初始用戶名及密碼并且這種郵件有沒有及時的刪除在郵件泄露或者郵箱被攻擊者攻破的情況下，則會泄露應用程序的密碼。除此之外有些激活URL可能存在某種規律，攻擊者可以通過注冊，連續地注冊用戶來觀察這種規律，從而推測其他用戶的激活URL。
證書傳輸易受攻擊
如果Web應用程序在網絡環境中以明文的方式傳遞證書，那么攻擊者則可能通過嘎探、中間人等各種方式獲取。

異常開放登錄機制
驗證機制在代碼實現過程中也可能由于編碼者某些疏忽造成安全問題。
使用控制的一個賬戶執行一次完整、有效的登錄。使用攔截代理服務器記錄提交的每一份數據、收到的每一個響應
多次重復登錄過程，以非常規方式修改提交的數據。比如對于客戶端傳送的每個請求參數或Cookie
提交一個空字符串
完全刪除鍵值對
提交非常長和非常短的值
提交字符串代替數字或相反
針對某一參數，嘗試重復提交相同和不同的值

仔細檢查應用程序對提交的每個畸形請求的響應，確定任何不同于基本情況的
差異
根據這些觀察結果調整測試過程。如果某個修改造成行為改變，設法將這個修
改與其他更改組合在一起，使應用程序的邏輯達到最大限度

多階段登錄機制中的缺陷
有些對于安全性要求較高的應用可能會采取多階段登錄驗證機制，比如一個多階段驗證機制可以有以下三個過程組成
提交用戶名及密碼
響應一個質詢，答案可能使PIN中的特殊數字或者一個值得紀念的詞
提交物理令牌上的值

多階段登錄機制確實可以明顯的提高登錄驗證的安全性，但是更多的階段同樣意味著可能潛在有更多的執行缺陷。比如可能存在以下幾個常見的缺陷
應用程序認為訪問第三階段的用戶已經完成了一二階段的認證。這種情況下僅擁有部分登錄憑證的攻擊者可以成功登錄
在每個階段的驗證過程中，應用程序會保存相應的標志，比如賬戶是否過期、是否被鎖定、是否屬于管理員、是否需要完成更多的登錄驗證階段。如果攻擊者可以在某一個登錄階段接觸到上一個階段設置的標記，那么攻擊者可以對這些標記進行修改從而完成一定程度的攻擊行為

應用程序有可能會認為各階段認證過程中用戶的身份都不會發生變化，并且不會在每一個階段檢查用戶身份的統一性，那么如果攻擊者在第一階段輸入的用戶名及密碼與后面階段輸入的驗證憑證不一致，且應用程序會以兩種或三種驗證憑證任一對應的用戶身份登錄的話，這就存在嚴重的安全問題。這種情況下攻擊者只需要知道目標用戶的部分驗證信息就可以登錄，而其他信息則可以通過自己注冊獲得部分信息，這種攻擊的嚴重程度取決于應用程序用于確定用戶身份的驗證憑證的易獲得度（比如應用程序以第一階段的用戶名及密碼來確定身份，那么存在上述缺陷的情況下攻擊者可以使用自己的后兩個階段的驗證憑證來進行登錄，PIN碼內容及物理令牌相對于用戶名及密碼來說更難獲得，所以這種情況下攻擊的嚴重程度比較高）

測試多階段驗證機制可以按照以下步驟進行：
記錄一次有效賬戶完整的登錄過程，并使用代理記錄每一階段的數據
收集那些由服務器返回的且重復提交的數據，這些數據往往放置與Cookie，URL預設參數，隱藏表單字段等位置
對于上述收集到的重復提交的數據試著在另一階段將其修改為不同的值看看是否能夠登錄成功
還需要注意任何提交到服務器且不是用戶直接輸入的數據，這些數據可能是登錄進展的狀態信息，比如stage2complete=True，攻擊者可以直接修改這些值進入下一階段
嘗試各種畸形的登錄過程

總結

以上是生活随笔為你收集整理的逻辑漏洞——验证机制问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。