Cross-Site Scripting 可以分為反射式(Reflected)、儲存式(Stored)：

• Reflected XSS  利用網站從存取可從外部修改的參數時，未經驗證而被埋入惡意語法，通常是利用可供輸入的欄位表單或可經proxy 修改的參數等功能，埋入惡意 script 語法，再將惡意連結偽裝讓受害人點擊，藉此騙過伺服器驗證而被盜取用戶端的身分資訊，並傳至第三方站台做為收集或掌控。

• Stored XSS 則為利用類似留言板等網站功能，將外部輸入的惡意語法直接儲存在資料庫，當每個用戶存取到該頁面時，都會讀取到該惡意行為而被攻擊，受害者的層面更為廣大。

由此可知，XSS 的攻擊面向很多樣化，就算針對特殊符號阻擋，還是可能利用編碼或其他格式來構成script 語法，只要想辦法避開檢驗規則即可，而不像 SQL injection 只能符合 SQL 的語法，相對於HTML 格式嚴謹許多。就如從外部輸入 onmouseover=alert(document.cookie) ，其中沒使用到< >等跳脫字元，但瀏覽器認定為合法的HTML事件而被執行，再加上可編成其他格式來逃避驗證規則，難怪此弱點仍然是眾多駭客攻打網站的首選。

防禦方法可參考如 HTTP Header 安全性所述，對 Header 加入安全設定防止被竊取機密資訊，或 Injection Attack 的通用原則，對可竄改的外部來源做過濾驗證，有幾項原則可參考：

• 不要將不信任資料放入 HTML 中，但通常難以達成。

• 不信任資料放入 HTML 前須先進行編碼特殊字元，例如 &  <  >  ”  ‘ 及 / 等字元。

• 不信任資料不建議放入 Javascript ，極度危險，因為難以確認編碼目標。

• 不信任資料放入CSS 中需要經過編碼處理，HTML Style格式同樣會造成跳脫。

當然最安全方法是使用白名單政策，可使用正則表示式(Regular Expression) 來限定外部參數的資料格式，但通常很難符合網站功能的需求，因此會採用黑名單方式，可藉由第三方套件或開發語言原生的安全套件來過濾跳脫字元，如 OWASP 的 ESAPI 專案或微軟原生提供的 AntiXSS 套件等，都是經測試防禦效果較為全面的選擇，並有經過第三方單位比較針對各字元編碼的成效。

ESAPI

輸入端驗證
String validatedFirstName = ESAPI.validator().getValidInput(“FirstName”,
myForm.getFirstName(), “FirstNameRegex”, 255, false, errorList);
boolean isValidFirstName = ESAPI.validator().isValidInput(“FirstName”,
myForm.getFirstName(), “FirstNameRegex”, 255, false);

輸出端編碼
String safeOutput = ESAPI.encoder().encodeForHTML( clean encoded output Comment );

AntiXSS

HtmlEncode Method： 將內容經過編碼

GetSafeHtml  Method： 輸出完整的HTML架構

GetSafeHtmlFragment  Method： 將輸入的HTML片段輸出

這篇文章 Cross-Site Scripting 最早出現於 VSCAN | 網站安全弱點檢測。

SQL Injection 為透過外部使用者的輸入或可供改造的參數，未經驗證就帶入 SQL 相關指令被執行，導致跳脫原先預期的行為，變成攻擊者想要的行為。攻擊行為可利用 SQL 的指令如 SELECT、UPDATE 或 DELETE 等來造成資料庫非預期的行為，若執行權限又沒特別去做區分，等於將整個資料庫被外部任意存取與動作，甚至可用來執行指令碼，後果將難以彌補！

SQL Injection 攻擊型態類型

• CAPEC-7：盲目的SQL注入
• CAPEC-66：SQL注入
• CAPEC-108：通過SQL注入執行命令行
• CAPEC-109：對象關係映射注入
• CAPEC-110：通過SOAP參數篡改進行SQL注入
• CAPEC-470：從數據庫擴展對操作系統的控制

綜合這幾種類型，可以得知為防範此攻擊，為當外部參數進入SQL 陳述式(Statement)前，需再經過驗證格式是否合法，是否有隱藏特殊符號等檢查，主要有以下幾種方法：

參數化
將參數經過 Parameter 或 Prepare 等可用來對 SQL 參數做執行前的型態轉換，若有特殊字元將無法產生攻擊作用，最為推薦此種方法！

.NET
String query = “SELECT account_balance FROM user_data WHERE user_name = “
+ request.getParameter(“customerName”);

try {
Statement statement = connection.createStatement( … );
ResultSet results = statement.executeQuery( query );
}

PHP
$preparedStatement = $db->prepare(‘INSERT INTO table (column) VALUES (:column)’); $preparedStatement->execute(array(‘column’ => $unsafeValue));

替代字元
使用 Replace() 等方法來將特定字元做替換，但可能攻擊字元稍微經過變化或加密後，變成誤擋或漏檔等結果。

string sql = “SELECT * FROM WIDGETS WHERE ID=” +badValue.Replace(“‘”,”””);

正則表達式
利用 Regular Expression 設定合法的格式，直接用白名單方式限定參數的內容，這就變成需根據資料的不同來調整對應的 Regex，雖然嚴謹但較為麻煩，但有可能產生誤擋或漏擋的情況發生。

以上幾種防範方法適用於 Injection attack 類型的攻擊行為，可針對外部不被信任的參數做驗證與過濾處理，避免產生不可預期的行為，可視資料的多樣性與參數用途來選擇相對應的防禦方式。

這篇文章 SQL Injection 最早出現於 VSCAN | 網站安全弱點檢測。

常見的 Injection attack

• SQL injection
• Cross-site Scripting (XSS)
• CRLF injection/Host Header
• Code injection/OS cmd
• SMTP injeciton
• XPath injection

SQL injection 及 XSS 更是蟬聯 OWASP TOP 10 多年，可見其造成的傷害及普遍性之高，畢竟開發人員在將外部參數丟入 SQL 命令列時，為了方便時常就直接帶入，省略了過濾或參數化等方式，相信有寫過串接 Database 的網站開發人員都會有的經驗吧!

CRLF 則是利用 \r\n 換行字元切割 HTTP Header 並帶入攻擊行為，因為 Header 就是使用 \r\n 來做欄位的分離，而通常會搭配 XSS 來進行更危險的攻擊手法。

Code injeciton 則為由外部未經驗證的字串被直接使用 eval 或 system 等執行指令來執行，導致伺服器被執行未預期的程式行為，能造成的後果自然也是無法預期。

SMTP injection 為類似 CRLF 利用換行字元切割參數導致送出 SMTP 相關指令，常被第三方用來寄送匿名廣告信件(Relay)，從而演變成釣魚信件的進階持續式攻擊 (APT)。

XPath injection 攻擊原理類似 SQL injection，利用跳脫字元繞過檢查，並帶入其他攻擊行為，若為處理使用者身分驗證等流程，則可能造成提權與機密資訊外洩等風險。

Injection 式的攻擊手法都是直接信任外部輸入，沒有經過字元的檢查或進行過濾，或是只利用前端 javascript 檢查輸入行為，卻很容易被駭客繞過，能這麼長久被列為最常見的攻擊千萬不可忽略。

這篇文章 Injection Attack 最早出現於 VSCAN | 網站安全弱點檢測。