SQL注入是服務端的安全問題，注入攻擊的本質，是把用戶輸入的數據當做代碼執行。這裏有兩個關鍵條件，第一個是用戶能控制輸入，
第二個是原本程序要執行的代碼拼接了用戶輸入的數據。
例如：
正常情況下，用戶輸入查詢條件“上海”時，sql語句是“select * from city where name = ‘上海’”，當用戶輸入“上海‘；drop table city”，那麼
sql語句就會變成“select * from city where name = ‘上海’; drop table city”。這樣就會把表city刪除。
如果web網站開啓了錯誤回顯功能，把錯誤信息展示到網頁上，那麼黑客容易發現數據庫的信息，容易給黑客構造sql注入攻擊。所以應該不顯示具體的錯誤信息
SQL注入的防禦
1. 對用戶輸入的值查找下有沒有insert， delete, drop等關鍵詞。
2. 檢查數據類型，比如手機號是11位的，數值類型，郵件地址的格式等。
3. 使用預編譯的語句，綁定變量。在使用參數化SQL查詢的情況下，數據庫服務器不會將參數的內容視爲SQL指令的一部份來處理，
而是在數據庫完成 SQL 指令的編譯後，才套用參數運行，因此就算參數中含有惡意的指令，由於已經編譯完成，就不會被數據庫所運行,因此，可從一定程度上避免SQL注入。
4. 使用存儲過程，因爲存儲過程與預編譯語句類似，區別是存儲過程需要先將sql語句定義在數據庫中。
總結，在對抗注入攻擊時，需要牢記“數據與代碼分離原則”，在“拼湊”發生時進行安全檢查，就能避免此類問題。
文件上傳漏洞
文件上傳漏洞是指當用戶上傳了一個可執行的腳本文件，並通過此腳本獲得了執行服務器端命令的能力。
文件上傳功能是一個很正常的業務需求，但是漏洞在文件上傳後，服務器怎麼處理，解釋服務器文件。
例如：
上傳文件是web腳本語言，服務器web容器解釋並執行了用戶上傳的腳本
上傳文件是病毒，木馬等，黑客誘騙用戶或管理員下載執行
IIS下的文件解析問題
例如，首先用戶提交了abc.asp;xx.jpg的圖片，然後用戶請求http://www.***.com/path/abc.asp;xx.jpg以獲取圖片，
但是IIS把abc.asp;xx.jpg會將此文件名解析爲abc.asp，文件名被截斷了，導致腳本被執行。當然這種情況得web服務器上存在這樣路徑的文件。
如何設計安全的文件上傳功能
1. 文件上傳的目錄設置爲不可執行。
2. 判斷文件類型，可以結合使用mime type，後綴檢查等方式。在文件檢查中使用白名單。
3. 使用隨機數改寫文件名和文件路徑。
4. 單據設置文件服務器的域名，因爲瀏覽器同源策略的關係，一系列的客戶端攻擊將失效。
DDOS攻擊（ddos是利用合理的請求，造成資源過載，導致服務不可用）
網絡層DDOS
SYN Flood是當前最流行的DoS（拒絕服務攻擊）與DDoS（分佈式拒絕服務攻擊）的方式之一，這是一種利用TCP協議缺陷，發送大量僞造的TCP連接請求，從而使得被攻擊方資源耗盡（CPU滿負荷或內存不足）的攻擊方式。TCP是基於連接的，爲了在服務端和客戶端之間傳送TCP數據，必須先建立一個虛擬電路，也就是TCP連接，建立TCP連接的過程是：第一步，客戶主機向服務器發送一個包含SYN標誌的TCP報文初始化連接，SYN即同步（Synchronize），同步報文會指明客戶端使用的端口以及TCP連接的初始序號，客戶時間戳的值等信息；第二步，服務器在收到客戶端的SYN報文後，設置ACK位，同時TCP序號被加一，這說明服務器接受了客戶的連接請求，服務器將返回一個SYN+ACK的報文給客戶端，表示客戶端的請求被接受，ACK即確認（Acknowledgement）。第三步，客戶端也設置ACK位，返回一個確認報文ACK給服務器端，同樣TCP序列號被加一，到此一個TCP連接完成。以上的連接過程在TCP協議中被稱爲三次握手（Three-way Handshake）。而洪水攻擊就是利用了這三次握手的信息交互特性。在TCP連接的三次握手中，假設一個客戶端向服務器發送了SYN報文後突然死機或掉線，那麼服務器在發出應答SYN+ACK報文後將是無法收到客戶端的ACK迴應報文的，這樣第三次握手將無法完成，在設計TCP時，由於考慮到數據包有可能在傳輸過程中丟失或傳錯方向，服務器端一般會重試，再次發送SYN+ACK迴應報文給客戶端，並等待一段時間，同時把其內存用在等待來自源地址的ACK上，這段等待時間的長度我們稱爲SYN Timeout，一般來說這個時間是分鐘的數量級（大約爲30秒-2分鐘）；一個用戶出現異常導致服務器的一個線程等待1分鐘並不是什麼很大的問題，但如果有一個惡意的攻擊者大量模擬這種情況，服務器端將爲了維護一個非常大的半連接列表而消耗非常多的內存資源，即使是簡單的保存並遍歷也會消耗非常多的CPU時間和內存，何況還要不斷對這個列表中的IP進行SYN+ACK的重試。如果服務器的TCP/IP棧不夠充足，最後的結果往往是堆棧溢出崩潰，服務器端也將忙於處理攻擊者僞造的TCP半連接請求而無暇顧及客戶的正常連接請求，此時從正常客戶的角度看來，服務器失去響應而癱瘓，這種情況被稱爲服務器端受到了SYN Flood攻擊。
對抗SYN Flood的主要措施有SYN Cookie/SYN Proxy等算法，SYN Cookie的主要思想是爲每一個ip地址分配一個cookie，並統計每個ip訪問的頻率，如果再短時間內收到大量來自同一個ip的數據包，則認爲收到攻擊，之後來自這個ip的數據包將被丟棄。
應用層DDOS
應用層DDOS攻擊是針對服務器性能的攻擊，黑客可以通過入侵一個流量很大的網站後，通過篡改頁面，將巨大的用戶流量分流到目標網站實施攻擊。
如何應對應用層DDOS攻擊
1. 首先是優化服務端性能，比如將高頻率的數據剛在redis中。
2. 使用驗證碼，但是會影響用戶體驗
3. 使用Http頭中的User-Agent字段來判斷客戶端，但是不是很安全，因爲User-Agent可以被客戶端篡改。
4. 一種比較可靠的方法，讓客戶端執行一段js，並給出正確的結果，因爲大部分自動化腳本是通過直接構造http包完成的，並非在瀏覽器環境下發起的請求，
不能執行js，這樣就可以判斷出客戶端到底是不是瀏覽器。
5. 通過記錄ip的請求頻率，進行攔截