網安教育

培養(yǎng)網絡安全人才

技術交流、學習咨詢

業(yè)務邏輯篡改

密碼修改/重置流程跨越

漏洞描述

密碼修改功能常采用分步驟方式來實現(xiàn)，攻擊者在未知原始密碼的情況下繞過某些檢驗步驟修改用戶密碼。

測試方法：

完成修改／重置密碼的正常流程；

繞過檢驗原密碼等步驟，直接訪問輸入新密碼頁面，輸入新密碼，修改／重置密碼。

風險分析：

有些密碼修改／重置流程采用step=1、step=2類似的方式實現(xiàn)，如果應用校驗不全面，

攻擊者可繞過前面的步驟，直接訪問最后一步，輸入新密碼進行修改／重置。

風險等級：

【高?！浚豪@過原密碼驗證或繞過驗證碼

修復方案

1一次性填寫校驗信息（原始密碼、新密碼等）后再提交修改／重置密碼請求。

負值反沖

漏洞描述

應用程序未校驗訂單數(shù)據的取值范圍，交易存在負值反沖。

測試方法

提交訂單時攔截請求，修改訂單參數(shù)為負數(shù)，如商品單價、數(shù)量、總價等。

風險分析

通過篡改訂單參數(shù)，使得訂單金額為負值，在使用余額支付時余額反而增加。

風險等級：

展開全文

【高?！浚何磳?shù)據進行校驗，導致業(yè)務數(shù)據被污染。

修復方案：

1.服務器端在生成交易訂單時，商品的價格從數(shù)據庫中取出，禁止使用客戶端發(fā)送的商品價格。

2.服務器端對客戶端提交的交易數(shù)據（如商品ID、商品數(shù)量、商品價格等）的取值范圍進行校驗，將商品ID和商品價格與數(shù)據庫中的數(shù)據對比校驗，商品數(shù)量為大于零的整型數(shù)。

3.服務器端在生成支付訂單時，對支付訂單中影響支付金額的所有因素（比如商品ID、商品數(shù)量、商品價格、訂單編號等）進行簽名，對客戶端提交的支付訂單進行校驗。

正負值對沖

漏洞描述

應用程序未校驗訂單數(shù)據的取值范圍，交易存在正負值對沖。

測試方法

提交訂單（包含多種商品）時攔截請求，修改部分商品的單價或數(shù)量，保證訂單總金額為正數(shù)。

風險分析

由于應用會校驗訂單總金額的取值范圍，所以在保證該條件滿足的前提下，修改個別商品的數(shù)量，達到正負值對沖。

風險等級：

【高?！浚何磳?shù)據進行校驗，導致業(yè)務數(shù)據被污染。

修復方案：

1服務器端在生成交易訂單時，商品的價格從數(shù)據庫中取出，禁止使用客戶端發(fā)送的商品價格。

2服務器端對客戶端提交的交易數(shù)據（如商品ID、商品數(shù)量、商品價格等）的取值范圍進行校驗，將商品ID和商品價格與數(shù)據庫中的數(shù)據對比校驗，商品數(shù)量為大于零的整型數(shù)。

3服務器端在生成支付訂單時，對支付訂單中影響支付金額的所有因素（比如商品ID、商品數(shù)量、商品價格、訂單編號等）進行簽名，對客戶端提交的支付訂單進行校驗。

業(yè)務流程跳躍

漏洞描述

業(yè)務邏輯流程分步驟進行且能越過中間校驗步驟直接進行后續(xù)操作，導致中間校驗等步驟失效。

測試方法：

首先完成正常的業(yè)務邏輯步驟，獲取每一個步驟的請求；

繞過中間步驟，直接訪問最后一個或幾個驗證請求，看是否可繞過。

風險分析

攻擊者可利用該漏洞繞過業(yè)務流程檢測，進行非法修改他人密碼等危險操作。

風險等級：

【高?！浚豪@過前面的校驗步驟，直接跳轉至后面的校驗步驟。

修復方案

建議在不影響業(yè)務的前提下，在Session中添加對每一步流程頁面的校驗標志位，在新步驟頁面瀏覽過程中，僅能夠順序執(zhí)行頁面校驗，不可進行跳步操作，例如：頁面二完成后，應更新Flag=3，則僅能夠打開頁面三。

業(yè)務功能失效

通配符注入

漏洞描述

允許使用通配符構造語句查詢數(shù)據庫，導致拒絕服務攻擊問題。

測試方法

模糊查詢時輸入第一個字符’%‘或’_’，sql會遍歷全表，導致應用訪問緩慢。

風險分析：SQL中通配符的使用如下：

1%包含零個或多個字符的任意字符串。

2_任何單個字符。

3[]指定范圍（例如 [a-f]）或集合（例如 [abcdef]）內的任何單個字符。

4[^]不在指定范圍（例如 [^a - f]）或集合（例如 [^abcdef]）內的任何單個字符。

5在模糊查詢 LIKE中，對于輸入數(shù)據中的通配符必須轉義，否則會造成客戶想查詢包含這些特殊字符的數(shù)據時，這些特殊字符卻被解析為通配符，數(shù)據庫響應緩慢，導致拒絕服務攻擊。

風險等級：

【中?！浚和ㄅ浞⑷胍l(fā)數(shù)據庫響應緩慢

修復方案

1有兩種將通配符轉義為普通字符的方法：

2

31) 使用ESCAPE關鍵字定義轉義符（通用）

4在模式中，當轉義符置于通配符之前時，該通配符就解釋為普通字符。例如，要搜索在任意位置包含字符串 5% 的字符串，請使用：

5WHERE ColumnA LIKE '%5/%%'ESCAPE '/'

62) 在方括號 ([ ]) 中只包含通配符本身，或要搜索破折號 (-) 而不是用它指定搜索范圍，請將破折號指定為方括號內的第一個字符。例如：

7符號 含義

8LIKE '5[%]'5%

9LIKE '5%'5后跟 0個或多個字符的字符串

10LIKE '[_]n'_n

11LIKE '[ [ ]'[

12LIKE ']'] （右括號不需要轉義）

13

14所以，對輸入參數(shù)的關鍵字過濾后，還需要做下面轉換確保LIKE的正確執(zhí)行

15privatestaticstringConvertSqlForLike( stringsql )

16{

17sql = sql.Replace( "[",

18"[[]");

19// 這句話一定要在下面兩個語句之前，否則作為轉義符的方括號會被當作數(shù)據被再次處理

20sql = sql.Replace( "_",

21"[_]");

22sql = sql.Replace( "%",

23"[%]");

24returnsql;

25}

業(yè)務功能濫用

短信定向轉發(fā)

漏洞描述

短信接收人可任意指定

測試方法

攔截發(fā)送短信的請求，將手機號改為測試人員的手機號，測試是否可接收短信驗證碼。

風險分析

攻擊者可利用該漏洞將驗證碼發(fā)送到自己的手機號上，重置他人密碼或轉賬。

風險等級：

【高?！浚憾绦沤邮杖丝扇我庵付?/p>

修復方案

發(fā)送短信時手機號從當前會話中獲取，避免從前端傳入。

郵件可定向轉發(fā)

漏洞描述

應用系統(tǒng)發(fā)送郵件的接收人可由客戶端任意指定

測試方法：=

攔截發(fā)送郵件的請求，將接收人郵箱改為測試人員的郵箱地址，測試是否可接收郵件。

風險分析

攻擊者可利用該漏洞將郵件發(fā)送到自己的郵箱中，重置他人密碼。

風險等級：

【高?！浚亨]件接收人可任意指定

修復方案

發(fā)送郵件時郵箱從當前會話中獲取，避免從前端傳入。

業(yè)務接口調用缺陷

漏洞描述

應用的業(yè)務接口存在缺陷，可以通過業(yè)務接口直接進行惡意操作。

測試方法

把業(yè)務邏輯和功能模塊呈現(xiàn)的內容結合，推測出隱藏的API接口。

如用戶信息的接口是http://www.xxx.com/api/user/userInfo，推測重置密碼接口可能是http://www.xxx.com/api/user/passReset，文件上傳接口是http://www.xxx.com/api/user/uploadFile等。

如果這些接口沒有限制訪問，則可以直接調用并提交數(shù)據。

針對開源或商業(yè)軟件的業(yè)務接口調用缺陷可參考《通用系統(tǒng)安全測試指導文檔》

風險分析

攻擊者可通過編寫API枚舉腳本，惡意調用敏感接口，從而進行提交數(shù)據等操作。

風險等級：

【高?！浚和ㄟ^業(yè)務接口能夠操作核心業(yè)務內容，進行越權

【高?！浚和ㄟ^業(yè)務接口能夠獲得重要敏感數(shù)據

【中?！浚和ㄟ^業(yè)務接口能夠獲得中等程度敏感數(shù)據

修復方案

對于每一個訪問的接口都首先檢查當前用戶是否已經登錄并授權（不需要認證的接口除外，例如，免費下載接口等）。

IMAP/SMTP注入

漏洞描述

和廣為人知的諸如SQL注入、XPath注入等技術類似，郵件服務器注入技術也是通過一個對用戶提供的數(shù)據沒有嚴格檢查的webmail應用程序將IMAP命令或者SMTP命令注入到郵件服務器。

要向郵件服務器注入命令，前提條件是允許用戶通過webmail應用程序訪問其端口25（SMTP）和143（IMAP）。

測試方法

要利用SMTP注射，用戶必須事先通過認證，所以用戶必須有一個有效的webmail帳戶。通過SMTP發(fā)送電子郵件消息的格式如下：

1* 發(fā)送方的e-mail地址

2* 接收方的e-mail地址

3* 主題

4* 消息主體

5* 附件

CC/BCC注入

1在發(fā)送者字段(sender)后注入CC和BCC參數(shù)

2From:sender@domain.com%0ACc:recipient@domain.com%0ABcc:recipient1@domain.com

3所以現(xiàn)在,消息將被發(fā)送到recipient和recipient1賬戶。

參數(shù)注射

1From:sender@domain.com%0ATo:attacker@domain.com

2現(xiàn)在消息將被發(fā)送到原來的收件人和攻擊者帳戶。注意，這里的攻擊者的賬戶是我們通過注入額外傳入的。

郵件主題注入

1From:sender@domain.com%0ASubject:This’ s%20Fake%20Subject

2攻擊者注入的假的主題subject將被添加到原來的主題中并且在某些情況下將取代原本的主題subject。這取決于郵件服務行為。即代碼編寫的容錯性，當參數(shù)中出現(xiàn)兩個subject的時候代碼是選擇丟棄還是后者覆蓋。

改變消息的主體body

1要注意 SMTP的 Mail格式，消息主題和頭部 Header之間有兩個換行符(和 HTTP是一樣的)。

2From:sender@ domain. com% 0A% 0AMy% 20New% 20% 0Fake% 20Message.

3假消息將被添加到原始消息中。

風險分析

電子郵件注入允許惡意攻擊者注入任意郵件頭字段,BCC、CC、主題等,它允許黑客通過注入手段從受害者的郵件服務器發(fā)送垃圾郵件。

風險等級：

【高?！浚嚎沙晒俪置艽a找回等信息

【高?！浚嚎沙晒Πl(fā)送垃圾郵件

修復方案

建議從以下幾個方面進行防御：

1.所有用戶輸入應該被認為是不可信的。使用正則表達式來過濾用用戶提交的數(shù)據。例如，可以在輸入字符串中搜索(r 或 n)。

2.使用外部組件和庫，例如ZEND mail、PEAR mail和swift mailer。

3.ModSecurity可以阻止服務器級別的電子郵件注入。利用ModSecurity，可以檢測通過POST或GET提交的CC, BCC或目的地址，并且拒絕任何包含這些字母請求。

引用第三方不可控腳本/URL

漏洞描述

頁面中引用了不可控的腳本或超鏈接

測試方法

檢查頁面內容，是否引用了第三方未知腳本或超鏈接，如惡意的js腳本或病毒木馬的下載鏈接等。

風險分析

攻擊者可在網站中插入惡意鏈接或腳本，導致正常用戶瀏覽時cookie被竊取或被種植病毒木馬。

風險等級：

【高危】：存在不可控外鏈或腳本，且未經過審批

【中?！浚捍嬖诓豢煽赝怄溁蚰_本，但可提供審批記錄

修復方案

建議在不影響業(yè)務的前提下，對網站引用的文件和源代碼進行審查，一經發(fā)現(xiàn)有未審批的外鏈或腳本，應立即刪除。

開啟危險接口

漏洞描述

開啟可利用的危險接口，如獲取訂單信息、用戶身份信息等。

測試方法：

使用掃描器掃描特殊目錄和鏈接

根據正常接口的命名特征猜測隱藏的危險接口，如獲取個人信息接口是getUserInfo，猜測獲取訂單信息接口getOrderDetail。

風險分析

開啟了危險接口，如訂單信息打印、上傳、web管理控制臺等，可能被攻擊者發(fā)現(xiàn)并利用，直接操作應用數(shù)據，造成數(shù)據泄漏等風險。

風險等級：

【高?！浚赫Ｇ闆r接口是在認證之后被調用，如果可公網直接無認證使用

【中?！浚捍嬖谔貦?、非正常用戶不可知但可利用接口

修復方案：

1.敏感接口增加訪問控制，避免未授權訪問；

2.用戶訪問接口需校驗權限，避免越權訪問。

未驗證的URL跳轉

漏洞描述

服務端未對傳入的跳轉url變量進行檢查和控制，可能導致可惡意構造任意一個惡意地址，誘導用戶跳轉到惡意網站。

由于是從可信的站點跳轉出去的，用戶會比較信任，所以跳轉漏洞一般用于釣魚攻擊，通過轉到惡意網站欺騙用戶輸入用戶名和密碼盜取用戶信息，或欺騙用戶進行金錢交易；

也可能引發(fā)的XSS漏洞（主要是跳轉常常使用302跳轉，即設置HTTP響應頭，Locatioin: url，如果url包含了CRLF，則可能隔斷了http響應頭，使得后面部分落到了http body，從而導致xss漏洞）。

另外在struts2 中存在重定向的漏洞，是因為struts2由于縮寫的導航和重定向前綴“action:”、 “redirect:”、 “redirectAction:” 等參數(shù)前綴的內容沒有被正確過濾導致的開放式重定向漏洞。

測試方法：

首先找到網站相關url中存在跳轉鏈接的參數(shù)（如登陸頁面）。

在檢測的同時，可以修改參數(shù)中的合法URL為非法URL，然后查看是否能正常跳轉或者通過抓包工具獲取其HTTP響應頭中Host:的值是否包含了構造的URL。

如果是struts2重定向漏洞，則可通過web掃描工具掃描發(fā)現(xiàn)，或者手工驗證，直接在URL后添加?redirect:+指定釣魚鏈接，例如：10.1.82.53:9098/admin/login.action?redirect:http://diaoyu.com進行驗證。

風險分析

攻擊者利用URL跳轉漏洞來欺騙安全意識低的用戶，從而導致“中獎”之類的欺詐事件發(fā)生。

同時利用URL跳轉，也可以突破常見的基于“白名單方式”的一些安全限制，如傳統(tǒng)IM里對于URL的傳輸會進行安全校驗，

但是對于知名網站的域名及URL將直接允許通過并且顯示為可信的URL，一旦該可信的URL里包含URL跳轉漏洞將導致安全限制被繞過。

URL跳轉最典型的例子就是登錄跳轉，示例代碼如下：

1publicvoiddoRedirect(HttpServletRequest req, HttpServletResponse res)

2{

3String jumpURL=request.getParameter(“jumptoURL”);

4response.setHeader( "Location",jumpURL);

5}

6若程序未過濾jumptoURL參數(shù)，攻擊者將惡意鏈接：http: //www.xxx.com/login.jsp?jumptoURL=http://www.evil.com發(fā)給其他用戶，

7安全意識較低的用戶會認為該鏈接展現(xiàn)的內容是www.xxx.com，從而產生欺詐行為。

8同時由于QQ、淘寶旺旺等在線IM都是基于URL的過濾，對部分站點會通過白名單的方式直接通過，因此惡意URL可以在IM里傳播。

9例如IM認為www.xxx.com是可信的，但是通過在IM里點擊上述鏈接將導致用戶最終訪問http: //www.evil.com。

風險等級：

【高?！浚篣RL 跳轉參數(shù)可控，且未對參數(shù)做白名單限制導致任意地址跳轉可被利用釣魚。

修復方案

對傳入的URL做有效性的認證，保證該URL來自于信任域。限制的方式可參考以下兩種：

1限制Referer（Referer是HTTP header中的字段，當瀏覽器向web服務器發(fā)送請求時，一般會帶上Referer，告訴服務器是從哪個頁面鏈接過來的），通過限制Referer保證將要跳轉URL的有效性，避免攻擊者生成自己的惡意跳轉鏈接；

2加入有效性驗證Token，保證所有生成的鏈接都來自于可信域，通過在生成的鏈接里加入用戶不可控的Token對生成的鏈接進行校驗。

服務器端請求偽造（SSRF）

漏洞描述

服務端請求偽造攻擊（Server-side Request Forgery）: 很多web應用都提供了從其他的服務器上獲取數(shù)據的功能。

使用用戶指定的URL，web應用可以獲取圖片，下載文件，讀取文件內容等。

這個功能如果被惡意使用，可以利用存在缺陷的web應用作為代理攻擊遠程和本地的服務器。

這種形式的攻擊稱為服務端請求偽造攻擊（Server-side Request Forgery）。

一般情況下， SSRF攻擊的目標是從外網無法訪問的內部系統(tǒng) 。（ 正是因為它是由服務端發(fā)起的，所以它能夠請求到與它相連而與外網隔離的內部系統(tǒng) ）.

SSRF 形成的原因大都是由于 服務端提供了從其他服務器應用獲取數(shù)據的功能且沒有對目標地址做過濾與限制 。

比如從指定URL地址獲取網頁文本內容，加載指定地址的圖片，下載等等。

攻擊者利用ssrf可以實現(xiàn)的攻擊主要有5種:

1可以對外網、服務器所在內網、本地進行端口掃描，獲取一些服務的banner信息;

2攻擊運行在內網或本地的應用程序（比如溢出）;

3對內網web應用進行指紋識別，通過訪問默認文件實現(xiàn);

4攻擊內外網的web應用，主要是使用 get參數(shù)就可以實現(xiàn)的攻擊（比如struts2，sqli等）;

5利用file協(xié)議讀取本地文件等。

測試方法

從WEB功能上尋找：我們從上面的概述可以看出，SSRF是由于服務端獲取其他服務器的相關信息的功能中形成的，

因此我們大可以列舉幾種在web 應用中常見的從服務端獲取其他服務器信息的的功能。

1通過分享功能：通過URL地址分享網頁內容：

2早期分享應用中，為了更好的提供用戶體驗，WEB應用在分享功能中，通常會獲取目標URL地址網頁內容中的 tilte / title 標簽或者 metaname= "deion"content= “”/ 標簽中content的文本內容作為顯示以提供更好的用戶體驗。例如人人網分享功能中：http://widget.renren.com/*****?resourceUrl=https://www.nsfocus.com

3通過目標URL地址獲取了title標簽和相關文本內容。而如果在此功能中沒有對目標地址的范圍做過濾與限制則就存在著SSRF漏洞.

4轉碼服務：通過URL地址把原地址的網頁內容調優(yōu)使其適合手機屏幕瀏覽：由于手機屏幕大小的關系，直接瀏覽網頁內容的時候會造成許多不便，因此有些公司提供了轉碼功能，把網頁內容通過相關手段轉為適合手機屏幕瀏覽的樣式。例如百度、騰訊、搜狗等公司都有提供在線轉碼服務。

5在線翻譯：通過URL地址翻譯對應文本的內容。提供此功能的國內公司有百度、有道等。

6圖片加載與下載，通過URL地址加載或下載圖片：圖片加載遠程圖片地址此功能用到的地方很多，但大多都是比較隱秘，比如在有些公司中的加載自家圖片服務器上的圖片用于展示。（此處可能會有人有疑問，為什么加載圖片服務器上的圖片也會有問題，直接使用img標簽不就好了？ ，沒錯是這樣，但是開發(fā)者為了有更好的用戶體驗通常對圖片做些微小調整例如加水印、壓縮等，所以就可能造成SSRF問題）。

7圖片、文章收藏功能：此處的圖片、文章收藏中的文章收藏就類似于功能一、分享功能中獲取URL地址中title以及文本的內容作為顯示，目的還是為了更好的用戶體驗，而圖片收藏就類似于功能四、圖片加載。

8未公開的api實現(xiàn)以及其他調用URL的功能：此處類似的功能有360提供的網站評分，以及有些網站通過api獲取遠程地址xml文件來加載內容.

風險分析

如果應用程序對用戶提供的URL和遠端服務器返回的信息沒有進行合適的驗證和過濾，則可能存在服務器端請求偽造攻擊。

服務器端請求偽造攻擊場景如下圖所示：

攻擊者想要訪問主機B上的服務，由于存在防火墻的原因無法直接訪問，這時可以借助主機A來發(fā)起服務器端請求偽造攻擊，通過主機A向主機B發(fā)起請求，從而完成攻擊。

1SSRF攻擊方式主要有以下 5種：

2

3對外網、服務器所在內網、本地進行端口掃描，獲取一些服務的banner信息（一般包括服務器的類型、版本，服務器上啟動的服務信息）；

4攻擊運行在內網或本地的應用程序（比如堆棧溢出）； 3) 通過訪問默認文件實現(xiàn)對內網Web應用的指紋識別；

5攻擊內外網的Web應用，主要是使用GET參數(shù)就可以實現(xiàn)的攻擊（比如Struts2，Sqli等）；

6利用 file協(xié)議讀取本地文件等。

風險等級：

【高危】：有回顯，可探測內網，文件訪問

【中?！浚簾o回顯，但可訪問外網

修復方案

通常從以下幾點來防御服務器端請求偽造攻擊：

1過濾內網服務器對公網服務器請求的響應。如果Web應用是獲取某一類型的文件，在把返回結果展示給用戶之前應先驗證返回的信息是否符合文件類型標準，比如返回信息應為圖片，如果返回信息是HTML，則停止將返回信息返回客戶端。

2統(tǒng)一錯誤提示信息，避免用戶可以根據錯誤信息來判斷遠端服務器的端口狀態(tài)。

3在內網服務器的防火墻上限制公網服務器的請求端口為HTTP等協(xié)議常用端口，如： 80、 443、 8080、 8090。

4若公網服務器的內網IP與內網無業(yè)務通信，建議將公網服務器對應的內網IP列入黑名單，避免應用被用來獲取內網數(shù)據。

5內網服務器禁用不必要的協(xié)議，僅允許HTTP和HTTPS請求，防止類似于 file: ///、gopher://、ftp:// 等協(xié)議引起的安全問題。

短信內容可控

漏洞描述

短信內容可從客戶端指定

測試方法

在客戶端編輯任意短信內容，測試是否過濾特殊內容。

風險分析

攻擊者可利用該漏洞，借助短信平臺，編輯釣魚短信發(fā)送給其他用戶。

風險等級：

【高危】：短信內容可控，且接收人可任意指定

【中?！浚憾绦艃热菘煽兀邮苋瞬豢煽?/p>

修復方案

建議在不影響業(yè)務的前提下，禁止客戶端編輯短信內容。

郵件內容可控

漏洞描述

應用系統(tǒng)發(fā)送郵件的郵件內容可由客戶端任意指定

測試方法

在客戶端編輯任意郵件內容，測試是否過濾特殊內容。

風險分析

攻擊者可利用該漏洞，借助郵件平臺，編輯釣魚郵件發(fā)送給其他用戶。

風險等級：

【高?！浚亨]件內容可控，且收件人可任意指定

【中?！浚亨]件內容可控，但收件人地址不可控

修復方案

建議在不影響業(yè)務的前提下，禁止客戶端編輯郵件內容。

請求重放攻擊

漏洞描述

關鍵業(yè)務操作未作token或者唯一標識碼，導致攻擊者可以重復多次進行請求，導致惡意操作。如重復交易等問題。

測試方法

重放http/tcp請求，查看第二次請求是否被正常處理。

風險分析

攻擊者惡意或欺詐性地重復發(fā)送一個有效的數(shù)據包，如果服務器未檢查此類重復提交的請求數(shù)據的有效性，那么轉賬充值等敏感操作將有可能會被重復執(zhí)行。

風險等級：

【高危】：關鍵業(yè)務操作請求未設置 token 或標識碼，導致業(yè)務數(shù)據越界或錯誤

修復方案

服務端應用程序應檢查客戶端提交的數(shù)據的唯一性，如使用流水號、時間戳、token等，并將流水號、時間戳等進行簽名。

批量提交

漏洞描述

應用程序未使用驗證碼等防自動化操作的方法，可批量提交請求，如批量注冊。

測試方法：

編寫自動提交HTTP數(shù)據包的腳本；

或使用burpsuite的intruder功能批量提交請求。

風險分析

注冊不需要驗證碼時，攻擊者通過編寫自動化腳本，實現(xiàn)程序自動提交注冊信息；

若注冊需要驗證碼，但驗證碼位數(shù)不多于4位且為純數(shù)字時，通過使用軟件burpsuite的intruder功能窮舉得到正確的驗證碼后，再結合自動化腳本工具即可實現(xiàn)批量注冊垃圾賬號。

風險等級：

【高?！浚赫I(yè)務為單條數(shù)據請求，且不存在防自動化批量操作措施，可批量自動化提交。

【低?！浚赫I(yè)務為單條數(shù)據請求，且存在防自動化批量操作措施，但在單個數(shù)據包中寫入批量數(shù)據，可成功提交，并且服務器能批量執(zhí)行。

修復方案：

2.用戶注冊功能處，提交注冊信息后進行郵箱或短信驗證通過后再將注冊信息寫入數(shù)據庫。

3.對同一IP地址短時間內提交請求的次數(shù)進行限制。

摘抄

在這煙塵人間，

并非俗不可耐索然無味，

冬日暖陽，夏日蟬鳴都顯可愛。

版權聲明：本文為CSDN博主「星球守護者」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權協(xié)議，轉載請附上原文出處鏈接及本聲明。

版權聲明：著作權歸作者所有。如有侵權請聯(lián)系刪除

開源聚合網安訓練營

環(huán)境搭建

Python

學員專輯

信息收集

CNVD

安全求職

滲透實戰(zhàn)

CVE

高薪揭秘

滲透測試工具

網絡安全行業(yè)

神秘大禮包

基礎教程

我們貼心備至

用戶答疑

QQ在線客服

加入社群

QQ+微信等著你

我就知道你“在看”