瀏覽器的同源策略限制了一些跨域行爲，但仍有些特例（img、iframe、script標籤）不受跨域限制，這就給XSS攻擊創造了機會（這完全不是同源策略的鍋，一定是程序員的鍋）。
在講下面的內容前，還是要提一下Cookie，Cookie是用來辨別用戶身份的重要依據。來做個形象的比喻，有一天，小A去了一家新開的理髮店，店裏的託尼老師不認識小A，於是小A就辦了一張VIP卡，當小A第二次去這家理髮店的時候，店裏的託尼老師刷了下小A的卡，想起來了你是小A啊，今天搞什麼樣的造型啊~ Cookie就是那張VIP卡，用於辨別用戶身份。
Cookie包含以下幾個屬性
採用 Name = Value 的鍵值對形式存儲數據，Name是唯一的
Domain：域名，限制哪些域名下可以使用（該VIP卡僅限本店使用）
Path：路徑，只有這個路徑前綴的纔可用（該VIP卡僅限燙頭）
Expires：過期時間（該VIP卡有效期一年）
HTTP（HTTPOnly）：只有瀏覽器請求時，纔會在請求頭中帶着，JavaScript無法讀寫
Secure：非HTTPS請求時不帶
SameSite：用於定義cookie如何跨域發送
Cookie就先簡單說到這裏，回到XSS攻擊，後續講到的XSS和CSRF攻擊都會圍繞着怎麼獲取Cookie來舉例。
XSS（Cross-site-Script跨站腳本攻擊），通常是帶有頁面可解析內容的數據未經處理直接插入到頁面上解析造成的。XSS根據攻擊腳本的引入位置來區分爲存儲型XSS、反射型XSS以及MXSS（也叫DOM XSS）三種。
根據上面的描述來舉個例子：
假設有一個論壇存在XSS漏洞，用戶小A在該論壇的一篇帖子中留言到
當小A寫的留言被該論壇保存下來之後，如果有其他的用戶看到了這條評論（相當於打開了這個頁面，執行了hark.js，hark.js裏面內容大致是獲取Cookie，發送請求），那麼這些用戶的Cookie都會發送到小A事先寫好的信息收集網站中進行保存，然後小A就可以用這些Cookie進行登錄啦。
上述這種XSS攻擊屬於存儲型，提交的代碼會被存儲在服務器端，下次請求目標網站時不用再提交XSS代碼。所以這種類型的主要原因是前端提交的數據未經處理直接存儲到數據庫，然後從數據庫中讀取出來後直接插入到頁面中導致的。
繼續講故事：
假設有一個網站lalala存在XSS漏洞，網址是http://www.lalala.com。然後有一天小A在郵件裏發現一封郵件，內容是一張你懂得圖片然後配下面的標籤。
小A好奇啊，然後就點了進去，如果在此之前小A登錄過lalala網站，那麼他的Cookie就被盜走了。
這種XSS攻擊屬於反射型，發出請求時，XSS代碼出現在URL中，作爲輸入提交到服務器，服務器解析後響應，XSS代碼隨着響應內容一起傳回給瀏覽器，最後瀏覽器解析執行XSS代碼。這個過程像一次反射，故叫做反射型XSS。
MXSS則是在渲染DOM屬性時將攻擊腳本插入DOM屬性中被解析而導致的。
至此，三種類型的XSS攻擊都描述完了，你看確實都是程序員的鍋吧。
服務端可以做以下動作：
1、剛剛上面講到Cookie中有個屬性時HTTP，設置爲True，不允許JavaScript讀取cookies，但該屬性只適配部分瀏覽器。對於HTTPS可以設置Secure
2、處理富文本框輸入內容，進行XSS過濾，過濾類似script、iframe、form等標籤以及轉義存儲
客戶端可以做以下動作：
1、輸入檢查，和服務端一樣都要做。
2、輸出檢查，編碼轉義，如果使用jquery，就是那些append、html、before、after等，插入DOM的方法需要注意。現今大部分的MV*框架在模板（view層）會自動處理XSS問題。
XSS攻擊的危害是很大的，像上面的例子注入script可以執行任何的JS代碼(意味着可以獲取cookie等信息了)，注入style可以把頁面全部弄崩。尤其是具有評論功能的網站需要注意防範此類攻擊，不要相信客戶端發送過來的任何數據！還有就是不要亂點開奇奇怪怪的鏈接啦~
什麼是CSRF？
CSRF（Cross-site request forgery）跨站請求僞造，也被稱爲“One Click Attack”或者Session Riding，通常縮寫爲CSRF或者XSRF，是一種對網站的惡意利用。儘管聽起來像跨站腳本（XSS），但它與XSS非常不同，XSS利用站點內的信任用戶，而CSRF則通過僞裝成受信任用戶的請求來利用受信任的網站。
CSRF攻擊的本質原因：
CSRF攻擊是源於Web的隱式身份驗證機制！Web的身份驗證機制大致就是說爲了防止用戶每次發送請求的時候都需要登錄，在進行一次登錄驗證通過後，之後發向該域名的請求都會自動帶上cookie。雖然可以保證一個請求是來自於某個用戶的瀏覽器，但卻無法保證該請求是用戶批准發送的。CSRF攻擊的一般是由服務端解決，而XSS主要是由客戶端解決。
CSRF攻擊的原理：
1. 用戶打開瀏覽器，訪問受信任網站A，輸入用戶名和密碼請求登錄網站A。
2.在用戶信息通過驗證後，網站A產生Cookie信息並返回給瀏覽器。
3. 用戶在未退出網站A之前，在同一瀏覽器中，打開一個TAB頁訪問網站B。
4. 網站B接收到用戶請求後，發出一個訪問網站A的請求。
5. 瀏覽器根據網站B的請求，在用戶不知情的情況下攜帶Cookie信息，向網站A發出請求。網站A並不知道該請求其實是由B發起的，所以會根據用戶的Cookie信息處理該請求，達到模擬用戶操作的目的。
tips：Session Cookie（在瀏覽器關閉後，就會失效，保存到內存）
Third-party Cookie（關閉瀏覽器後，不會失效，保存到本地）
常見的CSRF攻擊：
Get請求，操作數據庫內容
比如網站A的修改密碼接口是GET方式，通過調用api/ChangePassword？psw=123就可以進行密碼的修改，所以在開發的過程中如果涉及到數據改動都建議採用POST請求
隱藏表單提交POST請求
單純的POST當然也是能僞造的，JS利用form表單可以跨域請求的特性的提交POST請求仍然能夠產生CSRF攻擊。
如果網站A有使用Flash，並將跨域策略文件中的allow-access-from domain設置爲素有，也是有可能產生CSRF攻擊的。
XSRF
通常來說CSRF是由XSS實現的，所以CSRF時常也被稱爲XSRF，用XSS的方式實現僞造請求，比如網站A存在XSS漏洞，被注入惡意代碼後，當有用戶訪問到有惡意代碼的網頁的時候，就會發送一條類似轉賬，關注啊之類的請求，做到XSRF攻擊。
看完這幾種攻擊方式，大概應該能辨別什麼時候是CSRF攻擊了，簡單說就是隻要發起了冒牌請求那麼就算是CSRF（XSRF）
順便再總結下XSS和CSRF的其他區別，面試官可能會問到哦~
區別一，發生位置
XSS：發生在客戶端
CSRF：發生在服務端
區別二，原理
XSS：注入代碼，執行代碼，篡改內容
CSRF：攜帶Cookie模擬請求
區別三，根源
XSS：同源策略機制
CSRF：Web隱式身份驗證機制
區別四，就Cookie而言
XSS：盜取Cookie來幹壞事
CSRF：借用Cookie來幹壞事
最後還是要說下如何防範CSRF攻擊
一、Referer（記錄 HTTP 請求的來源地址） Check
好處是只需要增加一個攔截器來檢查 Referer ，用於過濾非該服務器域名的地址，不需要改變當前系統的任何已有代碼和邏輯，非常快捷。
但是，Referer 的值是由瀏覽器提供的，雖然 HTTP 協議上有明確的要求，但是每個瀏覽器對於 Referer 的具體實現可能有差別，並不能保證瀏覽器自身沒有安全漏洞。使用驗證 Referer 值的方法，就是把安全性都依賴於第三方（即瀏覽器）來保障，不是很靠譜，並且一些低版本的瀏覽器像IE6等有方法對Referer 進行篡改。還有重要的一點是，用戶可以設置瀏覽器不攜帶 Referer字段。
二、驗證碼
強制用戶必須與應用進行交互，才能完成最終請求。在通常情況下，驗證碼能很好遏制CSRF攻擊。但是出於用戶體驗考慮，網站不能給所有的操作都加上驗證碼。因此驗證碼只能作爲一種輔助手段，不能作爲主要解決方案。
三、Token
在 HTTP 請求中以參數的形式添加一個隨機產生的 token，並在服務器端建立一個攔截器來驗證這個 token，假設請求中沒有 token 或者 token 內容不對，則覺得可能是 CSRF 攻擊而拒絕該請求。並且涉及數據庫操作的接口使用POST，因爲GET不好加Token，會暴露Token的保密性。
關於Token
Token 應該保存到 local / session stograge（不會跨域工作） 或者 cookies
Tokens 除了像 cookie 一樣有有效期，還要提供過期重新獲取、強制刷新、撤回等操作
有需要的話，要加密並且簽名 token
將 JSON Web Tokens（JWT） 應用到 OAuth 2
四、HTTP 頭中自定義屬性並驗證
類似方法三，只不過不是以參數形式，而是請求頭字段攜帶Token信息。但是要把所有請求都改爲 XMLHttpRequest 請求。
至此，有關XSS和CSRF的內容都講解完畢了，感謝大家抽空閱讀。