Part1 前言?
CORS跨域資源共享漏洞與JSONP劫持漏洞類似，都是程序員在解決跨域問題中進行了錯誤的配置。攻擊者可以利用Web應用對用戶請求數據包的Origin頭校驗不嚴格，誘騙受害者訪問攻擊者制作好的惡意網站，從而跨域獲取受害者的敏感數據，包括轉賬記錄、交易記錄、個人身份證號信息、訂單信息等等。
近幾年在很多的滲透測試報告中，CORS跨域資源共享漏洞越來越多了。有的朋友實在挖不出漏洞，偶爾就會寫上一個CORS跨域資源共享漏洞出一份報告，但是細究起來以下幾個問題，卻都模棱兩可，搞不明白。
1.?什么是CORS漏洞？
2.?哪些情況下的CORS漏洞是高危漏洞？哪些情況下CORS漏洞是沒有危害的？
3.?CORS漏洞的怎么利用？
4.?CORS漏洞的修補建議？
很多朋友以為Web應用返回Access-Control-Allow-Origin: *就是存在漏洞，其實這個判斷是不完善的。本期作者自己寫了一個Java的測試環(huán)境，給大家演示一下CORS漏洞的復現過程及利用過程，相信大家一看就明白了。
Part2 CORS漏洞測試結果?
首先給出最終測試結果，以下結論是自寫Java代碼搭建環(huán)境進行測試給出的結論，歡迎大家批評指正。首先使用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跨域漏洞復現?
一般CORS漏洞的測試過程
首先復習一下常規(guī)的CORS漏洞測試過程：抓取一個能夠返回個人敏感數據的HTTP請求包，添加Origin: http://www.xxx.com，查看返回頭中是否包含“Access-Control-Allow-Origin: *”、“Access-Control-Allow-Credentials: true”，這里說明一點，如果返回包中這兩個頭同時存在，那么它其實是不存在CORS漏洞的。接下來依據Access-Control-Allow-Origin、Access-Control-Allow-Credentials的不同返回值的各種情況，分別寫Java代碼測試一下，是否能夠獲取敏感數據，大家就明白了。
-
編寫Java代碼測試
接下來我用Java編寫了兩個Servlet代碼模擬一個Web購物網站，用JS前端代碼模擬攻擊者構造的CORS漏洞利用html頁面。
如下所示，首先是登錄界面的servlet代碼如下。
?
代碼效果如下，用戶輸入用戶名密碼后，購物網站提示登錄成功，這時候后臺代碼已經生成Cookie。
接下來用戶訪問PersonInfo頁面，http://192.168.237.1:9999/Servlet/PersonInfo 會顯示交易密碼是123456。
?
此頁面對應的PersonInfo的Sevlet代碼如下：
?
接下來攻擊者為了獲取該購物網站用戶的交易密碼，精心構造了如下的attack.html頁面放到Web服務器上，此時攻擊URL是http://www.attacker111.com/attack.html。攻擊者將此URL發(fā)給受害者瀏覽，受害者的交易密碼將會被獲取到。
-
第1種情況：
首先看第1種情況，服務器返回如下消息頭，這種情況下，非常好利用，所以漏洞定級是高危：
Access-Control-Allow-Origin: https://www.attacker.com
Access-Control-Allow-Credentials: true
這兩個返回頭表示應用程序允許來自任何Origin的任何腳本向應用程序發(fā)出CORS請求，這時候程序員的代碼是這樣寫的：
受害者訪問攻擊者構造好的URL之后，成功獲取用戶的敏感數據。
F12查看瀏覽器發(fā)出的請求，發(fā)現其帶上了Cookie，成功繞過跨域的同源限制。
?
?文章來源地址http://www.zghlxwxcb.cn/news/detail-466204.html
-
第2種情況：
服務器返回如下消息頭，這種情況下，利用起來稍有困難，這里的null必須全部都是小寫，漏洞仍然是高危。
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true
在這種情況下，應用程序HTTP響應頭Access-Control-Allow-Origin的值始終為null。當用戶指定null以外的任何值時，應用程序不會處理。
這時候訪問http://192.168.237.199/attack.html，發(fā)現瀏覽器提示CORS策略錯誤。
?
因為這時候的Origin不等于null
?
這里需要想辦法讓Origin等于null，于是攻擊者構造如下js代碼：
?
此時發(fā)現仍然可以成功獲取用戶的敏感數據。
?
-
第3種情況：
服務器返回如下消息頭，這種情況下，其實是不存在漏洞的，如果非要牽強地說存在漏洞，可以協(xié)商CORS配置錯誤，畢竟設置為*本身就有問題。
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
對應著java代碼如下：
?訪問http://www.attacker111.com/attack.html發(fā)現，瀏覽器直接報錯，看來這種情況根本不被安全策略所允許。
-
第4種情況：
服務器返回如下消息頭，這個就不演示了，只能說明CORS配置存在問題，但是沒法獲取敏感數據，漏洞評級應為中?；蛘叩臀！?/p>
Access-Control-Allow-Origin：*
-
Chrome瀏覽器測試結果
接下來換谷歌Chrome瀏覽器最新版本下測試，發(fā)現確實成功繞過了同源策略，發(fā)起了跨域請求，但是Chrome瀏覽器卻沒有為請求帶上Cookie，所以漏洞利用有限。
?Part4 修補建議?
1.?Access-Control-Allow-Origin中指定的來源只能是受信任的站點，避免使用Access-Control-Allow-Origin: *，避免使用Access-Control-Allow-Origin: null，否則攻擊者可以偽造來源請求實現跨域資源竊取。
2.?嚴格校驗“Origin”值，校驗的正則表達式一定要編寫完善，避免出現繞過的情況。
3.?減少“Access-Control-Allow-Methods”所允許的請求方法。
4.?除了正確配置CORS之外，Web服務器還應繼續(xù)對敏感數據進行保護，例如身份驗證和會話管理等。
?文章來源：http://www.zghlxwxcb.cn/news/detail-466204.html
?
?
?
?
?
?
到了這里，關于CORS跨域資源共享漏洞的復現、分析、利用及修復過程的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！
