蛙蛙推薦：WEB安全入門

時間  2019-11-05
標籤 推薦 web 安全 入門 欄目 HTML 简体版
原文   原文鏈接

信息安全基礎

信息安全目標html

  1. 真實性：對信息的來源進行判斷，能對僞造來源的信息予以鑑別, 就是身份認證。
  2. 保密性：保證機密信息不被竊聽，盜取，或竊聽者不能瞭解信息的真實含義。
  3. 完整性：保證數據的一致性，防止數據被非法用戶篡改或部分丟失。
  4. 可用性：保證合法用戶對信息和資源的使用不會被不正當地拒絕。
  5. 不可抵賴性：創建有效的責任機制，防止用戶否定其行爲。

常見攻擊手段git

  1. 破壞信息的完整性，篡改信息
  2. 拒絕服務
  3. 竊聽,攔截信息
  4. 假冒
  5. 抵賴
  6. 重放
  7. 猜想預測
  8. 拖庫, 信息泄露

密碼學基礎

HASHgithub

  1. 介紹
    1. 摘要性，把任意大小的數據映射成固定長大小的摘要信息，不一樣信息有不一樣的哈希值。
    2. 不可逆性，經過hash值不能反推出原始數據。
  2. 用途：
    1. 防止信息被篡改
    2. 保證信息完整性
    3. 數據去重
  3. 常見算法：
    1. checksum: 就是簡單的總和校驗碼，通常在通訊中用於保證數據的完整性和準確性,好比tcp協議。
    2. crc32：32bit,性能好，碰撞率高，通常用於圖片去重。
    3. md5: 128bit,通常用戶密碼加密，文件校驗，對於密碼加密已經不安全，由於已經找到了碰撞條件
    4. sha1: 基本同md5, 已經找到了碰撞條件, 但用於文件校驗仍是沒問題的
    5. sha256: 相對安全，能夠用於密碼加密
    6. Bloom Filter: 多個hash函數組合進行去重，通常用於大數據量的去重，好比搜索引擎網頁收錄。 若是它說一個項目不在一個集合裏，那確定不在，若是說在，那有很小的可能不在。

隨機數web

  1. 介紹
    1. 指定一個範圍和種子，隨機的生成一個數字
  2. 用途：
    1. 防猜想預測，讓黑客猜想不到信息地址或加密因子。
    2. 防止重放，每次請求裏的隨機數不一致，用戶重放請求時隨機數已被使用而拒絕請求。
    3. Hash裏看成salt，讓相同的明文加鹽後生成不一樣的hash值，防止被人用字典攻擊破解密碼。
    4. 加密算法中看成iv(初始化向量)，讓相同的明文塊生成不一樣的密文，增長破解難度。
    5. 從集合裏隨機抽取數據，保證一段時間內惟一，好比tcp的seq。
    6. 動態口令，和時間，種子相關的隨機數。
  3. 經常使用算法：
    1. 線性同餘: 最經常使用的僞隨機數生成算法，若是知道種子有可能被預測到。
    2. GUID: 全球惟一字符串，很難被猜想到。

對稱加密算法

  1. 介紹：加密和解密須要使用相同的密鑰，有流加密和塊加密之分，通常能夠進行大數據量的加密。
  2. 用途：
    1. 防止信息泄露
    2. 防止信息攔截
  3. 常見算法：
    1. DES: 64bit密鑰, 破解難度較低
    2. 3DES: 三重DES，128bit密鑰，破解難度較高
    3. RC2: DES的建議替代算法, 密鑰長度可變,1-128bit, 速度較快
    4. RC4: 強度高，速度快, 不安全
    5. AES: 普遍使用的加密算法，速度快，安全級別高，已經成爲美國加密標準, 目前 AES 標準的一個實現是 Rijndael 算法

非對稱加密數據庫

  1. 介紹：
    1. 加密和解密使用不一樣的密鑰，通常只能加密不多量的數據，並且性能較差。
    2. 公鑰能夠公開，公鑰加密的數據私鑰能夠解密，反之也是。
    3. 私鑰須要祕密保管，私鑰簽名的數據，公鑰能夠驗證簽名。
    4. 非對稱加密算法的保密性比較好，它消除了最終用戶交換密鑰的須要。
  2. 用途：
    1. 驗證身份，數字簽名, 能夠解決否定、僞造、篡改及冒充等問題
    2. 數據加密, 防止信息泄露和攔截
  3. 常見算法：
    1. RSA: 基於大數運算和數學原理，可讓加密和解密使用不一樣的密鑰。
    2. DSA: 數據簽名算法，

身份認證方案

HTTP基本認證數組

  1. 介紹：用戶名追加一個冒號而後串接上口令，並將得出的結果字符串再用Base64算法編碼。
  2. 優勢：
    1. 瀏覽器支持普遍。
  3. 缺點：
    1. 不能防止信息泄露，base64只是編碼，不是加密。
    2. 不能防竊聽
    3. 不能防重放
    4. 不能防拖庫
  4. 使用場景：
    1. 在可信網絡環境中可以使用基本認證。
    2. 使用HTTPS作傳輸層。

HMAC瀏覽器

  1. 介紹：
    1. 用哈希算法，以一個密鑰和一個消息爲輸入，生成一個消息摘要做爲輸出。
    2. 消息認證碼是基於密鑰和消息摘要【hash】所得到的一個值，可用於數據源發認證和完整性校驗。
  2. 原理：
    1. 圖
    2. client要給server發送message，先用key和message加起來，而後哈希得出一個MAC
    3. 而後用戶把明文message和MAC發給server
    4. server知道key，用一樣的算法獲得MAC，看和client請求的MAC是否一致
    5. 若是MAC一致，說明message是擁有key的人發送的，並且message沒有被篡改
  3. 優勢：
    1. 實現了身份認證，實現了不可抵賴性
    2. 保證了數據完整性，達到了防篡改的效果
    3. HMAC與通常的加密重要的區別在於它具備「瞬時」性，即認證只在當時有效
  4. 缺點：
    1. message是明文，不能防竊聽
    2. 不能防重放
  5. 應用：
    1. 挑戰/響應（Challenge/Response）身份認證,如SIP，HTTP
    2. Cookie簽名

HTTP摘要認證(Digest access authentication, rfc2069)安全

  1. 介紹
    1. 它在密碼發出前，先對其應用哈希函數，這相對於HTTP基本認證發送明文而言，更安全。
    2. 圖
  2. 原理
    1. client請求認證頁面, 不提供用戶名和密碼
    2. server返回401應答
      1. realm：認證域, 明文，
      2. nonce: 隨機數, 明文，只使用一次
    3. client再次發起請求
      1. 對用戶名、認證域(realm)以及密碼的合併值計算 MD5 哈希值，結果稱爲 HA1。
      2. 對HTTP方法以及URI的摘要的合併值計算 MD5 哈希值，例如，"GET" 和 "/dir/index.html"，結果稱爲 HA2。
      3. 對 HA一、服務器密碼隨機數(nonce)、請求計數(nc,防止重放)、客戶端密碼隨機數(cnonce)、 HA2 的合併值計算 MD5獲得response 值以及cnonce。
    4. server收到應答，由於服務器擁有與客戶端一樣的信息，所以服務器能夠進行一樣的計算，以驗證客戶端提交的 response 值的正確性。
  3. 優勢
    1. 密碼明文不須要傳輸，因此明文不會被泄露,這樣server能夠不存明文密碼，而是隻存HA1。
    2. 能夠客戶端隨機數cnonce，夠防止選擇明文攻擊(劫持到密文後猜想加密算法及明文)。
    3. nonce容許包含時間戳, 過時後就失效，防止重放攻擊。
    4. 服務器也能夠維護一個最近發出的nonce的列表以防止nonce重用。
    5. 防監聽，防重放, 防抵賴，身份認證
  4. 缺點
    1. RFC 2617 中的許多安全選項都是可選的, 某些時候會降級爲RFC 2616。
    2. 容易受到中間人攻擊, 摘要訪問認證沒有提供任何機制幫助客戶端驗證服務器的身份。
    3. 使用HTTPS加密同時使用這些弱明文協議解決了許多摘要訪問認證試圖要防止的許多威脅。
    4. 使用md5是使用到了md5的不可逆性，但md5如今有能夠攻擊的方式，如窮舉攻擊(密碼比較簡單時)，字典攻擊，
    5. 如何面對衝突攻擊(不一樣明文哈希後相同)（rfc2617）。
  5. 其它說明
    1. 能夠容許每個nonce只使用一次，但這樣就會迫使客戶端在發送每一個請求的時候重複認證過程
    2. nonce在生成後馬上過時是不行的，由於客戶端將沒有任何機會來使用這個nonce。
    3. 客戶端屢次請求能夠重用nonce,但得提供新的cnonce。在後續的請求中，nc比前一次要大。

https/tls服務器

  1. 介紹：它是一個安全傳輸協議，但也能夠進行身份認證。
    1. 加密傳輸數據: 服務端和客戶端之間的全部通信，都是加密的。
    2. 用於身份驗證: 保證服務器就是他聲稱的服務器。
    3. 維護數據的完整性，確保數據在傳輸過程當中不被改變。
    4. RC4, X509
  2. 握手機制-簡化版
    1. client要訪問一個server, 知道server的域名domain
    2. client向server發起請求 2.1. ssl版本號 2.2. 加密算法類型 2.3. 隨機數
    3. server給client返回應答 3.1 ssl版本號 3.2 加密算法類型 3.3 隨機數 3.4 本身的證書(公鑰) 3.5 隨機數簽名。
    4. client驗證服務端返回的應答 4.1 證書是否過時 4.2 髮型證書的CA是否可靠（會和本地的可信任CA列表對比） 4.3 server的公鑰可否解開server返回的隨機數簽名 # 確認server有該證書的私鑰 4.4 server的證書受權的域名是不是server的域名
    5. client隨機產生一個用於對稱加密密鑰，而後用server的公鑰加密，發給Server
    6. server用本身三私鑰解密出對稱加密密鑰。
    7. 後續的通訊都用對稱加密密鑰進行加解密。
  3. 優勢：
    1. 防竊聽
    2. 防重放
    3. 防中間人攻擊，
    4. 保證數據完整性性
    5. 防止會話劫持
  4. 缺點
    1. 不能防止信息泄露，拖庫，只是保證傳輸層安全
    2. 通常不能用於客戶端身份驗證，須要配合http基本認證
    3. 創建鏈接速度慢

oauth

  1. 介紹：OAuth容許用戶提供一個令牌，而不是用戶名和密碼來訪問他們存放在特定服務提供者的數據。每個令牌受權一個特定的網站（例如，視頻編輯網站)在特定的時段（例如，接下來的2小時內）內訪問特定的資源（例如僅僅是某一相冊中的視頻）。
  2. 原理：
    1. 用戶訪問客戶端的網站，想操做本身存放在服務提供方的資源。
    2. 客戶端向服務提供方請求一個臨時令牌。
    3. 服務提供方驗證客戶端的身份後，授予一個臨時令牌。
    4. 客戶端得到臨時令牌後，將用戶引導至服務提供方的受權頁面請求用戶受權。在這個過程當中將臨時令牌和客戶端的回調鏈接發送給服務提供方。
    5. 用戶在服務提供方的網頁上輸入用戶名和密碼，而後受權該客戶端訪問所請求的資源。
    6. 受權成功後，服務提供方引導用戶返回客戶端的網頁。
    7. 客戶端根據臨時令牌從服務提供方那裏獲取訪問令牌 。
    8. 服務提供方根據臨時令牌和用戶的受權狀況授予客戶端訪問令牌。
    9. 客戶端使用獲取的訪問令牌訪問存放在服務提供方上的受保護的資源。

雙因素認證，動態口令

  1. 介紹： 1.簡單來講，雙因素身份認證就是經過你所知道再加上你所能擁有的這二個要素組合到一塊兒才能發揮做用的身份認證系統, 如ATM。
    1. 目前主流的雙因素認證系統是基於時間同步型，
    2. 市場佔有率高的有DKEY雙因素認證系統、RSA雙因素認證系統等
    3. 主流的有硬件令牌、手機短信密碼、USB KEY、混合型令牌（USBKEY+動態口令）, 密保卡，手機令牌
  2. 優勢
    1. 密碼丟失後，黑客不能登陸你的帳戶
  3. 缺點
    1. 使用不方便

用密鑰加密用戶密碼

  1. 介紹：
    1. 本機生成一個密鑰key存磁盤上，對稱加密密鑰。
    2. 建立用戶時，用戶提供password, 而後數據庫裏保存db_password = encrypt(key, hash(password))
    3. 這樣黑客把數據庫拖走後，由於沒有key解開用db_password，因此用戶密碼仍是安全的。
    4. 用戶登陸時提供密碼password, 哈希後是hash(password), 而後uncrypt(key, db_password)，
      1. 二者比較，一致就是認證經過
      2. 不一致就是終止認證
  2. 優勢：
    1. 防止拖庫
  3. 缺點
    1. key丟了就完蛋了，誰也登陸不上了。

Secure Remote Password protocol

  1. 介紹

    1. 一個認證和密鑰交換系統，它用來在不可靠的網絡中保護口令和交換密鑰。
    2. 經過消除了在網絡上發送明文口令的須要，而且經過安全的密鑰交換機制來使用加密，改進了安全性。
    3. 服務器不保存密碼或密碼的散列值, 防止字典攻擊. 而只是保存驗證因子(verifier).
    4. 客戶端和服務器能夠各自計算出一個會話祕鑰(session key), 其值相同. 防止竊聽和會話劫持.
    5. 好多遊戲服務端用SRP認證，好比魔獸世界。

  2. 優勢

    1. 防竊聽
    2. 防暴力破解，字典攻擊, 弱口令也不容易被破解
    3. 即便口令數據庫被公之於衆，攻擊者仍然須要一個龐大的字典去搜索來得到口令。
    4. 速度快，不須要證書和第三方認證機構

  3. 缺點

    1. 瀏覽器不支持，得本身實現

原理

N     一個安全的大質數, 好比N=2q+1,q 是一個素數
g     一個以N爲模的生成元，對任何X，有0 < X < N，存在一個值x，使得g^x % N == X。
k     k = H(N,G) 在 SRP6 中 k = 3
s     User’s Salt
I     用戶名
p     明文密碼
H()   單向 hash 函數
^     求冪運算
u     隨機數
a,b   保密的臨時數字
A,B   公開的臨時數字
x     私有密匙（從 p 和 s 計算得來）
v     密碼驗證數字

N和g的值必須由雙方討論來達成一致。它們能夠被提早設置好，或者主機把它們發送給客戶端。

服務器存儲以下信息
x = H(s, p)               (s is chosen randomly)
v = g^x                   (computes password verifier)

服務器的數據庫保存 {I, s, v} 整個驗證流程以下:

User -> Host:  I, A = g^a                  (標識本身是誰, a是隨機數)
Host -> User:  s, B = kv + g^b             (把salt發送給user, b是隨機數)

        Both:  u = H(A, B)

        User:  x = H(s, p)                 (用戶輸入密碼)
        User:  S = (B - kg^x) ^ (a + ux)   (計算會話密鑰)
        User:  K = H(S)

        Host:  S = (Av^u) ^ b              (計算會話密鑰)
        Host:  K = H(S)

這樣雙方都有一個會話密鑰S, 後續的消息傳輸能夠用S作加解密，從而保證安全。
爲了完成認證過程，雙方還得向對方證實本身擁有正確的S，
S不能讓第三方知道，因此不能直接傳輸給對方作比較，一個可能的辦法是:

User -> Host:  M = H(H(N) xor H(g), H(I), s, A, B, K)
Host -> User:  H(A, M, K)

雙方須要作以下保障
    1. 若是客戶端收到B == 0 (mod N) 或u == 0, 客戶端中止認證。
    2. 若是服務器發現 A == 0 (mod N)則中止認證。
    3. 用戶必須得證實本身擁有正確的K，不然服務器就會終止認證。

相關連接

  1. HTTPS的七個誤解（譯文）
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程