軟件測試中平常測試中融入的安全測試

軟件測試中平常測試中融入的安全測試

1. 用戶權限測試

    (1) 用戶權限控制

        1) 用戶權限控制主要是對一些有權限控制的功能進行驗證

        2) 用戶A才能進行的操做，B是否可以進行操做（可經過竄session，將在下面介紹）

        3）只能有A條件的用戶才能查看的頁面，是否B可以查看（可直接敲URL訪問）

    (2) 頁面權限控制

        1） 必須有登錄權限的頁面，是否可以在不登錄狀況下進行訪問

        2）必須通過A——B——C的頁面，是否可以直接由A——C?



2. URL安全測試

    （1）適用範圍： URL中含有參數，也就是經過GET方式傳遞的HTTP請求

    （2）什麼叫GET方式？

        HTTP 定義了與服務器交互的不一樣方法，最基本的方法是 GET 和 POST。

        GET方式在客戶端經過URL提交數據，數據在URL中能夠看到，例如在平常中訂購服務：

        http://pay.daily.taobao.net/mysub/subdeal/order_sub_deal.htm?servId=2

       POST方式，數據放置在HTML HEADER內提交，數據在URL中看不到

       GET只能傳輸比較少的數據，安全性較低，POST傳輸數據較多，安全性也比GET高

    （3）測試關注點：

       1） URL 參數檢查：

       A: 對URL中參數信息檢查是否正確

       如：URL中的訂單號、金額容許顯示出來的話，須要驗證其是否正確

       B: 對於一些重要的參數信息，不該該在URL中顯示出來

       如：用戶登錄時登陸名、密碼是否被顯示出來了 ，

       2） URL參數值篡改

       修改URL中的數據，看程序是否能識別：

       如：對於如下URL，修改其中planId，看是程序是否能夠識別：

       http://pay.daily.taobao.net/mysub/plan/subplan/confirmSubPlanInfo.htm?planId=878

       又如：對於URL中包含金額參數的，修改金額看是否可以提交成功（可能致使用戶把2元金額改爲1元金額       能提交），還有修改訂單號等重要信息看是否會報錯

       3） URL中參數修改進行XSS注入：

       什麼是XSS？

       XSS的全稱是Cross Site Script（跨站點腳本）

       XSS的原理很簡單，即進行腳本注入，URL執行時即把此腳本進行了執行，通常都是JavaScript腳本，如<script>alter(「abc」)<script>在URL中進行XSS注入，也就是把URL中的參數改爲JS腳本。

        4） URL參數中進行SQL 注入

       什麼是SQL注入？

       SQL注入全稱是SQL Injection ，當應用程序使用輸入內容來構造動態sql語句以訪問數據庫時，會發生sql注入攻擊，如查詢、插入數據時。

       測試方法： URL中寫入SQL注入語句，看是否被執行，如：’or 1=1;shutdown

通常狀況下要進行SQL注入攻擊，須要對數據庫類型、表名、判斷邏輯、查詢語句等比較清楚纔可以寫出有效的SQL注入語句。



3. 表單提交安全測試

適用範圍：有表單提交的地方、有HTTP請求的地方(包括GET、POST請求)

測試關注點：

1） 表單中注入XSS腳本

什麼是XSS？這已在上一節中說明。URL中須要檢測XSS注入，表單中更須要驗證

測試方法：即在表單填寫框中直接注入JS腳本

如在表單中輸入XSS腳本，程序是不該該讓腳本執行的

2） 表單中注入SQL 腳本

與URL中參數進行SQL注入相似，就是在表單中寫入SQL注入腳本提交看是否會有問題



4. Session測試

(1) Session是客戶端與服務器端創建的會話，老是放在服務器上的，服務器會爲每次會話創建一個sessionId，每一個客戶會跟一個sessionID對應。

並非關閉瀏覽器就結束了本次會話，一般是用戶執行「退出」操做或者會話超時時纔會結束。

(2) 測試關注點：

1) Session互竄

Session互竄便是用戶A的操做被用戶B執行了。

驗證Session互竄，其原理仍是基於權限控制，如某筆訂單隻能是A進行操做，或者只能是A才能看到的頁面，可是B的session竄進來卻可以得到A的訂單詳情等。

Session互竄方法：

多TAB瀏覽器，在兩個TAB頁中都保留的是用戶A的session記錄，而後在其中一個TAB頁執行退出操做，登錄用戶B, 此時兩個TAB頁都是B的session，而後在另外一個A的頁面執行操做，查看是否能成功。 預期結果：有權限控制的操做，B不能執行A頁面的操做，應該報錯，沒有權限控制的操做，B執行了A頁面 操做後，數據記錄是B的而不是A的。

2) Session超時

基於Session原理，須要驗證系統session是否有超時機制，還須要驗證session超時後功能是否還能繼續走下去。

測試方法：

一、打開一個頁面，等着10分鐘session超時時間到了，而後對頁面進行操做，查看效果。

二、多TAB瀏覽器，在兩個TAB頁中都保留的是用戶A的session記錄，而後在其中一個TAB頁執行退出操做，立刻在另一個頁面進行要驗證的操做，查看是能繼續到下一步仍是到登陸頁面。