該弱點導致攻擊者劫持受害者的 Session，等於攻擊者拿到了受害者的身分，並在不知情狀況下被操作未知行為，可能造成受害者的機敏資料洩漏或交易行為變更等後果。此攻擊行為與 XSS 不同的地方在於未利用 Script 取得受害者機密資訊，而是直接利用受害者發出的連線進行操作，因此除了 Cookie 的保護外，也必須對機敏內容的連線做二次驗證，採用不信任的方式檢查。

驗證的方向需能檢驗送出連線的使用者身分，以避免受害者在不知情狀況下被冒用身分，可參考方法如下，

• 檢查 HTTP Header 欄位：可透過檢查 Header 中的 Referer 欄位是否存在及是否為正常流程網域，藉此確認發送端的前一個頁面是否被偽造或合法使用。

• 驗證 Token 參數：除了驗證 Cookie 的 Token 之外，還需另外在 Request 中放入隱藏的動態 Token 參數。

• 辨識使用者資訊：取得使用者環境資訊如 IP 位址或瀏覽器的 User-Agent，若發現經變更即驗證失效或送出重複身份驗證需求。

.NET 開發者可參考如下方法來進行：

取得 Referer 標頭 (HttpRequest.UrlReferrer / HttpWebRequest.Referer)

https://msdn.microsoft.com/zh-tw/library/system.net.httpwebrequest.referer(v=vs.110).aspx

使用 ASP .NET Core 的 Antiforgery 防範

https://docs.microsoft.com/zh-tw/aspnet/core/security/anti-request-forgery

取得使用者資訊 (User-Agent)

https://msdn.microsoft.com/zh-tw/library/system.web.httprequest.useragent(v=vs.110).aspx

這篇文章 CSRF (Cross-Site Request Forgery) 最早出現於 VSCAN | 網站安全弱點檢測。

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 | 網站安全弱點檢測。

HTTP Header 可視為網站與客戶在連線時的橋溝通梁，也就是遵照 HTTP 的協議，利用 Server 端的參數來告知客戶端瀏覽器需遵守其遊戲規則，你才能跟我進行連線溝通與確認是否繼續進行下一步動作，所以當客戶端發出需求時，Server 端可藉由回應來確認連線的安全性需求。

近來跟客戶討論網站安全性時，常會遇到程式碼修補上的困難，不外乎還需要開發人員的調整及測試時間等問題，其實可以先進行 HTTP Header 的安全性設定。
就如 OWASP TOP 10 與 SANS/CWE TOP 25 所列弱點，常見的 XSS(Cross-Site Scripting)與 CSRF(Cross-Site Requset Forgery)等弱點都可藉由調整 HTTP Header 來達成初步的防禦效果! OWASP 就有針對此發表了相關說明。

HTTP Header 安全設定

• HTTP Strict Transport Security (HSTS)
• Public Key Pinning Extension for HTTP (HPKP)
• X-Frame-Options
• X-XSS-Protection
• X-Content-Type-Options
• Content-Security-Policy
• X-Permitted-Cross-Domain-Policies
• Referrer-Policy

其中 HPKP 可綁定憑證，限定客戶端只能使用 Server 提供的憑證來連線，中間若有經過 Proxy或第三方憑證被置換時，連線都會無效！這專門在防範中間人攻擊(Man-in-the-Middle Attack)，也就是常會有第三方或駭客想藉由置換憑證來修改或窺看SSL加密的通訊內容，但透過加入 HPKP 的方式，將憑證的資訊綁入 Header，這樣客戶在連線時就可以比對是否為正確的憑證，才能放心的進行安全連線。

X-Frame-Options 可限定網域連線存取，也就是防範釣魚網站或 Clickjacking 等攻擊，藉由限制來源網域是否符合同源政策或是允許的白名單才可進行存取，避免有心人透過 iframe 或蓋台等方式來騙取受害者點擊造假的網站或連結，導致客戶機密資訊被竊取。

其他關於防範 XSS 攻擊的有 Content-Security-Policy 及 X-XSS-Protection，另外在設定 Cookies 時可帶入 Httponly 參數，限制只能透過 HTTP 方式取得 Cookie，若利用 Script 方式會被拒絕，一樣可以達成防禦的效果!

利用調整 HTTP Header 的安全性，可謂有事半功倍的成效，但是這終究只是第一線的防禦並只能抵擋部份攻擊，根據資安的縱深防禦理論，須藉由定期的弱點掃描檢視網站，網站伺服器及程式碼持續性的安全性調整及更新，才是網站能長久安全的不二法門。

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