XSS：跨站腳本（Cross-site scripting）
CSRF：跨站請求偽造（Cross-site request forgery）定義：
跨網站腳本（Cross-site scripting，通常簡稱為XSS或跨站腳本或跨站腳本攻擊）,為了與層疊樣式表（Cascading Style Sheets）區分，故命名為XSS
XSS攻擊通常指的是通過利用網頁開發時留下的漏洞，通過巧妙的方法注入惡意指令代碼到網頁，使用戶加載並執行攻擊者惡意制造的網頁程序。這些惡意網頁程序通常是JavaScript，但實際上也可以包括Java， VBScript， ActiveX， Flash 或者甚至是普通的HTML。攻擊成功后，攻擊者可能得到包括但不限於更高的權限（如執行一些操作）、私密網頁內容、會話和cookie等各種內容。
XSS成因概括 ：
XSS其實就是 Html的注入問題，攻擊者的輸入沒有經過嚴格的控制進入了數據庫，最終顯示給來訪的用戶，導致可以在來訪用戶的瀏覽器里以瀏覽用戶的身份執行Html代碼，數據流程如下：攻擊者的 Html輸入—>web程序—>進入數據庫—>web程序—>用戶瀏覽器。
檢測方法：
//通常有一些方式可以測試網站是否有正確處理特殊字符：
><script>alert(document.cookie)</script>='><script>alert(document.cookie)</script>"><script>alert(document.cookie)</script><script>alert(document.cookie)</script><script>alert(vulnerable)</script>%3Cscript%3Ealert('XSS')%3C/script%3E<script>alert('XSS')</script><img src="javascript:alert('XSS')"><img src="http://xxx.com/yyy.png" onerror="alert('XSS')"><div style="height:expression(alert('XSS'),1)" />（這個僅限 IE 有效）
攻擊者使被攻擊者在瀏覽器中執行腳本后，如果需要收集來自被攻擊者的數據（如cookie或其他敏感信息），可以自行架設一個網站，讓被攻擊者通過JavaScript等方式把收集好的數據作為參數提交，隨后以數據庫等形式記錄在攻擊者自己的服務器上。
a. 盜用 cookie ，獲取敏感信息。
b.利用植入 Flash ，通過 crossdomain 權限設置進一步獲取更高權限；或者利用Java等得到類似的操作。
c.利用 iframe、frame、XMLHttpRequest或上述Flash等方式，以（被攻擊）用戶的身份執行一些管理動作，或執行一些一般的如發微博、加好友、發私信等操作。
d.利用可被攻擊的域受到其他域信任的特點，以受信任來源的身份請求一些平時不允許的操作，如進行不當的投票活動。
e.在訪問量極大的一些頁面上的XSS可以攻擊一些小型網站，實現DDoS攻擊的效果。
漏洞的防御和利用:
避免XSS的方法之一主要是將用戶所提供的內容進行過濾，許多語言都有提供對HTML的過濾：PHP的htmlentities()或是htmlspecialchars()。Python的cgi.escape()。ASP的Server.HTMLEncode()。ASP.NET的Server.HtmlEncode()或功能更強的Microsoft Anti-Cross Site Scripting LibraryJava的xssprotect(Open Source Library)。Node.js的node-validator。
使用HTTP頭指定類型:
很多時候可以使用HTTP頭指定內容的類型，使得輸出的內容避免被作為HTML解析。如在PHP語言中使用以下代碼：
header('Content-Type: text/javascript; charset=utf-8');
即可強行指定輸出內容為文本/JavaScript腳本（順便指定了內容編碼），而非可以引發攻擊的HTML。
CSRF：冒充用戶之手:
XSS：跨站腳本（Cross-site scripting）
CSRF：跨站請求偽造（Cross-site request forgery）
示意圖：
圖片引用來源：http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html
XSS 是實現 CSRF 的諸多途徑中的一條，但絕對不是唯一的一條。一般習慣上把通過 XSS 來實現的 CSRF 稱為 XSRF。
CSRF 顧名思義，是偽造請求，冒充用戶在站內的正常操作。我們知道，絕大多數網站是通過 cookie 等方式辨識用戶身份（包括使用服務器端 Session 的網站，因為 Session ID 也是大多保存在 cookie 里面的），再予以授權的。所以要偽造用戶的正常操作，最好的方法是通過 XSS 或鏈接欺騙等途徑，讓用戶在本機（即擁有身份 cookie 的瀏覽器端）發起用戶所不知道的請求。
請求令牌（一種簡單有效的防御方法）：
首先服務器端要以某種策略生成隨機字符串，作為令牌（token），保存在 Session 里。然后在發出請求的頁面，把該令牌以隱藏域一類的形式，與其他信息一並發出。在接收請求的頁面，把接收到的信息中的令牌與 Session 中的令牌比較，只有一致的時候才處理請求，處理完成后清理session中的值，否則返回 HTTP 403 拒絕請求或者要求用戶重新登陸驗證身份
令牌來防止 CSRF 有以下幾點要注意：
a.雖然請求令牌原理和驗證碼有相似之處，但不應該像驗證碼一樣，全局使用一個 Session Key。因為請求令牌的方法在理論上是可破解的，破解方式是解析來源頁面的文本，獲取令牌內容。如果全局使用一個 Session Key，那么危險系數會上升。原則上來說，每個頁面的請求令牌都應該放在獨立的 Session Key 中。我們在設計服務器端的時候，可以稍加封裝，編寫一個令牌工具包，將頁面的標識作為 Session 中保存令牌的鍵。
b.在 ajax 技術應用較多的場合，因為很有請求是 JavaScript 發起的，使用靜態的模版輸出令牌值或多或少有些不方便。但無論如何，請不要提供直接獲取令牌值的 API。這么做無疑是鎖上了大門，卻又把鑰匙放在門口，讓我們的請求令牌退化為同步令牌。
c.第一點說了請求令牌理論上是可破解的，所以非常重要的場合，應該考慮使用驗證碼（令牌的一種升級，目前來看破解難度極大），或者要求用戶再次輸入密碼（亞馬遜、淘寶的做法）。但這兩種方式用戶體驗都不好，所以需要產品開發者權衡。
d.無論是普通的請求令牌還是驗證碼，服務器端驗證過一定記得銷毀。忘記銷毀用過的令牌是個很低級但是殺傷力很大的錯誤。我們學校的選課系統就有這個問題，驗證碼用完並未銷毀，故只要獲取一次驗證碼圖片，其中的驗證碼可以在多次請求中使用（只要不再次刷新驗證碼圖片），一直用到
如下也列出一些據說能有效防范 CSRF，其實效果甚微或甚至無效的做法：
a.通過 referer 判定來源頁面：referer 是在 HTTP Request Head 里面的，也就是由請求的發送者決定的。如果我喜歡，可以給 referer 任何值。當然這個做法並不是毫無作用，起碼可以防小白。但我覺得性價比不如令牌。
b.過濾所有用戶發布的鏈接：這個是最無效的做法，因為首先攻擊者不一定要從站內發起請求（上面提到過了），而且就算從站內發起請求，途徑也遠遠不知鏈接一條。比如 <img src="./create_post.php" /> 就是個不錯的選擇，還不需要用戶去點擊，只要用戶的瀏覽器會自動加載圖片，就會自動發起請求。
c.在請求發起頁面用 alert 彈窗提醒用戶：這個方法看上去能干擾站外通過 iframe 發起的 CSRF，但攻擊者也可以考慮用 window.alert = function(){}; 把 alert 弄啞，或者干脆脫離 iframe，使用 Flash 來達到目的。
總體來說，目前防御 CSRF 的諸多方法還沒幾個能徹底無解的。 作為開發者，我們能做的就是盡量提高破解難度。當破解難度達到一定程度，網站就逼近於絕對安全的位置了