【Web滲透】業務邏輯漏洞
當前位置：點晴教程→知識管理交流
→『 技術文檔交流 』
身份驗證漏洞暴力破解漏洞漏洞介紹：攻擊者可以通過該漏洞獲取用戶名和對應弱口令密碼，并進行登錄操作 漏洞原理：由于沒有設置登錄失敗次數限制，導致攻擊者可以通過口令字典進行特定用戶的密碼爆破或通過用戶名字典進行特定弱口令的用戶枚舉 漏洞點：系統登錄點 漏洞修復：對于固定用戶名爆破密碼 可以針對用戶名進行錯誤次數計算，高于一定閾值賬號鎖定一段時間，或者添加驗證碼 但是不能永久鎖定，可能被用來進行賬戶惡意鎖定 對于固定密碼枚舉用戶名、 需要計算IP對URL的請求情況，某個IP短時間大量請求登錄應該加入黑名單 進行傳輸數據加密有一定的防護效果 Session固定攻擊漏洞介紹：會話固定攻擊是利用服務器的session不變機制，借他人之手獲得認證和授權，然后冒充他人 漏洞原理：在請求登錄過程時候，URL帶有一個session，登錄成功之后會將登錄成功的信息綁定到這個session中，攻擊者可以發送帶有session的URL給相關工作人員誘導其登錄，相當于獲取了其身份信息 漏洞點：在GET方法請求登錄時候帶有session值 修復思路： 只要避免在URL中帶入session信息即可比較有效的防御 另外也要注意POST請求中帶有sessionid進行session固定攻擊，雖然可利用性比較低，但是建議修復 Cookie欺騙漏洞漏洞介紹：通過偽造cookie信息能夠偽造其他用戶進行登錄。漏洞原理：開發者為了方便將身份信息/登錄信息明文或者只是簡單編碼、哈希之后存放在cookies中，網站通過獲取得到的cookies進行授權或者身份驗證 漏洞點：cookie中有明顯或者只是簡單編碼、哈希的字段時候 修改lsLogin值為1可以判定為用戶已經登錄 修改cookie為asp163=UserName=admin 漏洞修復：Cookie不應該存儲可理解的身份信息和登錄信息 按照規定，cookie對身份信息和登錄信息的存儲只能通過存儲足夠長度的隨機字符串進行，避免篡改 權限類邏輯漏洞權限相關邏輯漏洞是邏輯漏洞中出現的最多的漏洞 平行權限跨越漏洞介紹：即普通用戶/管理員能訪問其他普通用戶/管理員才能夠訪問的系統信息或者系統功能 形成原因：在進行方法調用時候未進行請求用戶和目標信息擁有者是否匹配一致，直接用userid/email之類的容易遍歷的參數進行數據庫查詢 漏洞點：在普通用戶/管理員登錄后的能訪問的鏈接或者功能中都可能存在 漏洞修復： 在權限管理中，平行越權的權限管理顆粒度最小 修復思路 需要在方法中進行相關的獲取請求request 再利用getAttribute("userid")獲取其userid 直接使用該userid作為參數進行數據增刪查改，避免userid參數傳輸 垂直權限跨越漏洞介紹：即普通用戶能夠訪問管理員甚至超級管理員才能夠訪問的系統信息或者系統功能 形成原因：程序再方法調用時候，缺少角色等級校驗 漏洞點：在任何用戶登錄后才能訪問的鏈接或者功能中都可能存在 對每一個傳輸的參數都要了解參數的目的，嘗試將用戶名改為admin嘗試繞過 漏洞修復： 需要校驗用戶是否有權限訪問這個方法 修復思路 獲取請求request 再利用getAuttribute("roleid")獲取其角色等級 檢查角色等級是否合法，錯誤則直接返回錯誤跳轉，返回頁面必須仍然從Attribute中獲取userid再進一步查詢相關信息 值得注意的是切勿將錯誤跳轉寫到Javascript里面，還返回目標URL頁面的相關信息。 未經授權訪問漏洞介紹：即游客能夠訪問普通用戶甚至超級管理員才能訪問的系統信息或者系統功能 形成原因：主要是系統設計期間沒有進行全局用戶身份校驗；或者校驗存在缺陷 漏洞點：在任何用戶登錄后才能訪問的鏈接或者功能中都可能存在 漏洞修復： J2EE中存在filter，可以獲取用戶的cookie等信息 修復思路： 建立LoginList，值是當前在線用戶的id 對所有需要登錄訪問到URL，獲取請求request 再利用 getAttribute("userid") 獲取其userid 檢查userid是否存在于LoginList中，不存在則直接返回錯誤跳轉 值得注意的是切勿將錯誤跳轉寫到Javascript里面，還返回目標URL頁面的相關信息 圖形驗證碼漏洞圖形驗證碼突破漏洞介紹：攻擊者通過突破圖形驗證碼的驗證，可以實現如登錄爆破、驗證碼繞過等攻擊 漏洞原理： 圖形驗證碼在錯誤后未失效 返回驗證碼信息 分步驗證驗證碼 漏洞點：任何存在圖形驗證碼的功能中 漏洞修復 一旦驗證碼使用過了，必須要進行刪除，重新生成驗證碼，可以梵高attribute中 驗證碼需要設置超時，時間一到立即刪除舊驗證碼，用戶需要獲取新的驗證碼 驗證碼只需要返回圖片，切勿將生成驗證碼的字符串也一并返回 驗證碼不應該進行分布校驗，應該連同請求數據一起發送到目標服務器進行校驗，服務器校驗通過則返回合法數據，否則返回錯誤 找回密碼邏輯漏洞密碼找回漏洞漏洞介紹：攻擊者通過密碼找回邏輯漏洞，可以重置他人賬號密碼，危害他人賬號安全 漏洞原理：其實是驗證碼漏洞的一種： 驗證碼時間長可爆破 返回重置密碼憑證 若加密的重置密碼憑證 漏洞點：任何密碼找回處（可延伸至相似具有驗證功能） 修改接受校驗碼目標 漏洞修復 一旦驗證碼使用過了，必須要進行刪除，重新生成驗證碼，可以放到attribute中 驗證碼需要設置超時，時間一到立即刪除舊驗證碼，用戶需要獲取新的驗證碼 校驗憑證不能夠隨著返回包進行返回 驗證碼不應該進行分布校驗，應該連同請求數據一起發送到目標服務器進行校驗，服務器校驗通過則返回合法數據，否則返回錯誤 校驗憑證的生成需要進行隨機生成，防止憑證破解 用戶身份憑證和權限類漏洞修復一樣，需要從attribute中獲取 業務數據篡改漏洞業務數據篡改（賦值反沖）漏洞介紹：攻擊者通過進行數值篡改進行攻擊，從而獲利 漏洞原理： 沒有對傳輸數據添加相關的校驗參數 后臺未對參數值進行校驗并直接使用數據包中的參數 漏洞點：抽獎、購買、轉賬、返現等功能 漏洞修復： 對于軟件來說，需要保護好內存數據，防止內存數據篡改 計算傳輸數據的哈希，并將哈希附加在傳輸數據中作為校驗值，避免被篡改 先校驗數值，防止大整數和負數；接著利用傳輸的商品ID從數據庫中獲取商品單價重新進行價格計算；最后生成訂單（訂單號應為隨機值） 執行順序邏輯漏洞執行順序篡改漏洞介紹：攻擊者通過篡改分步邏輯中的步驟數字，達到繞過支付、校驗等效果 漏洞原理：程序邏輯分布進行，但是對步驟、驗證信息、支付信息沒有做好嚴格校驗，導致修改步驟就直接繞過驗證或者支付 漏洞點：任何分布邏輯且帶步驟數字，或者利用JS進行步驟控制的功能中 漏洞修復 在請求最后一步時候需要帶入前面的驗證信息，服務端再進行一次校驗信息的驗證，驗證正確方能繼續執行數據操作 也可以及通過getAttributr("userid")獲取userid進行userid和驗證結果綁定，最后一步不帶入驗證信息，但是仍然要獲取userid進行校驗 再最后一步通過驗證之后或者服務器收到支付信息后再生成相應的數據交給用戶 其他類型邏輯漏洞條件競爭漏洞漏洞介紹：可以通過同時重放大量數據包進行漏洞利用，通常用于突破限量、限額的問題都有奇效 漏洞原理：由于目標函數中，判斷與數據修復兩個步驟之間，或者兩個數據修改步驟之間存在時間差，且函數未進行同步鎖定，則可以造成漏洞 漏洞點：程序中存在限制，可以猜測到后臺有判斷與修改操作的方法 漏洞修復 -修復思路：使用synchronized關鍵字，可以限制同一時間內訪問方法的只有單一線程 并不是每個條件競爭都必須修復 數據包重放漏洞漏洞介紹：通過數據包重放，可以造成短信轟炸、郵件轟炸、重復提交訂單等 漏洞原理：后臺未進行相關操作的技術導致數據包重放 漏洞點：短信驗證碼、郵件校驗、提交訂單等功能。 修復方案： 修復思路（針對短信、郵件） 構造一個Hashmap<String，short>，存放郵箱或電話號碼及對應次數 只要某個郵箱或者電話號碼次數夠了，就不能繼續發送了 或者計算兩次發送的時間間隔，時間過短就不繼續發送了 通用修復方案 需要建立token機制或驗證碼機制，一次有效 參數綁定漏洞漏洞介紹：通過添加對象字段相關參數進行數據篡改 漏洞原理：對象自動綁定被許多框架支持，它允許將HTTP請求參數自動的綁定到對象，開發者沒有對其進行安全校驗則容易導致數據篡改 漏洞點：常見的所有輸入的地方都會出現這個漏洞，特別是金融、用戶、緩存等。 漏洞修復：Spring MVC中可以使用@InitBinder注釋，通過WebDataBinder的方法setAllowedFields、setDisallowedFields設置允許或不允許綁定的參數 SRC中的邏輯漏洞總結注冊： 短信轟炸 驗證碼安全問題 密碼爆破 郵箱轟炸 用戶任意注冊、批量注冊 用戶名枚舉 XSS（有框的地方就可以嘗試插XSS） 登錄： 短信轟炸、驗證碼安全問題、密碼爆破、郵箱轟炸 SQL注入 撞庫 抓包把password字段修改為空值發送 認證憑證替換、比如返回的數據包中包含賬號，修改賬號就能登錄到其他賬號 Cookie仿冒 修改返回包的相關數據，可能會登陸到其他的用戶 找回密碼： 短信郵箱轟炸、短信郵箱劫持 重置任意用戶賬戶密碼、驗證碼手機用戶未統一驗證 直接跳過驗證步驟 購買支付、充值（要利用抓包去仔細查看每一個可用的參數） 交易金額、數量修改、更換支付模塊（比如更換支付的模塊金額） 交易信息訂單編碼/導致信息泄露 整數溢出，int最大值為2147483647，超過最大值 修改充值賬戶 支付繞過 抽獎活動 刷獎品、積分 并發 優惠卷、代金卷 并發邏輯漏洞（burp批量獲取優惠券） 修改優惠券金額、數量 訂單信息 訂單信息遍歷、泄露 訂單信息泄露導致用戶信息泄露 刪出他人訂單 會員系統 修改個人信息上傳文件，上傳帶彈窗的html 如遇上上傳xlsx、docx，可能存在XXE，上傳惡意的文檔盲測 圖片上傳也可能遇到imagereagick命令執行，上傳惡意圖片 視頻上傳如果使用ffmpeg<3.2.4（視頻按幀分割成圖片），上傳惡意avi盲測ssrf 用戶橫向越權訪問、遍歷、導致用戶信息泄露 SQL注入、個人簡歷處存儲XSS個人信息注冊的名稱也可以插入XSS 傳輸過程 明文傳輸賬戶密碼 修改信息處無session/token導致csrf POST/COOKIE注入 評論 POST注入 存儲型XSS 無session/token導致CSRF 驗證碼問題 萬能驗證碼 返回包中存在驗證碼 刪除驗證碼或者cookie中的值可以爆破賬號密碼 短信轟炸 一直重放 刪除修改cookie，重放數據包 遍歷參數發送數據包 手機號后面加空格或者前面加其他的比如+86或者逗號分號等，然后重發數據包 請求參數修改大小寫，或者添加請求參數比如&id=1 一個站的登錄處可能做了防護，但是再找回密碼處可能沒有安全防護，或者在注冊流程中沒有安全防護，所以說多測試接口 如果對手機號一天的次數進行了限制，還可以再發一次短信，DO intercept之后修改為成功回顯 水平越權 主要登陸后還是修改參數，主要找到多個接口不斷測試 關注網頁源代碼，有時候會有表單，但被bidden（隱藏標簽）給隱藏起來了，可以修改返回包然后嘗試獲取數據檢測 多個賬號，主要分析請求參數 數據泄露 再找回密碼處，填寫數據后抓包查看返回信息，有可能存在敏感數據返回 任意用戶密碼重置 目前大部分都是在修改密碼處參數修改 有些是前端驗證 支付邏輯漏洞 邊界值問題 : 正常的邏輯是用戶購買商品，然后價格累加得到一個總價進行扣款。這個時候就會產生邏輯問題：如果說用戶購買的商品是負數了，那么計算的總數就是負數。反過來錢給用戶 順序執行缺陷：正常的邏輯是a-b-c-d 循環漸進的進行流程操作。這個時候就會產生邏輯問題：可以直接從中繞過某一個過程進入到下一步操作。如果說有一項是支付的操作，那么也就會產生支付繞過，如果說有一項是驗證機制，就會繞過驗證直接進入下一步。 金額直接傳輸導致篡改：直接對下單的金額進行修改值，這里可以使用fd或者burp抓包 確定支付之后還可以加入購物車：把商品放入購物車點擊下單支付，會跳轉到微信，支付寶等第三方支付平臺。這個時候還可以繼續在購物車中加入商品，支付結束之后，商家發放的商品是現在的購物車里面的東西。 請求重放：購買成功之后，繼續重放請求，可以讓購買的商品一直增加。購買成功之后，會有一個銀行對商戶網站跳轉的過程，如果反復進行操作，有幾率會導致商品反復購買和增加，但是不需要付更多的錢。 請求參數干擾：金錢做了簽名認證之后，修改后不通過，但是在里面仍然會有一個參數對金額產生影響導致問題產生。 訂單替換：訂單替換發生在支付之后的事件處理，同時向服務器發起二次支付請求一個多一個少，支付金額少的，然后支付之后進行替換，告知服務器訂單支付完成，并且過程可以反復的回放。 欺詐:需要兩個收款人，一個是正常的商家，一個是偽造的商家 單位替換：產生在paypal類似的國際支付的場景。 用戶替換：在支付過程中發生用戶替換現象，首先登陸自己的賬戶，然后取得另外一個人的賬戶名等有效信息，在業務流程中用對方的用戶名替換自己的用戶名，用對方的余額購買完成后，再替換自己的賬戶名，這樣就形成別人的錢買自己的東西 強制攻擊：強制攻擊發生在暴力破解的情況下，如果一個商家運用一個自己的網店，接入第三方支付接口，由于設計上的不當導致商家與第三方支付約定的密鑰Key可以單獨被MD5加密，導致可以使用MD5碰撞技術對密鑰進行破解，攻擊者可以設計簡單的密鑰加密信息使得MD5加密是可以用MD5碰撞技術進行暴力破解。 秘鑰泄漏：內置支付功能的app為了設計上的方便有可能會把Md5或者是RSA的私鑰泄漏導致攻擊者反編譯apk之后獲取密鑰信息使得交易信息可以被篡改。 函數修改：apk反編譯之后的函數修改，可能導致商家在最后一步向支付方提交訂單時未驗證信息的準確性，仍然被篡改。 heart bleed：SSL（安全套接層）協議是使用最為普遍網站加密技術，而OpenSSL則是開源的 SSL 套件，為全球成千上萬的web服務器所使用。Web服務器正是通過它來將密鑰發送給訪客然后在雙方的連接之間對信息進行加密。URL中使用 https打頭的連接都采用了SSL加密技術。在線購物、網銀等活動均采用SSL技術來防止竊密及避免中間人攻擊。 該漏洞被歸為緩沖過度讀取。緩沖過度讀取錯誤是軟件可以讀取比應該被允許還多的數據。漏洞讓特定版本的openSSL成為無需鑰匙即可開啟的“廢鎖”，入侵者每次可以翻檢戶主的64K信息，只要有足夠的耐心和時間，就可以翻檢足夠多的數據，拼湊出戶主的銀行密碼、私信等敏感數據。產生原因：數據在傳輸的兩端是不加密的。一些數據如果在傳輸過程中不加密則會泄露個人數據等信息。 修改返回包的越權 修改手機號 一般的邏輯為：認證原手機號-> 填寫新手機號-> 提交修改 如果在下一步操作時，沒有校驗上一步的認證是否成功時，就會存在邏輯缺陷繞過 比如在進行第一步認證原手機號時，隨意輸入驗證碼，將response包中的相關字段進行修改，比如0改成1，false改成true，即可繞過第一步驗證，進入填寫新手機號界面，如果第三步提交修改時沒有驗證第一步的結果，就會造成邏輯漏洞 登錄繞過 部分網站的身份驗證放在了前端，因此只需要將response包中的相關字段進行修改，比如0改成1，false改成true，就可以登錄任意用戶賬號 水平越權 遍歷ID 在一些請求中，GET和POST中有明顯的ID數字參數（手機號、員工號、賬單號、銀行卡號、訂單號等等），可以嘗試進行遍歷，如果程序沒有對當前權限進行判斷，就會存在水平越權問題 ID替換 如果程序對用戶標識進行了hash或者加密，而無法破解用的什么方式的話，就無法通過遍歷ID來獲取其它用戶的信息了，此時可以嘗試注冊兩個賬號，通過替換兩個ID加密后的值，判斷程序是否對權限進行了驗證，如果沒有，也會存在越權問題 垂直越權 觀察cookie中的session字段，可能某些字段或者參數代表身份，嘗試修改 該文章在 2023/12/13 19:02:19 編輯過 |
關鍵字查詢
相關文章
正在查詢... 
|
400 186 1886
