接口安全測試

1、後臺接口分類

一、接口類別：restful(json) soap(xml)

二、協議 ：http https(ssl)

 

三、restful接口請求類型

get操做是安全的

post的操做是不安全的 同put

delete也是不安全的

 

四、現狀和問題

大部分APP的接口都採用restful架構，restful最重要的一個設計原則就是客戶端與服務端的交互在請求之間是無狀態的。大部分都採用token的認證方式。

token分別在兩臺手機上登錄微信

 

2、接口安全設計原則

一、接口類型儘可能使用https帶SSL證書模式

二、接口參數使用簽名（非對稱加密算法）

三、接口參數須要校驗

註冊：註冊機

四、每次請求須要用戶命令

五、屢次失敗後須要有鎖定機制

六、接口對應用戶權限，用戶只能調用有權限的接口

用戶的權限

接口權限：系統有多個模塊，每一個模塊有多個接口，我只購買了2個模塊的服務，只分配兩個模塊的接口來使用---license

七、系統接口作過負荷機制用來保護系統安全

過負載----保護系統，再好的系統也有瓶頸，超過請求後提示系統忙

（1）提交請求後當即提示系統忙

（2）提交請求後一段時間後提示系統忙

靜態：

動態：

 

3、接口安全設計注意事項：

一、對用戶任何輸入的都須要注意

二、不能只在客戶端進行校驗

三、服務端返回的任何服務錯誤信息不要返回給用戶

 

4、經常使用接口安全測試類

一、sql注入

(1)sql拼接：jdbc/obdc ----連接數據庫

select * from userInfo where userId=1 ---查詢id爲1的用戶

sql = sql + condition

（2）使用第三方組件，好比java裏面的hibernate,ibatis,jpa

經過各類sql查詢業務信息，甚至破壞系統表

 

（3）sql注入注意事項：

1.永遠不要信任用戶的輸入。對用戶的輸入進行校驗，能夠經過正則表達式，或限制長度；對單引號和雙"-"進行轉換等。

2.永遠不要使用動態拼裝sql，可使用參數化的sql或者直接使用存儲過程進行數據查詢存取。

3.永遠不要使用管理員權限的數據庫鏈接，爲每一個應用使用單獨的權限有限的數據庫鏈接。

4.不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息。

5.應用的異常信息應該給出儘量少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝

 

二、xss攻擊

（1）描述：利用XSS的攻擊者進行攻擊時會向頁面插入惡意Script代碼，當用戶瀏覽該頁面時，嵌入在頁面裏的Script代碼會被執行，從而達到攻擊用戶的目的。一樣會形成用戶的認證信息被獲取，仿冒用戶登陸，形成用戶信息泄露等危害

（2）安全風險：文字中能夠輸入js腳本，例如<script src=‘wrong URL’></script>這種有安全性的腳本，其它用戶進入後能夠獲取該用戶的cookie信息，便可以對該用戶資源進行操做

 

三、越權訪問

（1）描述：在一個產品中，一個正常的用戶A一般只可以編輯本身的信息，別人的信息沒法查看或者只能查看的權限，可是因爲程序不校驗用戶的身份，A用戶更改本身的id值就進入了B用戶的主頁，能夠查看、修改B用戶的信息，這種漏洞咱們就將其稱之爲越權漏洞

（2）舉例：用戶登陸app成功，系統記錄用戶id，例如userid爲1。

安全風險：此時用戶經過工具發送消息將userid設置爲2後可能登錄成功，及用戶能夠經過修改userid來訪問其它用戶資源，引起嚴重問題。

 

四、csrf 請求僞造

（1）描述：CSRF是一種對網站的惡意利用，過假裝來自受信任用戶的請求來利用受信任的網站。

（2）舉例：在APP上打開某個網站時，忽然彈出您已經中獎的提示和連接

安全風險：點開連接後會跳轉到對應異常界面，而且用戶本地信息可能已經被獲取，若是在跳出界面進行相關操做，好比銀行相關操做會引發更大的安全問題和嚴重損失。

（3）安全防禦

1. 使用post，不使用get修改信息

2. 驗證碼，全部表單的提交建議須要驗證碼

3. 在表單中預先植入一些加密信息，驗證請求是此表單發送