账户逻辑漏洞
隨著社會及科技的發(fā)展，眾多傳統(tǒng)行業(yè)逐步融入互聯(lián)網(wǎng)并利用信息通信技術(shù)以及互聯(lián)網(wǎng)平臺進(jìn)行著繁復(fù)的商務(wù)活動。這些平臺由于涉及到大量的金錢，個人信息，交易等重要個人敏感信息，成為了黑客的首要目標(biāo)，但是由于開發(fā)人員的安全意識淡薄，常常被黑客鉆空子屢屢得手，給廠家和用戶帶來巨大的損失。
相比SQL注入漏洞、XSS漏洞、上傳、命令執(zhí)行等傳統(tǒng)應(yīng)用安全方面的漏洞，現(xiàn)在的攻擊者更傾向于利用業(yè)務(wù)邏輯層面存在的安全問題。傳統(tǒng)的安全防護(hù)設(shè)備和措施主要針對應(yīng)用層面，而對業(yè)務(wù)邏輯層面的防護(hù)則收效甚微。攻擊者可以利用程序員的設(shè)計缺陷進(jìn)行交易數(shù)據(jù)篡改、敏感信自盜取、資產(chǎn)的竊取等操作。業(yè)務(wù)邏輯漏洞它可以逃逸各種安全防護(hù)，迄今為止沒有很好的解決辦法。現(xiàn)在為了規(guī)避該風(fēng)險，總結(jié)了一些賬戶邏輯漏洞場景。
?
1.登陸賬戶
賬戶登陸模塊，如果存在問題可能出現(xiàn)繞過防護(hù)機制進(jìn)行爆破賬戶甚至直接登陸他人賬戶。
1.1.登陸認(rèn)證功能繞過
①直接訪問登陸后的界面
一般登陸界面登陸成功后會進(jìn)行跳轉(zhuǎn)到主頁面，例如：main.php。但是如果沒有對其進(jìn)行校驗的話，可以直接訪問主頁面繞過了登陸認(rèn)證。
②前端驗證
有時候，登陸狀態(tài)如果只以登陸狀態(tài)碼進(jìn)行判斷登陸成功標(biāo)識，那么修改登陸狀態(tài)碼就能進(jìn)行登錄。
?
例如：對登陸狀態(tài)抓包
?
?
修改這里的code值,修改成1，放行成功登入
?
1.2圖形驗證碼
驗證碼的主要目的是強制性人機交互來抵御機器自動化攻擊的。用戶必須準(zhǔn)確的識別圖像內(nèi)的字符，并以此作為人機驗證的答案，方可通過驗證碼的人機測試。相反如果驗證碼填寫錯誤，那么驗證碼字符將會自動刷新并更換一組新的驗證字符，直到用戶能夠填寫正確的驗證字符為止，但是如果設(shè)計不當(dāng)會出現(xiàn)繞過的情況。
?
1.2.1圖形驗證碼前端可獲取
這種情況在早期的一些網(wǎng)站中比較常見，主要是因為程序員在寫代碼的時候安全意識不足導(dǎo)致的。驗證碼通常會被他們隱藏在網(wǎng)站的源碼中或者高級一點的隱藏在請求的Cookie中，但這兩種情況都可以被攻擊者輕松繞過。
?
第一種：驗證碼出現(xiàn)在html源碼中。
這種驗證碼實際并不符合驗證碼的定義，寫腳本從網(wǎng)頁中抓取即可
?
第二種：驗證碼隱藏在Cookie中
這種情況，我們可以在提交登錄的時候抓包，然后分析一下包中的Cookie字段，看看其中有沒有相匹配的驗證碼，或者是經(jīng)過了一些簡單加密后的驗證碼（一般都是base64編碼或md5加密）
1.2.2圖形驗證碼可識別
這種驗證碼確實是圖片，在前端也沒有出現(xiàn)，但是由于沒有對其做模糊處理，能夠被機器自動識別。
?
1.2.3驗證碼重復(fù)利用
有的時候會出現(xiàn)圖形驗證碼驗證成功一次后，在不刷新頁面的情況下可以重復(fù)進(jìn)行使用。
1.2.4出現(xiàn)萬能驗證碼
在滲透測試的過程中，有時候會出現(xiàn)這種情況，系統(tǒng)存在一個萬能驗證碼，如000000，只要輸入萬能驗證碼，就可以無視驗證碼進(jìn)行暴力破解。引發(fā)這樣的原因主要是開放上線之前，設(shè)置了萬能驗證碼，測試遺漏導(dǎo)致。
?
1.3短信驗證碼登陸
有時候為了方便用戶登陸，或者進(jìn)行雙因子認(rèn)證，會添加短信驗證碼的功能。如果設(shè)計不當(dāng)會造成短信資源浪費和繞過短信驗證的模塊。
1.3.1 短信驗證碼可爆破
短信驗證碼一般由4位或6位數(shù)字組成，若服務(wù)端未對驗證時間、次數(shù)進(jìn)行限制，則存在被爆破的可能。
1.3.2短信驗證碼前端回顯
點擊發(fā)送短信驗證碼后，可以抓包獲取驗證碼。
1.3.3 短信驗證碼與用戶未綁定
一般來說短信驗證碼僅能供自己使用一次，如果驗證碼和手機號未綁定，那么就可能出現(xiàn)如下A手機的驗證碼，B可以拿來用的情況
?
那么作為一個安全的短信驗證碼，他的設(shè)計要求應(yīng)該滿足如下幾點：
①A用戶獲取的短信驗證碼只能夠供A使用
②A用戶短時間內(nèi)獲取的多條短信只有最新的一條能使用
③短信驗證碼設(shè)置為6位數(shù)，有效期30分鐘甚至更短，當(dāng)驗證碼失敗3次后失效。
?
2重置賬戶密碼
重置密碼功能本身設(shè)計是為了給忘記密碼的用戶提供重置密碼的功能，但是如果設(shè)計不當(dāng)存在任意賬戶密碼重置。
2.1短信找回密碼
跟短信驗證碼登陸類似
2.2郵箱找回密碼
2.2.1鏈接弱token可偽造
這種一般都是找回密碼鏈接處對用戶標(biāo)識比較明顯，弱token能夠輕易偽造和修改
①基于用戶id標(biāo)識
?
例如
http://xxx.com/member/getbackpasswd.html?sendTime=MjAxOC0wNC0wNyAxMjozOQ==&userValue=bGlsZWlAdnNyYy5jb20=這里的明顯是base64編碼的
sendTime為時間的2018-04-07 12:39
userValue為用戶郵箱的 lilei@vsrc.com
知道構(gòu)造方式了 我們就可以自己構(gòu)造找回密碼的鏈接了
?
②基于服務(wù)器時間
?
例如
http://xxx.com/member/reSetPwdCheck.action?email=666@qq.com&startClickTime=20180810105628這里可以看到startClickTime為20180810105628，我們不確定服務(wù)器時間時候，可以在同一時間同時重置賬戶a和賬戶b，根據(jù)賬戶a收到的url中token值來推斷b對應(yīng)的值
?
Ps：這里有一種情況，不是簡單將用戶id變形，而是融合了精確的時間戳與帳號綁定。例如我的id是1998，現(xiàn)在時間戳是1533892152，合起來是15338921521998。這種看起來有唯一性，但是還是可以通過暴力猜解獲得。
2.2.2認(rèn)證憑證通用性
憑證跟用戶沒有綁定，可以中途在有用戶標(biāo)識的時候進(jìn)行修改
2.2.3 Session覆蓋
session或cookie的覆蓋(它被用作修改指定用戶的密碼,可能就是用戶名),而服務(wù)器端只是簡單判斷了一下修改鏈接的key是否存在就可以修改密碼了,而沒有判斷key是否對應(yīng)指定用戶名。
先向自己郵箱A發(fā)一封找回密碼，再向用戶B的郵箱發(fā)一封，當(dāng)前瀏覽器記錄用戶B的賬戶信息，然后去自己的郵箱A點擊找回密碼鏈接，讀取了存在瀏覽器用戶B的賬戶信息，成功修改了密碼。
?
2.3用戶名找回密碼
隨便輸入一個用戶 他有一個包檢驗用戶是否存在，這里回顯了用戶全部信息。
這里的問題在于查詢用戶處，回顯了多余的個人信息。
?
?
2.4找回密碼步驟缺失
找回密碼過程中跳過關(guān)鍵的驗證步驟，達(dá)到修改別人密碼的目的
輸入賬戶和驗證碼，點擊后進(jìn)入第二步
http://xxx.com/findpwd/step2.do?uri=fjtwQnY2eDp1LHI0DT9zXHBAAE1xUgg6dEVwQARCAzRzPnRECUEBXXJ3dWIFenABc0M=&type=2?
這里qazs1對應(yīng)用戶標(biāo)識就是
uri=fjtwQnY2eDp1LHI0DT9zXHBAAE1xUgg6dEVwQARCAzRzPnRECUEBXXJ3dWIFenABc0M=然后這里理論上是要輸入驗證碼，然后才會有step3，修改密碼步驟，實際上是可以進(jìn)行跳過的
http://xxx.com/step3.do?uri=fjtwQnY2eDp1LHI0DT9zXHBAAE1xUgg6dEVwQARCAzRzPnRECUEBXXJ3dWIFenABc0M=?
這里step3 最后一步也有uri參數(shù)，可以直接拼接構(gòu)造就可以完成重置密碼的功能。
總結(jié)
- 上一篇： 逻辑漏洞小结之SRC篇
- 下一篇： 几点基于Web日志的Webshell检测