Web安全實踐第8章邏輯漏洞（上）目錄CONTENTS8.1權(quán)限問題8.3數(shù)據(jù)問題8.4數(shù)據(jù)問題防御8.5習(xí)題8.6本章小結(jié)8.2權(quán)限問題防御8.1權(quán)限問題8.1.1未授權(quán)訪問8.1.2水平越權(quán)8.1.3垂直越權(quán)8.1.4暴力破解登錄憑證8.1權(quán)限問題邏輯漏洞是由于Web開發(fā)者在Web應(yīng)用程序的設(shè)計與開發(fā)過程中未能充分考慮業(yè)務(wù)功能的邏輯關(guān)系而導(dǎo)致的安全問題。與技術(shù)型漏洞不同，邏輯漏洞并非由代碼錯誤實現(xiàn)引起，而是由Web開發(fā)者對Web應(yīng)用程序整體業(yè)務(wù)邏輯的理解和設(shè)計存在缺陷所致。邏輯漏洞與業(yè)務(wù)功能密切相關(guān)，在具有復(fù)雜業(yè)務(wù)功能的Web應(yīng)用程序中，開發(fā)者往往難以完全預(yù)見所有特殊場景，攻擊者可能利用這些特殊場景中的邏輯缺陷實施攻擊。邏輯漏洞依托于正常的業(yè)務(wù)功能，且不同業(yè)務(wù)場景下的邏輯漏洞表現(xiàn)形式各異，使得此類漏洞具有較強(qiáng)的隱蔽性，難以被完全地發(fā)現(xiàn)和修復(fù)。相較于SQL注入或命令執(zhí)行等在代碼層面具有明顯特征的漏洞，邏輯漏洞難以總結(jié)出一個通用的檢測方法和利用過程，也就導(dǎo)致常規(guī)的自動化漏洞掃描工具無法有效識別此類安全問題。此外，邏輯漏洞與業(yè)務(wù)功能緊密關(guān)聯(lián)，其危害往往更為嚴(yán)重。攻擊者能夠通過邏輯漏洞實現(xiàn)各種攻擊，包括但不限于：越權(quán)訪問賬戶或篡改訂單價格，造成直接經(jīng)濟(jì)損失；利用密碼重置漏洞，非法修改用戶密碼并竊取隱私信息；越權(quán)獲取管理員權(quán)限，危及系統(tǒng)整體安全。8.1權(quán)限問題權(quán)限控制是Web應(yīng)用程序的核心安全機(jī)制之一，Web應(yīng)用程序通常根據(jù)不同權(quán)限級別為用戶提供差異化的功能操作。例如，系統(tǒng)可能將用戶分為訪客、普通用戶、會員用戶和管理員等權(quán)限級別，每個權(quán)限級別具有不同的操作權(quán)限：訪客只能瀏覽內(nèi)容，普通用戶能夠進(jìn)行基礎(chǔ)交易，會員用戶享有特權(quán)服務(wù)，而管理員則能夠進(jìn)行系統(tǒng)管理。用戶可執(zhí)行的操作與其擁有的權(quán)限密不可分，嚴(yán)格的權(quán)限驗證機(jī)制是確保Web應(yīng)用程序有序、安全運行的關(guān)鍵。權(quán)限問題是邏輯漏洞中一類常見且嚴(yán)重的安全問題，直接影響Web應(yīng)用程序的訪問控制機(jī)制。權(quán)限問題主要包括未授權(quán)訪問、水平越權(quán)、垂直越權(quán)以及暴力破解用戶憑證等類型。其中，水平越權(quán)和垂直越權(quán)統(tǒng)稱為越權(quán)漏洞。8.1權(quán)限問題未授權(quán)訪問指用戶在未經(jīng)授權(quán)的情況下，能夠直接獲取原本需要授權(quán)才能獲取的資源或執(zhí)行受限的操作。這類問題通常源于Web應(yīng)用程序開發(fā)過程中未實施有效的身份驗證措施（例如密碼驗證、多因素認(rèn)證、OAuth令牌驗證和會話管理等），導(dǎo)致未經(jīng)授權(quán)的用戶能夠訪問原本無權(quán)訪問的內(nèi)容。因此，對于任何需要授權(quán)才能使用的業(yè)務(wù)功能，都可能存在未授權(quán)訪問的風(fēng)險。未授權(quán)訪問可以被分為兩類：組件類未授權(quán)訪問和Web應(yīng)用類未授權(quán)訪問。1.組件類未授權(quán)訪問在默認(rèn)配置下，許多基礎(chǔ)組件（例如Redis、MongoDB、Memcached等）通常不強(qiáng)制執(zhí)行身份驗證，這使得攻擊者無需授權(quán)即可直接執(zhí)行組件內(nèi)的操作。攻擊者通常將此類組件的未授權(quán)訪問與其他攻擊方法相結(jié)合，形成更為復(fù)雜和危險的攻擊鏈。例如，在本書第6章中，就以Redis為例介紹了Redis未授權(quán)訪問和SSRF漏洞的組合攻擊。以MongoDB未授權(quán)訪問漏洞為例，MongoDB是一種開源的文檔型數(shù)據(jù)庫。在默認(rèn)配置下，MongoDB通常不啟用身份驗證機(jī)制，這意味著任何能夠與MongoDB建立連接的用戶都可以執(zhí)行數(shù)據(jù)庫的讀寫操作，包括查詢、插入、修改和刪除等敏感操作。8.1.1未授權(quán)訪問8.1權(quán)限問題如圖所示，當(dāng)MongoDB運行在IP地址為04的27017端口時，使用數(shù)據(jù)庫管理工具Navicat嘗試連接MongoDB。在連接配置中，將“驗證”選項設(shè)置為“None”（表示不使用身份驗證），如果測試連接后返回“連接成功”的提示，則表明該MongoDB存在未授權(quán)訪問漏洞。8.1.1未授權(quán)訪問8.1權(quán)限問題2.Web應(yīng)用類未授權(quán)訪問Web應(yīng)用程序可能存在未授權(quán)的文件上傳或系統(tǒng)日志訪問的漏洞，由于認(rèn)證機(jī)制的缺失，本應(yīng)需要授權(quán)才能執(zhí)行的操作被攻擊者繞過登錄限制，進(jìn)而得以執(zhí)行。典型的例子包括Swagger未授權(quán)訪問、Druid未授權(quán)訪問和Solr未授權(quán)訪問等。以Swagger未授權(quán)訪問漏洞為例，Swagger是一個開源的API文檔生成工具，用于生成、描述、調(diào)用和可視化RESTful風(fēng)格的Web服務(wù)，它提供了交互式界面，便于開發(fā)者查看和測試API接口。如果Swagger以默認(rèn)配置啟動且未設(shè)置身份驗證，攻擊者就可能未授權(quán)訪問Swagger界面并查看API文檔，進(jìn)而執(zhí)行未授權(quán)的數(shù)據(jù)操作。8.1.1未授權(quán)訪問8.1權(quán)限問題如圖所示，在未設(shè)置身份驗證的情況下，攻擊者通過訪問index.html頁面就能夠查看完整的API文檔。8.1.1未授權(quán)訪問8.1權(quán)限問題Swagger界面的常用路徑如下：8.1.1未授權(quán)訪問/swagger-ui.html/swagger-ui//swagger-ui.json/swagger.json/docs//api/api-docs/api-docs/swagger.json/api/swagger/api/swagger-ui.html/api/swagger.json/api/v1/api-docs/api/v1/swagger-ui.html/api/v2/api-docs/api/v2/swagger-ui.html/doc.html/swagger-resources/swagger-resources/configuration/ui/swagger/v1/swagger.json/swagger/v2/swagger.json/swagger/static/index.html/swagger/ui/index8.1權(quán)限問題8.1.1未授權(quán)訪問8.1權(quán)限問題水平越權(quán)是指攻擊者能夠越過相同權(quán)限級別的權(quán)限限制，非法訪問與其具有相同權(quán)限級別的其他用戶資源。攻擊者的權(quán)限與受害用戶的權(quán)限始終處于同一權(quán)限級別，因此被稱為水平越權(quán)。假設(shè)用戶A只擁有訪問私有資源α的權(quán)限，用戶B只擁有訪問私有資源β的權(quán)限，兩個用戶的權(quán)限級別相同。如果Web應(yīng)用程序只校驗用戶的權(quán)限級別，而未驗證用戶是否具備訪問特定私有資源的權(quán)限，則可能導(dǎo)致用戶A越權(quán)訪問用戶B的私有資源β，這種行為即為水平越權(quán)。水平越權(quán)的示意圖如圖所示。8.1.2水平越權(quán)8.1權(quán)限問題以Windows7靶機(jī)中Pikachu靶場的OverPermission漏洞模塊為例，選擇其中的“水平越權(quán)”關(guān)卡，如圖所示。8.1.2水平越權(quán)8.1權(quán)限問題越權(quán)類漏洞通常需要先進(jìn)行用戶登錄。已知在Pikachu靶場中，存在三個具有相同權(quán)限級別的用戶，用戶名/密碼分別為：lucy/123456、lili/123456、kobe/123456。首先使用lucy用戶登錄，登錄成功后點擊“點擊查看個人信息”按鈕即可查看姓名、性別、手機(jī)號、住址和郵箱等個人信息，如圖所示。8.1.2水平越權(quán)8.1權(quán)限問題此時的URL如下：8.1.2水平越權(quán)01/pikachu/vul/overpermission/op1/op1_mem.php?username=lucy&submit=點擊查看個人信息注意到URL中的username參數(shù)傳遞了用戶名信息，嘗試將username參數(shù)值修改為其他用戶名，此處修改為lili，URL如下：01/pikachu/vul/overpermission/op1/op1_mem.php?username=lili&submit=點擊查看個人信息8.1權(quán)限問題提交修改后的URL，頁面顯示了lili用戶的個人信息，如圖所示，表明水平越權(quán)漏洞已被成功利用。8.1.2水平越權(quán)8.1權(quán)限問題以下是op1_mem.php的關(guān)鍵代碼：8.1.2水平越權(quán)$html='';if(isset($_GET['submit'])&&$_GET['username']!=null){//使用escape()函數(shù)對客戶端傳遞的username參數(shù)值進(jìn)行轉(zhuǎn)義，然后直接進(jìn)行數(shù)據(jù)庫查詢。此處權(quán)限校驗存在缺陷，應(yīng)使用session進(jìn)行身份驗證，與用戶登錄狀態(tài)建立關(guān)聯(lián)$username=escape($link,$_GET['username']);$query="select*frommemberwhereusername='$username'";$result=execute($link,$query);if(mysqli_num_rows($result)==1){//檢查是否存在對應(yīng)用戶名的記錄$data=mysqli_fetch_assoc($result);$uname=$data['username'];$sex=$data['sex'];$phonenum=$data['phonenum'];$add=$data['address'];$email=$data['email'];$html.=<<<EOF<divid="per_info"><h1class="per_title">hello,{$uname},你的具體信息如下：</h1><pclass="per_name">姓名:{$uname}</p><pclass="per_sex">性別:{$sex}</p><pclass="per_phone">手機(jī):{$phonenum}</p><pclass="per_add">住址:{$add}</p><pclass="per_email">郵箱:{$email}</p></div>EOF;}}8.1權(quán)限問題8.1.2水平越權(quán)8.1權(quán)限問題在上述示例代碼中，Web應(yīng)用程序在處理用戶信息請求時只檢驗客戶端傳遞的username參數(shù)值（即用戶名）是否存在于數(shù)據(jù)庫中，未對請求發(fā)起者進(jìn)行身份驗證或權(quán)限校驗。例如，未通過Session驗證當(dāng)前用戶對目標(biāo)信息的訪問權(quán)限，從而導(dǎo)致攻擊者能夠通過修改username參數(shù)值來實現(xiàn)水平越權(quán)訪問。8.1.2水平越權(quán)8.1權(quán)限問題垂直越權(quán)是指攻擊者能夠越過不同權(quán)限級別的權(quán)限限制，非法訪問其他權(quán)限級別的資源或執(zhí)行其他權(quán)限級別的操作。在此過程中，攻擊者的權(quán)限級別發(fā)生變化，因此被稱為垂直越權(quán)。垂直越權(quán)分為向上越權(quán)和向下越權(quán)兩種類型：向上越權(quán)是指低權(quán)限用戶越權(quán)訪問高權(quán)限用戶的資源或執(zhí)行高權(quán)限操作；向下越權(quán)是指高權(quán)限用戶訪問低權(quán)限用戶的資源（通常指對高權(quán)限用戶屏蔽的資源）。其中，向下越權(quán)的情況較為罕見，因此通常情況下垂直越權(quán)特指向上越權(quán)。8.1.3垂直越權(quán)垂直越權(quán)與水平越權(quán)恰好相反，其發(fā)生在不同權(quán)限級別之間，典型場景是普通用戶越權(quán)執(zhí)行管理員操作。例如，在Web應(yīng)用程序中，管理員具有發(fā)布文章、刪除文章和創(chuàng)建用戶等特權(quán)操作。如果系統(tǒng)后臺未對不同身份用戶實施嚴(yán)格的權(quán)限控制，或只在Web前端界面進(jìn)行簡單的權(quán)限驗證，可能導(dǎo)致普通用戶越權(quán)執(zhí)行管理員特權(quán)操作，這種行為即為垂直越權(quán)。垂直越權(quán)的示意圖如圖所示。8.1權(quán)限問題垂直越權(quán)的本質(zhì)是權(quán)限驗證機(jī)制的缺失或不完整。主要體現(xiàn)在系統(tǒng)未將功能訪問權(quán)限與用戶身份標(biāo)識（例如Cookie、Session、Token）進(jìn)行有效關(guān)聯(lián)和驗證。這類安全問題在實際開發(fā)過程中較為常見，多由開發(fā)階段忽略了權(quán)限控制邏輯或身份認(rèn)證方案不夠完善所引起。以Windows7靶機(jī)中Pikachu靶場的OverPermission漏洞模塊為例，選擇其中的“垂直越權(quán)”關(guān)卡，如圖所示。8.1.3垂直越權(quán)8.1權(quán)限問題已知在Pikachu靶場中，存在兩個具有不同權(quán)限級別的用戶，用戶名/密碼分別為：admin/123456（管理員用戶）和pikachu/000000（普通用戶）。普通用戶擁有查看用戶的權(quán)限，如圖所示。8.1.3垂直越權(quán)8.1權(quán)限問題管理員用戶不僅擁有查看用戶的權(quán)限，還具備刪除和添加用戶的權(quán)限，如圖所示。8.1.3垂直越權(quán)8.1權(quán)限問題使用admin用戶進(jìn)行登錄，然后點擊“添加用戶”，URL路徑變?yōu)椤?1/pikachu/vul/overpermission/op2/op2_admin_edit.php”，即用戶添加頁面，如圖所示。8.1.3垂直越權(quán)8.1權(quán)限問題接下來切換至pikachu用戶，并使用Chrome瀏覽器訪問以下URL：8.1.3垂直越權(quán)01/pikachu/vul/overpermission/op2/op2_admin_edit.php結(jié)果如圖所示，pikachu用戶成功訪問到后臺管理中心的用戶添加頁面。8.1權(quán)限問題當(dāng)pikachu用戶成功在該頁面添加新用戶foo后，用戶列表顯示更新內(nèi)容如圖所示，表明垂直越權(quán)漏洞已被成功利用。8.1.3垂直越權(quán)8.1權(quán)限問題以下是op2_admin_edit.php的關(guān)鍵代碼：8.1.3垂直越權(quán)$link=connect();//只驗證登錄狀態(tài)，未驗證用戶的權(quán)限級別if(!check_op2_login($link)){header("location:op2_login.php");exit();}if(isset($_POST['submit'])){if($_POST['username']!=null&$_POST['password']!=null){//用戶和密碼必填$getdata=escape($link,$_POST);//對POST請求參數(shù)值做轉(zhuǎn)義處理$query="insertintomember(username,pw,sex,phonenum,email,address)values('{$getdata['username']}',md5('{$getdata['password']}'),'{$getdata['sex']}','{$getdata['phonenum']}','{$getdata['email']}','{$getdata['address']}')";$result=execute($link,$query);if(mysqli_affected_rows($link)==1){//判斷是否插入成功header("location:op2_admin.php");}else{$html.="<p>修改失敗，請檢查下數(shù)據(jù)庫是不是還是活著的</p>";}}}8.1權(quán)限問題8.1.3垂直越權(quán)8.1權(quán)限問題當(dāng)訪問用戶添加頁面op2_admin_edit.php時，首先通過check_op2_login()函數(shù)判斷用戶是否登錄，如果通過登錄驗證，便可嘗試添加新用戶。其中，登錄驗證函數(shù)check_op2_login()的實現(xiàn)代碼如下：8.1.3垂直越權(quán)functioncheck_op2_login($link){if(isset($_SESSION['op2']['username'])&isset($_SESSION['op2']['password'])){$query="select*fromuserswhereusername='{$_SESSION['op2']['username']}'andsha1(password)='{$_SESSION['op2']['password']}'";$result=execute($link,$query);if(mysqli_num_rows($result)==1){returntrue;}else{returnfalse;}}else{returnfalse;}}8.1權(quán)限問題上述示例代碼通過檢查“$_SESSION['op2']['username']和$_SESSION['op2']['password']”以驗證用戶的登錄狀態(tài)，并且只檢查Session中的用戶名和密碼是否與數(shù)據(jù)庫中所存儲的用戶信息相匹配，缺乏對當(dāng)前用戶的權(quán)限級別校驗。這些安全缺陷使得用戶只需完成登錄，即可訪問和使用原本僅限管理員使用的功能，從而導(dǎo)致垂直越權(quán)漏洞的產(chǎn)生。8.1.3垂直越權(quán)8.1權(quán)限問題登錄憑證是系統(tǒng)進(jìn)行身份驗證的重要依據(jù)，用戶需要提供正確的登錄憑證才能獲取相應(yīng)的訪問權(quán)限。然而，攻擊者可能通過暴力破解手段獲取用戶的密碼，一旦破解成功，即可獲得對應(yīng)用戶的權(quán)限。暴力破解通過窮舉所有可能的組合以破解信息。在系統(tǒng)缺乏有效防護(hù)措施的情況下，理論上任何密碼最終都可以被破解，只是破解時間存在差異。8.1.4暴力破解登錄憑證本節(jié)以Windows7靶機(jī)中的Niushop開源商城為例，PHP版本選擇5.6.9，使用Chrome瀏覽器訪問系統(tǒng)后臺“01/practice8/niushop/index.php?s=/admin/login”。輸入用戶名“admin”和密碼“admin”，點擊“登錄”按鈕，同時使用BurpSuite攔截請求數(shù)據(jù)包，如圖所示。8.1權(quán)限問題隨后右擊，點擊“SendtoIntruder”選項以將攔截的請求數(shù)據(jù)包轉(zhuǎn)發(fā)至Intruder模塊，如圖所示。8.1.4暴力破解登錄憑證8.1權(quán)限問題在Intruder模塊中，選中“password”的參數(shù)值，然后點擊“Add§”按鈕以設(shè)置插入位置的payload，如圖所示。8.1.4暴力破解登錄憑證8.1權(quán)限問題單擊Payloads選項卡，Payloadtype選擇為Simplelist，單擊Loaditemsfromfile按鈕以導(dǎo)入弱密碼字典，最后單擊Startattack按鈕。Payloads選項卡的相關(guān)設(shè)置如圖所示。8.1.4暴力破解登錄憑證8.1權(quán)限問題此時，BurpSuite就會利用Intruder模塊對admin用戶的密碼進(jìn)行暴力破解，如圖所示。當(dāng)密碼為123456時，響應(yīng)數(shù)據(jù)包中出現(xiàn)“操作成功”的關(guān)鍵詞，響應(yīng)數(shù)據(jù)包長度為522字節(jié)；而當(dāng)密碼不是123456時，響應(yīng)數(shù)據(jù)包中出現(xiàn)“用戶名或者密碼錯誤”的關(guān)鍵詞，響應(yīng)數(shù)據(jù)包長度為450字節(jié)。因此，攻擊者根據(jù)響應(yīng)數(shù)據(jù)包中出現(xiàn)的關(guān)鍵詞和響應(yīng)數(shù)據(jù)包長度即可判斷admin用戶的正確密碼為123456。憑借該密碼，攻擊者可以登錄系統(tǒng)后臺，獲取admin用戶的相關(guān)權(quán)限。8.1.4暴力破解登錄憑證8.1權(quán)限問題暴力破解通常以弱密碼為主要目標(biāo)，弱密碼在一定程度上反映了用戶貪圖便捷性而忽視了賬戶的安全性。根據(jù)密碼安全公司NordPass發(fā)布的2024年全球最常用密碼統(tǒng)計榜單，排名前十的弱密碼如圖所示，其中“123456”以使用頻次超過300萬次位居榜首，破解所需時間小于1秒。8.1.4暴力破解登錄憑證8.1權(quán)限問題系統(tǒng)可采取以下措施防范暴力破解：（1）強(qiáng)制使用強(qiáng)密碼：通常建議密碼長度至少為8位，并至少包含大寫字母、小寫字母、數(shù)字和特殊符號中的三種。（2）部署額外的驗證機(jī)制：引入圖形驗證碼、多因素認(rèn)證或其他形式的用戶驗證機(jī)制以提高攻擊者的暴力破解難度。（3）實施登錄限制：設(shè)置密碼錯誤次數(shù)閾值，超過閾值則臨時鎖定賬戶。在正常情況下，用戶登錄的失敗次數(shù)不會超過一個合理范圍，頻繁的登錄失敗可能預(yù)示暴力破解攻擊。此時，系統(tǒng)可臨時鎖定賬戶，在指定時間內(nèi)禁止該賬戶登錄。該措施適用于電子商務(wù)、網(wǎng)上銀行等安全要求較高的場景。8.1.4暴力破解登錄憑證8.1權(quán)限問題鎖定賬戶措施在某些情況下也可能被攻擊者惡意利用。以某在線拍賣平臺為例，該平臺對用戶登錄實施以下措施：當(dāng)密碼連續(xù)輸錯5次，系統(tǒng)將鎖定賬戶24小時，在此期間不允許該用戶登錄。設(shè)想在一次競價活動中，攻擊者通過某種手段獲取競爭對手用戶ID，故意觸發(fā)其賬戶的鎖定機(jī)制，導(dǎo)致對方無法在關(guān)鍵時刻參與競價，從而以較低價格獲得商品。這個案例揭示了兩個關(guān)鍵問題：一是用戶ID的保密性至關(guān)重要；二是過強(qiáng)的安全措施可能被轉(zhuǎn)化為攻擊手段。因此，安全措施的制定不僅要考慮防護(hù)效果，還需兼顧業(yè)務(wù)功能的可用性，在安全性和可用性之間找到適當(dāng)?shù)钠胶恻c。8.1.4暴力破解登錄憑證8.2權(quán)限問題防御針對邏輯漏洞中的權(quán)限問題，可以參考以下防御措施。（1）明確最小權(quán)限原則：根據(jù)用戶的工作職責(zé)或系統(tǒng)服務(wù)的功能需求，嚴(yán)格分配必要的最小權(quán)限集合，防止權(quán)限過度授予導(dǎo)致的安全隱患。（2）構(gòu)建精細(xì)化的訪問控制機(jī)制：創(chuàng)建訪問控制列表（AccessControlList，ACL），并結(jié)合基于角色的訪問控制（Role-BasedAccessControl，RBAC）或基于屬性的訪問控制（Attribute-BasedAccessControl，ABAC）等高級策略。通過詳細(xì)的訪問規(guī)則和動態(tài)權(quán)限管理，精確規(guī)定用戶可訪問的系統(tǒng)資源及可執(zhí)行的操作，確保權(quán)限分配的準(zhǔn)確性和靈活性。（3）實施統(tǒng)一身份認(rèn)證和授權(quán)：集成統(tǒng)一的身份認(rèn)證系統(tǒng)，確保用戶在系統(tǒng)內(nèi)的身份驗證過程一致，并根據(jù)用戶的身份信息進(jìn)行精確授權(quán)。這有助于避免在系統(tǒng)的不同部分使用不同的身份驗證和授權(quán)機(jī)制，降低了維護(hù)的復(fù)雜性，提高了系統(tǒng)整體的安全性。8.2權(quán)限問題防御（4）實施多因素認(rèn)證：對于敏感操作需多次驗證用戶身份，可以通過短信驗證碼、郵箱確認(rèn)或一次性密碼（OneTimePassword，OTP）等方式，建立多重身份驗證屏障。（5）嚴(yán)格管控參數(shù)傳遞：將用戶身份驗證信息和關(guān)鍵權(quán)限參數(shù)（例如用戶角色、權(quán)限標(biāo)識等）統(tǒng)一存儲于服務(wù)端Session中。在進(jìn)行權(quán)限驗證時直接讀取服務(wù)端Session，而不是依賴客戶端傳遞的參數(shù)值，這樣可以有效防止攻擊者通過篡改客戶端參數(shù)實施越權(quán)訪問。8.3數(shù)據(jù)問題8.3.1整數(shù)溢出8.3.2精度問題8.3.3負(fù)數(shù)問題8.3.4優(yōu)惠券問題8.3.5用戶數(shù)據(jù)泄露8.3數(shù)據(jù)問題Web應(yīng)用程序的運行離不開數(shù)據(jù)。在現(xiàn)實應(yīng)用中，如商城的用戶余額、銀行交易記錄、社交媒體的個人信息等核心業(yè)務(wù)場景都需要嚴(yán)格的數(shù)據(jù)管理。在Web安全中，相當(dāng)一部分邏輯漏洞都與數(shù)據(jù)錯誤處理相關(guān)，這類漏洞通常不是源于代碼實現(xiàn)層面的技術(shù)缺陷，而是由于業(yè)務(wù)邏輯層面缺乏適當(dāng)?shù)呐袛嗪吞幚?。攻擊者可能利用這些邏輯漏洞非法獲取、篡改或濫用關(guān)鍵數(shù)據(jù)，從而對系統(tǒng)和用戶帶來不可預(yù)測的安全風(fēng)險。8.3數(shù)據(jù)問題整數(shù)溢出是指當(dāng)Web應(yīng)用程序進(jìn)行整數(shù)運算時，如果運算結(jié)果超出了特定整數(shù)類型的取值范圍，就會發(fā)生整數(shù)溢出現(xiàn)象。以C/C++語言為例，32位有符號整型變量的取值范圍為-231~231-1，即-2147483648~2147483647，當(dāng)整型變量取值小于-2147483648或者大于2147483647時就會發(fā)生整數(shù)溢出，導(dǎo)致變量值回繞到取值范圍的另一端。如圖所示，當(dāng)整型變量取值為2147483648時，由于超出最大值范圍，整數(shù)溢出會導(dǎo)致結(jié)果變?yōu)樽钚≌麛?shù)值-2147483648。8.3.1整數(shù)溢出8.3數(shù)據(jù)問題各種編程語言的數(shù)值類型都存在取值范圍。如果Web開發(fā)者在實現(xiàn)業(yè)務(wù)功能時未充分考慮這些限制，且未對數(shù)值計算結(jié)果進(jìn)行有效驗證，就可能引發(fā)整數(shù)溢出漏洞。這類漏洞的典型危害之一是攻擊者可能以低成本（甚至零成本）購買金額巨大的商品。例如，當(dāng)攻擊者嘗試購買21474837件單價為100元的商品時，正常情況下總價應(yīng)為2147483700元。然而，如果Web開發(fā)者未根據(jù)總價的變量類型進(jìn)行邊界檢查，服務(wù)端可能因整數(shù)溢出而得出-2147483596元的錯誤總價。如圖所示，某商城以美元為單位展示商品價格，但在服務(wù)端實際以美分為單位進(jìn)行存儲（1美元=100美分）。例如，某商品價格為1337美元，則服務(wù)端實際存儲的數(shù)值為133700。8.3.1整數(shù)溢出8.3數(shù)據(jù)問題8.3.1整數(shù)溢出當(dāng)購買16061件單價為1337美元的商品時，總價為2147355700美分，如圖所示。8.3數(shù)據(jù)問題8.3.1整數(shù)溢出當(dāng)購買16062件商品時，系統(tǒng)顯示的總價卻變?yōu)椤?$21474778.96”，即-2147477896美分，顯然此處存在整數(shù)溢出漏洞。正確的總價計算過程應(yīng)為：16062×133700=2147489400（美分），但由于該商城未實現(xiàn)數(shù)值溢出檢測和異常處理機(jī)制，導(dǎo)致總價顯示為錯誤的負(fù)值，如圖所示。8.3數(shù)據(jù)問題8.3.1整數(shù)溢出該漏洞可以在BurpSuite官方在線靶場的“Lab:Low-levellogicflaw”實驗中完成復(fù)現(xiàn)，同學(xué)們可自行探索。在Web應(yīng)用程序中，當(dāng)整數(shù)計算結(jié)果超出可表示的最大正整數(shù)值時，數(shù)值會自動回繞至最小負(fù)整數(shù)繼續(xù)計算。在實際開發(fā)中，Web開發(fā)者通常會在交易支付環(huán)節(jié)實現(xiàn)嚴(yán)格的數(shù)值驗證，以避免出現(xiàn)負(fù)數(shù)交易金額。然而，某些Web應(yīng)用程序也存在最大正整數(shù)溢出后從0開始計數(shù)的情況，例如，2147483648溢出為0，2147483649溢出為1。8.3數(shù)據(jù)問題8.3.2精度問題在許多業(yè)務(wù)場景尤其是涉及交易支付的場景中，對數(shù)據(jù)精度的準(zhǔn)確處理至關(guān)重要，不一致的數(shù)據(jù)精度處理可能導(dǎo)致嚴(yán)重的安全問題。以下是常見的數(shù)據(jù)精度處理方法。（1）四舍五入：通過四舍五入的方式，將數(shù)據(jù)精度調(diào)整到指定的小數(shù)位數(shù)。例如，將0.6四舍五入到整數(shù)位得到1；將0.66四舍五入到一位小數(shù)得到0.7。（2）向上/向下取整：向上取整時，對于非整數(shù)，保留整數(shù)部分并加1（例如1.1變?yōu)?）；對于整數(shù)則保持不變（例如5仍為5）。向下取整時只保留整數(shù)部分（例如1.9變?yōu)?）。這種處理方式常用于商品數(shù)量、人數(shù)等不可分割的整數(shù)單位。（3）截斷：將數(shù)據(jù)截斷至特定的小數(shù)位數(shù)，忽略后續(xù)小數(shù)部分。例如，將1.66截斷至一位小數(shù)得到1.6。8.3數(shù)據(jù)問題8.3.2精度問題下面通過兩個典型案例進(jìn)一步闡述精度問題。1.系統(tǒng)和第三方支付平臺的精度處理方法不一致以交易支付為例，主流第三方支付平臺（例如微信和支付寶）只支持精確到分的金額。假設(shè)用戶在某系統(tǒng)充值1.005元（假設(shè)該系統(tǒng)允許輸入此精度的金額），由于第三方支付平臺采用截斷處理，實際支付金額為1.00元。然而，如果該系統(tǒng)充值時采取四舍五入的方式保留兩位小數(shù)，則會將1.005元四舍五入為1.01元。這就導(dǎo)致在用戶實際支付1.00元后，系統(tǒng)卻記錄了1.01元的充值金額，造成了0.01元的差額。在此案例中，系統(tǒng)和第三方支付平臺采用了不同的精度處理方式：系統(tǒng)采用四舍五入的方式處理數(shù)據(jù)精度，而第三方支付平臺采用截斷的方式處理數(shù)據(jù)精度，兩者在數(shù)據(jù)精度處理上的不一致導(dǎo)致了邏輯漏洞的產(chǎn)生。雖然攻擊者在本例中單次利用只能獲取0.01元的差額，但攻擊者能夠通過自動化程序批量進(jìn)行大量重復(fù)操作，最終可能累積成顯著的經(jīng)濟(jì)損失。這類邏輯漏洞不僅存在于充值場景，在提現(xiàn)、轉(zhuǎn)賬等場景同樣有可能出現(xiàn)。8.3數(shù)據(jù)問題8.3.2精度問題2.商品數(shù)量的精度問題商品數(shù)量的精度處理同樣是一個值得關(guān)注的安全問題，此處以Windows7靶機(jī)中的Verydows開源電商系統(tǒng)為例，PHP版本選擇7.0.9，使用Chrome瀏覽器訪問“01/practice8/verydows/index.php?c=goods&a=index&id=1”。商城通常在商品詳情頁面提供如左圖所示的控件供用戶選擇商品數(shù)量，大多數(shù)Web開發(fā)者和用戶都默認(rèn)商品數(shù)量為整數(shù)。此外，許多Web開發(fā)者會在Web前端使用JavaScript腳本限制商品數(shù)量為整數(shù)，如右圖所示。8.3數(shù)據(jù)問題8.3.2精度問題然而，Web前端限制往往是不可靠的，攻擊者可以通過攔截、修改請求數(shù)據(jù)包的方式輕松繞過Web前端商品數(shù)量檢測。以購買“手機(jī)”商品為例，在Web前端頁面將購買數(shù)量設(shè)定為“1”并點擊“立即購買”，同時使用BurpSuite攔截請求數(shù)據(jù)包。當(dāng)攔截到URL為“01/practice8/verydows/index.php?m=api&c=cart&a=list”的請求數(shù)據(jù)包時，觀察到商品數(shù)量被記錄在Cookie字段的CARTS參數(shù)中。通過對CARTS參數(shù)值進(jìn)行URL解碼（選中CARTS參數(shù)值，然后使用快捷鍵Ctrl+Shift+U即可進(jìn)行URL解碼），定位到代表商品數(shù)量的“qty”字段，并將該字段值從整數(shù)1修改為小數(shù)1.5，最終發(fā)送修改后的請求數(shù)據(jù)包，如圖所示。8.3數(shù)據(jù)問題8.3.2精度問題購物車中手機(jī)的數(shù)量被成功修改為1.5，按照“商品單價×購買數(shù)量”的計算邏輯，該訂單總價為7500元，如圖所示。8.3數(shù)據(jù)問題8.3.2精度問題點擊“去結(jié)算”按鈕并完成“填寫訂單”操作，當(dāng)點擊“確認(rèn)并提交訂單”按鈕完成支付時，商城最終生成的訂單如右圖所示。該訂單顯示商品數(shù)量為2，這表明商城在處理數(shù)據(jù)精度時采用了向上取整的處理方法，將小數(shù)1.5調(diào)整為整數(shù)2。對攻擊者而言，只花費7500元就能購買到總價值為10000元的2件商品，表明該商城存在邏輯漏洞。綜上所述，應(yīng)確保系統(tǒng)內(nèi)部各模塊、第三方支付平臺和前后端采用統(tǒng)一的數(shù)據(jù)精度處理方式，避免因處理方式不一致而產(chǎn)生安全漏洞。尤其在涉及金錢交易的相關(guān)業(yè)務(wù)中，即使是細(xì)微的數(shù)據(jù)處理差異也可能被攻擊者惡意利用，從而對系統(tǒng)和用戶造成實質(zhì)性的損失。因此，建立并嚴(yán)格執(zhí)行統(tǒng)一的數(shù)據(jù)處理規(guī)范，是增強(qiáng)系統(tǒng)安全性、可靠性和一致性的關(guān)鍵策略。8.3數(shù)據(jù)問題8.3.3負(fù)數(shù)問題早期網(wǎng)上商城系統(tǒng)中曾出現(xiàn)一個典型的邏輯漏洞：當(dāng)支付金額為負(fù)值時，由于驗證不嚴(yán)格，可能導(dǎo)致支付成功的同時用戶余額增加而非減少。具體來說，早期的網(wǎng)上商城沒有對商品單價和購買數(shù)量進(jìn)行負(fù)數(shù)檢驗，攻擊者能夠通過修改請求數(shù)據(jù)包，將商品的單價或者購買數(shù)量修改為負(fù)數(shù)，按照“商品單價×購買數(shù)量=商品總價”的計算邏輯，最終的支付金額也將是負(fù)數(shù)。如果這種異常支付被成功執(zhí)行，可能導(dǎo)致用戶余額不減反增。此處以Windows7靶機(jī)中的大米CMS為例，PHP版本選擇5.6.9，使用Chrome瀏覽器訪問“01/practice8/damicms/index.php”。8.3數(shù)據(jù)問題8.3.3負(fù)數(shù)問題在“公司產(chǎn)品”欄目中選擇“大米CMS手機(jī)開發(fā)專版”，商品購買頁面如圖所示，在“數(shù)量”文本框中填入-1，然后點擊“立即購買”按鈕填寫訂單。8.3數(shù)據(jù)問題8.3.3負(fù)數(shù)問題訂單列表如右上圖所示，訂單數(shù)量為-1，單價為5400元，價格合計為-5400元。付款方式選擇“站內(nèi)扣款”，完善送貨地址后，點擊“提交訂單”按鈕，在用戶余額為0的情況下完成了此次交易。點擊“查看我的訂單”按鈕，訂單詳情如右中圖所示，狀態(tài)顯示為“已付款，等待發(fā)貨”。訪問用戶中心的“在線充值”功能并選擇“我要提現(xiàn)”選項，可以觀察到用戶余額異常增加了5400元，如右下圖所示。更為嚴(yán)重的是，攻擊者能夠利用商城的提現(xiàn)功能，將這筆異常增加的資金提現(xiàn)出來，從而對商城造成嚴(yán)重的經(jīng)濟(jì)損失。8.3數(shù)據(jù)問題8.3.3負(fù)數(shù)問題分析該案例可知，攻擊者在未支付任何費用的情況下，不僅成功下單價值5400元的商品，還導(dǎo)致用戶余額異常增加5400元，表明該商城存在邏輯漏洞。該漏洞的產(chǎn)生過程可總結(jié)為以下3個階段：（1）商品總價計算階段：系統(tǒng)未對商品數(shù)量進(jìn)行負(fù)數(shù)校驗，而是直接按照計算式：5400×(-1)=-5400計算商品總價。（2）支付驗證階段：系統(tǒng)只進(jìn)行簡單的余額充足性驗證（用戶余額≥商品總價），即0≥-5400，導(dǎo)致異常訂單通過驗證。（3）余額扣減階段：系統(tǒng)采用“用戶余額-訂單價格”的計算邏輯，計算式為：0-(-5400)=5400，由于訂單價格為負(fù)數(shù)，導(dǎo)致用戶余額增加5400元。類似的負(fù)數(shù)問題同樣存在于系統(tǒng)積分計算、商品服務(wù)費計算、商品運費計算等其他場景。為防范此類邏輯漏洞，開發(fā)Web系統(tǒng)時應(yīng)當(dāng)對所有涉及數(shù)值計算的關(guān)鍵操作實施嚴(yán)格的正負(fù)值校驗，并考慮使用絕對值函數(shù)（例如abs()函數(shù)）等安全的數(shù)學(xué)運算方法處理相關(guān)數(shù)據(jù)。8.3數(shù)據(jù)問題8.3.4優(yōu)惠券問題在網(wǎng)上商城系統(tǒng)中，優(yōu)惠券作為一種營銷工具被廣泛使用。然而，優(yōu)惠券也可能導(dǎo)致一系列邏輯漏洞。優(yōu)惠券的功能實現(xiàn)主要包含以下3個核心機(jī)制。（1）優(yōu)惠券的基本設(shè)計：系統(tǒng)通常采用專門的生成算法創(chuàng)建優(yōu)惠券碼，這些算法可能包括隨機(jī)字符組合、哈希函數(shù)或其他更復(fù)雜的計算方法，以確保優(yōu)惠券碼具有唯一性和不可預(yù)測性。（2）優(yōu)惠券的生成時機(jī)：系統(tǒng)通常支持批量預(yù)生成和實時動態(tài)生成兩種生成模式，以允許商家根據(jù)營銷活動的變化快速調(diào)整優(yōu)惠券的發(fā)放。系統(tǒng)在數(shù)據(jù)庫中會完整記錄每張優(yōu)惠券的屬性信息，包括但不限于優(yōu)惠券類型、折扣金額、使用狀態(tài)、最低消費限額、有效期限等關(guān)鍵參數(shù)。（3）優(yōu)惠券的使用流程：系統(tǒng)會在用戶使用優(yōu)惠券時檢索數(shù)據(jù)庫中的相關(guān)信息，并據(jù)此計算出優(yōu)惠后商品的實際價格。交易完成后，系統(tǒng)會更新優(yōu)惠券的狀態(tài)為已使用，以防止優(yōu)惠券被重復(fù)使用。然而，在實際應(yīng)用中優(yōu)惠券的使用可能導(dǎo)致多種安全問題。本節(jié)以Windows7靶機(jī)中的Niushop開源商城為例，PHP版本選擇5.6.9，使用Chrome瀏覽器訪問“01/practice8/niushop/index.php”。8.3數(shù)據(jù)問題8.3.4優(yōu)惠券問題1.優(yōu)惠券遍歷使用優(yōu)惠券遍歷使用是指攻擊者通過遍歷優(yōu)惠券的標(biāo)識信息（例如優(yōu)惠券碼或優(yōu)惠券ID），非法獲取和使用其他用戶的優(yōu)惠券。在這種情況下，優(yōu)惠券通常并未與特定用戶或條件進(jìn)行綁定，因此攻擊者能夠非法使用未經(jīng)授權(quán)的優(yōu)惠券，從而獲取不當(dāng)優(yōu)惠。以Niushop商城為例，該商城向用戶發(fā)放面值200元的優(yōu)惠券，并限制每位用戶只能領(lǐng)取一次。當(dāng)攻擊者在“領(lǐng)券中心”領(lǐng)取200元優(yōu)惠券后，可以在購買“手機(jī)A”時使用該優(yōu)惠券，如圖所示。8.3數(shù)據(jù)問題8.3.4優(yōu)惠券問題當(dāng)攻擊者單擊“提交訂單”按鈕時，使用BurpSuite攔截請求數(shù)據(jù)包可以發(fā)現(xiàn)，請求數(shù)據(jù)包中包含use_coupon參數(shù)，如圖所示。攻擊者根據(jù)經(jīng)驗推測，該參數(shù)值很可能是優(yōu)惠券ID。8.3數(shù)據(jù)問題8.3.4優(yōu)惠券問題隨后右擊，點擊SendtoIntruder選項將捕獲的請求數(shù)據(jù)包轉(zhuǎn)發(fā)至Intruder模塊，如圖所示。8.3數(shù)據(jù)問題8.3.4優(yōu)惠券問題在Intruder模塊中，選中“use_coupon”的參數(shù)值，然后點擊“Add§”按鈕以設(shè)置payload的插入位置，如圖所示。8.3數(shù)據(jù)問題8.3.4優(yōu)惠券問題點擊Payloads選項卡，Payloadtype選擇為“Numbers”，F(xiàn)rom文本框中輸入“1001”，To文本框中輸入“1100”，Step文本框中輸入“1”，最后單擊“Startattack”按鈕，Payloads選項卡的相關(guān)設(shè)置如圖所示。8.3數(shù)據(jù)問題8.3.4優(yōu)惠券問題此時BurpSuite對use_coupon參數(shù)進(jìn)行自動化遍歷測試，例如，依次嘗試use_coupon=1001、use_coupon=1002、use_coupon=1003等參數(shù)值，如圖所示。8.3數(shù)據(jù)問題8.3.4優(yōu)惠券問題通過這種方式，攻擊者成功使用多張不同優(yōu)惠券創(chuàng)建訂單，如圖所示。8.3數(shù)據(jù)問題8.3.4優(yōu)惠券問題2.優(yōu)惠券重復(fù)使用優(yōu)惠券重復(fù)使用是一個典型的業(yè)務(wù)安全問題。當(dāng)系統(tǒng)只在Web前端界面隱藏已使用的優(yōu)惠券，而未在后端數(shù)據(jù)庫更新優(yōu)惠券使用狀態(tài)時，攻擊者一旦獲取優(yōu)惠券的標(biāo)識信息（例如優(yōu)惠券碼或優(yōu)惠券ID），就可能繞過Web前端限制重復(fù)使用同一張優(yōu)惠券，從而給商家?guī)碇苯咏?jīng)濟(jì)損失。以Niushop商城為例，該商城在某次活動中向用戶發(fā)放面值200元的優(yōu)惠券，并限制每個用戶只能領(lǐng)取一次。當(dāng)攻擊者從“領(lǐng)券中心”領(lǐng)取200元優(yōu)惠券后，在購買“手機(jī)A”過程中使用該優(yōu)惠券。通過BurpSuite攔截提交訂單時的請求數(shù)據(jù)包可以發(fā)現(xiàn)，請求數(shù)據(jù)包中包含use_coupon參數(shù)，如圖所示。攻擊者根據(jù)經(jīng)驗推測，該參數(shù)值很可能是優(yōu)惠券ID。8.3數(shù)據(jù)問題8.3.4優(yōu)惠券問題攻擊者在后續(xù)購買其他商品時，通過修改請求中的優(yōu)惠券ID為1001，使所有訂單都引用同一張優(yōu)惠券。如左圖所示，所有的訂單都獲得了200元的優(yōu)惠，表明此處存在優(yōu)惠券重復(fù)使用問題。通過查詢數(shù)據(jù)庫中的相關(guān)訂單信息，可以確定不同訂單都使用了同一張優(yōu)惠券，如右圖所示，進(jìn)一步證實了優(yōu)惠券在不同訂單中被重復(fù)使用的問題。為防范優(yōu)惠券重復(fù)使用漏洞，開發(fā)Web系統(tǒng)時不能只依賴前端的優(yōu)惠券狀態(tài)管理，更需要在后端實現(xiàn)嚴(yán)格的優(yōu)惠券狀態(tài)追蹤和驗證機(jī)制，確保每張優(yōu)惠券只能被使用一次。8.3數(shù)據(jù)問題8.3.4優(yōu)惠券問題3.滿額減優(yōu)惠券滿額減類型的優(yōu)惠券設(shè)有最低訂單金額門檻，例如，滿100元減10元。盡管商城前端界面通常會禁止用戶選擇不滿足條件的優(yōu)惠券，但如果后端驗證機(jī)制不完善，攻擊者能夠通過修改請求數(shù)據(jù)包的方式篡改請求參數(shù)以繞過限制。例如，假設(shè)攻擊者擁有兩張滿額減優(yōu)惠券：一張ID為1的滿100元減10元優(yōu)惠券和一張ID為2的滿200元減30元優(yōu)惠券。當(dāng)攻擊者購買價值150元的商品時，系統(tǒng)默認(rèn)選用滿100元減10元的優(yōu)惠券。然而，攻擊者能夠在提交訂單時攔截、修改請求數(shù)據(jù)包，將優(yōu)惠券ID從1修改為2，最終以120元的價格成功購買150元的商品。此時，攻擊者在總價不滿200元的情況下依舊使用了滿200元減30的優(yōu)惠券。4.新用戶優(yōu)惠的濫用針對新用戶的優(yōu)惠活動（例如，新用戶注冊送100元無門檻優(yōu)惠券）往往成為攻擊目標(biāo)。攻擊者通過自動化方式提前批量注冊賬戶并“養(yǎng)號”（即維持一定的活躍度），等到優(yōu)惠活動開始時，利用腳本快速領(lǐng)取大量優(yōu)惠券。隨后，他們可能將這些非法獲取的優(yōu)惠券轉(zhuǎn)移到“黑市”，通過各種渠道變現(xiàn)，從中牟取不當(dāng)利益。8.3數(shù)據(jù)問題8.3.4優(yōu)惠券問題5.退貨退款中的優(yōu)惠券問題退貨退款場景中同樣存在優(yōu)惠券相關(guān)的漏洞風(fēng)險。例如，某商城發(fā)放了滿100元減20元的優(yōu)惠券，當(dāng)用戶使用該優(yōu)惠券購買商品后申請退貨退款，假定商城存在邏輯缺陷，錯誤地返還一張無門檻的20元優(yōu)惠券，這使得攻擊者能夠利用商城返還的優(yōu)惠券購買21元的商品。在此過程中，攻擊者只需支付1元就獲得了原價21元的商品。綜上所述，以上安全隱患的核心在于系統(tǒng)對優(yōu)惠券使用規(guī)則的驗證存在漏洞，缺乏全面且嚴(yán)格的管控措施，這不僅造成了商城和商家的直接經(jīng)濟(jì)損失，還損害了正常用戶的權(quán)益和使用體驗。8.3數(shù)據(jù)問題8.3.5用戶數(shù)據(jù)泄露前文討論的數(shù)據(jù)問題主要圍繞支付安全部分，本節(jié)將重點探討用戶數(shù)據(jù)泄露相關(guān)的邏輯漏洞。1.越權(quán)訪問導(dǎo)致的數(shù)據(jù)泄露在用戶信息查詢功能中，部分系統(tǒng)會依賴客戶端傳遞的參數(shù)（例如用戶ID）以獲取對應(yīng)的用戶信息。如果系統(tǒng)未能有效驗證請求者身份與所查詢信息的關(guān)聯(lián)性，就會產(chǎn)生越權(quán)漏洞。攻擊者能夠通過遍歷相關(guān)參數(shù)，越權(quán)訪問并獲取其他用戶的敏感數(shù)據(jù)。此類問題通常出現(xiàn)在用戶資料查看、收貨地址管理、訂單信息查詢、簡歷展示等功能模塊。此處以Windows7靶機(jī)中的TinyShop為例，PHP版本選擇5.2.17，使用Chrome瀏覽器訪問“01/practice8/tinyshop/index.php”。8.3數(shù)據(jù)問題8.3.5用戶數(shù)據(jù)泄露首先注冊并登錄系統(tǒng)，依次單擊“我的商城”、“收貨地址”，然后點擊“添加新地址”按鈕完成地址添加，如圖所示。8.3數(shù)據(jù)問題8.3.5用戶數(shù)據(jù)泄露隨后，在點擊收貨地址中的“修改”時，使用BurpSuite攔截請求數(shù)據(jù)包。當(dāng)攔截到URL為“01/practice8/tinyshop/index.php?con=simple&act=address_other&id=2”的請求數(shù)據(jù)包時，注意到請求數(shù)據(jù)包中包含id參數(shù)，如圖所示，攻擊者根據(jù)經(jīng)驗推測，該參數(shù)值很可能是用戶ID。8.3數(shù)據(jù)問題8.3.5用戶數(shù)據(jù)泄露使用Chrome瀏覽器訪問“01/practice8/tinyshop/index.php?con=simple&act=address_other&id=2”，如左圖所示，成功獲取id為2的用戶收貨地址信息。嘗試對id參數(shù)進(jìn)行遍歷，訪問“01/practice8/tinyshop/index.php?con=simple&act=address_other&id=1”，如右圖所示，成功獲取id為1的用戶收貨地址信息。由此可見，系統(tǒng)未對用戶訪問權(quán)限進(jìn)行有效控制，攻擊者只需遍歷URL中的id參數(shù)，即可非法獲取其他用戶的姓名、手機(jī)號碼、詳細(xì)地址等隱私數(shù)據(jù)。8.3數(shù)據(jù)問題8.3.5用戶數(shù)據(jù)泄露2.服務(wù)端響應(yīng)差異性導(dǎo)致的數(shù)據(jù)泄露服務(wù)端響應(yīng)差異性可能間接造成用戶數(shù)據(jù)泄露，這種情況多發(fā)生在登錄、注冊及密碼找回等功能中。例如在用戶登錄場景中，系統(tǒng)可能返回“用戶名不存在”或“密碼錯誤”等信息，前者提示攻擊者當(dāng)前輸入的用戶名并不存在，后者則提示攻擊者當(dāng)前用戶名存在但密碼不正確。攻擊者可據(jù)此判斷用戶名的有效性，并通過系統(tǒng)性的遍歷收集已存在的用戶名列表，從而導(dǎo)致用戶數(shù)據(jù)的泄露。如右上圖所示，服務(wù)端回顯“沒有此賬號”，表明當(dāng)前系統(tǒng)中不存在admin用戶。反之如右下圖所示，服務(wù)端回顯“密碼錯誤”，表明當(dāng)前系統(tǒng)中存在sys用戶。如果系統(tǒng)缺乏針對暴力破解登錄憑證的相關(guān)防御措施，攻擊者就能夠利用已獲取的用戶名列表暴力破解相應(yīng)的登錄密碼，進(jìn)一步威脅賬戶安全。為防范此類漏洞，應(yīng)建立統(tǒng)一的錯誤提示機(jī)制，對登錄失敗情況都返回“用戶名或密碼錯誤”的模糊提示。此外，為防范攻擊者進(jìn)行登錄憑證暴力破解，系統(tǒng)還應(yīng)該引入驗證碼等安全機(jī)制。8.3數(shù)據(jù)問題8.3.5用戶數(shù)據(jù)泄露3.過度數(shù)據(jù)暴露導(dǎo)致的數(shù)據(jù)泄露在Web應(yīng)用程序開發(fā)過程中，開發(fā)人員可能由于以下原因在API接口中返回過度數(shù)據(jù)。（1）為提高接口復(fù)用性而設(shè)計通用接口。（2）為減少前后端交互次數(shù)以提升性能。然而，這種做法往往導(dǎo)致API接口返回超出客戶端實際需要的信息，這些信息中可能包含敏感信息。假設(shè)有一個用戶信息查詢