?我們?nèi)粘５慕涌跍y試工作主要是驗證接口的功能性（入?yún)ⅰ⒊鰠ⅰ⑦吔缰档龋以诮涌跍y試過程中遇到的一些接口安全性的問題，整理成了通用的測試點，不一定適用于全部的產(chǎn)品，僅做參考。

一、登錄接口校驗

(1) 驗證登錄接口中密碼是否密文傳輸

這個測試點聽起來很荒唐，應該大家都知道密碼應該加密，但是在很多時候，研發(fā)人員為了趕工就會忽略這個點，所以建議大家測試登錄功能的時候，一定要F12查看一下登錄接口中密碼是否是密文。

(2) 驗證登錄接口是否可以爆破登錄

對于一些安全性較高的系統(tǒng)，測試的時候有必要驗證一下是否可以爆破登錄，可以使用Burpsuit進行爆破登錄測試。當然現(xiàn)在很多系統(tǒng)都是用手機號碼進行動態(tài)登錄，如果還是常規(guī)的賬戶和密碼登錄，就一定要對安全性提出質(zhì)疑了，密碼強度符合等保要求么？驗證碼要不要加上去？

二、接口規(guī)則校驗

(1) 驗證接口類型是否合理

理論上來說，除了查詢接口使用GET，其余的接口都應該使用POST，這樣接口的安全性更高。沐沐以往的接口測試過程中確實遇到了不少業(yè)務接口使用get，參數(shù)拼接在url上及其不安全。此外，還有一個特殊情況，即不需要用戶登錄的系統(tǒng)，查詢類的接口也不建議使用GET，在安全掃描中會出現(xiàn)跨站點請求偽造的問題。

(2) 驗證新增和修改接口是否是獨立的接口

這個測試點有點離譜了，沐沐在測試過程中發(fā)現(xiàn)新增和修改接口共用同一個，這樣似乎是沒有什么問題，但是后期遇到了一些復雜的業(yè)務邏輯，新增和修改接口融合在一起，導致了生產(chǎn)數(shù)據(jù)被篡改。所以接口設計還是要嚴謹一點，新增和修改接口盡量是獨立的接口。

(3) 驗證POST接口中是否將參數(shù)拼接成URL

沐沐曾經(jīng)還遇到過將post接口的參數(shù)拼接到了url上，如果數(shù)據(jù)量較大的時候，url字符長度太大接口就會報錯，可能此類情況并不常見，但是遇到過就記錄下來了。

三、接口越權(quán)校驗

接口的越權(quán)分為水平越權(quán)和垂直越權(quán)，我們可以通過Burpsuit、Appcan等工具進行越權(quán)測試，測試過程中也遇到了以下問題：

• 驗證接口url上是否區(qū)域編碼、身份證號等參數(shù)；
• 驗證接口url上存在true或false時，進行篡改，功能、數(shù)據(jù)是否越權(quán)；
• 驗證接口url上存在type=1或2時，進行篡改，功能、數(shù)據(jù)是否越權(quán)；
• 接口參數(shù)中存在pagesize或者size時，進行篡改，是否進行最大值限制；
• 接口body參數(shù)中存在身份證號碼時，篡改參數(shù)值，接口是否返回正確提示。?