業務邏輯漏洞

轉載：https://github.com/PyxYuYu/MyBlog/issues/102

• 業務邏輯漏洞
  • 由於程序邏輯不嚴謹或邏輯太過復雜，導致一些邏輯分支不能正常處理或處理錯誤，統稱為 業務邏輯漏洞
  • 關注重點
    • 業務流程
    • HTTP/HTTPS 請求分析
• 漏洞分類
  • 身份認證
    • 暴力破解
      • 在 沒有 驗證碼限制或者一次驗證碼可以使用 多次 使用的情況下
        • 使用已知用戶名對密碼進行暴力破解
        • 使用一個弱口令密碼對用戶進行暴力破解
      • 工具
        • Burpsuite
        • Hydra
    • Cookie 和 Session 問題
      • Cookie 機制采用的是在客戶端保持狀態的方案，用來記錄用戶的一些信息，也是實現 Session 的一種方式
      • Session 機制采用的是在服務器端保持狀態的方案，用來跟蹤用戶的狀態，可以保存在集群、數據庫、文件中
      • Cookie 的內容主要包括：名字、值、過期時間、路徑和域，其中路徑和域一起構成 Cookie 的作用范圍，若不設置過期時間，則表示這個 Cookie 的生命期為瀏覽器會話期間，關閉瀏覽器窗口，則消失，這種生命期為瀏覽器會話期的 Cookie 被稱為會話 Cookie
        • Session 機制是一種服務端的機制，當程序需要為某個客戶端的請求創建一個 Session 時，服務器會首先檢查這個客戶端的請求里是否包含了一個 Session 標識（Session id），如果已包含說明此前已經為此客戶端創建過 Session，服務器會按照 Session id 將這個 Session 檢索出來使用（檢索不到，會新建一個），如果客戶端請求不包含 Session id，則會為此客戶端創建一個 Session 並且生成一個 Session id，這個 Session id 將被在本次響應中返回給客戶端保存，保存這個 Session id 的方式可以采用 Cookie，如果客戶端瀏覽器禁用了 Cookie，一般這種情況下，會使用一種 URL 重寫的技術來進行會話跟蹤，即每次 HTTP 交互，URL 后都會被附加一個諸如 sid=xxxxxxxx 這樣的參數，服務端根據此來識別用戶
      • 一些網站會利用 Cookie 是否為空、Session 是否為 true 來判斷用戶是否可以登錄，只要構造一個 Cookie 或 Session 為 true 就可以繞過認證登錄
      • Session 會話固定攻擊
        • 一種誘騙受害者使用攻擊者指定的會話標識（Session id）的攻擊手段
        • 攻擊步驟
          • 攻擊者通過某種手段重置目標用戶的 Session id，然后監聽用戶會話狀態
          • 目標用戶攜帶攻擊者設定的 Session id 登錄站點
          • 攻擊者通過 Session id 獲得合法會話
        • 攻擊者重置 Session id 的方式
          • XSS
          • 如果 Session id 在 URL 中，可以通過誘導用戶去點擊重置了 Session id 的 URL
          • 如果使用 Cookie 來存放 Session id，可以使用以下方法
            • 使用客戶端腳本來設置 Cookie 到瀏覽器
              • 大多數瀏覽器都支持用客戶端腳本來設置 Cookie
              • 例如： document.cookie="sessionid=123"
              • 這種方式可以采用 XSS 攻擊來達到目的
              • 防御方法
                • 設置 HttpOnly 屬性，但有少數瀏覽器存在漏洞，即使設置了 HttpOnly，也可以重寫 Cookie，所以還需要其他驗證方式，比如 User-Agent、Token 等
            • 使用 HTML 的 <META> 標簽加 Set-Cookie 屬性
              • 服務器可以采用在返回的 HTML 文檔中增加 <META> 標簽的方式來設置 Cookie
              • 例如： ``<meta http-equiv=Set-Cookiecontent="sessionid=123">
              • 與客戶端腳本相比，對 <META> 標簽的處理目前還不能被瀏覽器禁止
            • 使用 Set-Cookie 的 HTTP 響應頭部設置 Cookie
              • 攻擊者可以使用一些方法在 Web 服務器的響應中加入 Set-Cookie 的 HTTP 響應頭部
              • 例如：入侵目標服務器所在域的任一主機，或者攻擊用戶的 DNS 服務器
      • Cookie 仿冒攻擊
        • 通過修改 Cookie 中的某個參數來實現登錄其他用戶
    • 弱加密
      • 未使用 HTTPS，前端加密，用密文去后台驗證，可以利用 smart decode 進行解碼
  • 數據篡改
    • 手機號 篡改
      • 抓包修改手機號參數為其他號碼進行嘗試，例如辦理查詢頁面，輸入自己的號碼然后抓包，修改手機號為他人號碼，查看是否可以查詢他人業務
    • 郵箱或者用戶 篡改
      • 抓包修改用戶或者郵箱為其他用戶或者郵箱
      • 例如：
        • 修改普通用戶密碼，抓包
        • 將 Referer 和 POST 中的普通用戶改成 admin
        • 提交數據后，直接返回了 admin 的密碼修改頁面，利用邏輯漏洞獲取超級權限
    • 訂單ID 篡改
      • 查看自己訂單，修改 訂單ID 查看是否能查看其他訂單信息
    • 商品編號 篡改
      • 積分商城，利用低積分兌換高積分禮物
      • 選取低積分禮物兌換，提交抓包
      • 修改其中的 goods_id（商品編號）為高積分的商品編號
      • 提交，就可以發現邏輯漏洞的實現
    • 用戶ID 篡改
      • 抓包查看自己的 用戶ID，修改 ID 查看是否能查看其他用戶信息
      • 例如：
        • 查看簡歷處，抓包修改 簡歷ID
        • 提交，就可以查看其他用戶的簡歷
    • 金額 篡改
      • 抓包修改金額等字段
      • 例如：
        • 將支付頁面抓取請求中商品的金額字段，修改成任意數額的金額（如負數）
        • 提交，查看能否以修改后的金額數據完成業務流程
    • 商品數量 篡改
      • 抓包修改商品數量等字段
      • 例如：
        • 將支付頁面抓取請求中商品數量字段，修改成任意數量（如負數）
        • 提交，查看能否以修改后的數量完成業務流程
      • 最大數量突破限制
        • 很多商品限制用戶購買數量，服務器僅在頁面通過 JS 腳本限制，未在服務端校驗用戶提交的數量，通過抓包修改商品最大限制數量，即將請求中的商品數量改為大於最大數值限制，查看是否能完成修改后的數量完成業務流程
  • 密碼找回
    • 常見的密碼找回方式
      • 郵箱找回密碼
      • 根據密碼保護問題找回密碼
      • 根據手機號找回密碼
    • 密碼找回邏輯測試流程
      • 嘗試正常密碼找回流程
      • 選擇不同的找回方式，記錄所有數據包
      • 分析數據包，找出敏感部分
      • 分析后台找回機制所采用的驗證手段
      • 修改數據包進行驗證是否存在密碼找回漏洞
    • 漏洞分類
      • 用戶憑證暴力破解（驗證碼）
        • 四位或六位純數字，驗證碼次數未限制
        • 例如：
          • 根據手機號找回密碼，隨便輸個驗證碼，抓包
          • 暴力破解驗證碼（假如只有四位），很快就可以破解出來
        • 注意：如果驗證碼次數限制，破解一會就會提示請求過於頻繁，這時就需要繞過限制
          • 繞過的話，這里可以考慮一個現狀：
            • 國內很多情況下都沒有過濾字符和限制輸出長度，驗證很有可能只是簡單的處理
          • 例如：
            • 根據手機號找回密碼，但是驗證次數被限制，抓包
            • 可以嘗試在手機號后面添加不為數字的字符，查看是否過濾

               phone=18888888888abc
            

            • 只要更換手機號后面的字符，就可以繞過請求過於頻繁的限制
            • 但是校驗時，手機號后面的字符會被過濾，也就是可以利用暴力破解驗證碼
            • 所以只要在暴力破解的同時，改變手機號后面的字符即可達到漏洞效果
      • 返回憑證（驗證碼 及 token）
        • 抓包直接返回
          • 例如：
            • 根據手機號找回密碼，抓包，可以發現驗證碼直接顯示 verifycode=xxxx，或者由 md5 加密后顯示，解密即可（同理，有的時候輸入用戶名，抓包可以看到返回的手機號等其他信息）
            • 根據郵箱找回密碼
              • 抓包，可以發現返回的數據中有一個加密的字符串（token），先記錄下這個加密字符串
              • 繼續按照正常流程，登錄郵箱獲得驗證碼，返回填寫驗證碼后，進入下一個填寫新密碼頁面，發現 URL 后新增了一個加密驗證的字符串
              • 這個字符串就是之前數據包中記錄的字符串，所以郵箱驗證碼這個環節可以繞過，直接用他人郵箱抓包獲得加密字符串就可以重置他人密碼
        • 密碼找回憑證在頁面中
          • 例如：
            • 通過密保問題找回密碼，查看源碼，密保問題和答案就在源碼中顯示
      • 郵箱弱 token
        • 用戶名
          • 重置密碼鏈接直接使用用戶名來區別，改變用戶名即可更改他人密碼
        • Unix時間戳 + md5
          • 例如：
            • 通過郵箱找回密碼，正常流程去郵箱查看重置密碼鏈接，發現鏈接處有一串 md5 加密字符串
            • 字符串解密，類似 1491293277（10位），可以判斷為 Unix時間戳
            • 重置他人密碼只需要利用他人郵箱發送重置密碼郵箱，在短時間內對 Unix時間戳 進行暴力破解，即可獲得重置密碼的鏈接
        • 服務器時間
          • 例如：
            • 利用兩個帳號同時點擊找回密碼，去郵箱查看找回密碼的鏈接，發現兩者的隨機 token 只差 1-2，而且可以猜測出為服務器時間
            • 所以可以用一個未知帳號和一個已知帳號同時點擊找回密碼，稍微遍歷一下隨機 token，就可以構造出未知帳號的密碼找回鏈接
      • 用戶憑證有效性
        • 短信驗證碼
          • 例如：
            • 通過他人手機號找回密碼，抓包，將他人手機號替換成自己的手機號，獲取驗證碼，提交后修改密碼
            • 通過自己手機號找回密碼，獲取驗證碼后抓包，將數據包中的 username 改為他人用戶名，提交后成功修改他人密碼
        • 郵箱 token
          • 例如：
            • 通過郵箱找回密碼，訪問鏈接重置密碼，輸入新密碼后提交時抓包，雖然有 token，但是依然可以直接修改 用戶ID 進而修改他人密碼
        • 重置密碼 token
          • 例如：
            • 正常流程下，對每個功能模塊進行抓包，分別是發送驗證碼，驗證驗證碼是否正確，獲取 token，重置密碼
            • 接下來，用他人帳號通過郵箱驗證，抓包，將其中 Cookie 內從 JSESSIONID 開始的內容替換至正常流程的發生驗證碼包內，同時替換自己接受驗證碼的郵箱，提交
            • 通過郵箱獲取驗證碼后，將驗證碼、Cookie、他人帳號、自己郵箱替換至驗證驗證碼模塊，提交（不用在意返回是否錯誤）
            • 繼續替換內至獲取 token 模塊，提交獲取 token
            • 最后將獲取的 token 和上面的內容替換至最后的重置密碼模塊，提交成功修改密碼
      • 重新綁定
        • 手機綁定
          • 例如：
            • 給已知賬戶綁定手機，發現綁定手機的 URL 鏈接中有 uid 參數，修改 uid參數為他人的，即可實現將他人的賬戶綁定上自己的手機，之后通過手機來修改密碼
            • 修改個人資料處抓包，修改 userId 為他人，修改 mobilePhone 為自己的手機，即可實現將他人的賬戶綁定上自己的手機，之后通過手機來修改密碼
        • 郵箱綁定
          • 例如：
            • 通過郵箱找回密碼，URL 鏈接中修改 用戶ID 為他人，郵箱不變，之后通過鏈接可以將他人賬戶綁定為自己的郵箱，之后通過郵箱找回密碼
      • 服務器驗證
        • 最終提交步驟
          • 例如：
            • 通過郵箱找回密碼，最后通過鏈接至修改密碼頁面，修改密碼后提交，抓包，獲得 Uid 參數，修改為他人，即可修改其他用戶密碼
        • 服務器驗證可控內容
          • 例如：
            • 正常流程，通過手機號提交驗證碼找回密碼處抓包，記錄下這個包的內容
            • 通過已知用戶名找回密碼，查看源代碼可以發現用戶其他信息（比如：手機號、郵箱）
            • 通過發現的手機號選擇通過手機找回密碼，隨便輸入短信驗證碼，抓包
            • 修改之前記錄下的包的內容，將其中 Session id、用戶ID 修改為剛剛從其他用戶名抓包獲得的內容，提交這個包，即可成功修改他人密碼
        • 服務器驗證的驗證邏輯為空（繞過認證）
          • 例如：
            • 通過密碼保護問題找回密碼，抓包，將密碼保護問題刪除，直接修改密碼，提交
            • 注：此處密保問題和新密碼在同一頁面
      • 用戶身份驗證
        • 帳號與手機號的綁定
          • 例如：
            • 通過手機找回密碼，輸入驗證碼和新的密碼，F12 審查元素，修改自己的手機為他人手機，提交成功修改他人手機（也可以抓包修改）
        • 帳號與郵箱的綁定
          • 例如：
            • 通過郵箱找回密碼，點擊請重新發送郵件處抓包，將郵箱改為自己的郵箱，通過鏈接成功修改密碼
      • 找回步驟
        • 跳過驗證步驟、找回方式、直接到設置新密碼頁面
          • 例如：
            • 正常流程下，密碼找回，查看最后設置新密碼頁面的 URL，記錄下來
            • 繼續返回密碼找回處，輸入其他用戶名，提交找回申請，直接訪問上面記錄下的修改密碼頁面，成功修改密碼
            • 也可以正常流程下，修改密碼頁面抓包，修改其中的 USERNAME_COOKIE 為其他用戶（有可能會經過編碼，比如 base64），提交即可修改其他用戶密碼
            • 如果抓包其中有 step 參數，可以修改這個參數為最后一步（比如：5），提交便可略過之前的步驟
      • 本地驗證
        • 在本地驗證服務器的返回信息，確定是否執行密碼重置，但是其返回信息是可控的內容，或者是可以獲得的內容
          • 例如：
          • 通過手機找回密碼，隨便輸入驗證碼，抓包，發送，攔截返回包（Burpsuite 中可以選取 do intercept --> response to this request）
          • 修改返回包中的返回碼，繼續發送，說不定就可以繞過驗證，直接跳到修改密碼的頁面
          • 通過手機找回密碼，正常流程下到重置密碼頁面，抓包查看返回數據中有一段加密字符串
          • 利用他人手機找回密碼，URL 跳轉到驗證身份頁面，鏈接中就有一段加密字符串，記錄下，隨便輸入驗證碼，抓包，修改包中數據為正常流程下的數據，替換加密字符串，Forward 發送，就可以繞過驗證碼，直接修改密碼
        • 發生短信等驗證信息的動作在本地執行，可以通過修改返回包進行控制
          • 例如：
          • 通過用戶名找回密碼，提交后會自動發送驗證碼到手機中，所以抓包，修改手機為自己的手機（如果其中有 type 之類的參數，也可以嘗試修改，有 email 之類的參數，可以嘗試刪除內容），發送修改后的包，手機成功接收驗證碼
          • 輸入驗證碼，繼續發送，抓包，如果有 type 之類的參數，可以繼續嘗試修改，發送就可以成功修改密碼
      • 注入
        • 找回密碼處存在注入漏洞
          • 輸入用戶名，加個單引號報錯，說明可能存在報錯，抓包，保存為 txt 文件，導入 Sqlmap 中跑一遍
      • token 生成
        • token 生成可控
          • 通過郵箱找回密碼，正常流程下，抓包查看提交驗證碼后返回的數據，發現有加密字符串，這個加密字符串和后面重新設置新密碼 URL 鏈接中的加密字符串一樣，所以可以利用這個加密字符串
          • 根據上面提交驗證碼的抓包，修改其中的 User 為其他用戶（User 有可能會使用 md5 加密），發送，就可以返回其他用戶的加密字符串
          • 重新返回到找回密碼首頁，利用其他用戶找回，點下一步，到輸入驗證碼處（也有可能需要點擊發送驗證碼），直接修改 URL 鏈接，加入加密字符串，可以直接繞過驗證碼，重置密碼
      • 注冊覆蓋
        • 注冊重復的用戶名，例如 admin，相當於修改了密碼
      • session 覆蓋
        • 例如：
        • 同一瀏覽器，首先輸入自己的賬戶進行郵箱密碼找回，進入郵箱查看鏈接，接着輸入他人賬戶，進行密碼找回，返回剛剛自己的郵箱點擊鏈接，由於 session 覆蓋導致了，這個鏈接成為了修改他人密碼的鏈接，成功修改他人密碼
  • 繞過授權驗證
    • 未授權訪問
      • 用戶在沒有通過認證授權的情況下直接訪問需要通過認證才能訪問的頁面或文本
    • 水平越權
      • 相同級別（權限）的用戶或者同一角色不同的用戶之間，可以越權訪問、修改或者刪除的非法操作，如果出現此漏洞，可能會造成大批量的數據泄漏，嚴重的甚至會造成用戶信息被惡意篡改
    • 垂直越權
      • 不同級別之間或不同角色之間的越權
      • 垂直越權可以分為
        • 向上越權
          • 普通用戶可以執行管理員權限，比如發布文章、刪除文章等操作
          • 修復方法
            • 如果管理員和普通用戶是同一張數據庫表，就必須要存在權限驗證字段，權限驗證字段用於區分是否為管理員，如果不在同一張表，在過濾器中直接去除管理員信息即可
        • 向下越權
          • 一個高級用戶可以訪問低級用戶信息（暴露用戶隱私）
  • 驗證碼突破
    • 驗證碼暴力破解
      • 工具
        • Burpsuite
        • Hydra
    • 驗證碼時間、次數測試
      • 重復提交攜帶驗證碼的數據包，查看返回包，判斷次數
    • 驗證碼客戶端回顯測試
      • 抓包測試，是否有回顯，驗證碼是否會被返回
    • 驗證碼繞過測試
      • 抓包，刪除驗證碼字段，查看是否可以成功發送
      • 抓包，正常流程下，記錄驗證碼后的數據包，替換目標包中內容，直接發送，查看是否可以直接繞過驗證碼
  • 流程亂序
    • 順序執行
      • 在一個邏輯流程中，按照第一步、第二步、第三步這種模式進行一步一步的驗證，有順序的執行邏輯過程
    • 常見的順序執行漏洞
      • 密碼找回的順序執行
        • 可以繞過驗證，直接跳轉至重置密碼頁面
        • 繞過的方式有很多種
          • 更改 用戶名（郵箱等等）
          • 替換正常流程數據包
          • 分析數據包中關鍵字符串（加密后），進行關聯替換
      • 支付環節的順序執行
        • 商品數量正負數（最大值）
        • 價格正負數（不局限與商品價格，還有運費等待）
        • 同一訂單重復發送請求包，使購買數量增加
        • 抓包，分析是否有 type 之類的參數用於判斷執行順序，可直接更改跳轉至支付成功頁面
      • 登錄驗證的順序執行
        • 登錄驗證處，有的廠商會先檢驗驗證碼，正確后然后檢驗賬戶密碼，這樣就可以實現暴力破解
  • 接口調用安全
    • 重放攻擊
      • 在短信、郵件調用業務或生成業務數據環節中（類：短信驗證碼，郵件驗證碼，訂單生成，評論提交等），對其業務環節進行調用（重放）測試
      • 常見類型
        • 短信轟炸
        • 惡意注冊
    • 內容編輯
      • 例如
        • 點擊獲取短信驗證碼，抓包，可以修改短信內容，實施下一步攻擊
• 業務邏輯漏洞終總結
  • 測試業務的時候，先了解清楚業務整體流程，可以利用思維導圖快速理清各個業務之間的關系，也可以通過查看 JS 了解（JS 中可能會存在信息泄漏）
  • 重點關注的業務：個人（他人）信息、密碼修改（找回）、支付流程、注冊流程、需要手機（郵箱）驗證的業務
  • 對每個業務模塊進行抓包，分析其中各種請求，注意 特殊參數，很有可能就是這些 特殊參數 決定了業務步驟
  • 抓包重放的過程，需要多次實驗，判斷是否可以跳過（繞過），如何跳過（繞過），純數字可以用 數字 + 字母 嘗試繞過
  • 返回包中數據的分析，關注特殊字符串和特殊參數
  • 綜上所述，業務流程需同時結合 HTTP/HTTPS 請求分析，關注重點在各種可以用於區別的參數，繞過必要驗證，跳過業務步驟