聖誕節很快就要到了，對滲透測試的熱情仍然有增無減。我們在此為使用者認證登入安全制定一個全面的檢測方法和要點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，并做如下檢查
tgs生成一個session key組裝兩個票據給用戶端
1.用用戶端和tgs的session key加密的票據，包含新生成的session key和server_principal
2.用伺服器的密碼加密的票據，包括新生成的session key和client principal
用戶端收到兩個票據後，解開自己的，然後生成一個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)。一個比較典型認證過程如下：
Client通路受保護的資源
SP生成認證請求SAML傳回給Client
Client送出請求到IDP
IDP傳回認證請求
Client登陸IDP
認證成功後，IDP生成私鑰簽名辨別了權限的SAML，傳回給Client
Client送出SAML給SP
SP讀取SAML，确定請求合法，傳回資源
7.4.3. 安全問題
源于ssl模式下的認證可選性，可以删除簽名方式标簽繞過認證，如果SAML中缺少了expiration，并且斷言ID不是唯一的，那麼就可能被重播攻擊影響，越來越多的網站安全問題日益出現,如果想要對網站或平台進行全面的安全檢測以及滲透測試,可以咨詢下專業的網站安全公司來進行安全加強滲透測試。