業務邏輯篡改

密碼修改/重置流程跨越

漏洞描述

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

測試方法：

• 完成修改／重置密碼的正常流程；
• 繞過檢驗原密碼等步驟，直接訪問輸入新密碼頁面，輸入新密碼，修改／重置密碼。

風險分析：

有些密碼修改／重置流程採用step=1、step=2類似的方式實現，如果應用校驗不全面，
攻擊者可繞過前面的步驟，直接訪問最後一步，輸入新密碼進行修改／重置。

風險等級：

【高危】：繞過原密碼驗證或繞過驗證碼

修復方案

一次性填寫校驗資訊（原始密碼、新密碼等）後再提交修改／重置密碼請求。

負值反衝

漏洞描述

應用程式未校驗訂單資料的取值範圍，交易存在負值反衝。

測試方法

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

風險分析

通過篡改訂單引數，使得訂單金額為負值，在使用餘額支付時餘額反而增加。

風險等級：

【高危】：未對資料進行校驗，導致業務資料被汙染。

修復方案：

1.	伺服器端在生成交易訂單時，商品的價格從資料庫中取出，禁止使用客戶端傳送的商品價格。
2.	伺服器端對客戶端提交的交易資料（如商品ID、商品數量、商品價格等）的取值範圍進行校驗，將商品ID和商品價格與資料庫中的資料對比校驗，商品數量為大於零的整型數。
3.	伺服器端在生成支付訂單時，對支付訂單中影響支付金額的所有因素（比如商品ID、商品數量、商品價格、訂單編號等）進行簽名，對客戶端提交的支付訂單進行校驗。

正負值對衝

漏洞描述

應用程式未校驗訂單資料的取值範圍，交易存在正負值對衝。

測試方法

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

風險分析

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

風險等級：

【高危】：未對資料進行校驗，導致業務資料被汙染。

修復方案：

1.	伺服器端在生成交易訂單時，商品的價格從資料庫中取出，禁止使用客戶端傳送的商品價格。
2.	伺服器端對客戶端提交的交易資料（如商品ID、商品數量、商品價格等）的取值範圍進行校驗，將商品ID和商品價格與資料庫中的資料對比校驗，商品數量為大於零的整型數。
3.	伺服器端在生成支付訂單時，對支付訂單中影響支付金額的所有因素（比如商品ID、商品數量、商品價格、訂單編號等）進行簽名，對客戶端提交的支付訂單進行校驗。

業務流程跳躍

漏洞描述

業務邏輯流程分步驟進行且能越過中間校驗步驟直接進行後續操作，導致中間校驗等步驟失效。

測試方法：

• 首先完成正常的業務邏輯步驟，獲取每一個步驟的請求；
• 繞過中間步驟，直接訪問最後一個或幾個驗證請求，看是否可繞過。

風險分析

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

風險等級：

【高危】：繞過前面的校驗步驟，直接跳轉至後面的校驗步驟。

修復方案

建議在不影響業務的前提下，在Session中新增對每一步流程頁面的校驗標誌位，在新步驟頁面瀏覽過程中，僅能夠順序執行頁面校驗，不可進行跳步操作，例如：頁面二完成後，應更新Flag=3，則僅能夠開啟頁面三。

業務功能失效

萬用字元注入

漏洞描述

允許使用萬用字元構造語句查詢資料庫，導致拒絕服務攻擊問題。

測試方法

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

風險分析：SQL中萬用字元的使用如下：

%包含零個或多個字元的任意字串。
_任何單個字元。
[]指定範圍（例如 [a-f]）或集合（例如 [abcdef]）內的任何單個字元。
[^]不在指定範圍（例如 [^a - f]）或集合（例如 [^abcdef]）內的任何單個字元。
在模糊查詢LIKE中，對於輸入資料中的萬用字元必須轉義，否則會造成客戶想查詢包含這些特殊字元的資料時，這些特殊字元卻被解析為萬用字元，資料庫響應緩慢，導致拒絕服務攻擊。

風險等級：

【中危】：萬用字元注入引發資料庫響應緩慢

修復方案

有兩種將萬用字元轉義為普通字元的方法：

1)   使用ESCAPE關鍵字定義轉義符（通用）
在模式中，當轉義符置於萬用字元之前時，該萬用字元就解釋為普通字元。例如，要搜尋在任意位置包含字串 5% 的字串，請使用：
        WHERE ColumnA LIKE '%5/%%' ESCAPE '/'
2)   在方括號 ([ ]) 中只包含萬用字元本身，或要搜尋破折號 (-) 而不是用它指定搜尋範圍，請將破折號指定為方括號內的第一個字元。例如：
符號	含義
LIKE '5[%]'	5%
LIKE '5%'	5 後跟 0 個或多個字元的字串
LIKE '[_]n'	_n
LIKE '[ [ ]'	[
LIKE ']'	]   （右括號不需要轉義）

所以，對輸入引數的關鍵字過濾後，還需要做下面轉換確保LIKE的正確執行
private static string ConvertSqlForLike(string sql)
{
sql = sql.Replace("[",
"[[]");
// 這句話一定要在下面兩個語句之前，否則作為轉義符的方括號會被當作資料被再次處理
sql = sql.Replace("_",
"[_]");
sql = sql.Replace("%",
"[%]");
returnsql;
}

業務功能濫用

簡訊定向轉發

漏洞描述

簡訊接收人可任意指定

測試方法

• 攔截髮送簡訊的請求，將手機號改為測試人員的手機號，測試是否可接收簡訊驗證碼。

風險分析

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

風險等級：

【高危】：簡訊接收人可任意指定

修復方案

傳送簡訊時手機號從當前會話中獲取，避免從前端傳入。

郵件可定向轉發

漏洞描述

應用系統傳送郵件的接收人可由客戶端任意指定

測試方法：=

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

風險分析

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

風險等級：

【高危】：郵件接收人可任意指定

修復方案

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

業務介面呼叫缺陷

漏洞描述

應用的業務介面存在缺陷，可以通過業務介面直接進行惡意操作。

測試方法

把業務邏輯和功能模組呈現的內容結合，推測出隱藏的API介面。
如使用者資訊的介面是http://www.xxx.com/api/user/userInfo，推測重置密碼介面可能是http://www.xxx.com/api/user/passReset，檔案上傳介面是http://www.xxx.com/api/user/uploadFile等。
如果這些介面沒有限制訪問，則可以直接呼叫並提交資料。
針對開源或商業軟體的業務介面呼叫缺陷可參考《通用系統安全測試指導文件》

風險分析

攻擊者可通過編寫API列舉指令碼，惡意呼叫敏感介面，從而進行提交資料等操作。

風險等級：

【高危】：通過業務介面能夠操作核心業務內容，進行越權
【高危】：通過業務介面能夠獲得重要敏感資料
【中危】：通過業務介面能夠獲得中等程度敏感資料

修復方案

對於每一個訪問的介面都首先檢查當前使用者是否已經登入並授權（不需要認證的介面除外，例如，免費下載介面等）。

IMAP/SMTP注入

漏洞描述

和廣為人知的諸如SQL隱碼攻擊、XPath注入等技術類似，郵件伺服器注入技術也是通過一個對使用者提供的數據沒有嚴格檢查的webmail應用程式將IMAP命令或者SMTP命令注入到郵件伺服器。
要向郵件伺服器注入命令，前提條件是允許使用者通過webmail應用程式訪問其埠25（SMTP）和143（IMAP）。

測試方法

要利用SMTP注射，使用者必須事先通過認證，所以用戶必須有一個有效的webmail帳戶。通過SMTP傳送電子郵件訊息的格式如下：

* 傳送方的e-mail地址 
* 接收方的e-mail地址 
* 主題 
* 訊息主體 
* 附件

1. CC/BCC注入

在傳送者欄位(sender)後注入CC和BCC引數
From:sender@domain.com%0ACc:recipient@domain.com%0ABcc:recipient1@domain.com
所以現在,訊息將被髮送到recipient和recipient1賬戶。

2. 引數注射

From:sender@domain.com%0ATo:attacker@domain.com
現在訊息將被髮送到原來的收件人和攻擊者帳戶。注意，這裡的攻擊者的賬戶是我們通過注入額外傳入的。

3. 郵件主題注入

From:sender@domain.com%0ASubject:This’s%20Fake%20Subject
攻擊者注入的假的主題subject將被新增到原來的主題中並且在某些情況下將取代原本的主題subject。這取決於郵件服務行為。即程式碼編寫的容錯性，當引數中出現兩個subject的時候程式碼是選擇丟棄還是後者覆蓋。

4. 改變訊息的主體body

要注意SMTP的Mail格式，訊息主題和頭部Header之間有兩個換行符(和HTTP是一樣的)。
From:sender@domain.com%0A%0AMy%20New%20%0Fake%20Message.
假訊息將被新增到原始訊息中。

風險分析

電子郵件注入允許惡意攻擊者注入任意郵件頭欄位,BCC、CC、主題等,它允許黑客通過注入手段從受害者的郵件伺服器傳送垃圾郵件。

風險等級：

【高危】：可成功劫持密碼找回等資訊
【高危】：可成功傳送垃圾郵件

修復方案

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

1.	所有使用者輸入應該被認為是不可信的。使用正規表示式來過濾用使用者提交的資料。例如，可以在輸入字串中搜尋(r 或 n)。
2.	使用外部元件和庫，例如ZEND mail、PEAR mail和swift mailer。
3.	ModSecurity可以阻止伺服器級別的電子郵件注入。利用ModSecurity，可以檢測通過POST或GET提交的CC, BCC或目的地址，並且拒絕任何包含這些字母請求。

引用第三方不可控指令碼/URL

漏洞描述

頁面中引用了不可控的指令碼或超連結

測試方法

檢查頁面內容，是否引用了第三方未知指令碼或超連結，如惡意的js指令碼或病毒木馬的下載連結等。

風險分析

攻擊者可在網站中插入惡意連結或指令碼，導致正常使用者瀏覽時cookie被竊取或被種植病毒木馬。

風險等級：

【高危】：存在不可控外鏈或指令碼，且未經過審批
【中危】：存在不可控外鏈或指令碼，但可提供審批記錄

修復方案

建議在不影響業務的前提下，對網站引用的檔案和原始碼進行審查，一經發現有未審批的外鏈或指令碼，應立即刪除。

開啟危險介面

漏洞描述

開啟可利用的危險介面，如獲取訂單資訊、使用者身份資訊等。

測試方法：

• 使用掃描器掃描特殊目錄和連結
• 根據正常介面的命名特徵猜測隱藏的危險介面，如獲取個人資訊介面是getUserInfo，猜測獲取訂單資訊介面getOrderDetail。

風險分析

開啟了危險介面，如訂單資訊列印、上傳、web管理控制檯等，可能被攻擊者發現並利用，直接操作應用資料，造成資料洩漏等風險。

風險等級：

【高危】：正常情況介面是在認證之後被呼叫，如果可公網直接無認證使用
【中危】：存在特權、非正常使用者不可知但可利用介面

修復方案：

1.	敏感介面增加訪問控制，避免未授權訪問；
2.	使用者訪問介面需校驗許可權，避免越權訪問。

未驗證的URL跳轉

漏洞描述

• 服務端未對傳入的跳轉url變數進行檢查和控制，可能導致可惡意構造任意一個惡意地址，誘導使用者跳轉到惡意網站。
• 由於是從可信的站點跳轉出去的，使用者會比較信任，所以跳轉漏洞一般用於釣魚攻擊，通過轉到惡意網站欺騙使用者輸入使用者名稱和密碼盜取使用者資訊，或欺騙使用者進行金錢交易；
• 也可能引發的XSS漏洞（主要是跳轉常常使用302跳轉，即設定HTTP響應頭，Locatioin: url，如果url包含了CRLF，則可能隔斷了http響應頭，使得後面部分落到了http body，從而導致xss漏洞）。
• 另外在struts2 中存在重定向的漏洞，是因為struts2由於縮寫的導航和重定向字首“action:”、 “redirect:”、 “redirectAction:” 等引數字首的內容沒有被正確過濾導致的開放式重定向漏洞。

測試方法：

• 首先找到網站相關url中存在跳轉連結的引數（如登陸頁面）。
• 在檢測的同時，可以修改引數中的合法URL為非法URL，然後檢視是否能正常跳轉或者通過抓包工具獲取其HTTP響應頭中Host:的值是否包含了構造的URL。
• 如果是struts2重定向漏洞，則可通過web掃描工具掃描發現，或者手工驗證，直接在URL後新增?redirect:+指定釣魚連結，例如：10.1.82.53:9098/admin/login.action?redirect:http://diaoyu.com進行驗證。

風險分析

• 攻擊者利用URL跳轉漏洞來欺騙安全意識低的使用者，從而導致“中獎”之類的欺詐事件發生。
• 同時利用URL跳轉，也可以突破常見的基於“白名單方式”的一些安全限制，如傳統IM裡對於URL的傳輸會進行安全校驗，
• 但是對於知名網站的域名及URL將直接允許通過並且顯示為可信的URL，一旦該可信的URL裡包含URL跳轉漏洞將導致安全限制被繞過。
• URL跳轉最典型的例子就是登入跳轉，示例程式碼如下：

public void doRedirect(HttpServletRequest req, HttpServletResponse res)
{
   String jumpURL=request.getParameter(“jumptoURL”);
	response.setHeader("Location",jumpURL);
}
若程式未過濾jumptoURL引數，攻擊者將惡意連結：http://www.xxx.com/login.jsp?jumptoURL=http://www.evil.com發給其他使用者，
安全意識較低的使用者會認為該連結展現的內容是www.xxx.com，從而產生欺詐行為。
同時由於QQ、淘寶旺旺等線上IM都是基於URL的過濾，對部分站點會通過白名單的方式直接通過，因此惡意URL可以在IM裡傳播。
例如IM認為www.xxx.com是可信的，但是通過在IM裡點選上述連結將導致使用者最終訪問http://www.evil.com。

風險等級：

【高危】：URL 跳轉引數可控，且未對引數做白名單限制導致任意地址跳轉可被利用釣魚。

修復方案

對傳入的URL做有效性的認證，保證該URL來自於信任域。限制的方式可參考以下兩種：
1	限制Referer（Referer是HTTP header中的欄位，當瀏覽器向web伺服器傳送請求時，一般會帶上Referer，告訴伺服器是從哪個頁面連結過來的），通過限制Referer保證將要跳轉URL的有效性，避免攻擊者生成自己的惡意跳轉連結；
2	加入有效性驗證Token，保證所有生成的連結都來自於可信域，通過在生成的連結里加入使用者不可控的Token對生成的連結進行校驗。

伺服器端請求偽造（SSRF）

漏洞描述

• 服務端請求偽造攻擊（Server-side Request Forgery）: 很多web應用都提供了從其他的伺服器上獲取資料的功能。
• 使用使用者指定的URL，web應用可以獲取圖片，下載檔案，讀取檔案內容等。
• 這個功能如果被惡意使用，可以利用存在缺陷的web應用作為代理攻擊遠端和本地的伺服器。
• 這種形式的攻擊稱為服務端請求偽造攻擊（Server-side Request Forgery）。
• 一般情況下， SSRF攻擊的目標是從外網無法訪問的內部系統 。（ 正是因為它是由服務端發起的，所以它能夠請求到與它相連而與外網隔離的內部系統 ）.
• SSRF 形成的原因大都是由於 服務端提供了從其他伺服器應用獲取資料的功能且沒有對目標地址做過濾與限制 。
• 比如從指定URL地址獲取網頁文字內容，載入指定地址的圖片，下載等等。

攻擊者利用ssrf可以實現的攻擊主要有5種:

1	可以對外網、伺服器所在內網、本地進行埠掃描，獲取一些服務的banner資訊;
2	攻擊執行在內網或本地的應用程式（比如溢位）;
3	對內網web應用進行指紋識別，通過訪問預設檔案實現;
4	攻擊內外網的web應用，主要是使用get引數就可以實現的攻擊（比如struts2，sqli等）;
5	利用file協議讀取本地檔案等。

測試方法

從WEB功能上尋找：我們從上面的概述可以看出，SSRF是由於服務端獲取其他伺服器的相關資訊的功能中形成的，
因此我們大可以列舉幾種在web 應用中常見的從服務端獲取其他伺服器資訊的的功能。

1	通過分享功能：通過URL地址分享網頁內容：
早期分享應用中，為了更好的提供使用者體驗，WEB應用在分享功能中，通常會獲取目標URL地址網頁內容中的<tilte></title>標籤或者<meta name="description" content=“”/>標籤中content的文字內容作為顯示以提供更好的使用者體驗。例如人人網分享功能中：http://widget.renren.com/*****?resourceUrl=https://www.nsfocus.com
通過目標URL地址獲取了title標籤和相關文字內容。而如果在此功能中沒有對目標地址的範圍做過濾與限制則就存在著SSRF漏洞.
2	轉碼服務：通過URL地址把原地址的網頁內容調優使其適合手機螢幕瀏覽：由於手機螢幕大小的關係，直接瀏覽網頁內容的時候會造成許多不便，因此有些公司提供了轉碼功能，把網頁內容通過相關手段轉為適合手機螢幕瀏覽的樣式。例如百度、騰訊、搜狗等公司都有提供線上轉碼服務。
3	線上翻譯：通過URL地址翻譯對應文字的內容。提供此功能的國內公司有百度、有道等。
4	圖片載入與下載，通過URL地址載入或下載圖片：圖片載入遠端圖片地址此功能用到的地方很多，但大多都是比較隱祕，比如在有些公司中的載入自家圖片伺服器上的圖片用於展示。（此處可能會有人有疑問，為什麼載入圖片伺服器上的圖片也會有問題，直接使用img標籤不就好了？ ，沒錯是這樣，但是開發者為了有更好的使用者體驗通常對圖片做些微小調整例如加水印、壓縮等，所以就可能造成SSRF問題）。
5	圖片、文章收藏功能：此處的圖片、文章收藏中的文章收藏就類似於功能一、分享功能中獲取URL地址中title以及文字的內容作為顯示，目的還是為了更好的使用者體驗，而圖片收藏就類似於功能四、圖片載入。
6	未公開的api實現以及其他呼叫URL的功能：此處類似的功能有360提供的網站評分，以及有些網站通過api獲取遠端地址xml檔案來載入內容.

風險分析

如果應用程式對使用者提供的URL和遠端伺服器返回的資訊沒有進行合適的驗證和過濾，則可能存在伺服器端請求偽造攻擊。

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

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

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

1. 對外網、伺服器所在內網、本地進行埠掃描，獲取一些服務的banner資訊（一般包括伺服器的型別、版本，伺服器上啟動的服務資訊）；
2. 攻擊執行在內網或本地的應用程式（比如堆疊溢位）； 3) 通過訪問預設檔案實現對內網Web應用的指紋識別；
3. 攻擊內外網的Web應用，主要是使用GET引數就可以實現的攻擊（比如Struts2，Sqli等）；
4. 利用file協議讀取本地檔案等。

風險等級：

【高危】：有回顯，可探測內網，檔案訪問
【中危】：無回顯，但可訪問外網

修復方案

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

1	過濾內網伺服器對公網伺服器請求的響應。如果Web應用是獲取某一型別的檔案，在把返回結果展示給使用者之前應先驗證返回的資訊是否符合檔案型別標準，比如返回資訊應為圖片，如果返回資訊是HTML，則停止將返回資訊返回客戶端。
2	統一錯誤提示資訊，避免使用者可以根據錯誤資訊來判斷遠端伺服器的埠狀態。
3	在內網伺服器的防火牆上限制公網伺服器的請求埠為HTTP等協議常用埠，如：80、443、8080、8090。
4	若公網伺服器的內網IP與內網無業務通訊，建議將公網伺服器對應的內網IP列入黑名單，避免應用被用來獲取內網資料。
5	內網伺服器禁用不必要的協議，僅允許HTTP和HTTPS請求，防止類似於file:///、gopher://、ftp:// 等協議引起的安全問題。

簡訊內容可控

漏洞描述

簡訊內容可從客戶端指定

測試方法

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

風險分析

攻擊者可利用該漏洞，藉助簡訊平臺，編輯釣魚簡訊傳送給其他使用者。

風險等級：

【高危】：簡訊內容可控，且接收人可任意指定
【中危】：簡訊內容可控，但接受人不可控

修復方案

建議在不影響業務的前提下，禁止客戶端編輯簡訊內容。

郵件內容可控

漏洞描述

應用系統傳送郵件的郵件內容可由客戶端任意指定

測試方法

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

風險分析

攻擊者可利用該漏洞，藉助郵件平臺，編輯釣魚郵件傳送給其他使用者。

風險等級：

【高危】：郵件內容可控，且收件人可任意指定
【中危】：郵件內容可控，但收件人地址不可控

修復方案

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

請求重放攻擊

漏洞描述

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

測試方法

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

風險分析

攻擊者惡意或欺詐性地重複傳送一個有效的資料包，如果伺服器未檢查此類重複提交的請求資料的有效性，那麼轉賬充值等敏感操作將有可能會被重複執行。

風險等級：

【高危】：關鍵業務操作請求未設定 token 或標識碼，導致業務資料越界或錯誤

修復方案

服務端應用程式應檢查客戶端提交的資料的唯一性，如使用流水號、時間戳、token等，並將流水號、時間戳等進行簽名。

批量提交

漏洞描述

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

測試方法：

• 編寫自動提交HTTP資料包的指令碼；
• 或使用burpsuite的intruder功能批量提交請求。

風險分析

註冊不需要驗證碼時，攻擊者通過編寫自動化指令碼，實現程式自動提交註冊資訊；
若註冊需要驗證碼，但驗證碼位數不多於4位且為純數字時，通過使用軟體burpsuite的intruder功能窮舉得到正確的驗證碼後，再結合自動化指令碼工具即可實現批量註冊垃圾賬號。

風險等級：

【高危】：正常業務為單條資料請求，且不存在防自動化批量操作措施，可批量自動化提交。
【低危】：正常業務為單條資料請求，且存在防自動化批量操作措施，但在單個資料包中寫入批量資料，可成功提交，並且伺服器能批量執行。

修復方案：

1.	使用安全性強的驗證碼，驗證碼應從以下方面保證其安全性：驗證碼長度不低於4位，避免使用容易被程式自動識別的驗證碼，驗證碼不應返回客戶端。
2.	使用者註冊功能處，提交註冊資訊後進行郵箱或簡訊驗證通過後再將註冊資訊寫入資料庫。
3.	對同一IP地址短時間內提交請求的次數進行限制。

摘抄

---

在這煙塵人間，

並非俗不可耐索然無味，

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

---