XSS是跨站指令碼攻擊，是一種常見的web應用程式中的電腦保安漏洞，xss通過使用者端注入惡意的可執行指令碼，若伺服器對使用者輸入不進行處理，直接將使用者的輸入
輸出到瀏覽器，然後瀏覽器將會執行注入的指令碼；
可以直接寫一個可執行指令碼，也可以直接寫html，在標籤裡面寫一個惡意指令碼；
分類有兩種：非持久型和持久型
非持久型：反射型XSS，資料是要呈現給使用者的
持久型：儲存型XSS，資料是儲存在伺服器中的
理論上，所有可輸入的地方沒有對輸入資料進行處理的話，都會存在XSS漏洞，漏洞的危害取決於攻擊程式碼的威力，攻擊程式碼也不侷限於script。
防禦：
 1. 在輸入流中截住form data中的惡意指令碼（然後過濾，只允許使用者輸入應該合法的值）
具體是：我們可以截下進入server的每一個request，對使用者的輸入資料進行惡意指令碼清理。其中有效的一個方法就是使用spring的filter。
 2.html encode，對使用者輸入進行編碼，對標籤進行轉換

 
CSRF跨站點請求偽造
關鍵是：繞過使用者偽造請求進行攻擊

 CSRF攻擊攻擊原理及過程如下：
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的惡意程式碼被執行。 
CSRF攻擊例項：
受害者 Bob 在銀行有一筆存款，通過對銀行的網站傳送請求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 
       可以使 Bob 把 1000000 的存款轉到 bob2 的賬號下。通常情況下，該請求傳送到網站後，伺服器會先驗證該請求是否來自一個合法的 session，並且該 session 的使用者 Bob 已經成功登陸。
        黑客 Mallory 自己在該銀行也有賬戶，他知道上文中的 URL 可以把錢進行轉帳操作。Mallory 可以自己傳送一個請求給
        銀行：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是這個請求來自 Mallory 而非 Bob，
        他不能通過安全認證，因此該請求不會起作用。
        這時，Mallory 想到使用 CSRF 的攻擊方式，他先自己做一個網站，在網站中放入如下程式碼： 
        src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，並且通過廣告等誘使 Bob 來訪問他的網站。
        當 Bob 訪問該網站時，上述 url 就會從 Bob 的瀏覽器發向銀行，而這個請求會附帶 Bob 瀏覽器中的 cookie 一起發向銀行伺服器。大多數情況下，
        該請求會失敗，因為他要求 Bob 的認證資訊。但是，如果 Bob 當時恰巧剛訪問他的銀行後不久，他的瀏覽器與銀行網站之間的 session 尚未過期，
        瀏覽器的 cookie 之中含有 Bob 的認證資訊。這時，悲劇發生了，這個 url 請求就會得到響應，錢將從 Bob 的賬號轉移到 Mallory 的賬號，
        而 Bob 當時毫不知情。等以後 Bob 發現賬戶錢少了，即使他去銀行查詢日誌，他也只能發現確實有一個來自於他本人的合法請求轉移了資金，
        沒有任何被攻擊的痕跡。而 Mallory 則可以拿到錢後逍遙法外。   
 csrf攻擊.黑客不能拿到cookie,也沒辦法對伺服器返回的內容進行解析.唯一能做的就是給伺服器傳送請求.通過傳送請求改變伺服器中的資料.

上面的例子中攻擊者誘導使用者點選連結進行轉賬操作,使得銀行資料庫中受害者的金額發生了改變.

瞭解了csrf攻擊的原理和目標,提出了兩種防禦手段
referer 驗證
根據HTTP協議,在http請求頭中包含一個referer的欄位,這個欄位記錄了該http請求的原地址.通常情況下,執行轉賬操作的post請求
www.bank.com/transfer.php應該是點選www.bank.com網頁的按鈕來觸發的操作,這個時候轉賬請求的referer應該是www.bank.com.而如果黑客
要進行csrf攻擊,只能在自己的網站www.hacker.com上偽造請求.偽造請求的referer是www.hacker.com.所以我們通過對比post請求的referer是
不是www.bank.com就可以判斷請求是否合法.
這種方式驗證比較簡單,網站開發者只要在post請求之前檢查referer就可以,但是由於referer是由瀏覽器提供的.雖然http協議有要求不能篡改
referer的值.但是一個網站的安全性絕對不能交由其他人員來保證.
token 驗證
從上面的樣式可以發現,攻擊者偽造了轉賬的表單,那麼網站可以在表單中加入了一個隨機的token來驗證.token隨著其他請求資料一起被提交
到伺服器.伺服器通過驗證token的值來判斷post請求是否合法.由於攻擊者沒有辦法獲取到頁面資訊,所以它沒有辦法知道token的值.那麼偽造
的表單中就沒有該token值.伺服器就可以判斷出這個請求是偽造的.
SQL注入攻擊
這個就是在使用者輸入後增加一段sql語句，去非法讀取伺服器中的資料；