appscan 對api的手工檢測

標籤：開始   expires   ring   查看   介面   並且   目的   header   import   

AppScan 在 API 安全性測試中的執行個體介紹

在本項目中，API 遵循標準的的 REST 架構和背端伺服器進行通訊。針對 API 的功能測試由兩部分組成：一部分是用一個 Web 的測試頁面直接實現的，另一部分，由於 Web 頁面的局限性（比如不能任意修改 HTTP header），所以是通過 Shell 指令碼調用 curl 實現的。 並且這個 API 的測試環境沒有固定的網域名稱和 IP 位址。針對 Web 應用程式的安全性測試採用 AppScan Standard。項目實施過程中面臨這樣幾個問題：

• 針對 Web 頁面的非 REST API 測試，AppScan Standard 可以很好的勝任工作，但對於 API 部分，由於瀏覽器下的頁面的 HTTP 要求的局限性，API 測試頁面本身的對 API 的覆蓋率就不夠。所以通過 AppScan 掃描調用 API 的頁面，也難以保證覆蓋率。
• 系統沒有固定的網域名稱或 IP 位址， 導致每次要重新錄製和建立測試工作。一個掃描後的 scan 檔案內 Starting URL 也是一個唯讀屬性 1 所示。

圖 1 .匯出 Starting URL

在開始介紹解決方案之前，先介紹一下 AppScan 的錄製檔案。使用者通過普通的 Web 程式進行 AppScan 的測試，可以通過 Manual Explorer 錄製收集資訊。 這樣會產生一個 manualExplore_1.exd 的檔案在 AppScan 的掃描檔案.scan 壓縮包裡，scan 檔案是通過 Deflate 壓縮打包的，所以您可以使用一個解壓工具查看 scan 檔案裡的結構和檔案。在這裡使用者可以通過點擊功能表列中的 File-> Export -> Recorded Manual Explore 可以把 manualExplore_1.exd 檔案匯出， 2 所示。

圖 2 .匯出 manualExplore_1.exd 檔案

而當需要時可以通過重新匯入這個檔案，將之前錄製的資訊重新匯入一個新的 scan 任務。而當測試者要測試某個同樣的 Web 執行個體時，當執行個體的網域名稱或 IP 各不相同，並且測試者已經對其中一個進行了錄製，這樣就可以通過簡單修改這個 exd 檔案然後分別 import 到不同的測試執行個體中。

這個檔案本身是一個 XML 檔案，這個檔案大體結構，如清單 1。

清單 1 .exd 檔案結構

<?xml version="1.0" encoding="utf-16"?><!--Automatically created by AppScan at 1/16/2014 11:20:26 AM--><!--Do NOT Edit!--><requests>  <request>  ...  </request>  ...</requests><!--Number of Requests in file = 100-->

從注釋中我們也可以看出，這個檔案是 AppScan 自動產生的檔案，因此修改時要特別注意，因為錯誤的修改可能使 AppScan 會無法識別錄製的 HTTP 要求，或者錯誤的識別 HTTP 的請求。最後一行的注釋表明裡這裡記錄了多少個 HTTP 的請求。

這些請求會都放在<requests>裡，一個 request 的錄製資訊結構，如清單 2。

清單 2 .request 的錄製結構

<request scheme="https" host="www.ibm.com" path="/" port="443"  method="GET" SessionRequestType="Login" ordinal="15"><raw encoding="none"></raw><cookie name="JSESSIONID" value="XXX" path="/" domain="www.ibm.com" secure="False" expires="1/1/0001 12:00:00 AM" /><parameter name="XXX" captureIndex="0" value="" type="QUERY" linkParamType="simplelink" separator="&" operator="=" reportName="XXX" /><sessionCookies>  <cookie name="JSESSIONID" value="XXX path="/" domain="www.ibm.com" secure="False" expires="1/1/0001 12:00:00 AM" /></sessionCookies>  </request>

其中<raw>部分是原始的請求資料，包括 HTTP Header 和 body 部分的全部資料。 而其他的是從這個未經處理資料中結構化出來的一些資料，熟悉的 HTTP 的應該對這個結構化的資料並不陌生。比如 scheme 是請求的協議，session 是 HTTP header 裡的 session 部分，parameter 是 URL 裡的參數。在這裡 ordinal 是對 request 在這個錄製檔案內的一個計數。

熟悉了檔案的結構我們就可以對其進行修改或添加自己的 HTTP 錄製的資訊。來提高測試的覆蓋率。

下面介紹一下如何解決前面提到的兩個問題。

針對問題一，這裡舉一個簡單的例子：現有一個針對資料庫查詢的請求，有兩個參數分別是 parm1 和 parm2，並且已經有對這個 API 的掃描的 exd 檔案如下：

清單 3 .已有的錄製資訊

<request scheme="https" host="www.site1.com" path="/test/API1" port="443" method="POST" SessionRequestType="Login" ordinal="146"> <raw encoding="none">POST /test/API1 HTTP/1.1Host: www.site1.comUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.7,ja;q=0.3Connection: keep-aliveContent-Type: application/x-www-form-urlencoded; charset=UTF-8X-Requested-With: XMLHttpRequestReferer: https://www.site1.com/Content-Length: 83Cookie: JSESSIONID=0000F7u3iiCtkF0SIR4G9viBIQr:156f4da9-0cc6-4460-9ac9-f791e0aac903Pragma: no-cacheCache-Control: no-cacheparm1=test1&parm2=test2</raw> <cookie name="JSESSIONID" value="0000F7u3iiCtkF0SIR4G9viBIQr:156f4da9-0cc6-4460-9ac9-f791e0aac903" path="/" domain="www.site1.com" secure="False" expires="1/1/0001 12:00:00 AM" /> <parameter name="parm1" captureIndex="0" value="test1" type="BODY" linkParamType="simplelink" separator="&" operator="=" reportName="parm1" /> <parameter name="parm2" captureIndex="0" value="test2" type="BODY" linkParamType="simplelink" separator="&" operator="=" reportName="parm2" /> <sessionCookies><cookie name="JSESSIONID" value="0000F7u3iiCtkF0SIR4G9viBIQr:156f4da9-0cc6-4460-9ac9-f791e0aac903" path="/" domain="www.site1.com" secure="False" expires="1/1/0001 12:00:00 AM" /> </sessionCookies>  </request>

現在由於介面的更改，其中一個參數的 name 由原來的 parm1 改為新的 newparm。如果按照常規的流程，我們還需要對整個結構的測試頁面進行掃描。而其實我們只用改掉文檔裡相應的部分，將原來的 exd 的參數部分改成如清單 4。

清單 4 .修改後的 exd 檔案

<request scheme="https" host="www.site1.com" path="/test/API1" port="443" method="POST" SessionRequestType="Login" ordinal="146"><raw encoding="none">POST /test/API1 HTTP/1.1...Content-Length: 23newparm=test1&parm2=test2</raw>...<parameter name="newparm" captureIndex="0" value="test1" type="BODY" linkParamType="simplelink" separator="&" operator="=" reportName="newparm" />...  </request>

針對第二個問題，使用上面提到的方法，將 exd 檔案匯出，並修改補充後存檔備份。當有新的不同網域名稱或 IP 的任務時，可以通過建立 scan 任務，完成任務配置後，複製一份已經存檔的 exd 檔案，將檔案裡所有的網域名稱或 IP 替換成新的網域名稱或 IP 並儲存，然後再建立的 scan 檔案內匯入這個錄製檔案就可以了。

通過上面的方法，項目的問題很好的得到瞭解決，即保證了測試覆蓋率，又確保了測試靈活性。

回頁首

總結

隨著 API 的廣泛應用，API 安全性測試變得越來越重要，本文介紹的 AppScan Standard 在 API 安全性測試中的應用方法，是一個簡單而有效方法，可以很好的提高 API 安全性測試效率，提高測試覆蓋率。

appscan 對api的手工檢測