99偷拍视频精品区一区二,口述久久久久久久久久久久,国产精品夫妇激情啪发布,成人永久免费网站在线观看,国产精品高清免费在线,青青草在线观看视频观看,久久久久久国产一区,天天婷婷久久18禁,日韩动漫av在线播放直播

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

b995aad3ea4247c2d8d00cac0e69682b.png

創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供宿城網(wǎng)站建設、宿城做網(wǎng)站、宿城網(wǎng)站設計、宿城網(wǎng)站制作等企業(yè)網(wǎng)站建設、網(wǎng)頁設計與制作、宿城企業(yè)網(wǎng)站模板建站服務,10余年宿城做網(wǎng)站經(jīng)驗,不只是建網(wǎng)站,更提供有價值的思路和整體網(wǎng)絡服務。Part1 前言?

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

近幾年在很多的滲透測試報告中,CORS跨域資源共享漏洞越來越多了。有的朋友實在挖不出漏洞,偶爾就會寫上一個CORS跨域資源共享漏洞出一份報告,但是細究起來以下幾個問題,卻都模棱兩可,搞不明白。

1. 什么是CORS漏洞?

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

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

4. CORS漏洞的修補建議?

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

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

首先給出ABC_123的測試結(jié)果,以下結(jié)論是我自己寫Java代碼搭建環(huán)境進行測試給出的結(jié)論,歡迎大家批評指正。首先使用burpsuite抓包對http請求添加Origin: http://www.attacker.com進行測試:

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

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

Access-Control-Allow-Credentials: true

2? ?如果返回頭是以下情況,那么也可以認為是高危漏洞,只是利用起來麻煩一些:

Access-Control-Allow-Origin: null

Access-Control-Allow-Credentials: true

3? ?如果返回以下,則不存在漏洞,因為Null必須是小寫才存在漏洞:

Access-Control-Allow-Origin: Null

Access-Control-Allow-Credentials: true

4? ?如果返回以下,可認為不存在漏洞,因為CORS安全機制阻止了這種情況下的漏洞利用,也可以寫上低危的CORS配置錯誤問題。

Access-Control-Allow-Origin: *

Access-Control-Allow-Credentials: true

5? ?如果返回以下,可認為不存在漏洞,也可以寫上低危的CORS配置錯誤問題。

Access-Control-Allow-Origin: *

Part3 CORS跨域漏洞復現(xiàn)?

  • 一般CORS漏洞的測試過程

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

5ad4f46b34315d98123da545f4dabd86.png

  • 編寫Java代碼測試

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

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

4f2b5ca2ccf31cfc77c9788c7a212be1.png

代碼效果如下,用戶輸入用戶名密碼后,購物網(wǎng)站提示登錄成功,這時候后臺代碼已經(jīng)生成Cookie。

43abfd800c68fb1014b34aa0e645441d.png

接下來用戶訪問PersonInfo頁面,http://192.168.237.1:9999/Servlet/PersonInfo 會顯示交易密碼是123456。

1d56e910766e7762b4f8f56c48d423c4.png

此頁面對應的PersonInfo的Sevlet代碼如下:

d59f6302381f210a5c6f9886c82d3780.png

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

1ee100d5a157f1ecf5581991b1a7f0fb.png

  • 第1種情況:

首先看第1種情況,服務器返回如下消息頭,這種情況下,非常好利用,所以漏洞定級是高危:

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

Access-Control-Allow-Credentials: true

這兩個返回頭表示應用程序允許來自任何Origin的任何腳本向應用程序發(fā)出CORS請求,這時候程序員的代碼是這樣寫的:

d3f040530bf546b9c150132d08fd4310.png

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

471d2b61e69b691102f0b2f002a7fbf9.png

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

f41b754f4027c0466e709d530c70b6f7.png

  • 第2種情況:

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

Access-Control-Allow-Origin: null

Access-Control-Allow-Credentials: true

在這種情況下,應用程序HTTP響應頭Access-Control-Allow-Origin的值始終為null。當用戶指定null以外的任何值時,應用程序不會處理。

0a5e48c4e3531467c8c7e6d65585a84d.png

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

8999a82d4563af197efd92b89100b0d8.png

因為這時候的Origin不等于null

2730e3efbd8495b5b7ebae5ef730bb20.png

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

d64a9528769681870d2dc5722a902e4d.png

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

f5ee3309922f3c52bcae68e4b438e380.png

  • 第3種情況:

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

Access-Control-Allow-Origin: *

Access-Control-Allow-Credentials: true

對應著java代碼如下:

bbaf09c1cc39971d5c575464875e38a4.png

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

8b288daa7aa45a8d94b5834e2672c5f8.png

  • 第4種情況:

服務器返回如下消息頭,這個就不演示了,只能說明CORS配置存在問題,但是沒法獲取敏感數(shù)據(jù),漏洞評級應為中危或者低危。

Access-Control-Allow-Origin:*

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

接下來換谷歌Chrome瀏覽器最新版本下測試,發(fā)現(xiàn)確實成功繞過了同源策略,發(fā)起了跨域請求,但是Chrome瀏覽器卻沒有為請求帶上Cookie,所以漏洞利用有限。

2d0c84da10dcaa301ba15281ca93093a.png

Part4 修補建議?

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

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

3. 減少“Access-Control-Allow-Methods”所允許的請求方法。

4. 除了正確配置CORS之外,Web服務器還應繼續(xù)對敏感數(shù)據(jù)進行保護,例如身份驗證和會話管理等。

bbb8aa2681deeab77a6a3b66ae4af345.png

專注于網(wǎng)絡安全技術(shù)分享,包括紅隊攻防、藍隊分析、滲透測試、代碼審計等。每周一篇,99%原創(chuàng),敬請關(guān)注

Contact me: 0day123abc#gmail.com(replace # with @)

2b098d7652ff111c910fd3616efec50c.jpeg

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

當前標題:第40篇:CORS跨域資源共享漏洞的復現(xiàn)、分析、利用及修復過程-創(chuàng)新互聯(lián)
當前地址:http://www.yijiale78.com/article28/deoejp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供動態(tài)網(wǎng)站商城網(wǎng)站響應式網(wǎng)站網(wǎng)站維護網(wǎng)站制作全網(wǎng)營銷推廣

廣告

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

成都網(wǎng)站建設公司