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).連接配接元件，例如http://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字段位址通常應該是轉賬按鈕所在的 網頁位址，應該也位于http://www.examplebank.com之下。而如果是CSRF攻擊傳 來的請求，Referer字段會是包含惡意網址的位址，不會位于 http://www.examplebank.com之下，這時候伺服器就能識别出惡意的通路。
2.添加校驗token
由于CSRF的本質在于攻擊者欺騙使用者去通路自己設定的位址，是以如果要求 在通路敏感資料請求時，要求使用者浏覽器提供不儲存在cookie中，并且攻擊 者無法僞造的資料作為校驗，那麼攻擊者就無法再執行CSRF攻擊。這種資料 通常是表單中的一個資料項。伺服器将其生成并附加在表單中，其内容是一個 僞亂數。當用戶端通過表單送出請求時，這個僞亂數也一并送出上去以供校驗。 正常的通路時，用戶端浏覽器能夠正确得到并傳回這個僞亂數，而通過CSRF 傳來的欺騙性攻擊中，攻擊者無從事先得知這個僞亂數的值，伺服器端就會因 為校驗token的值為空或者錯誤，拒絕這個可疑請求。
