摘要：眾所周知軟件測試分為四大類型，分別是功能測試自動化測試安全測試和性能測試，而安全測試是在功能測試和自動化測試之后，性能測試之前執(zhí)行的，以免安全測試后修改的一些問題會影響性能。

云智慧 汪曉宇

安全測試是在IT軟件產(chǎn)品的生命周期中，特別是產(chǎn)品開發(fā)基本完成到發(fā)布階段，對產(chǎn)品進(jìn)行檢驗(yàn)以驗(yàn)證產(chǎn)品符合安全需求定義和產(chǎn)品質(zhì)量標(biāo)準(zhǔn)的過程。一句話總結(jié)，安全測試就是檢查產(chǎn)品是否滿足安全需求的過程。

眾所周知軟件測試分為四大類型，分別是：功能測試、自動化測試、安全測試和性能測試，而安全測試是在功能測試和自動化測試之后，性能測試之前執(zhí)行的，以免安全測試后修改的一些問題會影響性能。

安全測試的內(nèi)容通常包括跳過權(quán)限驗(yàn)證、修改提交的請求信息等等，復(fù)雜一些的產(chǎn)品還要進(jìn)行SQL注入，跨站點(diǎn)腳本之類的測試，下面我們來看看安全問題對于互聯(lián)網(wǎng)產(chǎn)品的威脅。

SQL注入
由于程序員的水平及工作經(jīng)驗(yàn)參差不齊，相當(dāng)一大部分程序員在編寫程序的時候?qū)τ脩糨斎霐?shù)據(jù)的合法性沒有進(jìn)行判斷，就給應(yīng)用程序帶來一定的安全隱患，用戶可以通過提交一段數(shù)據(jù)庫查詢代碼，在得到的結(jié)果中分析出他想要的數(shù)據(jù)，這就是所謂的SQL Injection，即SQL注入。

對于一個產(chǎn)品或網(wǎng)站來說，如果缺少安全性測試，攻擊者可能會通過SQL盲注等方法直接暴庫（獲取所有的數(shù)據(jù)庫）或是獲取當(dāng)前項(xiàng)目所使用的數(shù)據(jù)庫名稱、Web應(yīng)用使用的賬戶、表、表結(jié)構(gòu)、字段名甚至數(shù)據(jù)庫中存儲的數(shù)據(jù)內(nèi)容等，這就是為什么我們的底層連接數(shù)據(jù)庫代碼要用一些防SQL注入技術(shù)的原因了。

SQL注入是從正常的WWW端口訪問，而且表面看起來跟一般的Web頁面訪問沒什么區(qū)別，所以目前市面的防火墻都不會對SQL注入發(fā)出警報，如果管理員沒查看服務(wù)器日志的習(xí)慣，可能被入侵很長時間都不會發(fā)覺。

展示一個最基本的漏洞：

某個系統(tǒng)登錄頁面，按照如圖方式輸入用戶面密碼后點(diǎn)擊登錄，結(jié)果登錄成功了，為什么呢？
登錄模塊的經(jīng)典SQL為：

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

假如用戶名為admin，密碼為123456的用戶登錄該系統(tǒng)，那么登錄時所產(chǎn)生的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‘—
這樣就以管理員的方式登錄進(jìn)去了或者以uname用戶成功登錄，對于SQL解析器來說，這是一個可以被解析并且可以被執(zhí)行的SQL語句。
我們知道m(xù)ysql代碼的注釋是用—來表示的，若我們變一下上面的SQL語句：

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

如上紅色部分是我們的輸入，這樣我們的SQL仍然可以被正確解析，導(dǎo)致user表被刪除（如果有刪除表權(quán)限的話）；如果沒有刪除表權(quán)限的話也沒關(guān)系，我們可以用delete from user刪除整張表的數(shù)據(jù)來代替刪除整張表的效果。
當(dāng)然，根據(jù)SQL需要的參數(shù)類型不同，所需的注入?yún)?shù)類型也不同，一般判斷某一參數(shù)點(diǎn)是否存在SQL注入的話可以用如下兩種方式：
1.在參數(shù)后面直接加‘來觀察是不是報錯，如果發(fā)現(xiàn)數(shù)據(jù)庫報內(nèi)部錯誤，則可以斷定有SQL注入的問題。
2.如果參數(shù)類型是int型，可以用and 1=1；and 1=2來判斷，如果and 1=1可以搜索出來，而and 1=2搜索出來的結(jié)果為null或報錯，那么我們認(rèn)識存在SQL注入漏洞，因?yàn)槿绻鸻nd 1=1和and 1=2沒有被打入系統(tǒng)的話，兩個返回值應(yīng)該與原始值一致，如果兩個都被完全當(dāng)做字符打入系統(tǒng)兩個返回值應(yīng)該都是空，如下圖1；對于String類型來說，我們可以用’and ‘1’=’1以及 ‘a(chǎn)nd ‘1’=’2來的判斷，如下圖2，道理與int類型一樣。如果是搜索型參數(shù)的話可以用‘a(chǎn)nd’%’來注入，如下圖3.根據(jù)實(shí)際遇到的情況不同需要有意識的去分析需要注入的參數(shù)，從而得到注入語句。

確定了SQL注入漏洞的存在，作為測試人員可以將這個漏洞報給開發(fā)人員進(jìn)行修復(fù)，但作為安全愛好者我們可以做的更多。最基本的方式是使用簡單的SQL 語句去猜解表名及字段名，確認(rèn)表名的方法可以用and true ，and false 的方式來判斷，如：and （select count(*) from user）>0 返回為空 證明user表存在，返回與原始頁面一致，則證明不存在；還有確認(rèn)字段的方法，如：and (select count(username) from user)>0；我們來重點(diǎn)說說確認(rèn)字段值的方法，這塊挺好玩的。
咱們以字符型來舉個例子，假如有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"
當(dāng)然也可以用ASCII的方法：
and (select ASCII(substr (username,1,1)) from users where id=1)=0~128
來看個實(shí)例：
1.先獲取長度，通過burpsuite工具攔截有sql注入的請求，對圖中高亮處進(jìn)行參數(shù)化，獲取到的name字段值長度為4；

2.再對應(yīng)獲取name字段值的每一位，然后分別把獲取到的每一位對應(yīng)ASCll碼中的值（參數(shù)化時是0~128）找出來就可以了。

字符的方式參數(shù)化時a~z A~Z 0~9，設(shè)置這些就可以了。

有時候開發(fā)人員會有意識的執(zhí)行某種輸入過濾以防止攻擊者輸入如’.selecet等字符，下面來看下怎么避開過了字符：
3.使用ASCII碼動態(tài)構(gòu)建替代，如在輸入中單引號被屏蔽，我們可以嘗試使用字符的ASCII碼代替：CHAR (39)。
4.如果select關(guān)鍵字被屏蔽，嘗試使用URL hex編碼：
%00SELECT
%53%45%4c%45%43%54
有些開發(fā)人員可能會過濾Select、Update、Delete這些關(guān)鍵字，但偏偏忘記區(qū)分大小寫，大家可以用selecT這樣嘗試一下。在猜不到字段名時，不妨看看網(wǎng)站上的表單，一般為了方便字段名都與表單的輸入框取相同的名字。
特別注意：地址欄的+號傳入程序后解釋為空格，%2B解釋為+號，%25解釋為%號，還有就是用Get方法注入時，IIS、Apache等Web服務(wù)器會記錄你提交的所有字符串，而對Post方法則不做記錄，所以能用 Post的網(wǎng)址盡量不用Get。

不過使用透視寶產(chǎn)品的同學(xué)就不用有此顧慮啦，因?yàn)橥敢晫毜讓舆B接數(shù)據(jù)庫的代碼已經(jīng)用了一些防SQL注入的技術(shù)，大可放心使用！

權(quán)限控制的危害
接下來說說權(quán)限控制，權(quán)限就好像公司的門禁，只有帶了門禁卡的同學(xué)才可以隨便進(jìn)出，而沒有門禁的人雖然可以出去，但是安全的公司只能讓里面的同學(xué)開門或別人刷卡才允許進(jìn)來，這就是最簡單的權(quán)限。如果少了安全性的保障，那么就會有一些人跳過權(quán)限去做一些他們不該做的事情。
舉個簡單的例子，一個登陸模塊只有輸入注冊過的用戶名密碼才能登錄成功，然后我們就老老實(shí)實(shí)的輸入我們自己注冊過的用戶名密碼（如abc@baidu .com /123 )，然后就可以登陸成功了。然而假如我們輸入一個不存在的用戶名呢？
先來看個SQL，登錄模塊到數(shù)據(jù)庫對比用的是如下SQL：
? ? select count(*) from user where uname="abc@baidu .com" and pwd=“123”
當(dāng)然實(shí)際應(yīng)用中的SQL會比這個復(fù)雜的多，若在SQL后邊加一些特殊的字符串‘ or "1=1其結(jié)果會是什么樣呢？
? ??select count(*) from user where uname=" abc@baidu .com " and pwd=“” or "1=1"
我們成功的繞過登錄權(quán)限認(rèn)證了……說好的只有注冊過的用戶才能登錄的呢？！……感覺再也不相信愛了有木有……
訪問控制大體可以分為三大類：垂直訪問控制、水平訪問控制和上下文相關(guān)訪問控制。如果想證明一個電商系統(tǒng)沒有權(quán)限問題，需要驗(yàn)證以下幾點(diǎn)：
第一，登錄是否可以不經(jīng)授權(quán)，也就是說有些請求本來是需要登錄后才能訪問的請求，結(jié)果在沒有登錄的情況下直接訪問該請求時也能訪問成功；
第二，有無越權(quán)問題，比如普通用戶是否可以訪問只有管理員用戶才能訪問的請求，如果可以說明存在越權(quán)的安全漏洞；
第三，如用戶A和用戶B同屬于普通用戶，每個人的訪問請求差不多，但顯示的內(nèi)容會不一樣，這時可以看看B是否能看到只有A才有權(quán)限看的內(nèi)容；
第四，有些功能需要分段操作才能成功，例如找回密碼功能，要先輸入用戶賬號，再通過回答各種密保問題，最后才能到獲取密碼，這時候如果某一步?jīng)]有做好權(quán)限控制，就可能導(dǎo)致應(yīng)用忽略之前的驗(yàn)證結(jié)果而直接執(zhí)行當(dāng)前階段問題；
第五，基于Referer消息頭的訪問控制，嘗試執(zhí)行一些獲得授權(quán)的特權(quán)操作,并提交一個缺少 Referer消息頭或其被修改的請求，如果這種改變導(dǎo)致應(yīng)用程序阻止請求，應(yīng)用程序很可能以不安全的方式使用Referer消息頭。這樣繼續(xù)嘗試使用一個未通過驗(yàn)證的用戶賬戶執(zhí)行相同操作，但提交原始的Referer消息頭，確認(rèn)系統(tǒng)是否能夠成功執(zhí)行該操作，有可能獲取管理員權(quán)限。
接下來說說修改提交數(shù)據(jù)內(nèi)容，比如我們上某寶買一個腎8，需要支付金額10000 RMB，支付的時候通過工具攔截支付請求，修改金額為1 RMB ，提交后發(fā)現(xiàn)竟然支付成功了。OMG！喜歡蘋果的小朋友再也不用擔(dān)心自己的腎了，哈哈。這些都是因?yàn)榇a里只在前端做了驗(yàn)證，而后端沒有做二次驗(yàn)證所導(dǎo)致的漏洞，透視寶產(chǎn)品幾乎所有的驗(yàn)證都是在后端做驗(yàn)證，所以壓根就不用擔(dān)心會出現(xiàn)客戶端繞過的漏洞啦。
跨站腳本的安全隱患
最后簡單說說跨站腳本的安全隱患，跨站腳本攻擊(Cross Site Scripting，簡稱XSS)是一種經(jīng)常出現(xiàn)在Web應(yīng)用中的計算機(jī)安全漏洞，它允許惡意Web用戶將代碼植入到提供給其它用戶使用的頁面中，用戶在觀看網(wǎng)頁時惡意腳本就會執(zhí)行。這類攻擊通過注入 HTML或js等腳本發(fā)動，攻擊成功后攻擊者可以得到私密網(wǎng)頁內(nèi)容和Cookies等，最近幾年XSS攻擊已經(jīng)成為最流行的Web攻擊方式。

XSS主要分成三大類：

1.反射式 XSS：不存儲到數(shù)據(jù)庫中，直接通過頁面302跳轉(zhuǎn)顯示到頁面的，僅在頁面上及時顯示惡意腳本，測試方法是、；
2.存儲式 XSS：存儲到數(shù)據(jù)庫中，然后從數(shù)據(jù)庫中讀取出來顯示到頁面上；
3.基于DOM的XSS：不保存到數(shù)據(jù)庫也不與后臺發(fā)生請求關(guān)系，只在dom或js上。
XSS的危害包括盜取各類用戶帳號（機(jī)器登錄帳號、用戶網(wǎng)銀帳號、各類管理員帳號），控制數(shù)據(jù)（包括讀取、篡改、添加、刪除企業(yè)敏感數(shù)據(jù)的能力），盜竊企業(yè)重要的具有商業(yè)價值的資料，非法轉(zhuǎn)賬，強(qiáng)制發(fā)送網(wǎng)站掛馬，控制受害者機(jī)器向其它網(wǎng)站發(fā)起攻擊等……
舉個存儲式XSS漏洞的例子，在一個交友網(wǎng)站上有人在個人信息里寫了一段腳本，如：

而該網(wǎng)站沒有對該段內(nèi)容進(jìn)行正確編碼，那么網(wǎng)站其他用戶看到這個用戶信息頁時，就會將當(dāng)前的cookie提交到該用戶的web站點(diǎn)上。
關(guān)于xss漏洞的資料大家自己可以在網(wǎng)上搜索了解，我這了就不仔細(xì)描述啦~

CSRF跨站請求偽造
既然說到XSS，那么順便把CSRF也簡單說下吧，CSRF（Cross-site Request Forgery）是跨站請求偽造的意思，也被稱為“one click attack”或者session riding，通?？s寫為CSRF 或者XSRF, 是一種對網(wǎng)站的惡意利用。盡管聽起來像跨站腳本(XSS)，但它與 XSS 非常不同，并且攻擊方式幾乎相左。
XSS 利用站點(diǎn)內(nèi)的信任用戶(受害者)，而CSRF 通過偽裝來自受信任用戶的請求來利用受信任的網(wǎng)站，通過社會工程學(xué)的手段(如通過電子郵件發(fā)送一個鏈接) 來蠱惑受害者進(jìn)行一些敏感性的操作，如修改密碼、修改E-mail、轉(zhuǎn)賬等，而受害者還不知道他已經(jīng)中招。
CSRF 的破壞力依賴于受害者的權(quán)限，如果受害者只是個普通的用戶, 則一個成功的CSRF 攻擊會危害用戶的個人數(shù)據(jù)以及一些功能；如果受害者具有管理員權(quán)限，則一個成功的CSRF攻擊甚至?xí){到整個網(wǎng)站的安全。與XSS 攻擊相比，CSRF 攻擊往往不太流行(因此對其進(jìn)行防范的資源也相當(dāng)稀少)和難以防范，故被認(rèn)為是比XSS更具危險性的，所以CSRF在業(yè)內(nèi)有個響當(dāng)當(dāng)?shù)拿帧了木奕恕?br>舉個典型的CSRF例子：

Alice 登錄了某金融網(wǎng)站mybank.com準(zhǔn)備進(jìn)行網(wǎng)上支付，Bob 知道這個金融網(wǎng)站并且意識到這個站點(diǎn)的轉(zhuǎn)賬功能有 CSRF 漏洞，于是Bob在myblog.com上發(fā)表了一條日志，這個日志支持 img 自定義功能，Bob 插入了這么一行HTML 代碼：

Alice 在自己的瀏覽器上打開了另一個標(biāo)簽頁正好讀到這個頁面，于是Alice 的賬戶就不知不覺地向Bob 的賬戶轉(zhuǎn)賬3000 元，而她卻毫不知情。
本次分享就先到這里吧，只是啟蒙下，詳細(xì)的過程以后有機(jī)會再給大家一一介紹，謝謝~