CORS跨域資源共享漏洞的復(fù)現(xiàn)、分析、利用及修復(fù)過程-創(chuàng)新互聯(lián)

Part1 前言?

CORS跨域資源共享漏洞與JSONP劫持漏洞類似，都是程序員在解決跨域問題中進(jìn)行了錯(cuò)誤的配置。攻擊者可以利用Web應(yīng)用對(duì)用戶請(qǐng)求數(shù)據(jù)包的Origin頭校驗(yàn)不嚴(yán)格，誘騙受害者訪問攻擊者制作好的惡意網(wǎng)站，從而跨域獲取受害者的敏感數(shù)據(jù)，包括轉(zhuǎn)賬記錄、交易記錄、個(gè)人身份證號(hào)信息、訂單信息等等。

從策劃到設(shè)計(jì)制作，每一步都追求做到細(xì)膩，制作可持續(xù)發(fā)展的企業(yè)網(wǎng)站。為客戶提供成都網(wǎng)站制作、做網(wǎng)站、網(wǎng)站策劃、網(wǎng)頁(yè)設(shè)計(jì)、域名注冊(cè)、虛擬主機(jī)、網(wǎng)絡(luò)營(yíng)銷、VI設(shè)計(jì)、 網(wǎng)站改版、漏洞修補(bǔ)等服務(wù)。為客戶提供更好的一站式互聯(lián)網(wǎng)解決方案,以客戶的口碑塑造優(yōu)易品牌,攜手廣大客戶,共同發(fā)展進(jìn)步。

近幾年在很多的滲透測(cè)試報(bào)告中，CORS跨域資源共享漏洞越來(lái)越多了。有的朋友實(shí)在挖不出漏洞，偶爾就會(huì)寫上一個(gè)CORS跨域資源共享漏洞出一份報(bào)告，但是細(xì)究起來(lái)以下幾個(gè)問題，卻都模棱兩可，搞不明白。

1.?什么是CORS漏洞？

2.?哪些情況下的CORS漏洞是高危漏洞？哪些情況下CORS漏洞是沒有危害的？

3.?CORS漏洞的怎么利用？

4.?CORS漏洞的修補(bǔ)建議？

很多朋友以為Web應(yīng)用返回Access-Control-Allow-Origin: *就是存在漏洞，其實(shí)這個(gè)判斷是不完善的。本期作者自己寫了一個(gè)Java的測(cè)試環(huán)境，給大家演示一下CORS漏洞的復(fù)現(xiàn)過程及利用過程，相信大家一看就明白了。

Part2 CORS漏洞測(cè)試結(jié)果?

首先給出最終測(cè)試結(jié)果，以下結(jié)論是自寫Java代碼搭建環(huán)境進(jìn)行測(cè)試給出的結(jié)論，歡迎大家批評(píng)指正。首先使用burpsuite抓包對(duì)http請(qǐng)求添加Origin: http://www.attacker.com進(jìn)行測(cè)試：

1???如果返回頭是以下情況，那么就是高危漏洞，這種情況下漏洞最好利用：

Access-Control-Allow-Origin: https://www.attacker.com

Access-Control-Allow-Credentials: true

2???如果返回頭是以下情況，那么也可以認(rèn)為是高危漏洞，只是利用起來(lái)麻煩一些：

Access-Control-Allow-Origin: null

Access-Control-Allow-Credentials: true

3???如果返回以下，則不存在漏洞，因?yàn)镹ull必須是小寫才存在漏洞：

Access-Control-Allow-Origin: Null

Access-Control-Allow-Credentials: true

4???如果返回以下，可認(rèn)為不存在漏洞，因?yàn)镃ORS安全機(jī)制阻止了這種情況下的漏洞利用，也可以寫上低危的CORS配置錯(cuò)誤問題。

Access-Control-Allow-Origin: *

Access-Control-Allow-Credentials: true

5???如果返回以下，可認(rèn)為不存在漏洞，也可以寫上低危的CORS配置錯(cuò)誤問題。

Access-Control-Allow-Origin: *

?Part3 CORS跨域漏洞復(fù)現(xiàn)? 一般CORS漏洞的測(cè)試過程

首先復(fù)習(xí)一下常規(guī)的CORS漏洞測(cè)試過程：抓取一個(gè)能夠返回個(gè)人敏感數(shù)據(jù)的HTTP請(qǐng)求包，添加Origin: http://www.xxx.com，查看返回頭中是否包含“Access-Control-Allow-Origin: *”、“Access-Control-Allow-Credentials: true”，這里說明一點(diǎn)，如果返回包中這兩個(gè)頭同時(shí)存在，那么它其實(shí)是不存在CORS漏洞的。接下來(lái)依據(jù)Access-Control-Allow-Origin、Access-Control-Allow-Credentials的不同返回值的各種情況，分別寫Java代碼測(cè)試一下，是否能夠獲取敏感數(shù)據(jù)，大家就明白了。

• 編寫Java代碼測(cè)試

接下來(lái)我用Java編寫了兩個(gè)Servlet代碼模擬一個(gè)Web購(gòu)物網(wǎng)站，用JS前端代碼模擬攻擊者構(gòu)造的CORS漏洞利用html頁(yè)面。

如下所示，首先是登錄界面的servlet代碼如下。

代碼效果如下，用戶輸入用戶名密碼后，購(gòu)物網(wǎng)站提示登錄成功，這時(shí)候后臺(tái)代碼已經(jīng)生成Cookie。

接下來(lái)用戶訪問PersonInfo頁(yè)面，http://192.168.237.1:9999/Servlet/PersonInfo 會(huì)顯示交易密碼是123456。

此頁(yè)面對(duì)應(yīng)的PersonInfo的Sevlet代碼如下：

接下來(lái)攻擊者為了獲取該購(gòu)物網(wǎng)站用戶的交易密碼，精心構(gòu)造了如下的attack.html頁(yè)面放到Web服務(wù)器上，此時(shí)攻擊URL是http://www.attacker111.com/attack.html。攻擊者將此URL發(fā)給受害者瀏覽，受害者的交易密碼將會(huì)被獲取到。

• 第1種情況：

首先看第1種情況，服務(wù)器返回如下消息頭，這種情況下，非常好利用，所以漏洞定級(jí)是高危：

Access-Control-Allow-Origin: https://www.attacker.com

Access-Control-Allow-Credentials: true

這兩個(gè)返回頭表示應(yīng)用程序允許來(lái)自任何Origin的任何腳本向應(yīng)用程序發(fā)出CORS請(qǐng)求，這時(shí)候程序員的代碼是這樣寫的：

受害者訪問攻擊者構(gòu)造好的URL之后，成功獲取用戶的敏感數(shù)據(jù)。

F12查看瀏覽器發(fā)出的請(qǐng)求，發(fā)現(xiàn)其帶上了Cookie，成功繞過跨域的同源限制。

• 第2種情況：

服務(wù)器返回如下消息頭，這種情況下，利用起來(lái)稍有困難，這里的null必須全部都是小寫，漏洞仍然是高危。

Access-Control-Allow-Origin: null

Access-Control-Allow-Credentials: true

在這種情況下，應(yīng)用程序HTTP響應(yīng)頭Access-Control-Allow-Origin的值始終為null。當(dāng)用戶指定null以外的任何值時(shí)，應(yīng)用程序不會(huì)處理。

這時(shí)候訪問http://192.168.237.199/attack.html，發(fā)現(xiàn)瀏覽器提示CORS策略錯(cuò)誤。

因?yàn)檫@時(shí)候的Origin不等于null

這里需要想辦法讓Origin等于null，于是攻擊者構(gòu)造如下js代碼：

此時(shí)發(fā)現(xiàn)仍然可以成功獲取用戶的敏感數(shù)據(jù)。

• 第3種情況：

服務(wù)器返回如下消息頭，這種情況下，其實(shí)是不存在漏洞的，如果非要牽強(qiáng)地說存在漏洞，可以協(xié)商CORS配置錯(cuò)誤，畢竟設(shè)置為*本身就有問題。

Access-Control-Allow-Origin: *

Access-Control-Allow-Credentials: true

對(duì)應(yīng)著java代碼如下：

訪問http://www.attacker111.com/attack.html發(fā)現(xiàn)，瀏覽器直接報(bào)錯(cuò)，看來(lái)這種情況根本不被安全策略所允許。

• 第4種情況：

服務(wù)器返回如下消息頭，這個(gè)就不演示了，只能說明CORS配置存在問題，但是沒法獲取敏感數(shù)據(jù)，漏洞評(píng)級(jí)應(yīng)為中?；蛘叩臀?。

Access-Control-Allow-Origin：*

• Chrome瀏覽器測(cè)試結(jié)果

接下來(lái)?yè)Q谷歌Chrome瀏覽器最新版本下測(cè)試，發(fā)現(xiàn)確實(shí)成功繞過了同源策略，發(fā)起了跨域請(qǐng)求，但是Chrome瀏覽器卻沒有為請(qǐng)求帶上Cookie，所以漏洞利用有限。

Part4 修補(bǔ)建議?

1.?Access-Control-Allow-Origin中指定的來(lái)源只能是受信任的站點(diǎn)，避免使用Access-Control-Allow-Origin: *，避免使用Access-Control-Allow-Origin: null，否則攻擊者可以偽造來(lái)源請(qǐng)求實(shí)現(xiàn)跨域資源竊取。

2.?嚴(yán)格校驗(yàn)“Origin”值，校驗(yàn)的正則表達(dá)式一定要編寫完善，避免出現(xiàn)繞過的情況。

3.?減少“Access-Control-Allow-Methods”所允許的請(qǐng)求方法。

4.?除了正確配置CORS之外，Web服務(wù)器還應(yīng)繼續(xù)對(duì)敏感數(shù)據(jù)進(jìn)行保護(hù)，例如身份驗(yàn)證和會(huì)話管理等。

你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機(jī)房具備T級(jí)流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級(jí)服務(wù)器適合批量采購(gòu)，新人活動(dòng)首月15元起，快前往官網(wǎng)查看詳情吧

本文標(biāo)題：CORS跨域資源共享漏洞的復(fù)現(xiàn)、分析、利用及修復(fù)過程-創(chuàng)新互聯(lián)
標(biāo)題來(lái)源：http://bm7419.com/article30/ihpso.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營(yíng)銷推廣、軟件開發(fā)、網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、App開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)