【安全】安全測試基本切入點

安全問題，一個全部互聯網公司揮之不去的傷痛，咱們也是被捅過以後才知道痛

大體列舉一下咱們在平常測試工做中應該要注意的安全問題（不涉及拿安全工具描述部分）

一、XSS類：包括存儲型和反射型

反射型最容易傳播的是搜索URL，注意處理處理這類URL中的XSS風險代碼，其中存儲型的危害比反射型的危害相對要更大，建議在平臺作統一處理

測試代碼舉例：http://drops.wooyun.org/tips/845

二、前端存在業務校驗

任何前端的檢驗都是爲提升用戶體驗而作，不具體任何安全性。若涉及業務上重要的校驗，須要確保先後端都存在統一的邏輯校驗

例如：數字大小範圍、時間長度範圍

三、POST表單冗餘數據

POST表單中提交了頁面或業務邏輯中不容許直接修改的數據

例如：經常使用的如手機號、郵箱，修改時會單獨跳轉到其餘頁面進行校驗，展現時以灰色不可編輯的形式展現在表單中

 

4、突破搜索參數數量

不少網站都會有搜索，搜索中有不少的條件可選，業務在設計時對部分搜索條件的數量進行了限制

在截獲請求以後，對搜索條件進行擴充後併發請求服務器，會對服務器形成比較大的壓力，這一條也與前面講到的<前端存在業務校驗>有關聯

五、密碼類傳輸

主要涉及註冊、登陸、修改密碼、忘記密碼這幾類經常使用操做，傳輸過程當中若使用明文密碼是很是不安全的

六、數據操做類帶有ID

密切注意編輯、刪除操做中帶有數據ID的狀況，水平越權操做數據，是很是危險的漏洞

七、數據庫存儲長度

在產品設計時會對數據的可輸入在前端作一個長度或輸入類型限制，是爲了保證更好的用戶體驗和確保有限的系統開銷

在前面咱們已經知道前端的限制是沒有任何安全意義的，經過工具修改數據類型和長度一樣可被正常提交，若出錯頗有可能會暴露數據庫的關鍵信息

八、重複提交請求|數據數量有限制

對於不容許重複提交的請求和數量有限制的存儲，不光在前端作限制，在服務端也在有對應的校驗和限制

九、數據回填

將用戶輸入的數據直接回填在JSP，而後做爲標籤中某個屬性值顯示在頁面的HTML中，這種狀況下若是不做處理，可能有XSS

常見有屬性有value和title

十、自動登陸

修改密碼、重置密碼類操做時，必定不要在最後附加一個自動登陸的動做。不可將這個判斷將給前端或者瀏覽器

十一、撞庫

網絡上有不少泄漏的帳號密碼資源，被拿到以後會用於撞庫，取得一些網站的用戶名密碼

這各狀況一般的作法是增長操做成本，好比限制每一個IP下請求對應接口的次數、出現驗證碼、鎖定帳戶2小時等

十二、暴力破解

重災區在找回密碼驗證碼，或者其餘的任何重要操做須要數字驗證碼的部分

建議：將驗證碼複雜度增長（由純屬4位數據變成6位數字和字母組合），同時加上圖形驗證碼，同時最好有其餘訪問防爆或監控機制