圣誕節(jié)很快就要到了，對滲透測試的熱情仍然有增無減。我們SINE安全在此為用戶認(rèn)證登錄安全制定一個(gè)全面的檢測方法和要點(diǎn)Json web token (JWT), 是為了在網(wǎng)絡(luò)應(yīng)用環(huán)境間傳遞聲明而執(zhí)行的一種基于JSON的開放標(biāo)準(zhǔn)（(RFC 7519).該token被設(shè)計(jì)為緊湊且安全的，特別適用于分布式站點(diǎn)的單點(diǎn)登錄（SSO）場景。JWT的聲明一般被用來在身份提供者和服務(wù)提供者間傳遞被認(rèn)證的用戶身份信息，以便于從資源服務(wù)器獲取資源，也可以增加一些額外的其它業(yè)務(wù)邏輯所必須的聲明信息，該token也可直接被用于認(rèn)證，也可被加密。

10年積累的網(wǎng)站設(shè)計(jì)、做網(wǎng)站經(jīng)驗(yàn)，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先制作網(wǎng)站后付款的網(wǎng)站建設(shè)流程，更有淮安區(qū)免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

7.2.2. 構(gòu)成

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

7.2.3. 安全問題

7.2.3.1. Header部分

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

7.2.3.2. Payload部分

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

7.2.3.3. Signature部分

• 檢查是否強(qiáng)制檢查簽名
• 密鑰是否可以被強(qiáng)行登錄
• 是否可以通過其他方式拿到密鑰

7.2.3.4. 其他

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

Kerberos

7.3.1. 簡介

簡單地說，Kerberos提供了一種單點(diǎn)登錄(SSO)的方法。考慮這樣一個(gè)場景，在一個(gè)網(wǎng)絡(luò)中有不同的服務(wù)器，比如，打印服務(wù)器、郵件服務(wù)器和文件服務(wù)器。這些服務(wù)器都有認(rèn)證的需求。很自然的，不可能讓每個(gè)服務(wù)器自己實(shí)現(xiàn)一套認(rèn)證系統(tǒng)，而是提供一個(gè)中心認(rèn)證服務(wù)器（AS-Authentication Server）供這些服務(wù)器使用。這樣任何客戶端就只需維護(hù)一個(gè)密碼就能登錄所有服務(wù)器。

因此，在Kerberos系統(tǒng)中至少有三個(gè)角色：認(rèn)證服務(wù)器（AS），客戶端（Client）和普通服務(wù)器（Server）?？蛻舳撕头?wù)器將在AS的幫助下完成相互認(rèn)證。在Kerberos系統(tǒng)中，客戶端和服務(wù)器都有一個(gè)唯一的名字，叫做Principal。同時(shí)，客戶端和服務(wù)器都有自己的密碼，并且它們的密碼只有自己和認(rèn)證服務(wù)器AS知道。

7.3.2. 簡化的認(rèn)證過程

• 客戶端向服務(wù)器發(fā)起請求，請求內(nèi)容是：客戶端的principal，服務(wù)器的principal
• AS收到請求之后，隨機(jī)生成一個(gè)密碼Kc, s(session key), 并生成以下兩個(gè)數(shù)據(jù)返回給客戶端
• 1.給客戶端的 數(shù)據(jù)，用客戶端的密碼加密，內(nèi)容為隨機(jī)密碼，session，server_principal
• 2.給服務(wù)器端的 數(shù)據(jù)，用服務(wù)器的密碼加密，內(nèi)容為隨機(jī)密碼，session，client_principal
• 客戶端拿到了第二步中的兩個(gè) 數(shù)據(jù)后，首先用自己的密碼解開 數(shù)據(jù)，得到Kc、s，然后生成一個(gè)Authenticator，其中主要包括當(dāng)前時(shí)間和Ts,c的校驗(yàn)碼，并且用SessionKey Kc,s加密。之后客戶端將Authenticator和給server的 數(shù)據(jù)同時(shí)發(fā)給服務(wù)器
• 服務(wù)器首先用自己的密碼解開 數(shù)據(jù)，拿到SessionKey Kc,s，然后用Kc,s解開Authenticator，并做如下檢查
• 1.檢查Authenticator中的時(shí)間戳是不是在當(dāng)前時(shí)間上下5分鐘以內(nèi)，并且檢查該時(shí)間戳是否首次出現(xiàn)。如果該時(shí)間戳不是第一次出現(xiàn)，那說明有人截獲了之前客戶端發(fā)送的內(nèi)容，進(jìn)行Replay攻擊。
• 2.檢查checksum是否正確
• 3.如果都正確，客戶端就通過了認(rèn)證
• 服務(wù)器段可選擇性地給客戶端回復(fù)一條消息來完成雙向認(rèn)證，內(nèi)容為用session key加密的時(shí)間戳
• 客戶端通過解開消息，比較發(fā)回的時(shí)間戳和自己發(fā)送的時(shí)間戳是否一致，來驗(yàn)證服務(wù)器

7.3.3. 完整的認(rèn)證過程

上方介紹的流程已經(jīng)能夠完成客戶端和服務(wù)器的相互認(rèn)證。但是，比較不方便的是每次認(rèn)證都需要客戶端輸入自己的密碼。

因此在Kerberos系統(tǒng)中，引入了一個(gè)新的角色叫做： 數(shù)據(jù)授權(quán)服務(wù)(TGS - Ticket Granting Service)，它的地位類似于一個(gè)普通的服務(wù)器，只是它提供的服務(wù)是為客戶端發(fā)放用于和其他服務(wù)器認(rèn)證的 數(shù)據(jù)。

這樣，Kerberos系統(tǒng)中就有四個(gè)角色：認(rèn)證服務(wù)器（AS），客戶端（Client），普通服務(wù)器（Server）和 數(shù)據(jù)授權(quán)服務(wù)（TGS）。這樣客戶端初次和服務(wù)器通信的認(rèn)證流程分成了以下6個(gè)步驟：

• 客戶端向AS發(fā)起請求，請求內(nèi)容是：客戶端的principal， 數(shù)據(jù)授權(quán)服務(wù)器的rincipal
• AS收到請求之后，隨機(jī)生成一個(gè)密碼Kc, s(session key), 并生成以下兩個(gè) 數(shù)據(jù)返回給客戶端：
• 1.給客戶端的 數(shù)據(jù)，用客戶端的密碼加密，內(nèi)容為隨機(jī)密碼，session，tgs_principal
• 2.給tgs的 數(shù)據(jù)，用tgs的密碼加密，內(nèi)容為隨機(jī)密碼，session，client_principal
• 客戶端拿到了第二步中的兩個(gè) 數(shù)據(jù)后，首先用自己的密碼解開 數(shù)據(jù)，得到Kc、s，然后生成一個(gè)Authenticator，其中主要包括當(dāng)前時(shí)間和Ts,c的校驗(yàn)碼，并且用SessionKey Kc,s加密。之后客戶端向tgs發(fā)起請求，內(nèi)容包括:
• 1.Authenticator
• 2.給tgs的 數(shù)據(jù)同時(shí)發(fā)給服務(wù)器
• 3.server_principal
• TGS首先用自己的密碼解開 數(shù)據(jù)，拿到SessionKey Kc,s，然后用Kc,s解開Authenticator，并做如下檢查
• 1.檢查Authenticator中的時(shí)間戳是不是在當(dāng)前時(shí)間上下5分鐘以內(nèi)，并且檢查該時(shí)間戳是否首次出現(xiàn)。如果該時(shí)間戳不是第一次出現(xiàn)，那說明有人截獲了之前客戶端發(fā)送的內(nèi)容，進(jìn)行Replay攻擊。
• 2.檢查checksum是否正確
• 3.如果都正確，客戶端就通過了認(rèn)證
• tgs生成一個(gè)session key組裝兩個(gè) 數(shù)據(jù)給客戶端
• 1.用客戶端和tgs的session key加密的 數(shù)據(jù)，包含新生成的session key和server_principal
• 2.用服務(wù)器的密碼加密的 數(shù)據(jù)，包括新生成的session key和client principal
• 客戶端收到兩個(gè) 數(shù)據(jù)后，解開自己的，然后生成一個(gè)Authenticator，發(fā)請求給服務(wù)器，內(nèi)容包括
• 1.Authenticator
• 2.給服務(wù)器的 數(shù)據(jù)
• 服務(wù)器收到請求后，用自己的密碼解開 數(shù)據(jù)，得到session key，然后用session key解開authenticator對可無端進(jìn)行驗(yàn)證
• 服務(wù)器可以選擇返回一個(gè)用session key加密的之前的是時(shí)間戳來完成雙向驗(yàn)證
• 客戶端通過解開消息，比較發(fā)回的時(shí)間戳和自己發(fā)送的時(shí)間戳是否一致，來驗(yàn)證服務(wù)器

SAML

7.4.1. 簡介

SAML (Security Assertion Markup Language) 譯為安全斷言標(biāo)記語言，是一種xXML格式的語言，使用XML格式交互，來完成SSO的功能。 SAML存在1.1和2.0兩個(gè)版本，這兩個(gè)版本不兼容，不過在邏輯概念或者對象結(jié)構(gòu)上大致相當(dāng)，只是在一些細(xì)節(jié)上有所差異。

7.4.2. 認(rèn)證過程

SAML的認(rèn)證涉及到三個(gè)角色，分別為服務(wù)提供者(SP)、認(rèn)證服務(wù)(IDP)、用戶(Client)。一個(gè)比較典型認(rèn)證過程如下：

1. Client訪問受保護(hù)的資源
2. SP生成認(rèn)證請求SAML返回給Client
3. Client提交請求到IDP
4. IDP返回認(rèn)證請求
5. Client登陸IDP
6. 認(rèn)證成功后，IDP生成私鑰簽名標(biāo)識(shí)了權(quán)限的SAML，返回給Client
7. Client提交SAML給SP
8. SP讀取SAML，確定請求合法，返回資源

7.4.3. 安全問題

源于ssl模式下的認(rèn)證可選性，可以刪除簽名方式標(biāo)簽繞過認(rèn)證，如果SAML中缺少了expiration，并且斷言ID不是唯一的，那么就可能被重放攻擊影響，越來越多的網(wǎng)站安全問題日益出現(xiàn),如果想要對網(wǎng)站或平臺(tái)進(jìn)行全面的安全檢測以及滲透測試,可以咨詢下專業(yè)的網(wǎng)站安全公司來進(jìn)行安全加固滲透測試,國內(nèi)做的比較好的推薦Sinesafe,綠盟,啟明星辰,深信服等等都是比較大的安全公司。