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