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

圣誕節很快就要到了，對滲透測試的熱情仍然有增無減。我們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,綠盟,啟明星辰,深信服等等都是比較大的安全公司。