一、基礎知識
1、XSS（Cross Site Scripting）跨站腳本攻擊
（1）原理：頁面渲染的數據中包含可運行的腳本
（2）攻擊的基本類型：反射型（url參數直接注入）和存儲型（存儲到DB后讀取時注入）
（3）注入點：HTML節點內的內容（text）；HTML中DOM元素的屬性；Javascript代碼；富文本
//HTML節點內容注入 <div><script>alert(1);</script></div> //DOM屬性注入 <img src='/images/1.png' onerror='alert(1);'> //javascript代碼 <script> var a = '1';alert(1);'' </script> //富文本是html標簽，文字，以及樣式的集合，很容易實現HTML節點內容注入和DOM屬性注入，有被攻擊的風險
2、CSRF（Cross Site Request Forgy）跨站請求偽造
原理：在第三方網站向本網站發起請求（如圖）
（1）用戶在a站前端頁面發起登錄（身份認證）請求
（2）a站后端確認身份，登錄成功，cookie中存在用戶的身份認證信息
（3）b站前端頁面向a站后端發起請求，帶着a站的cookie信息（身份認證信息），請求成功
綜上，可以清楚的知道，只要用戶訪問了b站的前端頁面，b站就可以在用戶完全不知道的情況下，帶着a站的用戶登錄態（cookie）向a站發起請求
3、點擊劫持
原理：第三方網站通過iframe內嵌某一個網站，並且將iframe設置為透明不可見，將其覆蓋在其他經過偽裝的DOM上，偽裝的可點擊DOM（按鈕等）與實際內嵌網站的可點擊DOM位置相同，當用戶點擊偽裝的DOM時，實際上點擊的是iframe中內嵌的網頁的DOM從而觸發請求操作
特點：用戶自己做了點擊操作；用戶毫不知情；
二、如何防御
1、XSS攻擊防御
（1）瀏覽器自帶防御機制，主要應對反射型攻擊（HTML內容或屬性）：http響應頭中自動添加x-xss-protection，值為0（關閉），1（打開），默認打開
（2）對特定字符做轉義：內容注入替換尖括號（ < => < > => > ） 屬性注入替換單引號或雙引號（ " => " ' => ' ）
（3）CSP（Content Security Policy）內容安全策略：用於指定哪些內容可執行
//我們可以在http響應頭中設置Content-Security-Policy //圖片可以從任何地方加載(注意 "*" 通配符) //多媒體文件僅允許從 media1.com 和 media2.com 加載(不允許從這些站點的子域名) //可運行腳本僅允許來自於userscripts.example.com Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com //同時meta中也支持設置Content-Security-Policy <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">
2、CSRF攻擊防御：
CSRF的發生有幾個特點，b站發送的請求帶着a站的cookie信息； b站發送請求不經過a站的前端；http請求頭中的referer為b站。我們可以從這些特點入手，思考防御的辦法
（1）禁止第三方網站攜帶本網站的cookie信息：設置same-site屬性，same-site屬性有兩個值，Strict（所有的第三方請求都不能攜帶本網站的cookie）和Lax（鏈接可以，但是form表單提交和ajax請求不行）
（2）本網站前端頁面添加驗證信息：使用驗證碼或者添加token驗證
驗證碼：當發起請求時，前端需要輸入本網站頁面的驗證碼信息，后端對驗證碼進行驗證，驗證碼正確才會進行相關操作（存取數據等）
token驗證：a站前端將token存在當前頁面中（比如表單中的input隱藏域，meta標簽或者任何一個dom的屬性）和cookie中，當請求a站后端的時候，參數中帶上這個token字段，a站后端將參數中的token和cookie中的token做對比， 相同則驗證通過，不同則請求不合法
不管是驗證碼還是token驗證，原理都是一樣的，在a站前端頁面加入驗證，當第三方網站請求a站后端時，即使能攜帶a站cookie，但是因為沒有經過a站的前端頁面從而拿不到驗證信息，也會導致請求失敗。
兩種防御的方法也有區別，驗證碼需要用戶去填寫，從而增加了用戶使用網站的復雜度，而token驗證在用戶無感知的情況下就可以實現，不影響用戶體驗。我個人理解，驗證碼驗證一般使用在需要提高用戶認知的場景，比如，登錄多次失敗，修改個人信息（用戶名，密碼，綁定手機號等等），而一些獲取商品列表信息，搜索等接口，使用token比較合理。可以看看我們平時使用的這些網站，作參考～
（3）referer驗證：禁止來自第三方的請求
（4）使用post請求：有一個說法是“post請求比get請求更安全”，那這種說法對不對呢？實際上這種說法並不准確，對於CSRF攻擊來講，不管是post還是get都能實現攻擊，區別只是post請求攻擊方需要構造一個form表單才可以發起請求，比get請求（img的src， a標簽的href等等）的攻擊方式復雜了一些，但是並不能有效的阻止攻擊。
3、點擊劫持攻擊防御
（1）Javascript禁止內嵌：當網頁沒有被使用iframe內嵌時，top和window是相等的；當網頁被內嵌時，top和window是不相等的；可以在本網站的頁面中添加如下判斷：
<script> if (top.location != window.location) { //如果不相等，說明使用了iframe，可進行相關的操作 } </script>
但是這種方式並不是萬能的，因為iframe標簽中的屬性sandbox屬性是可以禁用內嵌網頁的腳本的：
<iframe sandbox='allow-forms' src='...'></iframe>
（2）設置http響應頭 X-Frame-Options：有三個值 DENY（禁止內嵌） SAMEORIGIN（只允許同域名頁面內嵌） ALLOW-FROM（指定可以內嵌的地址）
能在所有的web服務器端預設好X-Frame-Options字段值是最理想的狀態。
（3）一些輔助手段，比如添加驗證碼，提高用戶的防范意識
三、總結
本文旨在對平時了解到的知識做一些總結和記錄，方便查閱和復習，描述不當之處，歡迎指出。
文中有些部分並未深入展開，比如iframe的sandbox屬性（只適用於內嵌網頁是form提交的情況，如果所有的請求都通過ajax來請求，而js腳本又被禁用的話，那就沒辦法實現點擊劫持了），有一些內容需要你自己動腦思考。
后續可能還會有補充，比如SQL注入部分，總之，今天先這樣啦～