網站滲透測試安全檢測登陸認證分析

聖誕節很快就要到了，對滲透測試的熱情仍然有增無減。咱們SINE安全在此爲用戶認證登陸安全制定一個全面的檢測方法和要點Json web token (JWT), 是爲了在網絡應用環境間傳遞聲明而執行的一種基於JSON的開放標準（(RFC 7519).該token被設計爲緊湊且安全的，特別適用於分佈式站點的單點登陸（SSO）場景。JWT的聲明通常被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便於從資源服務器獲取資源，也能夠增長一些額外的其它業務邏輯所必須的聲明信息，該token也可直接被用於認證，也可被加密。

7.2.2. 構成

分爲三個部分，分別爲header/payload/signature。其中header是聲明的類型和加密使用的算法。payload是載荷，最後是加上 HMAC((header)+(payload), secret)

7.2.3. 安全問題

7.2.3.1. Header部分

• 是否支持修改算法爲none
• kid字段是否有注入
• jwk元素是否可信
• 是否強制使用白名單上的加密算法

7.2.3.2. Payload部分

• 其中是否存在敏感信息
• 檢查過時策略，好比 exp , iat

7.2.3.3. Signature部分

• 檢查是否強制檢查簽名
• 密鑰是否能夠被強行登陸
• 是否能夠經過其餘方式拿到密鑰

7.2.3.4. 其餘

• 修改算法RS256爲HS256
• 弱密鑰破解

Kerberos

7.3.1. 簡介

簡單地說，Kerberos提供了一種單點登陸(SSO)的方法。考慮這樣一個場景，在一個網絡中有不一樣的服務器，好比，打印服務器、郵件服務器和文件服務器。這些服務器都有認證的需求。很天然的，不可能讓每一個服務器本身實現一套認證系統，而是提供一箇中心認證服務器（AS-Authentication Server）供這些服務器使用。這樣任何客戶端就只需維護一個密碼就能登陸全部服務器。

所以，在Kerberos系統中至少有三個角色：認證服務器（AS），客戶端（Client）和普通服務器（Server）。客戶端和服務器將在AS的幫助下完成相互認證。在Kerberos系統中，客戶端和服務器都有一個惟一的名字，叫作Principal。同時，客戶端和服務器都有本身的密碼，而且它們的密碼只有本身和認證服務器AS知道。

7.3.2. 簡化的認證過程

• 客戶端向服務器發起請求，請求內容是：客戶端的principal，服務器的principal
• AS收到請求以後，隨機生成一個密碼Kc, s(session key), 並生成如下兩個票據返回給客戶端
• 1.給客戶端的票據，用客戶端的密碼加密，內容爲隨機密碼，session，server_principal
• 2.給服務器端的票據，用服務器的密碼加密，內容爲隨機密碼，session，client_principal
• 客戶端拿到了第二步中的兩個票據後，首先用本身的密碼解開票據，獲得Kc、s，而後生成一個Authenticator，其中主要包括當前時間和Ts,c的校驗碼，而且用SessionKey Kc,s加密。以後客戶端將Authenticator和給server的票據同時發給服務器
• 服務器首先用本身的密碼解開票據，拿到SessionKey Kc,s，而後用Kc,s解開Authenticator，並作以下檢查
• 1.檢查Authenticator中的時間戳是否是在當前時間上下5分鐘之內，而且檢查該時間戳是否首次出現。若是該時間戳不是第一次出現，那說明有人截獲了以前客戶端發送的內容，進行Replay攻擊。
• 2.檢查checksum是否正確
• 3.若是都正確，客戶端就經過了認證
• 服務器段可選擇性地給客戶端回覆一條消息來完成雙向認證，內容爲用session key加密的時間戳
• 客戶端經過解開消息，比較發回的時間戳和本身發送的時間戳是否一致，來驗證服務器

7.3.3. 完整的認證過程

上方介紹的流程已經可以完成客戶端和服務器的相互認證。可是，比較不方便的是每次認證都須要客戶端輸入本身的密碼。

所以在Kerberos系統中，引入了一個新的角色叫作：票據受權服務(TGS - Ticket Granting Service)，它的地位相似於一個普通的服務器，只是它提供的服務是爲客戶端發放用於和其餘服務器認證的票據。

這樣，Kerberos系統中就有四個角色：認證服務器（AS），客戶端（Client），普通服務器（Server）和票據受權服務（TGS）。這樣客戶端初次和服務器通訊的認證流程分紅了如下6個步驟：

• 客戶端向AS發起請求，請求內容是：客戶端的principal，票據受權服務器的rincipal
• AS收到請求以後，隨機生成一個密碼Kc, s(session key), 並生成如下兩個票據返回給客戶端：
• 1.給客戶端的票據，用客戶端的密碼加密，內容爲隨機密碼，session，tgs_principal
• 2.給tgs的票據，用tgs的密碼加密，內容爲隨機密碼，session，client_principal
• 客戶端拿到了第二步中的兩個票據後，首先用本身的密碼解開票據，獲得Kc、s，而後生成一個Authenticator，其中主要包括當前時間和Ts,c的校驗碼，而且用SessionKey Kc,s加密。以後客戶端向tgs發起請求，內容包括:
• 1.Authenticator
• 2.給tgs的票據同時發給服務器
• 3.server_principal
• TGS首先用本身的密碼解開票據，拿到SessionKey Kc,s，而後用Kc,s解開Authenticator，並作以下檢查
• 1.檢查Authenticator中的時間戳是否是在當前時間上下5分鐘之內，而且檢查該時間戳是否首次出現。若是該時間戳不是第一次出現，那說明有人截獲了以前客戶端發送的內容，進行Replay攻擊。
• 2.檢查checksum是否正確
• 3.若是都正確，客戶端就經過了認證
• tgs生成一個session key組裝兩個票據給客戶端
• 1.用客戶端和tgs的session key加密的票據，包含新生成的session key和server_principal
• 2.用服務器的密碼加密的票據，包括新生成的session key和client principal
• 客戶端收到兩個票據後，解開本身的，而後生成一個Authenticator，發請求給服務器，內容包括
• 1.Authenticator
• 2.給服務器的票據
• 服務器收到請求後，用本身的密碼解開票據，獲得session key，而後用session key解開authenticator對可無故進行驗證
• 服務器能夠選擇返回一個用session key加密的以前的是時間戳來完成雙向驗證
• 客戶端經過解開消息，比較發回的時間戳和本身發送的時間戳是否一致，來驗證服務器

SAML

7.4.1. 簡介

SAML (Security Assertion Markup Language) 譯爲安全斷言標記語言，是一種xXML格式的語言，使用XML格式交互，來完成SSO的功能。 SAML存在1.1和2.0兩個版本，這兩個版本不兼容，不過在邏輯概念或者對象結構上大體至關，只是在一些細節上有所差別。

7.4.2. 認證過程

SAML的認證涉及到三個角色，分別爲服務提供者(SP)、認證服務(IDP)、用戶(Client)。一個比較典型認證過程以下：

1. Client訪問受保護的資源
2. SP生成認證請求SAML返回給Client
3. Client提交請求到IDP
4. IDP返回認證請求
5. Client登錄IDP
6. 認證成功後，IDP生成私鑰簽名標識了權限的SAML，返回給Client
7. Client提交SAML給SP
8. SP讀取SAML，肯定請求合法，返回資源

7.4.3. 安全問題

源於ssl模式下的認證可選性，能夠刪除簽名方式標籤繞過認證，若是SAML中缺乏了expiration，而且斷言ID不是惟一的，那麼就可能被重放攻擊影響，愈來愈多的網站安全問題日益出現,若是想要對網站或平臺進行全面的安全檢測以及滲透測試,能夠諮詢下專業的網站安全公司來進行安全加固滲透測試,國內作的比較好的推薦Sinesafe,綠盟,啓明星辰,深信服等等都是比較大的安全公司。