更新時(shí)間：2025-05-11 13:31:56
開發(fā)經(jīng)驗(yàn)
545圣誕節(jié)很快就要到了，對(duì)滲透測(cè)試的熱情仍然有增無減。我們SINE安全在此為用戶認(rèn)證登錄安全制定一個(gè)全面的檢測(cè)方法和要點(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）場(chǎng)景。JWT的聲明一般被用來在身份提供者和服務(wù)提供者間傳遞被認(rèn)證的用戶身份信息，以便于從資源服務(wù)器獲取資源，也可以增加一些額外的其它業(yè)務(wù)邏輯所必須的聲明信息，該token也可直接被用于認(rèn)證，也可被加密。
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. 簡(jiǎn)介
簡(jiǎn)單地說，Kerberos提供了一種單點(diǎn)登錄(SSO)的方法。考慮這樣一個(gè)場(chǎng)景，在一個(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. 簡(jiǎn)化的認(rèn)證過程
客戶端向服務(wù)器發(fā)起請(qǐng)求，請(qǐng)求內(nèi)容是：客戶端的principal，服務(wù)器的principal
AS收到請(qǐng)求之后，隨機(jī)生成一個(gè)密碼Kc, s(session key), 并生成以下兩個(gè)票據(jù)返回給客戶端
1.給客戶端的票據(jù)，用客戶端的密碼加密，內(nèi)容為隨機(jī)密碼，session，server_principal
2.給服務(wù)器端的票據(jù)，用服務(wù)器的密碼加密，內(nèi)容為隨機(jī)密碼，session，client_principal
客戶端拿到了第二步中的兩個(gè)票據(jù)后，首先用自己的密碼解開票據(jù)，得到Kc、s，然后生成一個(gè)Authenticator，其中主要包括當(dāng)前時(shí)間和Ts,c的校驗(yàn)碼，并且用SessionKey Kc,s加密。之后客戶端將Authenticator和給server的票據(jù)同時(shí)發(fā)給服務(wù)器
服務(wù)器首先用自己的密碼解開票據(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è)新的角色叫做：票據(jù)授權(quán)服務(wù)(TGS - Ticket Granting Service)，它的地位類似于一個(gè)普通的服務(wù)器，只是它提供的服務(wù)是為客戶端發(fā)放用于和其他服務(wù)器認(rèn)證的票據(jù)。
這樣，Kerberos系統(tǒng)中就有四個(gè)角色：認(rèn)證服務(wù)器（AS），客戶端（Client），普通服務(wù)器（Server）和票據(jù)授權(quán)服務(wù)（TGS）。這樣客戶端初次和服務(wù)器通信的認(rèn)證流程分成了以下6個(gè)步驟：
客戶端向AS發(fā)起請(qǐng)求，請(qǐng)求內(nèi)容是：客戶端的principal，票據(jù)授權(quán)服務(wù)器的rincipal
AS收到請(qǐng)求之后，隨機(jī)生成一個(gè)密碼Kc, s(session key), 并生成以下兩個(gè)票據(jù)返回給客戶端：
1.給客戶端的票據(jù)，用客戶端的密碼加密，內(nèi)容為隨機(jī)密碼，session，tgs_principal
2.給tgs的票據(jù)，用tgs的密碼加密，內(nèi)容為隨機(jī)密碼，session，client_principal
客戶端拿到了第二步中的兩個(gè)票據(jù)后，首先用自己的密碼解開票據(jù)，得到Kc、s，然后生成一個(gè)Authenticator，其中主要包括當(dāng)前時(shí)間和Ts,c的校驗(yàn)碼，并且用SessionKey Kc,s加密。之后客戶端向tgs發(fā)起請(qǐng)求，內(nèi)容包括:
1.Authenticator
2.給tgs的票據(jù)同時(shí)發(fā)給服務(wù)器
3.server_principal
TGS首先用自己的密碼解開票據(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è)票據(jù)給客戶端
1.用客戶端和tgs的session key加密的票據(jù)，包含新生成的session key和server_principal
2.用服務(wù)器的密碼加密的票據(jù)，包括新生成的session key和client principal
客戶端收到兩個(gè)票據(jù)后，解開自己的，然后生成一個(gè)Authenticator，發(fā)請(qǐng)求給服務(wù)器，內(nèi)容包括
1.Authenticator
2.給服務(wù)器的票據(jù)
服務(wù)器收到請(qǐng)求后，用自己的密碼解開票據(jù)，得到session key，然后用session key解開authenticator對(duì)可無端進(jìn)行驗(yàn)證
服務(wù)器可以選擇返回一個(gè)用session key加密的之前的是時(shí)間戳來完成雙向驗(yàn)證
客戶端通過解開消息，比較發(fā)回的時(shí)間戳和自己發(fā)送的時(shí)間戳是否一致，來驗(yàn)證服務(wù)器
SAML
7.4.1. 簡(jiǎn)介
SAML (Security Assertion Markup Language) 譯為安全斷言標(biāo)記語言，是一種xXML格式的語言，使用XML格式交互，來完成SSO的功能。 SAML存在1.1和2.0兩個(gè)版本，這兩個(gè)版本不兼容，不過在邏輯概念或者對(duì)象結(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)證過程如下：
Client訪問受保護(hù)的資源
SP生成認(rèn)證請(qǐng)求SAML返回給Client
Client提交請(qǐng)求到IDP
IDP返回認(rèn)證請(qǐng)求
Client登陸IDP
認(rèn)證成功后，IDP生成私鑰簽名標(biāo)識(shí)了權(quán)限的SAML，返回給Client
Client提交SAML給SP
SP讀取SAML，確定請(qǐng)求合法，返回資源
7.4.3. 安全問題
源于ssl模式下的認(rèn)證可選性，可以刪除簽名方式標(biāo)簽繞過認(rèn)證，如果SAML中缺少了expiration，并且斷言ID不是唯一的，那么就可能被重放攻擊影響，越來越多的網(wǎng)站安全問題日益出現(xiàn),如果想要對(duì)網(wǎng)站或平臺(tái)進(jìn)行全面的安全檢測(cè)以及滲透測(cè)試,可以咨詢下專業(yè)的網(wǎng)站安全公司來進(jìn)行安全加固滲透測(cè)試,國內(nèi)做的比較好的推薦Sinesafe,綠盟,啟明星辰,深信服等等都是比較大的安全公司。
我們專注高端建站，小程序開發(fā)、軟件系統(tǒng)定制開發(fā)、BUG修復(fù)、物聯(lián)網(wǎng)開發(fā)、各類API接口對(duì)接開發(fā)等。十余年開發(fā)經(jīng)驗(yàn)，每一個(gè)項(xiàng)目承諾做到滿意為止，多一次對(duì)比，一定讓您多一份收獲！
