近期，兩位安全研究人員，Klemen Bratec及 Ioannis Kakavas，公布了他們發(fā)現(xiàn)的一個(gè)在MicrosoftOffice 365平臺(tái)上的SAML服務(wù)漏洞，該漏洞可被利用進(jìn)行跨域認(rèn)證繞過，最終可對(duì)365平臺(tái)上的所有聯(lián)邦域造成影響。
攻擊者可以利用這個(gè)漏洞突破訪問權(quán)限限制，越權(quán)獲取到受害用戶的Office 365賬戶信息，并可借此訪問他們的郵箱以及存儲(chǔ)在 OneDrive(微軟的云存儲(chǔ)服務(wù))上的文件等等。目前該漏洞已經(jīng)被微軟臨時(shí)修復(fù)。
SAML簡介
SAML即為安全聲明標(biāo)記語言，英文全稱是Security Assertion Markup Language。它是一個(gè)基于XML的標(biāo)準(zhǔn)，用于在不同的安全域(security domain)之間交換認(rèn)證和授權(quán)數(shù)據(jù)。其重要的作用在于跨域的單點(diǎn)登錄。SAML實(shí)現(xiàn)的目標(biāo)在于用戶經(jīng)過認(rèn)證后，能對(duì)多個(gè)應(yīng)用服務(wù)中的資源進(jìn)行訪問，無需重新進(jìn)行身份驗(yàn)證(比如再次輸入賬戶和密碼等)，而SAML便是這個(gè)過程中的“中間人”。
web單點(diǎn)登錄(Single Sign-on，SSO)
單點(diǎn)登錄是一種用于方便用戶訪問網(wǎng)絡(luò)的技術(shù)。如上所述，用戶只需在登錄時(shí)進(jìn)行一次注冊(cè)，即可獲得訪問系統(tǒng)和應(yīng)用軟件的授權(quán)，以后便可以在各類應(yīng)用中切換，不必多次輸入用戶名和口令來確定身份。在此條件下，管理員無需修改或干涉用戶登錄就能方便地實(shí)施希望得到的安全控制。
例如，我們很多時(shí)候登錄一些網(wǎng)站時(shí)，發(fā)現(xiàn)除了注冊(cè)新賬戶外，還可以通過其他應(yīng)用賬戶(如QQ、微博等)來進(jìn)行登錄，其中便會(huì)使用到WEB單點(diǎn)登錄技術(shù)。因?yàn)閺挠脩糁貜?fù)性的角度出發(fā)的話，實(shí)際上有些網(wǎng)站的用戶是重復(fù)的，那么對(duì)于這部分用戶來說，如何在訪問網(wǎng)站A之后，無需驗(yàn)證地去訪問網(wǎng)站B，web單點(diǎn)登錄技術(shù)便是一個(gè)不錯(cuò)的解決方案。
SAML中若干重要的概念
我們從前文簡單了解了這一部分主要會(huì)詳細(xì)關(guān)注在SAML 2.0的原理上。目前，SAML標(biāo)準(zhǔn)中最為重要的組成部分如下，
1、聲明(Assertions)
首先，聲明是一個(gè)XML結(jié)構(gòu)，其中包含了打包在聲明中的用戶信息。其中兩個(gè)最為常用的聲明類型是：
(1)認(rèn)證聲明(Authentication Assertions)，包含用戶已經(jīng)對(duì)其身份進(jìn)行認(rèn)定的信息;
(2)屬性聲明(Attribute Assertions)，包含關(guān)于用戶的特定信息(如郵件地址，名稱等等)。
2、協(xié)議(Protocols)
SAML協(xié)議描述了某些SAML要素(例如聲明)是如何被封裝在請(qǐng)求及系統(tǒng)是如何響應(yīng)請(qǐng)求的，并給出了當(dāng)進(jìn)行登錄或注銷時(shí)，SAML實(shí)體(身份提供方和服務(wù)提供方)必須遵循的處理規(guī)則。也可以這么說，SAML協(xié)議定義了系統(tǒng)實(shí)體之間傳遞和處理SAML聲明的協(xié)議集合，其中上述提到的驗(yàn)證請(qǐng)求協(xié)議將在之后介紹。
3、綁定(Bindings)
SAML綁定描述了一個(gè)SAML消息如何被映射到非SAML相關(guān)的消息格式和通信協(xié)議中。例如，我們?cè)谶M(jìn)行身份驗(yàn)證過程中，服務(wù)提供方(即用戶去訪問的應(yīng)用資源)需與身份提供方進(jìn)行通訊驗(yàn)證，那么如何從傳輸?shù)南⒅校崛‰p方需要的信息，這個(gè)就涉及到了綁定。當(dāng)需要從一個(gè)HTTP GET請(qǐng)求中取出URL中的查詢字符串時(shí)，HTTP重定向綁定(HTTP Redirect Binding)定義了如何對(duì)該URL進(jìn)行格式化，使之符合SAML消息標(biāo)準(zhǔn)格式。而在通訊過程中，SAML請(qǐng)求是經(jīng)過SAMLRequest查詢參數(shù)進(jìn)行傳遞的，并經(jīng)過壓縮后，再進(jìn)行基于base64的編碼和URL解碼。
4、身份提供方(Identity Provider)
身份提供方經(jīng)過SAML 授權(quán)，并持有著關(guān)于用戶的信息，身份提供方可以為使用者發(fā)布聲明，使其能夠于身份提供方的應(yīng)用上進(jìn)行權(quán)限內(nèi)的操作。
5、服務(wù)提供方(Service Provider)
服務(wù)提供方是SAML消息的接收者，其接受來自身份提供方的用戶信息，并開放符合該用戶訪問權(quán)限的資源。
Web瀏覽器單點(diǎn)登錄(SSO)的例子
接下來可以看一個(gè)基于Web瀏覽器單點(diǎn)登錄框架的簡單例子，我們可以通過這個(gè)例子來更加深入理解SAML。首先，在進(jìn)行單點(diǎn)登錄的過程中，服務(wù)提供方使用 HTTP重定向綁定和身份提供方使用 HTTP POST綁定。其中整個(gè)過程涉及到的部分如下，
1、用戶使用的瀏覽器
2、身份提供方
3、服務(wù)提供方
我們從下圖中也可以看到關(guān)于三者之間的交互，
一、在我們這個(gè)例子中，這個(gè)單點(diǎn)登錄過程始于一個(gè)用戶嘗試訪問一個(gè)受保護(hù)的資源(或者簡單來說，可以理解為請(qǐng)求登錄)。服務(wù)提供方擁有允許或者拒絕聯(lián)合登錄的功能配置，以及實(shí)時(shí)地將用戶重定向到一個(gè)發(fā)現(xiàn)服務(wù)接口，以便來選擇他們的身份提供方。通過自動(dòng)匹配選擇，可讓服務(wù)提供方知道和信任所其選擇的身份提供方，接著服務(wù)提供方會(huì)創(chuàng)建一個(gè)SAML身份驗(yàn)證請(qǐng)求
在請(qǐng)求的信息中，有兩個(gè)重要部分需要了解下，
1、編碼中的Issuer(發(fā)行人)代表了服務(wù)提供方的實(shí)體ID，其表現(xiàn)形式為一個(gè) URI(統(tǒng)一資源標(biāo)識(shí)符)，像一串身份標(biāo)識(shí)字符串一樣的。Issuer(發(fā)行人)包含了服務(wù)提供方請(qǐng)求用戶身份驗(yàn)證的信息。
2、IssueIstant，其包含的信息體現(xiàn)了當(dāng)服務(wù)提供方發(fā)出請(qǐng)求后，生成的內(nèi)部識(shí)別ID ,用以匹配在接受到該條請(qǐng)求后發(fā)出的SAML響應(yīng)。
二、然后用戶的瀏覽器被重定向到身份提供方綁定的URL，SAML Authentication Request(SAML 驗(yàn)證請(qǐng)求)是通過 HTTP GET中的一串查詢參數(shù)(之后請(qǐng)求的信息會(huì)被進(jìn)行壓縮，再經(jīng)過 base64以及URL編碼再進(jìn)行傳遞)
三、在接收來自用戶瀏覽器的SAML請(qǐng)求后，身份提供方檢查發(fā)送請(qǐng)求驗(yàn)證信息的服務(wù)提供方身份，并在成功認(rèn)證服務(wù)提供方身份后，驗(yàn)證請(qǐng)求的內(nèi)容，提示用戶進(jìn)行登錄認(rèn)證(輸入賬戶密碼)。如果用戶認(rèn)證成功，身份提供方將生成SAML回應(yīng)
gxnHkIizISbLkkB1vSWapmWuQzk=
Qn69P4a3PQTISfqk/0t2JdJqG1nlswFQt8bNWPZ+K41EIYkCcTyuwlKnCzlTvU1YgNXIvHcFEyKjYAge+s3gwqecATI+yRB9OtD34YxBC4kyGcbq/ETQxIQ515xehfRxLrQjUpRzgHQXMLSjGdgjeelfKsHeSczA9Hp44kasQSs=
MIICajCCAdOgAwIBAgIBADANBgkqhkiG9w0BAQ0FADBSMQswCQYDVQQGEwJ1czETMBEGA1UECAwKQ2FsaWZvcm5pYTEVMBMGA1UECgwMT25lbG9naW4gSW5jMRcwFQYDVQQDDA5zcC5leGFtcGxlLmNvbTAeFw0xNDA3MTcxNDEyNTZaFw0xNTA3MTcxNDEyNTZaMFIxCzAJBgNVBAYTAnVzMRMwEQYDVQQIDApDYWxpZm9ybmlhMRUwEwYDVQQKDAxPbmVsb2dpbiBJbmMxFzAVBgNVBAMMDnNwLmV4YW1wbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZx+ON4IUoIWxgukTb1tOiX3bMYzYQiwWPUNMp+Fq82xoNogso2bykZG0yiJm5o8zv/sd6pGouayMgkx/2FSOdc36T0jGbCHuRSbtia0PEzNIRtmViMrt3AeoWBidRXmZsxCNLwgIV6dn2WpuE5Az0bHgpZnQxTKFek0BMKU/d8wIDAQABo1AwTjAdBgNVHQ4EFgQUGHxYqZYyX7cTxKVODVgZwSTdCnwwHwYDVR0jBBgwFoAUGHxYqZYyX7cTxKVODVgZwSTdCnwwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQ0FAAOBgQByFOl+hMFICbd3DJfnp2Rgd/dqttsZG/tyhILWvErbio/DEe98mXpowhTkC04ENprOyXi7ZbUqiicF89uAGyt1oqgTUCD1VsLahqIcmrzgumNyTwLGWo17WDAa1/usDhetWAMhgzF/Cnf5ek0nK00m0YZGyc4LzgD0CROMASTWNg==
_ce3d2948b4cf20146dee0a0b3dd6f69b6cf86f62d7
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
test
users
examplerole1
四、接下來，引導(dǎo)用戶瀏覽器回應(yīng)一個(gè)HTTP POST請(qǐng)求到服務(wù)提供方。其中，有部分內(nèi)容也是需要了解的，具體如下。
1、InResponseTo，包含了一個(gè)ID值，該ID會(huì)與先前服務(wù)提供方發(fā)送請(qǐng)求的時(shí)候產(chǎn)生的內(nèi)部標(biāo)識(shí)ID進(jìn)行匹配(避免重放攻擊);
2、IssueIstant, NotBefore 以及NotOnOrAfter 定義了 SAML響應(yīng)(以及聲明)的有效時(shí)間，也是為了避免重放攻擊;
3、聲明還包含了一個(gè) Isssuer字段，其中具有一個(gè) url,因此服務(wù)提供方可以確認(rèn)身份提供方的身份(是否符合此前請(qǐng)求指定的身份提供方地址);
4、AudienceRestriction部分，則定義了可對(duì)該聲明進(jìn)行讀取的服務(wù)提供方，而其他服務(wù)提供方并無權(quán)限進(jìn)行讀取。
5、Subject，用于識(shí)別驗(yàn)證用戶身份;
6、AttributeStatement部分，包含用戶進(jìn)行驗(yàn)證的信息，其中也包括各種屬性以及它們的值;
在這份聲明中(也包括全部的 SAML響應(yīng))是基于XML簽名( XML Signature)來保護(hù)其完整性，檢查其在傳輸過程中并未遭受篡改。
五、在接收到SAML響應(yīng)后，服務(wù)提供方可以驗(yàn)證其內(nèi)容和結(jié)構(gòu)，并驗(yàn)證簽名，隨后通過了用戶認(rèn)證，分配用戶一個(gè)Cookie，啟動(dòng)與用戶間的Web會(huì)話。
問題在哪里?
那么到這里，或許你會(huì)有些疑惑，
1、服務(wù)提供方如何知道并信任身份提供方?
2、身份提供方如何知道并信任服務(wù)提供方?
3、身份提供方如何對(duì)聲明進(jìn)行簽名?
4、服務(wù)提供方在接受到一份聲明后如何驗(yàn)證其完整性?
實(shí)際上，在驗(yàn)證之前，身份提供方和服務(wù)提供方會(huì)進(jìn)行相互之間的信任處理。為了實(shí)現(xiàn)在請(qǐng)求和響應(yīng)的交互過程中，身份及信息的驗(yàn)證，兩者之間需要交換元數(shù)據(jù)。我們可以理解為，此處的元數(shù)據(jù)包含了一個(gè)公鑰，對(duì)應(yīng)著身份提供方對(duì)聲明進(jìn)行簽名加密所使用的私鑰，每一個(gè)實(shí)體(可以是用戶、服務(wù)提供方或是身份提供方)所綁定的URL以及支持或響應(yīng)的算法等等。那么基于這樣的出發(fā)點(diǎn)，有兩種方法可讓他們獲取彼此的元數(shù)據(jù)：
1、雙方以一種安全的方式交換元數(shù)據(jù)，確立信任關(guān)系;
2、或者通過加入一個(gè)聯(lián)邦(Federation)，將這種信任關(guān)系委托給第三方機(jī)構(gòu)。然后聯(lián)邦運(yùn)營者會(huì)設(shè)定任務(wù)，收集來自所有參與的實(shí)體(身份提供方和服務(wù)提供方)的元數(shù)據(jù)，并發(fā)布這些數(shù)據(jù)。每個(gè)身份提供方和服務(wù)供應(yīng)方都會(huì)提交其元數(shù)據(jù)來獲取有關(guān)參與該聯(lián)邦的其他實(shí)體的信息。
Office 365 的SAML交互是如何運(yùn)行的?
Office 365平臺(tái)服務(wù)提供方使用的是一個(gè)WS-Trust以及 SAML 2.0 web 瀏覽器單點(diǎn)登錄框架的混合體。Office 365平臺(tái)支持通過WS-Trust以及SAML 2.0 web 瀏覽器進(jìn)行單點(diǎn)登錄兩種方式進(jìn)行訪問，但兩者之間并不孤立。
實(shí)際上，WS-Trust為我們提供了一種安全令牌服務(wù)，比如令牌的頒發(fā)(Issuance)、續(xù)訂(Renewal)和終止(Cancel)等。但SAML的服務(wù)提供方會(huì)將SAML 2.0標(biāo)準(zhǔn)的傳輸信息，使用令牌( token)轉(zhuǎn)換服務(wù)，在內(nèi)部將 SAML信息轉(zhuǎn)化為WS-Trust信息。而因?yàn)樯鲜龅牧钆妻D(zhuǎn)換服務(wù)，所以此次在 SAML服務(wù)提供方發(fā)現(xiàn)的漏洞，也會(huì)影響到WS-Trust單點(diǎn)登錄。
然而，為了簡單起見，在理解本文Office 365 的服務(wù)提供方時(shí)，均可認(rèn)為是使用SAML進(jìn)行單點(diǎn)登錄。
不過有一點(diǎn)需要強(qiáng)調(diào)的是， 對(duì)于經(jīng)過SAML的賬戶驗(yàn)證，Office 365并不支持實(shí)時(shí)資源配置，所以對(duì)于使用賬戶進(jìn)行單點(diǎn)登錄的用戶，需要已經(jīng)在Azure AD上有租戶才行。這個(gè)需要經(jīng)過Directory同步或者經(jīng)過用戶在IDM 系統(tǒng)的幫助下進(jìn)行配置，不過這已經(jīng)超出了本文的范圍，這里先略過不談。
從一個(gè)身份提供方到 Office 365服務(wù)提供方，需要在請(qǐng)求消息中發(fā)布的屬性，以便進(jìn)行信息匹配，包括以下兩個(gè)：
1、UPN(User principal name)用戶主體名稱，包含IDP(即身份提供方)Email名稱等信息;
2、ImmutableId，用戶的唯一識(shí)別符，存放于SAML聲明的Subject中。
接下來，我們可以看下Office 365平臺(tái)的登錄情況，
流程始于用戶開始訪問 Office 365 portal，接著被重定向到 https://login.microsoftonline.com/login.srf，而響應(yīng)形式如下，
在鍵入用戶名稱以及按下“TAB”或點(diǎn)擊密碼輸入?yún)^(qū)域，該頁面將構(gòu)建一個(gè)XHR (XMLHttpRequest)，而為了驗(yàn)證用戶的域(可以簡單理解為用戶歸屬的企業(yè))是否能與Office 365平臺(tái)上的租戶(可以理解為某企業(yè)所租賃的服務(wù))相匹配。
GET /common/userrealm/[email protected]&api-version=2.1&stsRequest=rQIIAbNSzigpKSi20tcvyC8qSczRy09Ly0xO1UvOz9XLL0rPTAGxioS4BMruuVuZ2Fh77Wj-e6KxLMF2FaMaTp36OYl5KZl56XqJxQUVFxgZu5hYDA2MjTcxsfo6-zp5nmCacFbuFpOgf1G6Z0p4sVtqSmpRYklmft4jJt7Q4tQi_7ycypD87NS8Scx8OfnpmXnxxUVp8Wk5-eVAAaDxBYnJJfElmcnZqSW7mFVSU00tTCxTUnRNkpOTdU2Sksx0kwxSzXRTzZMtTC1ME00Mk1MOsGwIucAi8IOFcREr0C-3A6ZLrn182Gt-tWV-vVlpwi5OW-L8Yl-SWJSeWmKrapSWkpqWWJpTAhYGAA2&checkForMicrosoftAccount=false HTTP/1.1
Host: login.microsoftonline.com
User-Agent:Mozilla/5.0 (X11;UbuntuLinuxx86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: application/json
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
DNT: 1
X-Requested-With: XMLHttpRequest
Referer: https://login.microsoftonline.com/login.srf?wa=wsignin1.0&rpsnv=4&ct=1460721662&rver=6.7.6640.0&wp=MCMBI&wreply=https%3a%2f%2fportal.office.com%2flanding.aspx%3ftarget%3d%252fdefault.aspx&lc=1033&id=501392&msafed=0&client-request-id=3a47de76-3c34-4a3b-b883-fdc88176603d
如果域已被知道及配置成聯(lián)邦身份，用戶的瀏覽器將被引導(dǎo)構(gòu)建一個(gè) HTTP POST請(qǐng)求到 HTTP-POST綁定的身份提供方的 URL，具體的信息如下，
urn:federation:MicrosoftOnline
用戶實(shí)時(shí)在身份提供方中進(jìn)行身份驗(yàn)證，如下，
隨后瀏覽器會(huì)被引導(dǎo)到創(chuàng)建一個(gè)HTTP POST返回到 Office 365 HTTP-POST綁定的 URL。通過包含著聲明的SAML響應(yīng)。一個(gè)簡單的響應(yīng)例子如下，
dc1f3jn97lZ6FWdxGxsEWxXNsTM=
Removed for brevity
Removed for brevity
WBgE+nW+3g9P5XpiZwGE06MT//g=
Removed for brevity
Removed for brevity
This is where my ImmutableId is
urn:federation:MicrosoftOnline
urn:oasis:names:tc:SAML:2.0:ac:classes:
在聲明中的Subject 屬性里面，包含的唯一標(biāo)識(shí)符ImmutableId，具體如下，
//以下為ImmutableId所在
在屬性聲明中，包含著與用戶在Azure AD已有賬號(hào)的UPN(用戶主體名稱)相匹配的 IDPEmail信息，具體如下，
在這里，同樣能將SAML響應(yīng)以及SAML聲明看成是經(jīng)過數(shù)字簽名的。
關(guān)于SAML NameID
首先我們從上方的聲明中可以注意到，Office 365 SAML 服務(wù)提供方忽略了聲明中的Subject，雖然ImmutableId 值包含了用戶在Azure AD 唯一標(biāo)識(shí)符。
而名稱標(biāo)識(shí)符，可以通過SAML 2 .0
從攻擊者的角度出發(fā)，事實(shí)上NameID的準(zhǔn)確性并無進(jìn)行校驗(yàn)，而使得事情更加容易的是，ImmutableID通常是來自于 AD objectGUID。
范圍界定
在身份校驗(yàn)的過程中，IDPEmail屬性值會(huì)去匹配Azure AD中用戶的UPN，而這依靠在聲明中的信息便可達(dá)到。但是聲明中亦包含了Issuer(發(fā)行人)的信息(雖然有經(jīng)過簽名驗(yàn)證)，所以根據(jù)前文的了解，正常來說，一個(gè)不相關(guān)的身份提供方是無法為其他域(或是租戶)的用戶創(chuàng)建聲明么?
答案是否定的。
事實(shí)證明(在本文的漏洞利用過程中)，服務(wù)提供方使用使用聲明中的 Issuer (發(fā)行人)只是為了找到匹配的認(rèn)證，識(shí)別SAML響應(yīng)或者是聲明的簽名而已，但卻沒有真正對(duì)IDPEmail屬性值進(jìn)行任何檢查。這基本上意味著可以通過聲明，以身份提供方A的聲明來認(rèn)證身份提供方B的用戶。以此便可實(shí)現(xiàn)越權(quán)訪問B域的資源。
如何利用前文提到的漏洞?
在驗(yàn)證該漏洞時(shí)，我們需要有一個(gè) Office 365租戶作為連接Office 365和 SAML 2.0身份提供方的平臺(tái)。我們還需要擁有一個(gè)基本的 Active Directory實(shí)例以及 SimpleSAMLphp(SAML 2.0 服務(wù)提供者和標(biāo)識(shí)提供者功能的 PHP 實(shí)現(xiàn)，兼容 Shibboleth 1.3 和 2.0)作為我們的身份提供方。
首先，設(shè)置另外一個(gè)組織機(jī)構(gòu)，其在我們這次試驗(yàn)中扮演著受害用戶的角色。其中包含不同的EntityID并且是為新的Office 365試用租戶，同時(shí)我們還需另外一個(gè)SimpleSAMLphp實(shí)例。
我們的測試所需環(huán)境如下，
1、首先，Office 365通過預(yù)設(shè)someorg-attacker.com作為身份提供方
2、接著， Office 365再通過預(yù)設(shè) someorg-victim.com作為身份提供方。
接下來，我們?cè)黾淤~戶到 someorg-attacker的用戶目錄下，看下當(dāng)我們嘗試登錄時(shí)會(huì)發(fā)生些什么。在AD(Active Directory)上增加一個(gè)新的alternative UPN suffix，接著通過內(nèi)置的工具來新增用戶，
以下為someorg-victim用戶目錄下的實(shí)體用戶，
以下為someorg-attacker用戶目錄下的包含兩個(gè)組織機(jī)構(gòu)的實(shí)體用戶，
我們可以看到其中新增了關(guān)于受害方中的實(shí)體用戶。
接下來，該驗(yàn)證我們的發(fā)現(xiàn)了。，驗(yàn)證步驟具體如下，
1、我們通過使用[email protected]賬戶(以上用戶目錄中的兩個(gè)賬戶任意一個(gè))作為登錄的用戶名，然后瀏覽器會(huì)被重定向到someorg-attacker的身份提供方進(jìn)行身份認(rèn)證;
2、當(dāng)我們?cè)谏矸萏峁┓降膶?shí)時(shí)身份驗(yàn)證登錄過程中，我們通過使用此前在someorg-attacker目錄下創(chuàng)建的帶有受害方域名稱的賬戶(例如[email protected])，進(jìn)行登錄驗(yàn)證，接著順利完成了在身份提供方的驗(yàn)證過程;
3、接下來，我們會(huì)看到問題點(diǎn)所在，如上，在經(jīng)過身份提供方的驗(yàn)證后，微軟的登錄頁面會(huì)提示一個(gè)錯(cuò)誤的信息，但除此之外并沒有其他特別的提示和處置。而最終，我們也“順利”以 [email protected]的身份登錄進(jìn)來了，并擁有了訪問someorg-victim資源的權(quán)限。
而對(duì)于這樣的情況，我們不知道該是高興(因?yàn)轵?yàn)證了我們的發(fā)現(xiàn))還是擔(dān)憂(因?yàn)槠溆绊懙姆秶?。
影響的用戶
受影響的用戶包括，
1、telefonika
2、Caltex Australia
3、Georgia State University
4、Japan Airlines
5、Santa Clara County
6、City of Chicago,IL
7、British Airways
漏洞檢測方法
我們也可以通過以下的查詢方式，確認(rèn)某個(gè)域是否設(shè)置為加入聯(lián)邦中
上述為檢測一個(gè)域是否加入聯(lián)邦的HTTP GET請(qǐng)求，而將會(huì)返回一個(gè) json的響應(yīng)信息，
{
"NameSpaceType":"Federated",
"federation_protocol":"WSTrust",
"Login":"[email protected]",
"AuthURL":"",
"DomainName":"ba.com",
"FederationBrandName":"BA.COM",
"cloudinstancename":"login.microsoftonline.com"
}
京公網(wǎng)安備 11010502049343號(hào)