三種對CORS錯誤配置的利用方法

2022-09-23 16:36:15 字數 3638 閱讀 6960

同源策略(sop)限制了應用程式之間的資訊共享,並且僅允許在託管應用程式的域內共享。這有效防止了系統機密資訊的洩露。但與此同時,也帶來了另外的問題。隨著web應用程式和微服務使用的日益增長,出於實用目的往往需要將資訊從乙個子域傳遞到另乙個子域,或者在不同域之間進行傳遞(例如將訪問令牌和會話識別符號,傳遞給另乙個應用程式)。

為了允許跨域通訊,開發人員必須使用不同的技術來繞過sop並傳遞敏感資訊,以至於現今也成為了乙個棘手的安全問題。因此,為了在不影響應用程式安全狀態的情況下實現資訊共享,在html5中引入了跨源資源共享(cors)。但問題也隨之而來,許多人為了方便乾脆直接使用預設的配置,或是由於缺乏對此的了解而導致了錯誤的配置。

因此,作為安全分析師/工程師,了解如何利用錯誤配置的cors標頭非常重要。這也將有助於你在災難發生之前更好地對其進行補救。

什麼是 cors?

cors是乙個w3c標準,全稱是」跨域資源共享」(cross-origin resource sharing)。它允許瀏覽器向跨源(協議 + 網域名稱 + 埠)伺服器,發出xmlhttprequest請求,從而克服了ajax只能同源使用的限制。

cors需要瀏覽器和伺服器同時支援。它的通訊過程,都是瀏覽器自動完成,不需要使用者參與。對於開發者來說,cors通訊與同源的ajax通訊沒有差別,**完全一樣。瀏覽器一旦發現ajax請求跨源,就會自動新增一些附加的頭資訊,有時還會多出一次附加的請求,但使用者不會有感覺。

因此,實現cors通訊的關鍵是伺服器。只要伺服器實現了cors介面,就可以跨源通訊。

關鍵 cors 標頭

有許多與cors相關的http標頭,但以下三個響應標頭對於安全性最為重要:

access-control-allow-origin:指定哪些域可以訪問域資源。例如,如果requester.com想要訪問provider.com的資源,那麼開發人員可以使用此標頭安全地授予requester.com對provider.com資源的訪問許可權。

access-control-allow-credentials:指定瀏覽器是否將使用請求傳送cookie。僅當allow-credentials標頭設定為true時,才會傳送cookie。

access-control-allow-methods:指定可以使用哪些http請求方法(get,put,delete等)來訪問資源。此標頭允許開發人員通過在requester.com請求訪問provider.com的資源時,指定哪些方法有效來進一步增強安全性。

三個攻擊場景

利用cors標頭中錯誤配置的萬用字元(*)

最常見的cors配置錯誤之一是錯誤地使用諸如(*)之類的萬用字元,允許域請求資源。這通常設定為預設值,這意味著任何域都可以訪問此站點上的資源。例如:

get /api/userinfo.php

host: www.victim.com

origin: www.victim.com

當你傳送上述請求時,你將獲得具有access-control-allow-origin標頭設定的響應。請參閱以下響應**。

在此示例中,標頭配置了萬用字元(*)。 這意味著任何域都可以訪問資源。

在測試我們客戶的web應用程式時,我們注意到了這種錯誤配置。我們能夠利用它來獲取使用者資訊,如姓名,使用者id,電子郵件id,並能夠將此資訊傳送到外部伺服器。在下圖中,我們將request origin從受害者域修改為攻擊者域。

以下是我們收到的響應,這意味著受害域允許訪問來自所有站點的資源。我們的攻擊案例中的testing.aaa.com**。

由於該站點共享來自任何站點的資訊,因此讓我們進一步的使用我們自己的域來利用它。我們建立了名為的域,並將其嵌入漏洞利用**,以便從易受攻擊的應用程式中竊取機密資訊。當受害者在瀏覽器中開啟時,它會檢索敏感資訊並傳送給攻擊者的伺服器。以下是我們可以收集到的資訊,如下圖所示。

將信任域萬用字元作為 origin

另一種常見的錯誤配置是允許與部分驗證的網域名稱共享資訊。例如,以下請求:

get /api/userinfo.php

host: provider.com

origin: requester.com

響應如下:

考慮一下開發人員是否配置了cors來驗證「origin header」url,白名單域只是「requester.com」。現在,當攻擊者發起如下請求時:

get /api/userinfo.php

host: example.com

connection: close

origin: attackerrequester.com

伺服器會響應:

發生這種情況的原因可能是後端配置錯誤,例如:

我們在客戶的乙個應用程式中遇到了這個問題。主機域「provider.com」信任以主機名「requester.com」結尾的所有**,例如「attackerrequester.com」。 因此,我們將origin頭部篡改為attackerrequester.com並繼續執行請求。

在以下響應中,相同的origin在響應access-control-allow-origin標頭中,這意味著provider.com域允許共享資源到以requester.com結尾的域。

因此,我們可以建立乙個由列入白名單的網域名稱組成的新網域名稱。然後,將惡意站點嵌入利用**從而獲取受害者站點上的敏感資訊。

使用 xss 實現 cors 的利用

開發人員用於對抗cors利用的一種防禦機制,是將頻繁請求訪問資訊的域列入白名單。但這並不完全安全,因為只要白名單域中的乙個子域易受到其他攻擊(如xss),那麼也可以進行cors利用。

讓我們看乙個示例,以下**將允許requester.com的子域訪問provider.com的資源配置。

假設使用者可以訪問sub.requester.com而不是requester.com,並且sub.requster.com易受xss攻擊。那麼使用者就可以使用xss來利用provider.com。

我們在同乙個域上託管了兩個應用程式。cors應用程式託管在testingcors.com上,另乙個應用程式則託管在p**an.testingcors.com上,該應用程式易受xss的攻擊。

使用這個易受攻擊的xss子域,我們可以從testingcors.com上獲取敏感資訊。我們在「name」引數中注入了惡意j**ascript payload。頁面載入後,指令碼將被執行,並從testingcors.com中獲取敏感資訊。

總結cors是上榜owasp top 10的安全漏洞。在實現站點之間資訊共享的過程中,人們往往會忽略cors配置的重要性。作為開發人員或安全專家,了解此漏洞以及如何對它進行利用至關重要。

SPRING JDBC事務管理的三種配置方法

一.一般的jdbc事務,通常可以這樣處理 txproxytemplate abstract true class org.springframework.transaction.interceptor.transactionproxyfactorybean propagation required,...

執行緒的三種建立方

一,繼承thread 重寫run class programmer extends thread public static void main string args 二,繼承runnable 實現run class programmer implements runnable public st...

VMware ESXi Vlan的三種實現方式

在vmware esx esxi網路中vlan實現方式可以分成3種,分別是通過物理交換機,虛擬交換機 vswitch 和esxi中的虛擬機器 vm 來新增vlan標記,具體方式如下 1 est external switch tagging 通過將交換機的埠劃分到不同的vlan實現虛擬機器的vlan...