0x01前言

最近在做一個介面測試的項目，雖然難度不大，但是 路漫漫心累~在乙方做安全服務的，平常的Web、App的滲透測試可以說是家常便飯了，但是好像很少會碰到介面測試的，但說不定哪天就會碰到了2333~，所以這裡分享一下做介面測試的簡單步驟和測試過程中踩過的坑吧，希望老表們在遇到同類問題時可以一把梭，不要再一步一卡，步步踩坑了。0x02什麼是介面測試首先在你拿到一個介面測試項目的時候，只有一個黑人問號臉肯定是不行的，比如這樣：

所以我們先來看一下，什麼是介面測試？百度百科解釋一波：介面測試是測試系統組件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。Are you kidding me？我們測試的重點當然是安全，所以個人理解，介面安全測試就是檢測外部系統與系統之間以及內部各個子系統之間交互點中可能發生的安全問題。如：
  • 檢測數據交換過程中是否可以在數據輸入過程中向系統之中插入一些臟數據，在數據輸出的時候得以達到攻擊者想要的結果，常見漏洞有：SQL注入、XSS跨站腳本漏洞、溢出漏洞、文件上傳漏洞等。
  • 檢測重要數據如身份證號、銀行卡號、電話號碼、郵箱等在傳遞和存儲的過程中是否進行了加密，敏感數據在前端輸出時，若非業務需求，還需要進行脫敏處理。常見漏洞有：賬號密碼明文傳輸、用戶個人信息明文泄露等。
  • 檢測系統中各子系統及各功能的邏輯依賴關係是否存在安全問題，比如打亂具有前後順序的業務是否依然能達成原有效果、重放某一業務的數據包是否能多次執行該業務功能、遍曆數據包中的某些有規律的欄位是否能得到更多信息，常見漏洞有：密碼重置漏洞、批量提交訂單漏洞、越權漏洞、未授權訪問等。

0x03前期準備

實際上，介面安全測試與我們常見的Web安全測試、App安全測試大同小異，所以對於有web和app測試經驗的工程師來說，測試過程並不會有太大難度，前提是前期的準備足夠充足。介面測試的前期準備主要是測試環境、測試文檔和測試工具的準備。首先是測試環境，通常程序員們在開發這些介面的時候，需要進行一系列的功能性測試，所以也會有相應的測試系統，我們需要的就是這個測試系統的URL和測試Demo，同時需要保證我們的網路環境能夠訪問到這個URL（因為通常測試系統都部署在內網系統，由於內網的一些網路限制，如果不事先準備問清楚，很容易一臉懵逼）。對於測試Demo，要求不高，只要能夠讓我們可以正常的發送報文，得到正常響應即可，但是有些特殊的介面在傳輸過程中可能還涉及到加解密的步驟，最好在Demo中也有響應的功能。比如下圖的測試Demo，不需要有多好看的UI，能用就行：

當測試環境準備好了以後，我們還需要開發提供介面文檔，介面文檔中需要包含的內容有各功能介面的功能描述、應用場景、請求方、應答方以及報文樣例等，介面文檔的作用是為了讓我們能夠清楚每個介面的功能以及它的應用場景，只有瞭解了這些介面具體是做什麼的，我們纔能夠更好的分析出在這個介面被調用的過程中可能發生的安全問題，然後根據報文樣例構造請求，進行我們的常規測試，不過這裡需要提一下的是，報文樣例中的測試數據一定要是可以用的！！！不然心累肯定是在所難免的。下圖是之前烏雲上某大佬挖洞過程中挖到介面文檔，借圖參考：

最後是測試工具的準備，常見的介面測試工具有SOAP UI、POSTMAN、BurpSuite等，工具的選擇主要還是要看介面使用的協議是什麼，比如使用soap協議的介面我們就可以使用SOAP UI進行測試，使用SOCKET協議的介面我們需要使用TCP助手等能發送socket請求的工具，而使用HTTP協議的介面，能用的工具就更多了，對於工具的選擇當然是怎麼順手怎麼選。0x04測試步驟介面測試的步驟肯定是因人而異的，大佬們的騷姿勢更是層出不窮~此處僅以簡單的HTTP介面測試為例，供和我一樣的菜鳥們參考使用。假設我們拿到一個基於HTTP協議的介面，沒有測試Demo，能用的東西只有介面文檔（純屬虛構，僅作講解）如下：

介面描述：序號項目說明1介面名稱餘額查詢2功能描述查詢餘額3應用場景目前應用於xxx的餘額查詢4請求方XX用戶5應答方xxx系統輸入介面:序號中文名稱英文名稱類型長度必填備註1.客戶IDCUST_IDINT10Y2.產品類別PRD_TYPEString10Y3.產品代碼PRD_CODEString10Y公有欄位4.支付密碼PASSWORDString10Y輸出介面：序號中文名稱英文名稱類型長度必須備註1.客戶IDCUST_IDINT10Y2.產品類別PRD_TYPEString10Y3.產品代碼PRD_CODEString10Y公有欄位4.客戶姓名NAMEString10N

5.餘額BALANCEString10N

輸入報文樣例：{ NAME：「xiaoming」， AGE：「18」}看到這樣的一段介面文檔，因為我們知道它是基於HTTP協議進行數據傳輸的，所以我們可以通過POSTMAN來發送請求報文，從介面文檔的描述中可以知道這是一個查詢餘額的介面，請求報文中必須要填的欄位有：CUST_ID、PRD_TYPE、PRD_CODE、PASSWORD，其中PRD_CODE是一個公共欄位，因此我們可以構造如下請求報文：{ CUST_ID："anquanzushiye"， PRD_TYPE："yuebaobao",

PRD_CODE:"666",

PASSWORD:"123456",}將上面的這段報文複製到POSTMAN中如圖：

點擊Send後，在POSTMAN中就能看到返回的響應報文如圖：

我們通過構造的報文成功用這個介面查到「安全祖師爺」的餘額。到這裡我們已經能夠正常的使用這個介面進行餘額查詢了。

通過IE瀏覽器做了系統代理後，就可以使用BurpSuite抓包如圖：

0x05經驗總結那些年踩過的坑，表哥們別再踩了~最後寫一下我在做介面測試的時候踩的坑和總結的經驗吧，希望對還沒有進行過介面測試的表哥們有所幫助。
  • 首先最好是能夠拿到開發在做功能性測試的時候使用的測試Demo，這樣後期會省下大量時間，否則需要自己去摸清楚他的介面調用原理，再去寫測試Demo會花去大量的項目時間。
  • 介面文檔和報文樣例是一定要有的，而且是越詳細越好，否則自己探索報文格式，構造報文或者去了解介面功能和應用場景都需要花費大把的時間，尤其是我們在進行邏輯關係的安全測試時，很多情況是必須要結合業務的應用場景來判斷是否存在安全問題。
  • 拿到的介面文檔一定要是最新的，需要與開發一再確認，因為前期項目準備的時候，開發提供的介面文檔可能已經是幾年前的了，這樣你在測試過程中，運氣好點的可能碰到測試數據過期了，運氣不好的可能會碰到，報文格式正確，請求怎麼構造都無法請求成功，然後最後得知該介面是幾年前的，如今已經刪除，不再使用。
  • 提前與開發溝通好，盡量保障測試樣例裏的數據都提前埋好，保障測試數據的可用性，不然這個在後面的測試中可能是測試進度的最大攔路虎，比如一個查詢介面，介面文檔中給出的數據根本無法查詢到任何信息，無任何回顯，這樣你就很難測試SQL注入、XSS漏洞等問題。如果條件允許測試樣例中所有數據都最好是開發新埋的數據，並且由開發將所有文檔中的介面都調通一遍，因為開發對系統給的熟悉程度肯定遠勝於剛拿到介面文檔的我們。
  • 介面的測試順序很重要，很多介面之間會有依賴關係，可能要按一定順序去測試，所以需要搞清楚系統的功能邏輯。比如要測試一個賬戶的餘額查詢介面，首先要通過創建賬戶介面創建一個用戶然後才能去查詢。
  • 報文結構一定要喫透、各欄位含義要注意記憶，這樣對於測試的時候需要修改報文中的哪個欄位就更清楚了，測試的時候也會更加的得心應手。
  • 所測試介面的功能可能與其他系統的介面會有交互，這時候就需要及時地去跟開發溝通並索要相應系統介面的介面文檔。比如一個申請介面，發送請求後可能需要其他系統的審批介面進行審批，這時候就需要審批介面的介面文檔了。
  • 看到文檔的右下角烏雲的水印，感觸頗多，在的時候沒什麼感覺，甚至反感，因為提交漏洞因為各種原因給幾十元RMB，當時戲稱打發要飯的，離開後卻再也沒有一個社區的更新內容及氛圍能及烏雲一半。。。聲明：本文章來自團隊成員辭令投稿，僅供安全愛好者研究學習，對於用於非法途徑的行為，作者不承擔任何責任。如果有想投稿的可以在公眾號聯繫我，有技術含量的文章如果通過可獲得稿費及加入我們的核心團隊，成員大部分為各大公司安全負責人和安全行業專家，0day多多內部資料多多，歡迎來撩。

推薦閱讀：

相關文章