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

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