域名預(yù)訂/競(jìng)價(jià),好“米”不錯(cuò)過
圣誕節(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,綠盟,啟明星辰,深信服等等都是比較大的安全公司。
申請(qǐng)創(chuàng)業(yè)報(bào)道,分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處,共同探討創(chuàng)業(yè)新機(jī)遇!