網絡數據傳輸安全性問題和常見的網絡攻擊
一. 常見的網絡攻擊與解決辦法
轉自:https://blog.csdn.net/loongshawn/article/details/88047373 .
1. XSS攻擊
XSS（Cross Site Scripting）跨站腳本攻擊，爲了不與層疊樣式表（CSS）混淆，故將跨站腳本攻擊縮寫爲XSS。原理即在網頁中嵌入惡意腳本，當用戶打開網頁時，惡意腳本便開始在用戶瀏覽器上執行，以盜取客戶端cookie、用戶名、密碼，甚至下載木馬程式，危害可想而知。
以一個表單輸入舉例說明
<input type="text" name="firstname" value="">
在這裏插入圖片描述
倘若用戶在表單中輸入惡意腳本，即對輸入做些處理，如：
<input type="text" name="firstname" value=""/><script>alert("longlong")</script><!-- "/>
就會出現以下結果：
其實攻擊的形式還有很多，比如將腳本僞裝進URL，然後將URL進行URLEncode編碼，當用戶點擊鏈接後，腳本就會被執行。
XSS防範：
之所以會發生XSS攻擊，是因爲用戶輸入的數據變成了代碼， 因此需要對用戶輸入的數據進行HTML轉義處理，將輸出的“尖括號”、“單引號”、“引號”之類的特色符號進行轉義。
| HTML | HTML轉義後的字符 |
|---|---|
| < | < |
| > | > |
| ‘ | & |
| “ | " |
2. CSRF攻擊
CSRF攻擊的全稱跨站請求僞造（Cross Site Request Forgery），通過盜用用戶的身份信息，以你的名義向第三方網站發起惡意請求，若轉賬、盜取賬號、發信息、郵件。流程框圖如下：
所以CSRF攻擊一般場景是：
1、用戶登錄受信站點A，生成本地cookie；
2、用戶沒有退出站點A，訪問了惡意站點B。
CSRF攻擊舉例：惡意轉賬
Get請求
www.boc.com/transfer.do?accountNum=6233XXXX4324&money=10000
參數說明
accountNum轉賬目標賬號
money轉賬金額
如果銀行系統利用上述接口轉賬，就用可能會被惡意網站攻擊。當然上面僅是舉例，銀行安全等級不至於這麼低，使用GET轉賬。比如銀行升級接口爲POST提交，當然這也不能解決根本的安全問題，黑客照樣能夠利用XSS漏洞植入惡意代碼，請求轉賬接口。
真實銀行交易系統付款會有USB key、驗證碼、登陸密碼、支付密碼等一系列屏障，支付流程要複雜得多，安全係數也高很多。
CSRF攻擊防禦：
1、將cookie設置爲HttpOnly
CSRF攻擊很大程度是利用了瀏覽器的cookie，爲了防止站內XSS漏洞，cookie設置HttpOnly屬性，JS腳本就無法讀取到cookie中的信息，避免攻擊者僞造cookie的情況出現。
2、增加token
CSRF攻擊之所以成功，主要是攻擊中僞造了用戶請求，而用戶請求的驗證信息都在cookie中，攻擊者就可以利用cookie僞造請求通過安全驗證。因此抵禦CSRF攻擊的關鍵就是，在請求中放入攻擊者不能僞造的信息，並且信息不在cookie中。
鑑於此，開發人員可以在http請求中以參數的形式加一個token，此token在服務端生成，也在服務端校驗，服務端的每次會話都可以用同一個token。如果驗證token不一致，則認爲至CSRF攻擊，拒絕請求。
3、通過Referer識別
Http頭中有一個字段Referer，它記錄了Http請求來源地址。但是注意不要把Rerferer用在身份驗證或者其他非常重要的檢查上，因爲Rerferer非常容易在客戶端被改變。
（火狐的一個插件RefControl修改Referer引用）
1. SQL注入攻擊
SQL注入攻擊就是把SQL命令僞裝成正常的http請求參數，傳遞到服務端，欺騙服務器最終執行惡意的SQL命令，達到入侵目的。
SQL注入攻擊原理如下：
String sql = "select * from user where nick = '" + nickname + "' and password = '" + password + "'";
上述代碼是校驗用戶名、密碼是否有效，查詢結果記錄數大於0則表示有效。正常邏輯是用戶名、密碼匹配數據庫記錄；但攻擊者會利用http參數進行SQL注入攻擊，即password參數輸入’ or ‘1’ = '1，導致SQL語句變爲
select * from user where nick = 'zhangshan' and password = '' or '1' = '1';
上述語句的執行結果就相當於用戶能夠繞過登錄驗證。
SQL注入防範
1、使用SqlParameter代替普通的字符串拼接
2、使用ORM框架
2. 文件上傳漏洞
倘若web網站沒有對文件類型進行嚴格的校驗，導致可執行文件上傳到了服務器，惡意程序就會執行。
爲了避免惡意文件上傳，需要對上傳文件類型進行白名單校驗，並限制文件大小，上傳文件進行重命名。有關文件類型的校驗，需要去了解下魔數（magic number）這個概念，這裏不做引伸。
1. DDoS攻擊
1、SYN flood
攻擊者僞造大量無效IP，不斷與目標主機建立TCP鏈接，導致服務器維護了一個非常大的鏈接等待列表，佔用大量系統資源，直至新鏈接無法建立。
這種攻擊是利用了TCP三次握手的異常處理機制，即第三次握手，服務端在沒有收到客戶端ACK報文時，服務端會進行多次SYN+ACK重試，然後維護一個等待列表，而系統會爲即將建立的TCP連接分配一部分資源。資源耗盡，系統也就無法再建立TCP連接。
2、DNS query flood
攻擊者僞造大量無效域名，發送給目標服務器解析，這些域名均爲無效域名，導致DNS服務器耗用大量資源去處理這些無效域名，造成DNS解析域名超時，達到攻擊目的。
2. 其他攻擊手段
攻擊手段永遠都比防禦方法多得多。因此平時的業務中需要及時的添加各種攻擊防禦策略。
二. 數據傳輸安全性問題與解決辦法
1. 竊聽
A和B在互聯網傳輸數據時，A向B發送的消息可能會在傳輸過程中被C偷看。C的行爲稱爲“竊聽”。
2. 假冒
A和B在互聯網傳輸數據時，B收到的消息不一定是A發送的，也有可能是C發送的。C的行爲稱爲“假冒”。
3. 篡改
A和B在互聯網傳輸數據時，B收到的消息有可能被C截獲並且進行來修改。C的行爲稱爲“篡改”。
4. 事後否認
A和B在互聯網傳輸數據時，B收到了A的惡意信息，但是事後A不承認自己發送來惡意信息。A的行爲稱爲“事後否認”
解決辦法： 點擊此處瞭解以上數據傳輸安全問題的解決辦法.