29
2021-12
今天距2022年3天
這是ITester軟體測試小棧第340次推文
本文3724字，閱讀約需10分鐘
Hi，大家好。我們在開展接口測試時也需要關注
安全測試
，例如敏感資訊是否加密、必要參數是否進行校驗。今天就給大家介紹接口安全性測試應該如何開展，文末附年終總結模闆，需要年末彙報的童鞋們，走過路過不要錯過。
一接口防刷案例分析
1案例
- 黃牛在12306網上搶票再倒賣并牟利。
- 惡意攻擊競争對手，如短信接口被請求一次，會觸發幾分錢的營運商費用。
- 進行壓測時，用Apache Bench做壓力測試。
2什麼行為判定為刷接口？
- 接口請求次數多；
- 接口請求機率頻繁，可能1秒上千次；
- 使用者身份難以識别，可能會在刷的過程中随時換浏覽器或者ip；
3如何判斷使用者粒度？
根據目前網頁
- 缺點：沒有任何意義，重新整理頁面後使用者的身份就變了；
根據session
- 缺點：當使用者手動清除 cookie 的時候即失效；
根據ip
- 優點：僞造成本高；
- 缺點：要考慮一個公司、一個小區的人一般會共享一個 ip，是以适當的要放寬對單一 ip 的請求限制；
二如何處理惡意請求？
1業務邏輯上限制
結合業務邏輯對使用者行為進行分析，在代碼實作層面對進行完善的使用者權限判斷。例如限制使用者登入，使用者必須滿足一定條件才可以（任務限制，金額限制，參與次數限制）；
2 IP頻率限制
通過 memcached 和 redis 都可以實作成熟的方案。
3驗證碼及短信限制
可以通過要求使用者輸入驗證碼或短信驗證碼驗證使用者真實性，但是也要保證短信接口不會被刷。
4防止XSS、CSRF、SQL注入攻擊
防止XSS、CSRF、SQL注入常見的WEB接口安全防範手段，對參數過濾轉義，表單驗證等。
三接口安全性用例設計
1接口安全性設計原則
1.接口類型盡量使用https帶SSL證書模式；
2.接口參數使用簽名（非對稱加密算法）；
3.接口參數需要校驗；
4.每次請求需要使用者指令；
5.多次失敗後需要有鎖定機制；
6.接口對應使用者權限，使用者隻能調用有權限的接口；
7.系統接口做過負荷機制用來保護系統安全；
2接口安全性用例設計
(1) 輸入驗證
用戶端驗證伺服器端驗證(禁用腳本調試，禁用Cookies)
1.輸入很大的數（如72932398579857），輸入很小的數(負數)；
2.輸入超長字元,如對輸入文字長度有限制,則嘗試超過限制,剛好到達限制字數時有何反應；
3.輸入特殊字元,如:~!@#$%^&*()_+<>:”{}|；
4.輸入中英文空格，輸入字元串中間含空格，輸入首尾空格；
5.輸入特殊字元串NULL,null，0x0d 0x0a；
6.輸入正常字元串；
7.輸入與要求不同類型的字元，如: 要求輸入數字則檢查正值,負值,零值（正零，負零）,小數,字母,空值; 要求輸入字母則檢查輸入數字；
8.輸入html和javascript代碼；
9.對于像回答數這樣需檢驗數字正确性的測試點，不僅對比其與問題最終頁的回答數，還要對回答進行添加删除等操作後檢視變化，例如：
①輸入<html”>”hello</html>，是否出錯；
②輸入<input type=”text” name=”user”/>，是否出現文本框；
③輸入<script type=”text/javascript”>alert(“提示”)</script>，是否出現提示。
(2) 使用者名和密碼
1.輸入密碼是否直接顯示在輸入欄；
2.是否有密碼最小長度限制（密碼強度）；
3.使用者名和密碼中是否支援輸入空格或回車；
4.是否允許密碼和使用者名一緻；
5.防惡意注冊：可否用自動填表工具自動注冊使用者；
6.有無預設的超級使用者（admin等，關鍵字需屏蔽）；
7.有無超級密碼；
8.是否有校驗碼；
9.密碼錯誤次數有無限制；
10.是否大小寫敏感；
11.密碼是否以明碼顯示在輸出裝置上；
12.強制修改的時間間隔限制（初始預設密碼）；
13.token的唯一性限制（需求是否需要）；
14.token過期失效後，是否可以不登入而直接浏覽某個頁面；
15.哪些頁面或者檔案需要登入後才能通路/下載下傳；
16.cookie中或隐藏變量中是否含有使用者名、密碼、userid等關鍵資訊；
(3) 檔案上傳下載下傳
1.上傳檔案是否有格式限制，是否可以上傳exe檔案；
2.上傳檔案是否有大小限制，上傳太大的檔案是否導緻異常錯誤；
3.通過修改擴充名的方式是否可以繞過格式限制，是否可以通過壓包方式繞過格式限制；
4.是否有上傳空間的限制，是否可以超過空間所限制的大小；
5.上傳0K的檔案是否會導緻異常錯誤；
6.上傳是否有成功的判斷，上傳過程中中斷，程式是否判斷上傳是否成功；
7.對于檔案名中帶有中文字元，特殊字元等的檔案上傳；
8.上傳并不存在的檔案是否會導緻異常錯誤；
(4) URL校驗
1.某些需登入後或特殊使用者才能進入的頁面，是否可以通過直接輸入URL的方式進入；
2.對于帶參數的網址，惡意修改其參數(若為數字,則輸入字母,或很大的數字,或輸入特殊字元等)，打開網址是否出錯，是否可以非法進入某些頁面；
3.搜尋頁面URL中含有關鍵字，輸入html代碼或JavaScript看是否在頁面中顯示或執行；
(5) 越權通路
在一個産品中，使用者A通常隻能夠編輯自己的資訊，他人的資訊無法檢視或者隻能檢視已有權限的部分，但是由于程式不校驗使用者的身份，A使用者更改自己的id值就進入了B使用者的首頁，可以檢視、修改B使用者的資訊，這種漏洞稱之為越權漏洞。
舉例：使用者登入app成功，系統記錄使用者id，例如userid為1。
安全風險：此時使用者通過工具校驗發送消息将userid設定為2後是否登入成功，及使用者是否可以通過修改userid來通路其它使用者資源，引發嚴重問題。
(5) 防止SQL注入
①sql拼接：jdbc/obdc連接配接連結資料庫
select * from userInfo where userId=1
sql = sql + condition
②三方元件，比如java裡面的hibernate,ibatis,jpa通過各種sql查詢業務資訊，甚至破壞系統表；
示例：在檔案框中輸入，在參數值中輸入如下。
(6) 跨站腳本攻擊（XSS）
原理：利用XSS的攻擊者進行攻擊時會向頁面插入惡意Script代碼，當使用者浏覽該頁面時，嵌入在頁面裡的Script代碼會被執行，進而達到攻擊使用者的目的。同樣會造成使用者的認證資訊被擷取，仿冒使用者登入，造成使用者資訊洩露等危害。
安全風險：文字中可以輸入js腳本，例如<script src=‘wrong URL’></script>這種有安全性的腳本，其它使用者進入後可以擷取該使用者的cookie資訊，即可以對該使用者資源進行操作。
示例：在輸入框中輸入，這些腳本如果有對應的回報就是有問題。
(7) 跨站請求僞造（CSRF）
CSRF是一種對網站的惡意利用，過僞裝來自受信任使用者的請求來利用受信任的網站。
舉例：在APP上打開某個網站時，突然彈出您已經中獎的提示和連結。
安全風險：點開連結後會跳轉到對應異常界面，并且使用者本地資訊可能已經被擷取，如果在跳出界面進行相關操作，比如銀行相關操作會引起更大的安全問題和嚴重損失。
安全防護：使用post，不使用get修改資訊；驗證碼，所有表單的送出建議需要驗證碼；在表單中預先植入一些加密資訊，驗證請求是此表單發送。
3 總結
接口安全性測試用例與一般測試用例的差別如下。
相同點：基本的用例設計方法，參照相同的需求和業務；
不同點：不受界面限制，邏輯性更重，存在隐藏内容，特殊值更多，傳輸格式種類繁多。