久久久一区二区三区污,風間一区二区,97欧美国产

對稱加密與非對稱加密

對稱密鑰加密（Symmetric-Key Encryption），是指加密和解密使用同一個密鑰的方式，這種方式存在的最大問題就是密鑰發(fā)送問題，即如何安全地將密鑰發(fā)給對方；

對稱密鑰加密特點：

優(yōu)點：運算速度快；

缺點：無法安全地將密鑰傳輸給通信方。

非對稱加密（Public-Key Encryption），是指加密和解密使用不同的密鑰，使用一對非對稱密鑰，即公鑰和私鑰，公鑰可以隨意發(fā)布，但私鑰只有自己知道。發(fā)送密文的一方使用對方的公鑰進行加密處理，對方接收到加密信息后，使用自己的私鑰進行解密。

由于非對稱加密的方式不需要發(fā)送用來解密的私鑰，所以可以保證安全性；但是和對稱加密比起來，它非常的慢，所以我們還是要用對稱加密來傳送消息，但對稱加密所使用的密鑰我們可以通過非對稱加密的方式發(fā)送出去。

非對稱密鑰除了用來加密，還可以用來進行簽名。因為私有密鑰無法被其他人獲取，因此通信發(fā)送方使用其私有密鑰進行簽名，通信接收方使用發(fā)送方的公開密鑰對簽名進行解密，就能判斷這個簽名是否正確。

優(yōu)點：可以更安全地將公開密鑰傳輸給通信發(fā)送方；

缺點：運算速度慢。

客戶端不斷進行請求鏈接會怎樣？DDos(Distributed Denial of Service)攻擊？

服務器端會為每個請求創(chuàng)建一個鏈接，并向其發(fā)送確認報文，然后等待客戶端進行確認

1)、DDos攻擊

客戶端向服務端發(fā)送請求鏈接數(shù)據(jù)包

服務端向客戶端發(fā)送確認數(shù)據(jù)包

客戶端不向服務端發(fā)送確認數(shù)據(jù)包，服務器一直等待來自客戶端的確認

2)、DDos預防 ( 沒有徹底根治的辦法，除非不使用TCP )

限制同時打開SYN半鏈接的數(shù)目

縮短SYN半鏈接的Time out 時間

關閉不必要的服務

SQL 注入

SQL注入就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執(zhí)行惡意的SQL命令。

1). SQL注入攻擊的總體思路

　(1).尋找到SQL注入的位置

　(2).判斷服務器類型和后臺數(shù)據(jù)庫類型

　(3).針對不通的服務器和數(shù)據(jù)庫特點進行SQL注入攻擊

2). SQL注入攻擊實例

　比如，在一個登錄界面，要求輸入用戶名和密碼，可以這樣輸入實現(xiàn)免帳號登錄：

???用戶名：‘or 1 = 1 --

密碼：

用戶一旦點擊登錄，如若沒有做特殊處理，那么這個非法用戶就很得意的登陸進去了。這是為什么呢?下面我們分析一下：從理論上說，后臺認證程序中會有如下的SQL語句：String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”; 因此，當輸入了上面的用戶名和密碼，上面的SQL語句變成：SELECT * FROM user_table WHERE username=’’or 1 = 1 – and password=’’。分析上述SQL語句我們知道， username=‘ or 1=1 這個語句一定會成功；然后后面加兩個-，這意味著注釋，它將后面的語句注釋，讓他們不起作用。這樣，上述語句永遠都能正確執(zhí)行，用戶輕易騙過系統(tǒng)，獲取合法身份。

3). 應對方法

(1). 參數(shù)綁定

　　使用預編譯手段，綁定參數(shù)是最好的防SQL注入的方法。目前許多的ORM框架及JDBC等都實現(xiàn)了SQL預編譯和參數(shù)綁定功能，攻擊者的惡意SQL會被當做SQL的參數(shù)而不是SQL命令被執(zhí)行。在mybatis的mapper文件中，對于傳遞的參數(shù)我們一般是使用#和$來獲取參數(shù)值。當使用#時，變量是占位符，就是一般我們使用javajdbc的PrepareStatement時的占位符，所有可以防止sql注入；當使用$時，變量就是直接追加在sql中，一般會有sql注入問題。

(2). 使用正則表達式過濾傳入的參數(shù)

XSS 攻擊（跨站腳本攻擊）

XSS是一種經(jīng)常出現(xiàn)在web應用中的計算機安全漏洞，與SQL注入一起成為web中最主流的攻擊方式。XSS是指惡意攻擊者利用網(wǎng)站沒有對用戶提交數(shù)據(jù)進行轉(zhuǎn)義處理或者過濾不足的缺點，進而添加一些腳本代碼嵌入到web頁面中去，使別的用戶訪問都會執(zhí)行相應的嵌入代碼，從而盜取用戶資料、利用用戶身份進行某種動作或者對訪問者進行病毒侵害的一種攻擊方式。

1). XSS攻擊的危害

* 盜取各類用戶帳號，如機器登錄帳號、用戶網(wǎng)銀帳號、各類管理員帳號

* 控制企業(yè)數(shù)據(jù)，包括讀取、篡改、添加、刪除企業(yè)敏感數(shù)據(jù)的能力

* 盜竊企業(yè)重要的具有商業(yè)價值的資料

* 非法轉(zhuǎn)賬

* 強制發(fā)送電子郵件

* 網(wǎng)站掛馬

* 控制受害者機器向其它網(wǎng)站發(fā)起攻擊

2）攻擊原理

例如有一個論壇網(wǎng)站，攻擊者可以在上面發(fā)布以下內(nèi)容：

location.+ document.cookielocation.+ document.cookielocation.+ document.cookielocation.+ document.cookie<script>location. + document.cookie</script>

location.+ document.cookie

之后該內(nèi)容可能會被渲染成以下形式：

<p><script>location. + document.cookie</script></p>

location.+ document.cookie

另一個用戶瀏覽了含有這個內(nèi)容的頁面將會跳轉(zhuǎn)到 domain.com 并攜帶了當前作用域的 Cookie。如果這個論壇網(wǎng)站通過 Cookie 管理用戶登錄狀態(tài)，那么攻擊者就可以通過這個 Cookie 登錄被攻擊者的賬號了。

3). 原因解析

　　主要原因：過于信任客戶端提交的數(shù)據(jù)！

　　解決辦法：不信任任何客戶端提交的數(shù)據(jù)，只要是客戶端提交的數(shù)據(jù)就應該先進行相應的過濾處理然后方可進行下一步的操作。

　　進一步分析細節(jié)：客戶端提交的數(shù)據(jù)本來就是應用所需要的，但是惡意攻擊者利用網(wǎng)站對客戶端提交數(shù)據(jù)的信任，在數(shù)據(jù)中插入一些符號以及javascript代碼，那么這些數(shù)據(jù)將會成為應用代碼中的一部分了，那么攻擊者就可以肆無忌憚地展開攻擊啦，因此我們絕不可以信任任何客戶端提交的數(shù)據(jù)?。?！

4). XSS 攻擊分類

(1). 反射性XSS攻擊 (非持久性XSS攻擊)

　　漏洞產(chǎn)生的原因是攻擊者注入的數(shù)據(jù)反映在響應中。一個典型的非持久性XSS攻擊包含一個帶XSS攻擊向量的鏈接(即每次攻擊需要用戶的點擊)，例如，正常發(fā)送消息：

http://www.test.com/message.php?send=Hello,World！

接收者將會接收信息并顯示Hello,World；但是，非正常發(fā)送消息：

http://www.test.com/message.php?send=<script>alert(‘foolish!’)</script>！

接收者接收消息顯示的時候?qū)棾鼍娲翱冢?/p>

(2). 持久性XSS攻擊 (留言板場景)

　　XSS攻擊向量(一般指XSS攻擊代碼)存儲在網(wǎng)站數(shù)據(jù)庫，當一個頁面被用戶打開的時候執(zhí)行。也就是說，每當用戶使用瀏覽器打開指定頁面時，腳本便執(zhí)行。與非持久性XSS攻擊相比，持久性XSS攻擊危害性更大。從名字就可以了解到，持久性XSS攻擊就是將攻擊代碼存入數(shù)據(jù)庫中，然后客戶端打開時就執(zhí)行這些攻擊代碼。

例如，留言板表單中的表單域：

正常操作流程是：用戶是提交相應留言信息 —— 將數(shù)據(jù)存儲到數(shù)據(jù)庫 —— 其他用戶訪問留言板，應用去數(shù)據(jù)并顯示；而非正常操作流程是攻擊者在value填寫:

并將數(shù)據(jù)提交、存儲到數(shù)據(jù)庫中；當其他用戶取出數(shù)據(jù)顯示的時候，將會執(zhí)行這些攻擊性代碼。

5). 修復漏洞方針

漏洞產(chǎn)生的根本原因是太相信用戶提交的數(shù)據(jù)，對用戶所提交的數(shù)據(jù)過濾不足所導致的，因此解決方案也應該從這個方面入手，具體方案包括：

（1）將重要的cookie標記為http only, 這樣的話Javascript 中的document.cookie語句就不能獲取到cookie了（如果在cookie中設置了HttpOnly屬性，那么通過js腳本將無法讀取到cookie信息，這樣能有效的防止XSS攻擊）；

（2）表單數(shù)據(jù)規(guī)定值的類型，例如：年齡應為只能為int、name只能為字母數(shù)字組合

（3）對數(shù)據(jù)進行Html Encode 處理

（4）過濾或移除特殊的Html標簽，例如: , , for>, " for

（5）過濾JavaScript 事件的標簽，例如 “onclick=”, “onfocus” 等等。

需要注意的是，在有些應用中是允許html標簽出現(xiàn)的，甚至是javascript代碼出現(xiàn)。因此，我們在過濾數(shù)據(jù)的時候需要仔細分析哪些數(shù)據(jù)是有特殊要求（例如輸出需要html代碼、javascript代碼拼接、或者此表單直接允許使用等等），然后區(qū)別處理！

跨站請求偽造

概念

跨站請求偽造（Cross-site request forgery，CSRF），是攻擊者通過一些技術(shù)手段欺騙用戶的瀏覽器去訪問一個自己曾經(jīng)認證過的網(wǎng)站并執(zhí)行一些操作（如發(fā)郵件，發(fā)消息，甚至財產(chǎn)操作如轉(zhuǎn)賬和購買商品）。由于瀏覽器曾經(jīng)認證過，所以被訪問的網(wǎng)站會認為是真正的用戶操作而去執(zhí)行。

XSS 利用的是用戶對指定網(wǎng)站的信任，CSRF 利用的是網(wǎng)站對用戶瀏覽器的信任。

攻擊原理

假如一家銀行用以執(zhí)行轉(zhuǎn)賬操作的 URL 地址如下：

http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName。

那么，一個惡意攻擊者可以在另一個網(wǎng)站上放置如下代碼：

<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">。

如果有賬戶名為Alice 的用戶訪問了惡意站點，而她之前剛訪問過銀行不久，登錄信息尚未過期，那么她就會損失1000 美元。

這種惡意的網(wǎng)址可以有很多種形式，藏身于網(wǎng)頁中的許多地方。此外，攻擊者也不需要控制放置惡意網(wǎng)址的網(wǎng)站。例如他可以將這種地址藏在論壇，博客等任何用戶生成內(nèi)容的網(wǎng)站中。這意味著如果服務器端沒有合適的防御措施的話，用戶即使訪問熟悉的可信網(wǎng)站也有受攻擊的危險。

通過例子能夠看出，攻擊者并不能通過 CSRF 攻擊來直接獲取用戶的賬戶控制權(quán)，也不能直接竊取用戶的任何信息。他們能做到的，是欺騙用戶瀏覽器，讓其以用戶的名義執(zhí)行操作。

防范手段

1. 檢查Referer 首部字段

Referer 首部字段位于 HTTP 報文中，用于標識請求來源的地址。檢查這個首部字段并要求請求來源的地址在同一個域名下，可以極大的防止 CSRF 攻擊。

這種辦法簡單易行，工作量低，僅需要在關鍵訪問處增加一步校驗。但這種辦法也有其局限性，因其完全依賴瀏覽器發(fā)送正確的 Referer 字段。雖然 HTTP 協(xié)議對此字段的內(nèi)容有明確的規(guī)定，但并無法保證來訪的瀏覽器的具體實現(xiàn)，亦無法保證瀏覽器沒有安全漏洞影響到此字段。并且也存在攻擊者攻擊某些瀏覽器，篡改其 Referer 字段的可能。

2. 添加校驗Token

在訪問敏感數(shù)據(jù)請求時，要求用戶瀏覽器提供不保存在 Cookie 中，并且攻擊者無法偽造的數(shù)據(jù)作為校驗。例如服務器生成隨機數(shù)并附加在表單中，并要求客戶端傳回這個隨機數(shù)。

3. 輸入驗證碼

因為CSRF 攻擊是在用戶無意識的情況下發(fā)生的，所以要求用戶輸入驗證碼可以讓用戶知道自己正在做的操作。

拒絕服務攻擊

拒絕服務攻擊（denial-of-service attack，DoS），亦稱洪水攻擊，其目的在于使目標電腦的網(wǎng)絡或系統(tǒng)資源耗盡，使服務暫時中斷或停止，導致其正常用戶無法訪問。

分布式拒絕服務攻擊（distributed denial-of-service attack，DDoS），指攻擊者使用兩個或以上被攻陷的電腦作為“僵尸”向特定的目標發(fā)動“拒絕服務”式攻擊。

相關網(wǎng)址：

http://blog.jobbole.com/105402/

https://segmentfault.com/a/1190000015822376

https://blog.csdn.net/qq_39322743/article/details/79700863

https://blog.csdn.net/jxh_123/article/details/40316081