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