域名預(yù)訂/競(jìng)價(jià)，好“米”不錯(cuò)過(guò)

圣誕節(jié)很快就要到了，對(duì)滲透測(cè)試的熱情仍然有增無(wú)減。我們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的聲明一般被用來(lái)在身份提供者和服務(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. 安全問(wèn)題

7.2.3.1. Header部分

是否支持修改算法為none

kid字段是否有注入

jwk元素是否可信

是否強(qiáng)制使用白名單上的加密算法

7.2.3.2. Payload部分

其中是否存在敏感信息

檢查過(guò)期策略，比如 exp , iat

7.2.3.3. Signature部分

檢查是否強(qiáng)制檢查簽名

密鑰是否可以被強(qiáng)行登錄

是否可以通過(guò)其他方式拿到密鑰

7.2.3.4. 其他

修改算法RS256為HS256

弱密鑰破解

Kerberos

7.3.1. 簡(jiǎn)介

簡(jiǎn)單地說(shuō)，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)證過(guò)程

客戶端向服務(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)，那說(shuō)明有人截獲了之前客戶端發(fā)送的內(nèi)容，進(jìn)行Replay攻擊。

2.檢查checksum是否正確

3.如果都正確，客戶端就通過(guò)了認(rèn)證

服務(wù)器段可選擇性地給客戶端回復(fù)一條消息來(lái)完成雙向認(rèn)證，內(nèi)容為用session key加密的時(shí)間戳

客戶端通過(guò)解開消息，比較發(fā)回的時(shí)間戳和自己發(fā)送的時(shí)間戳是否一致，來(lái)驗(yàn)證服務(wù)器

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

上方介紹的流程已經(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)，那說(shuō)明有人截獲了之前客戶端發(fā)送的內(nèi)容，進(jìn)行Replay攻擊。

2.檢查checksum是否正確

3.如果都正確，客戶端就通過(guò)了認(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ì)可無(wú)端進(jìn)行驗(yàn)證

服務(wù)器可以選擇返回一個(gè)用session key加密的之前的是時(shí)間戳來(lái)完成雙向驗(yàn)證

客戶端通過(guò)解開消息，比較發(fā)回的時(shí)間戳和自己發(fā)送的時(shí)間戳是否一致，來(lái)驗(yàn)證服務(wù)器

SAML

7.4.1. 簡(jiǎn)介

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

7.4.2. 認(rèn)證過(guò)程

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

Client訪問(wèn)受保護(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. 安全問(wèn)題

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

申請(qǐng)創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！