Hi，大傢好。我們在開展接口測試時也需要關註安全測試，例如敏感信息是否加密、必要參數是否進行校驗。今天就給大傢介紹接口安全性測試應該如何開展，文末可領資料。走過路過不要錯過。一接口防刷案例分析1案例黃牛在12306網上搶票再倒賣並牟利。惡意攻擊競爭對手，如短信接口被請求一次，會觸發幾分錢的運營商費用。進行壓測時，用Apache Bench做壓力測試。2什麼行為判定為刷接口？接口請求次數多；接口請求概率頻繁，可能1秒上千次；用戶身份難以識別，可能會在刷的過程中隨時換瀏覽器或者ip；3如何判斷用戶粒度？根據當前網頁缺點：沒有任何意義，刷新頁面後用戶的身份就變瞭；根據session缺點：當用戶手動清除 cookie 的時候即失效；根據ip優點：偽造成本高；缺點：要考慮一個公司、一個小區的人一般會共享一個 ip，所以適當的要放寬對單一 ip 的請求限制；二如何處理惡意請求？1業務邏輯上限制結合業務邏輯對用戶行為進行分析，在代碼實現層面對進行完善的用戶權限判斷。例如限制用戶登錄，用戶必須滿足一定條件才可以（任務限制，金額限制，參與次數限制）；2IP頻率限制通過 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=1sql = 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總結接口安全性測試用例與一般測試用例的區別如下。相同點：基本的用例設計方法，參照相同的需求和業務；不同點：不受界面限制，邏輯性更重，存在隱藏內容，特殊值更多，傳輸格式種類繁多。文末福利：需要軟件測試相關學習資料的朋友關註並私信“資料”，即可領取免費哦