1.SQL注入
原理:
1).SQL命令可查詢、插入、更新、刪除等，命令的串接。而以分號(hào)字元為不同命 令的區(qū)別。（原本的作用是用于SubQuery或作為查詢、插入、更新、刪除……等 的條件式）
2).SQL命令對于傳入的字符串參數(shù)是用單引號(hào)字元所包起來。（但連續(xù)2個(gè)單引 號(hào)字元，在SQL資料庫中，則視為字串中的一個(gè)單引號(hào)字元）
3).SQL命令中，可以注入注解
預(yù)防:
1).在設(shè)計(jì)應(yīng)用程序時(shí)，完全使用參數(shù)化查詢（Parameterized Query）來設(shè)計(jì)數(shù)據(jù) 訪問功能。
2).在組合SQL字符串時(shí)，先針對所傳入的參數(shù)作字元取代（將單引號(hào)字元取代為 連續(xù)個(gè)單引號(hào)字元）。
3).如果使用php開發(fā)網(wǎng)頁程序的話，亦可打開PHP的魔術(shù)引號(hào)（Magic quote）功 能（自動(dòng)將所有的網(wǎng)頁傳入?yún)?shù)，將單引號(hào)字元取代為連續(xù)2個(gè)單引號(hào)字元）。
4).其他，使用其他更安全的方式連接SQL數(shù)據(jù)庫。例如已修正過SQL注入問題的 數(shù)據(jù)庫
5).連接組件，例如ASP.NET的SqlDataSource對象或是 LINQ to SQL。
使用SQL防注入系統(tǒng)。
2. XSS攻擊
原理:
xss攻擊可以分成兩種類型：
1.非持久型xss攻擊
非持久型xss攻擊是一次性的，僅對當(dāng)次的頁面訪問產(chǎn)生影響。非持久型xss攻擊 要求用戶訪問一個(gè)被攻擊者篡改后的鏈接，用戶訪問該鏈接時(shí)，被植入的攻擊腳本 被用戶游覽器執(zhí)行，從而達(dá)到攻擊目的。
2.持久型xss攻擊
持久型xss攻擊會(huì)把攻擊者的數(shù)據(jù)存儲(chǔ)在服務(wù)器端，攻擊行為將伴隨著攻擊數(shù)據(jù)
一直存在。下面來看一個(gè)利用持久型xss攻擊獲取session id的實(shí)例。
防范:
1.基于特征的防御
XSS漏洞和著名的SQL注入漏洞一樣，都是利用了Web頁面的編寫不完善，所以每一個(gè)漏洞所利用和針對的弱點(diǎn)都不盡相同。這就給XSS漏洞防御帶來了困難：不可能以單一特征來概括所有XSS攻擊。
傳統(tǒng)XSS防御多采用特征匹配方式，在所有提交的信息中都進(jìn)行匹配檢查。對于這種類型的XSS攻擊，采用的模式匹配方法一般會(huì)需要對“JAVAscript”這個(gè)關(guān)鍵字進(jìn)行檢索，一旦發(fā)現(xiàn)提交信息中包含“JavaScript”，就認(rèn)定為XSS攻擊。這種檢測方法的缺陷顯而易見：駭客可以通過插入字符或完全編碼的方式躲避檢測：
1). 在javascript中加入多個(gè)tab鍵，得到
<IMG SRC="jav ascript:alert('XSS');">;
2). 在javascript中加入(空格)字符，得到
<IMG SRC="javascri pt:alert('XSS');">;
3). 在javascript中加入(回車)字符，得到
<IMG SRC="javasc
ript:alert('XSS');">;
4). 在javascript中的每個(gè)字符間加入回車換行符，得到
<IMG SRC="javascriprnt:alert('XSS');">
5). 對”javascript:alert(‘XSS’)”采用完全編碼，得到
<IMGSRC=javascrip?74:alert('XSS')>
上述方法都可以很容易的躲避基于特征的檢測。而除了會(huì)有大量的漏報(bào)外，基于特征的
還存在大量的誤報(bào)可能：在上面的例子中，對上述某網(wǎng)站這樣一個(gè)地址，由于包含了關(guān)鍵字“javascript”，也將會(huì)觸發(fā)報(bào)警。
2.基于代碼修改的防御
和SQL注入防御一樣，XSS攻擊也是利用了Web頁面的編寫疏忽，所以還有一種方法就是從Web應(yīng)用開發(fā)的角度來避免：
對所有用戶提交內(nèi)容進(jìn)行可靠的輸入驗(yàn)證，包括對URL、查詢關(guān)鍵字、HTTP頭、POST數(shù)據(jù)等，僅接受指定長度范圍內(nèi)、采用適當(dāng)格式、采用所預(yù)期的字符的內(nèi)容提交，對其他的一律過濾。
實(shí)現(xiàn)Session標(biāo)記(session tokens)、CAPTCHA系統(tǒng)或者HTTP引用頭檢查，以防功能被第三方網(wǎng)站所執(zhí)行。
確認(rèn)接收的的內(nèi)容被妥善的規(guī)范化，僅包含最小的、安全的Tag(沒有javascript)，去掉任何對遠(yuǎn)程內(nèi)容的引用(尤其是樣式表和javascript)，使用HTTP only的cookie。
3. CSRF攻擊
原理:
CSRF攻擊原理比較簡單，假設(shè)Web A為存在CSRF漏洞的網(wǎng)站，Web B為攻 擊者構(gòu)建的惡意網(wǎng)站，User C為Web A網(wǎng)站的合法用戶。
1.用戶C打開瀏覽器，訪問受信任網(wǎng)站A，輸入用戶名和密碼請求登錄網(wǎng)站A；
2.在用戶信息通過驗(yàn)證后，網(wǎng)站A產(chǎn)生Cookie信息并返回給瀏覽器，此時(shí)用 戶登錄網(wǎng)站A成功，可以正常發(fā)送請求到網(wǎng)站A；
3.用戶未退出網(wǎng)站A之前，在同一瀏覽器中，打開一個(gè)TAB頁訪問網(wǎng)站B；
4.網(wǎng)站B接收到用戶請求后，返回一些攻擊性代碼，并發(fā)出一個(gè)請求要求訪 問第三方站點(diǎn)A；
5.瀏覽器在接收到這些攻擊性代碼后，根據(jù)網(wǎng)站B的請求，在用戶不知情的 情況下攜帶Cookie信息，向網(wǎng)站A發(fā)出請求。網(wǎng)站A并不知道該請求其實(shí)是 由B發(fā)起的，所以會(huì)根據(jù)用戶C的Cookie信息以C的權(quán)限處理該請求，導(dǎo)致 來自網(wǎng)站B的惡意代碼被執(zhí)行。
防范:
1.檢查Referer字段
HTTP頭中有一個(gè)Referer字段，這個(gè)字段用以標(biāo)明請求來源于哪個(gè)地址。在 處理敏感數(shù)據(jù)請求時(shí)，通常來說，Referer字段應(yīng)和請求的地址位于同一域 名下。以上文銀行操作為例，Referer字段地址通常應(yīng)該是轉(zhuǎn)賬按鈕所在的 網(wǎng)頁地址，應(yīng)該也位于www.examplebank.com之下。而如果是CSRF攻擊傳 來的請求，Referer字段會(huì)是包含惡意網(wǎng)址的地址，不會(huì)位于 www.examplebank.com之下，這時(shí)候服務(wù)器就能識(shí)別出惡意的訪問。
2.添加校驗(yàn)token
由于CSRF的本質(zhì)在于攻擊者欺騙用戶去訪問自己設(shè)置的地址，所以如果要求 在訪問敏感數(shù)據(jù)請求時(shí)，要求用戶瀏覽器提供不保存在cookie中，并且攻擊 者無法偽造的數(shù)據(jù)作為校驗(yàn)，那么攻擊者就無法再執(zhí)行CSRF攻擊。這種數(shù)據(jù) 通常是表單中的一個(gè)數(shù)據(jù)項(xiàng)。服務(wù)器將其生成并附加在表單中，其內(nèi)容是一個(gè) 偽亂數(shù)。當(dāng)客戶端通過表單提交請求時(shí)，這個(gè)偽亂數(shù)也一并提交上去以供校驗(yàn)。 正常的訪問時(shí)，客戶端瀏覽器能夠正確得到并傳回這個(gè)偽亂數(shù)，而通過CSRF 傳來的欺騙性攻擊中，攻擊者無從事先得知這個(gè)偽亂數(shù)的值，服務(wù)器端就會(huì)因 為校驗(yàn)token的值為空或者錯(cuò)誤，拒絕這個(gè)可疑請求。
