一、HTTPS是一種通過計算機網路進行安全通信的傳輸協議,經由HTTP進行通信,利用SSL/TLS建立全信道,加密資料包,HTTPS使用的主要目的是提供對網站服務器的身份認證,同時保護交換資料的隱私與完整性,
1、他的資料是加密的,2、驗證身份,客戶端和服務端都會向CA機構申請證書,在SSL握手階段會驗證雙方的身份,防止第三方的冒充;3、保證資料的完整性,每次資料都要加上MAC摘要并簽名,接受和發送資料,都要保證摘要一致,防止資料被篡改,
結果分析:HTTP協議傳輸資料以明文形式顯示
針對無狀態的一些解決策略:
場景:逛電商商場用戶需要使用的時間比較長,需要對用戶一段時間的HTTP通信狀態進行保存,比如執行一次登陸操作,在30分鐘內所有的請求都不需要再次登陸,
通過Cookie/Session技術
HTTP/1.1持久連接(HTTP keep-alive)方法,只要任意一端沒有明確提出斷開連接,則保持TCP連接狀態,在請求首部欄位中的Connection: keep-alive即為表明使用了持久連接
HTTPS特點:
基于HTTP協議,通過SSL或TLS提供加密處理資料、驗證對方身份以及資料完整性保護
HTTPS有如下特點:
- 內容加密:采用混合加密技術,中間者無法直接查看明文內容
- 驗證身份:通過證書認證客戶端訪問的是自己的服務器
- 保護資料完整性:防止傳輸的內容被中間人冒充或者篡改
混合加密:**結合非對稱加密和對稱加密技術,客戶端使用對稱加密生成密鑰對傳輸資料進行加密,然后使用非對稱加密的公鑰再對秘鑰進行加密,所以網路上傳輸的資料是被秘鑰加密的密文和用公鑰加密后的秘密秘鑰,因此即使被黑客截取,由于沒有私鑰,無法獲取到加密明文的秘鑰,便無法獲取到明文資料,
**數字摘要:**通過單向hash函式對原文進行哈希,將需加密的明文“摘要”成一串固定長度(如128bit)的密文,不同的明文摘要成的密文其結果總是不相同,同樣的明文其摘要必定一致,并且即使知道了摘要也不能反推出明文,
**數字簽名技術:**數字簽名建立在公鑰加密體制基礎上,是公鑰加密技術的另一類應用,它把公鑰加密技術和數字摘要結合起來,形成了實用的數字簽名技術,
二、常見的密碼學演算法
1、哈希演算法
位元幣系統中使用的哈希函式分別用于完成作業量證明計算合生成地址,簡言之,哈希演算法是將任意長度的字串映射為較短的固定長度的字串,因為這個運算的確定性,高效性使得去中心化的計算能夠實作,又因為對輸入的敏感性,和該映射逆函式難以尋找(抗原像攻擊),對區塊鏈系統安全性有很大幫助,
哈希演算法是一種常見的單向加密演算法,它將一串資料加密生成一串固定長度的二進制字串,這段二進制字串就是哈希值,但不能由哈希值還原為原來的輸入資料,密碼學中的哈希函式有3個重要的性質,即抗碰撞性、原像不可逆、難題友好性,
碰撞性:是指兩個不同的資料在同一哈希函式作用下,生成相同的哈希值,首先,兩個不同的輸入產生相同哈希值答案是肯定的,但在于它需要像十億年后的所有計算機一樣來尋找碰撞,以目前計算機的運算能力可以忽略不計,在區塊鏈中,哈希函式的抗碰撞性可以用來做區塊和交易的完整性驗證,
原像不可逆:是指根據輸出的二進制字串很難計算出輸入的資料,因為輸出的哈希值長度遠遠小于輸入的長度,所以在運算程序中會丟棄大量的資訊,由于缺失了很多資訊,所以根本無法逆向出任何一個輸入值,
難題友好性:是指沒有便捷的方法去產生一個滿足特殊要求的哈希值,是什么意思呢,通俗的講,就是沒有捷徑,需要一步一步算出來,假如要求得到的哈希結果以若干個0開頭,那么計算找到前3位均為0的哈希值和找到前6位均為0的哈希值,其所需的哈希計算次數是呈一定數量關系,
常用的哈希演算法有MD5、SHA256和RIPEMD,在區塊鏈中很多地方用了哈希演算法,比如對區塊計算哈希值、區塊和交易的完整性驗證等等,
2、對稱加密演算法
對稱加密技術,是采用同一個混淆因子(也叫密碼),然后使用混淆演算法對輸入進行混淆,得到加密后的資料,之后,采用相同的混淆因子(密碼)進行逆運算,可以得到原始的輸入值,它的特點是:使用的密鑰只有一個,發收信雙方都使用這個密鑰對資料進行加密和解密,要求解密方事先必須知道加密密鑰.
如果有人在傳輸程序中截取了密文和密鑰,就一樣能解密出明文,這就導致了安全性問題,目前區塊鏈領域最常用的對稱加密演算法是AES、PBKDF2和SCRYPT,
3、非對稱加密技術
非對稱加密演算法需要兩個密鑰:公鑰(publickey)和私鑰(privatekey),公鑰與私鑰是一對,私鑰可以推匯出公鑰而公鑰不可以推匯出私鑰,如果用公鑰對資料進行加密,只有用對應的私鑰才能解密;如果用私鑰對資料進行加密,那么只有用對應的公鑰才能解密,簡單的說是“公鑰加密,私鑰解密;私鑰加密,公鑰解密”,
在區塊鏈中,數字簽名就是基于上述非對稱加密技術,不同點在于數字簽名使用私鑰生成一個簽名,接收方使用公鑰進行校驗,比如上面用私鑰解密得到明文后,用私鑰進行簽名進行回復,收到回復后用公鑰解密得到的內容與資料相同即可證明簽名正確,

因為公鑰和私鑰是成對的,唯一對應的,私鑰只有對方擁有,所以對方也不能對簽名進行抵賴,
在區塊鏈技術中常見的簽名演算法是橢圓曲線加密技術,其演算法用對橢圓曲線上的點進行加法或乘法運算來表達,區塊鏈中私鑰是一個亂數,通過橢圓曲線簽名演算法生成公鑰,但反向從公鑰計算出私鑰幾乎是不可能的,橢圓曲線簽名演算法還具有安全性高和存盤空間占用小的特點,
4、BASE58演算法
Base58是位元幣使用的編碼方式,主要用于產生位元幣的錢包地址,這種編碼格式不僅實作了資料壓縮,保持了易讀性,還具有錯誤診斷功能,
5. 零知識證明
零知識證明,它主要是指證明者能夠在不向驗證者提供任何有用資訊的情況下,使驗證者相信某個論斷是正確的,
零知識證明能夠成立需要具備三個要素,即完整性、可靠性和零知識,舉個例子來說就是,假設有一個環形走廊,出口和入口相鄰但不互通(在目測距離之內),在這個環形走廊中間的某處有一道鎖起來的門,只有擁有鑰匙的人才可以通過;這時A要向B證明自己擁有打開這道門的鑰匙,用零知識量證明來解決就是,B看著A走進入口并在出口等待,如果A從入口進入通過走廊并從出口走出,則可以證明其擁有打開中間那扇門的鑰匙,而在這個程序中,他完全不用向B提供鑰匙的具體資訊,所以零知識證明實際上是一種概率證明而非確定性證明,
三、常見的網路攻擊和防御
1、中間人攻擊
產生中間人攻擊的本質原因是協商程序中的資料沒有經過端點認證,通信兩端不知道收到的協商資料是來自對端還是來自中間人,
- 因此單純的“密鑰協商”是不夠的,還需要“帶認證的密鑰協商”
- 防御方式
- CA證書
- 基于簽名演算法的非對稱認證
- HMAC
- 基于訊息認證碼(Message Authentication Code)的對稱認證
- 訊息認證碼的認證方式需要預先共享一個私密的Key(PSK)
2、重放攻擊
- 攻擊者不需要理解請求本身的意思,只需要截獲并重新發送請求即可
- 如果轉賬業務沒有做防重放處理,就會重現重復轉賬問題
- 防御方式
- 每次連接生成不同的秘鑰來進行加密
- 對于不加密的請求,使用 時間戳+不重數
3、CSRF跨站請求偽造

- CSRF攻擊利用Cookie或Session盜取了用戶身份
- 和XSS區別在于惡意請求全部發生在用戶的瀏覽器上
- 這樣不需要拿到cookie,繞開了HTTPOnly的限制
CSRF的主要防御思路是識別請求者身份
防御方式
使用 HTTP 的 Referer 頭
因為 Referer 頭可以攜帶請求的來源頁面地址,這樣可以根據 Referer 頭鑒別出偽造的請求
很多網站使用這個功能實作圖片防盜鏈
如果訪問圖片的請求不是來自自己網站就拒絕
使用表單 token,服務端給每個表單都生成的一個亂數引數
Token和Cookie 所不同的是,前者是對每個頁面或每個表單就會生成一個新的值,而后者則是只有會話重新生成的時候才會生成
當用戶正常操作的時候,這個 token 會被帶上,從而證明用戶操作的合法性,而如果是 CSRF 的情形,這個請求來自于一個非預期的位置,那么就不可能帶有這個正確的 token
驗證碼
用戶體檢不好,一般用于關鍵頁面
一旦存在xss,csrf的防御措施都可能失效
4、XSS(跨站腳本攻擊)
![[?¤é????è???-?¤±è′¥,?o???ˉè??é2?é??o??,??oè???°??????-???¥?′?¥???? (img-xHqzfIXr-1587467432534)(C:\Users\35135\Desktop\markdown\1587355817945.png)]](https://img.uj5u.com/2021/12/31/293516310716083.png)
全球大約70%的web應用攻擊來自XSS和SQL注入攻擊
攻擊者在服務器回傳的普通頁面中嵌入特殊的腳本代碼,那么在普通用戶瀏覽這個網頁的時候,這個特殊的腳本代碼就得到了執行,于是用戶的 Cookie 通過請求的方式發送給了這個攻擊者指定的地址,這樣攻擊者就劫持了用戶的會話,利用 Cookie 中標識身份的字串,就可以偽裝成實際的用戶在這個網頁操作了
惡意腳本的上傳方式,往往是利用網站沒有對用戶的輸入(例如提交的表單)進行過濾或轉義造成的
防御方式
做好字符轉義和過濾
讓用戶上傳的文本在展示的時候永遠只是文本,而不能變成 HTML 和腳本
控制好 Cookie 的作用范圍
比如服務器在回傳 Set-Cookie 頭的時候,設定 HttpOnly 這個標識
這樣只能通過http訪問,javascript無法訪問,惡意上傳的js腳本就無法獲得 Cookie 了
5、SQL注入

SQL 注入指的是攻擊者利用網站漏洞,通過構造特殊的嵌入了 SQL 命令的網站請求以欺騙服務器,并執行該惡意 SQL 命令
SQL注入需要攻擊者對資料庫結構有所了解
獲取方式:
網站使用開源軟體搭建,那么網站資料庫結構就是公開的
網站開啟錯誤回顯,那么內部錯誤會顯示在瀏覽器上,可以通過故意構造非法引數獲取例外資訊
防御方式
對輸入引數進行校驗和過濾
SQL陳述句的執行盡可能采用引數化查詢介面,而不是字串拼接
HTTP劫持
由于HTTP是明文傳輸,所以可以被運營商或者網路服務提供商任意篡改
常用方式是把原網頁嵌入一個iframe中,并讓這個iframe占據這個瀏覽器,然后就可以在iframe外添加浮動廣告了
把網站換位HTTPS可以避免這種劫持
DNS劫持
用戶的瀏覽器在通過 DNS 查詢目標域名對應的 IP 地址的時候,會被攻擊者引導到一個惡意網站的地址,這個假的網站也可以有相似的頁面布局,也可能有“正規”方式申請的 HTTPS 證書
HTTPS加密本身并不能防范DNS劫持
可以通過DNS over HTTPS 的安全域名決議方案防御
DDoS攻擊(分布式拒絕服務攻擊)
攻擊者使用若干被“攻陷”的電腦(比如被病毒占領和控制的“肉雞”),向網路應用和服務同一時間發起請求,通過一瞬間的請求洪峰,將服務沖垮
錯誤回顯
一些服務端直接把未處理的例外堆疊資訊直接輸出到客戶端
黑客通過故意制造非法請求,使系統出錯獲取例外資訊,來尋找漏洞
防御方式: 出錯時跳轉到專門的錯誤頁面即可
路徑遍歷
在請求的URL中使用相對路徑,遍歷系統未開放的目錄和檔案
防御方式:
把JS,CSS等資源部署在獨立服務器、使用獨立域名
其他檔案不適用靜態URL訪問
動態引數不包含檔案路徑
轉載請註明出處,本文鏈接:https://www.uj5u.com/qukuanlian/398460.html
標籤:區塊鏈
下一篇:驗證合約的三種方式
