業務邏輯漏洞

轉載：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 請求分析，關注重點在各類能夠用於區別的參數，繞過必要驗證，跳過業務步驟