• <tr id="yyy80"></tr>
  • <sup id="yyy80"></sup>
  • <tfoot id="yyy80"><noscript id="yyy80"></noscript></tfoot>
  • 99热精品在线国产_美女午夜性视频免费_国产精品国产高清国产av_av欧美777_自拍偷自拍亚洲精品老妇_亚洲熟女精品中文字幕_www日本黄色视频网_国产精品野战在线观看 ?

    OAuth 2.0授權(quán)協(xié)議常見(jiàn)安全問(wèn)題及修復(fù)建議

    2018-04-26 08:34:33邱永哲
    無(wú)線互聯(lián)科技 2018年7期
    關(guān)鍵詞:令牌新浪服務(wù)商

    邱永哲

    (中國(guó)科學(xué)技術(shù)館 網(wǎng)絡(luò)科普部,北京 100012)

    1 互聯(lián)網(wǎng)發(fā)展概述

    隨著互聯(lián)網(wǎng)的高速發(fā)展,各種社交、購(gòu)物網(wǎng)站層出不窮,中國(guó)已經(jīng)全面邁入了互聯(lián)網(wǎng)時(shí)代。對(duì)用戶來(lái)說(shuō),這些繁雜的網(wǎng)站、應(yīng)用程序在方便生活的同時(shí),也引入了個(gè)人信息安全的問(wèn)題。為避免個(gè)人信息遭到泄露,不同的網(wǎng)站設(shè)置不同的賬戶密碼這一方法也逐漸深入人心,成了每個(gè)網(wǎng)民在互聯(lián)網(wǎng)中保護(hù)個(gè)人安全的最有效方法。然而,大量的賬號(hào)和密碼也給用戶帶來(lái)了記憶負(fù)擔(dān),大大降低了使用體驗(yàn)。因此,跨應(yīng)用數(shù)據(jù)共享這一需求逐漸呈現(xiàn)出越來(lái)越高的態(tài)勢(shì),Google,F(xiàn)acebook,騰訊等各大互聯(lián)網(wǎng)廠商也相繼推出了自己的跨應(yīng)用數(shù)據(jù)共享接口,使得用戶在不同網(wǎng)站之間能使用相同的用戶數(shù)據(jù),在提高用戶數(shù)據(jù)安全性的同時(shí)也極大地方便了用戶的使用。

    本文通過(guò)介紹跨應(yīng)用授權(quán)協(xié)議OAuth及其運(yùn)行機(jī)制,詳細(xì)闡述了不同應(yīng)用之間數(shù)據(jù)的共享方式和其安全性保護(hù)措施,并列舉了OAuth 2.0協(xié)議在實(shí)施過(guò)程中容易出現(xiàn)的安全問(wèn)題,最后對(duì)開(kāi)發(fā)者提出了相應(yīng)的安全性建議。

    2 OAuth 2.0授權(quán)協(xié)議介紹

    2.1 OAuth授權(quán)協(xié)議背景

    開(kāi)放授權(quán)(Open Authorization,OAuth)是一個(gè)開(kāi)放的授權(quán)協(xié)議,其允許用戶讓第三方應(yīng)用訪問(wèn)自己在某一網(wǎng)站上存儲(chǔ)的私密資源(例如照片、視頻、聯(lián)系人等信息),而無(wú)需將用戶名和密碼提供給第三方應(yīng)用。OAuth規(guī)定用戶必須使用一個(gè)訪問(wèn)令牌來(lái)獲取存放在OAuth服務(wù)提供方的數(shù)據(jù),每一個(gè)訪問(wèn)令牌只對(duì)唯一一個(gè)第三方應(yīng)用有效。如圖1所示為國(guó)內(nèi)開(kāi)發(fā)者社區(qū)SegmentFault提供的Google,Github等平臺(tái)OAuth服務(wù)快速登錄接口。

    OAuth的出現(xiàn)極大地方便了用戶在不同應(yīng)用之間數(shù)據(jù)的共享需求。2010年4月,OAuth 1.0正式以RFC 5849的形式出現(xiàn),后被全世界廣泛運(yùn)用[1]。目前經(jīng)過(guò)多年的發(fā)展,OAuth授權(quán)協(xié)議已經(jīng)升級(jí)至2.0版本,其官方文檔也已更迭為RFC 6749。

    2.2 OAuth 2.0運(yùn)行流程

    從RFC 6749當(dāng)中可以看到OAuth 2.0的運(yùn)行流程,如圖2所示。

    圖中左側(cè)的Client(客戶端)為想要獲取用戶數(shù)據(jù)的第三方應(yīng)用,右側(cè)的Resource owner、Authorization Server、Resource Server均為提供OAuth接口服務(wù)的Server(服務(wù)商)。因此整個(gè)OAuth 2.0的授權(quán)運(yùn)行過(guò)程如下。

    圖1 開(kāi)發(fā)者社區(qū)SegmentFault快速登錄接口

    圖2 OAuth 2.0運(yùn)行流程

    (1)用戶打開(kāi)客戶端后客戶端要求給予授權(quán)。

    (2)用戶同意給予客戶端授權(quán)。

    (3)用戶使用上一步獲得的授權(quán),向服務(wù)商授權(quán)服務(wù)器申請(qǐng)?jiān)L問(wèn)令牌。

    (4)服務(wù)商授權(quán)服務(wù)器對(duì)客戶端確認(rèn)無(wú)誤后同意發(fā)放訪問(wèn)令牌給客戶端。

    (5)客戶端使用訪問(wèn)令牌向服務(wù)商資源服務(wù)器獲取相應(yīng)的數(shù)據(jù)。

    (6)服務(wù)商資源服務(wù)器確認(rèn)客戶端訪問(wèn)令牌有效,向客戶端開(kāi)放相應(yīng)數(shù)據(jù)。

    2.3 OAuth 2.0的4種授權(quán)方式

    OAuth 2.0授權(quán)協(xié)議共有4種授權(quán)方式:Authorization code(授權(quán)碼)模式,Implicit(隱式)模式,Resource owner password credentials(賬號(hào)密碼)模式,Client credentials(客戶端)模式。其中,授權(quán)碼模式是目前OAuth 2.0中功能最完善、流程最嚴(yán)密的模式,因而被廣泛使用。這4種授權(quán)方式的流程分別如圖3—6所示。

    圖3 Authorization code授權(quán)模式

    圖4 Implicit授權(quán)模式

    圖5 Resource owner password credentials授權(quán)模式

    圖6 Client credentials授權(quán)模式

    3 OAuth 2.0常見(jiàn)安全問(wèn)題

    OAuth 2.0本身是一套非常嚴(yán)密的結(jié)構(gòu),但是一些開(kāi)發(fā)者在實(shí)現(xiàn)、部署OAuth授權(quán)服務(wù)的時(shí)候因?yàn)槭韬龆a(chǎn)生了很多安全問(wèn)題,這些問(wèn)題一旦被利用,將導(dǎo)致嚴(yán)重的后果。下面就列舉一些OAuth 2.0授權(quán)協(xié)議在實(shí)現(xiàn)過(guò)程中容易造成的安全問(wèn)題。

    3.1 隱蔽重定向漏洞

    2014年5月,新加坡南洋理工大學(xué)研究人員王晶發(fā)現(xiàn),一些提供OAuth服務(wù)的網(wǎng)站在對(duì)第三方應(yīng)用進(jìn)行OAuth授權(quán)過(guò)程中未對(duì)回調(diào)的統(tǒng)一資源標(biāo)識(shí)符(Uniform Resource Identifier,URI)進(jìn)行驗(yàn)證,導(dǎo)致回調(diào)的URI可以被修改為非原定URI,因此可以被用來(lái)釣魚(yú),是一個(gè)明顯的跳轉(zhuǎn)漏洞。這一漏洞被命名為“Covert Redirect”即隱蔽重定向漏洞。

    在國(guó)內(nèi),該漏洞也被叫作OAuth redirect_uri回調(diào)污染。事實(shí)上該漏洞造成的危害不僅僅是可被用來(lái)釣魚(yú)攻擊,看下面的例子。假設(shè)某OAuth服務(wù)商使用授權(quán)碼模式進(jìn)行第三方應(yīng)用的授權(quán)服務(wù),某個(gè)第三方應(yīng)用可以通過(guò)該服務(wù)商的OAuth接口綁定賬號(hào),以此來(lái)方便用戶登錄和使用。該客戶端綁定賬號(hào)的請(qǐng)求如下:

    GET /authorize?which=Login&display=pc&response_type=code&client_id=100263567&redirect_uri=http://client.com/index.php/sign/callback&scope=get_user_info,add_pic_t,add_t HTTP/1.1

    Host: server.com

    現(xiàn)在某用戶已經(jīng)登錄了該第三方應(yīng)用,攻擊者向他發(fā)送了如下一個(gè)URL:

    http://server.com/authorize?which=Login&display=p c&response_type=code&client_id=100263567&redirect_uri=http://hacker.com/index.php&scope=get_user_info,add_pic_t,add_t

    可以看出這是一個(gè)用于綁定賬號(hào)的URL,并且將用于回調(diào)的redirect_uri修改成自己控制的頁(yè)面http://hacker.com/index.php。此時(shí),如果OAuth服務(wù)商存在隱蔽重定向漏洞,那么當(dāng)該用戶點(diǎn)擊并授權(quán)以后頁(yè)面會(huì)跳轉(zhuǎn)至http://hacker.com/index.php?code=***。這時(shí)候該用戶的授權(quán)碼code將會(huì)被hacker.com捕獲便遭到了泄露。對(duì)于一些網(wǎng)站來(lái)說(shuō),授權(quán)碼code一旦泄露,將導(dǎo)致用戶賬號(hào)被劫持,國(guó)內(nèi)騰訊、新浪微博等OAuth服務(wù)均出現(xiàn)過(guò)此問(wèn)題。同時(shí),對(duì)于第三方應(yīng)用來(lái)說(shuō),如果其自身存在XSS或者沒(méi)有做好頁(yè)面防嵌入,也同樣能造成授權(quán)碼code的泄露。

    3.2 錯(cuò)誤使用state參數(shù)導(dǎo)致CSRF

    OAuth 2.0當(dāng)中定義了一個(gè)state參數(shù),根據(jù)RFC 6749,其含義為:

    state:RECOMMENDED. An opaque value used by the client to maintain state between the request and callback.The authorization server includes this value when redirecting the user-agent back to the client.The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12.

    即該參數(shù)用于在授權(quán)過(guò)程中請(qǐng)求和回調(diào)階段的狀態(tài)保持,用于防止該過(guò)程中產(chǎn)生CSRF攻擊。然而事實(shí)卻是很多OAuth服務(wù)開(kāi)發(fā)者忘記或錯(cuò)誤使用state參數(shù),造成大量用戶賬號(hào)被劫持的安全事件。國(guó)內(nèi)白帽子黑客horseluke給出了一個(gè)新浪微博的例子[2]。

    某用戶在登錄了第三方網(wǎng)站a.com后想在該網(wǎng)站關(guān)聯(lián)并綁定自己的新浪微博賬號(hào),于是就點(diǎn)擊了該網(wǎng)站上給出的“綁定微博”按鈕,該按鈕的URL為http://a.com/index.php?m=user_3rd

    _bind_sina。該用戶點(diǎn)擊以后瀏覽器將用戶重定向至新浪微博OAuth授權(quán)頁(yè)面,URL為:http://

    api.weibo.com/oaut h 2/aut hor i ze?cl ie nt_id=999999&redirect_uri=http://a.com/index.php?m=user_3rd_

    bind_sina_callback&response_type=code。隨后用戶對(duì)a.com給予了授權(quán),新浪微博授權(quán)服務(wù)器生成了授權(quán)碼code,瀏覽器將用戶重定向至http://a.com/index.php?m=user_3rd_bind_sina_callback&

    code=809ui0asduve,此時(shí)完成了賬號(hào)綁定。

    上述過(guò)程粗略地看并沒(méi)有問(wèn)題,但事實(shí)上完成賬號(hào)綁定時(shí)的URL跟當(dāng)前用戶沒(méi)有任何關(guān)系,因?yàn)樵揢RL只能證明新浪微博用戶信息,但無(wú)法證明a.com的用戶信息?,F(xiàn)在如果有兩個(gè)用戶同時(shí)發(fā)起綁定請(qǐng)求,登錄到不同的微博賬號(hào),隨后在獲取到授權(quán)碼code后雙方互相交換code,這將會(huì)導(dǎo)致兩個(gè)用戶綁定的新浪微博賬戶也發(fā)生交換和改變。黑客正是利用這一點(diǎn)實(shí)現(xiàn)了劫持用戶賬號(hào)的目的,而這一過(guò)程也體現(xiàn)了state參數(shù)的重要性[3]。

    3.3 賬號(hào)體系控制不嚴(yán)造成任意登錄

    2013年,國(guó)內(nèi)著名的音樂(lè)圈APP啪啪被發(fā)現(xiàn)存在任意賬號(hào)登錄的嚴(yán)重漏洞,這一問(wèn)題是啪啪在使用OAuth授權(quán)服務(wù)時(shí)產(chǎn)生的[4]。啪啪客戶端為方便用戶使用,提供了使用新浪微博、QQ登錄的功能,登錄的大致流程為:

    (1)用戶點(diǎn)擊使用新浪微博或QQ登錄,將彈出新浪微博或QQ的OAuth授權(quán)頁(yè)。(2)用戶授權(quán)以后啪啪客戶端獲得服務(wù)商提供的訪問(wèn)令牌。(3)啪啪客戶端將訪問(wèn)令牌移交給api.papa.me已獲取啪啪自己的認(rèn)證字符串。(4)啪啪客戶端得到認(rèn)證字符串后獲得操作該微博或QQ綁定的啪啪賬號(hào)權(quán)限。

    漏洞發(fā)現(xiàn)者在測(cè)試過(guò)程中,將第二步獲得的訪問(wèn)令牌替換為其他應(yīng)用在OAuth服務(wù)商獲得的訪問(wèn)令牌,隨后繼續(xù)進(jìn)行第三步和第四步,結(jié)果發(fā)現(xiàn)登錄了另一個(gè)啪啪賬號(hào)。該漏洞的關(guān)鍵在于當(dāng)啪啪通過(guò)OAuth服務(wù)商獲得授權(quán)信息(訪問(wèn)令牌、令牌有效期等)后,是將其作為參數(shù)匹配到自己的賬號(hào)并自動(dòng)登錄或自動(dòng)注冊(cè)的。由于后續(xù)的匹配處理邏輯出現(xiàn)紕漏,甚至無(wú)驗(yàn)證機(jī)制,就直接導(dǎo)致了啪啪賬號(hào)的任意登錄。

    4 OAuth 2.0安全建議

    可見(jiàn),無(wú)論OAuth 2.0是多么嚴(yán)密安全的流程,對(duì)于OAuth服務(wù)商和其使用者來(lái)說(shuō),錯(cuò)誤的實(shí)現(xiàn)和運(yùn)用都可能會(huì)引發(fā)嚴(yán)重的漏洞,以至于大量用戶數(shù)據(jù)和信息也將面臨被劫持泄露的風(fēng)險(xiǎn)。針對(duì)目前發(fā)生過(guò)的一些安全問(wèn)題,本文對(duì)于OAuth在實(shí)現(xiàn)和運(yùn)用過(guò)程中有以下安全建議。

    4.1 保護(hù)授權(quán)過(guò)程中的回調(diào)URI

    為了防止OAuth授權(quán)過(guò)程產(chǎn)生隱蔽重定向漏洞和redirect_uri回調(diào)污染,OAuth服務(wù)商應(yīng)當(dāng)對(duì)redirect_uri進(jìn)行全路徑校驗(yàn),避免產(chǎn)生跳轉(zhuǎn)漏洞。同時(shí)要加強(qiáng)驗(yàn)證過(guò)程和邏輯,避免被繞過(guò)。

    4.2 驗(yàn)證授權(quán)過(guò)程中的第三方應(yīng)用

    為了防止訪問(wèn)令牌泄露,應(yīng)當(dāng)驗(yàn)證OAuth授權(quán)過(guò)程中的授權(quán)請(qǐng)求來(lái)源信息、第三方應(yīng)用信息。例如在Resource owner password credentials(賬號(hào)密碼)授權(quán)模式中,用戶將在OAuth服務(wù)商的個(gè)人賬戶密碼移交給了第三方應(yīng)用,如果第三方應(yīng)用不被信任,則會(huì)產(chǎn)生用戶數(shù)據(jù)泄露的風(fēng)險(xiǎn)[5]。

    4.3 正確使用state參數(shù)以防止CSRF

    使用OAuth的第三方應(yīng)用應(yīng)當(dāng)按照官方文檔的描述,在請(qǐng)求授權(quán)和回調(diào)過(guò)程中正確使用state參數(shù)以防止產(chǎn)生CSRF漏洞,該參數(shù)與anti csrf token類似,要做到隨機(jī)不可預(yù)測(cè)。

    4.4 驗(yàn)證OAuth使用者信息

    使用OAuth的第三方應(yīng)用需要考慮在自動(dòng)登錄或者自動(dòng)注冊(cè)的過(guò)程中,驗(yàn)證OAuth服務(wù)商返回的授權(quán)信息,同時(shí)要驗(yàn)證該授權(quán)信息例如訪問(wèn)令牌是否為指定來(lái)源應(yīng)用所頒發(fā)。第三方應(yīng)用如果發(fā)現(xiàn)了訪問(wèn)令牌中的服務(wù)商給出的uid和自己在服務(wù)商綁定的uid不一致、非自身應(yīng)用appkey授權(quán)的訪問(wèn)令牌、過(guò)期訪問(wèn)令牌等異常情況均需要全部撤銷,并且要求這些異常用戶重新授權(quán)登錄。

    4.5 避免不可信第三方應(yīng)用強(qiáng)制使用Implicit授權(quán)模式

    由于一些OAuth服務(wù)商在Implicit授權(quán)模式中直接將訪問(wèn)令牌放進(jìn)回調(diào)URL,這就增加了訪問(wèn)令牌泄露的風(fēng)險(xiǎn),因此OAuth服務(wù)商應(yīng)當(dāng)避免第三方應(yīng)用強(qiáng)制更換授權(quán)方式為Implicit模式。

    [參考文獻(xiàn)]

    [1]佚名.RFC 6749.[EB/OL].(2017-12-29)[2018-03-05].http://www.rfc-editor.org/rfc/rfc6749.txt.

    [2]阮一峰. 理解OAuth 2.0[EB/OL].(2014-05-12)[2018-03-05].http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

    [3]維基百科.OAuth概念解析[EB/OL].(2017-02-15)[2018-03-05].https://en.wikipedia.org/wiki/OAuth.

    [4]HORSELUKE.OAuth 2.0安全案例回顧[EB/OL].(2014-03-11)[2018-03-05].http://wooyun.jozxing.cc/static/drops/papers-598.html.

    [5]∑-TEAM.OAuth安全指南[EB/OL].(2014-05-13)[2018-03-05].http://wooyun.jozxing.cc/static/drops/papers-1989.html.

    猜你喜歡
    令牌新浪服務(wù)商
    航天衛(wèi)星領(lǐng)域?qū)I(yè)服務(wù)商
    稱金塊
    猴子雖小
    讀者(2021年20期)2021-09-25 20:30:35
    論IaaS云服務(wù)商的著作權(quán)侵權(quán)責(zé)任
    基于路由和QoS令牌桶的集中式限速網(wǎng)關(guān)
    動(dòng)態(tài)令牌分配的TCSN多級(jí)令牌桶流量監(jiān)管算法
    新浪讀書(shū)排行榜
    期刊展示宣傳服務(wù)商
    2014中國(guó)金服務(wù)·十大杰出服務(wù)商
    令牌在智能小區(qū)訪客系統(tǒng)的應(yīng)用
    科技傳播(2011年10期)2011-06-14 02:29:04
    敦煌市| 博罗县| 托克托县| 沙湾县| 新竹市| 宁明县| 张家界市| 昌吉市| 隆林| 张北县| 京山县| 泰和县| 平乐县| 琼结县| 林口县| 关岭| 镇原县| 霍邱县| 革吉县| 海淀区| 池州市| 荆州市| 宝清县| 文成县| 同江市| 花莲县| 寿宁县| 垫江县| 大同县| 公安县| 民勤县| 宿州市| 惠州市| 清河县| 澳门| 鄢陵县| 贵德县| 华阴市| 祁阳县| 驻马店市| 石泉县|