what：
DDOS攻擊：也叫分布式拒絕服務攻擊。使很多的計算機在同一時間遭受到攻擊，使攻擊的目標無法正常使用。攻擊的時候，可以對源IP地址進行偽造。從而影響用戶的正常使用，同時造成的經濟損失也是非常巨大的。
CC攻擊：攻擊者借助代理服務器（也叫肉雞）生成指向受害主機的合法請求，實現DDOS和偽裝就叫：CC(Challenge Collapsar)。
XSS攻擊：跨站腳本攻擊（Cross-Site Scripting），為了防止和“層疊樣式表”（Cascading Style Sheets, CSS）混淆，顧將該縮寫改為XSS。
攻擊方式：攻擊者將惡意代碼植入到提供給其它用戶使用的頁面中，從而盜取存儲在客戶端的cookie或者其他網站用於識別客戶端身份的敏感信息。
分類：
1、存儲型XSS：一般出現在，第三方用戶生產數據內容，供其他用戶消費的場景中。大概流程是“惡意用戶的Html輸入Web程序->進入數據庫->Web程序->用戶瀏覽器”。消費用戶在瀏覽器中瀏覽數據內容時，帶有惡意腳本的內容，就會攻擊消費用戶；
2、反射型XSS：主要做法就是惡意用戶在URL的參數中加上惡意腳本，在消費用戶打開鏈接（點擊鏈接）時，就會攻擊消費用戶
栗子：在網頁中加上“<script>alert(document.cookie)</script>”，那么消費用戶在頁面就會將cookie展現出來，出現下圖內容：
規避方案：
1、過濾特殊字符：將用戶所提供的內容進行過濾(如上面的script標簽)。；
2、使用HTTP頭指定類型：w.Header().Set("Content-Type","text/javascript")，可以讓瀏覽器解析javascript代碼，而不會是html輸出；
SQL注入：
攻擊者向服務器提交惡意的SQL查詢語句，導致服務將惡意的SQL語句當作正常查詢語句的一部分，從而改變原來查詢語句的邏輯，最終執行了惡意的事情。
栗子：' OR '1'='1，當我們輸如用戶名 admin ，然后密碼輸入' OR '1'= '1的時候，本來要執行的是SELECT * FROM user WHERE username='admin' and password='',經過參數拼接后為SELECT * FROM user WHERE username='admin' and password='' OR '1'='1' 。由於1=1是成立，自然就跳過驗證了。
規避方案：不要信用戶輸入的可靠性。
1、java使用預編譯語句(PreparedStatement)，到了服務端的時候，這個偽造 SQL語句的參數也只是簡單的字符；
2、對進入數據庫的特殊字符（'"\尖括號&*;等）進行轉義處理，或編碼轉換；
3、應用發布前，使用專業的SQL注入檢測工具進行檢測；
4、避免打印出SQL錯誤信息，以防信息泄露；
SYN攻擊：
在三次握手過程中，服務器發送 SYN-ACK 之后，收到客戶端的 ACK 之前的 TCP 連接稱為半連接(half-open connect)。此時服務器處於 SYN_RCVD 狀態。當收到服務器 ACK 后，才能轉入 ESTABLISHED 狀態。如果無效的半連接數過多，從而導致正常的鏈接被丟棄，而產生服務慢，甚至統癱瘓。
具體參考：https://www.cnblogs.com/sfzlstudy/p/15109276.html
CSRF：
CSRF（Cross-site request forgery），中文名稱：跨站請求偽造。
即：攻擊者盜用了你的身份，以你的名義發送惡意請求。
關鍵點：借助本地cookie進行認證，偽造發送請求
根本原因：對於同樣域名的每個請求來說，它的 cookie 都會被自動帶上（這個是瀏覽器的機制決定的）
原理：
從上圖可以看出，要完成一次CSRF攻擊，受害者必須依次完成兩個步驟：
1、登錄受信任網站A，並在本地生成Cookie。
2、在不登出A的情況下，訪問危險網站B。
demo：
預防方案：
Tokens：在一次session中，產生一個csrf_token（服務端生產）。以后在請求服務端時都會獲得一個隨機的Token（是csrf_token加密后的，但是服務端可以恢復出原值）。在客戶端提交請求時，在請求中增加一個隱藏的隨機變化的 Token。提交到后台進行驗證，如果驗證通過則可以繼續執行操作。
有效的原因：在請求中放入攻擊者所不能偽造的信息，並且該信總不存在於 cookie之中。
網站 B 拿不到網站 A 表單里的 Token（或者說，不知道拿哪個數值作為Token）。因為cookie已經不安全了，因此把csrf_token值存儲在local storage中（不同頁面最好使用變化的token key，例如：服務生成key，返回客戶，同時session中存；防止黑客獲得key），然后每次表單提交時都從local storage取出來放到form表單的隱藏域中（如：POST 請求來說，要在 form 的最后加上 <input type=”hidden” name=”csrftoken” value=”tokenvalue”/>；get就放在url后面參數中），這樣B網站不方便（如果配置XSS也是可以破解的）得到這個存儲到local storage中的值。
最好的方案是：核心操作需要用戶再次合身；
token的原理如下：https://www.cnblogs.com/sfzlstudy/p/15906003.html