CORS目的並非保護API端點 - nikofischer

banq發表於2022-02-14
CORSAPI

CORS 不會保護API端點免受攻擊，因為您始終可以在瀏覽器之外發出相同的請求，而且它不會保護任何站點防止跨站點請求，因為CORS始終可以在伺服器端禁用。
CORS可以防止惡意網站欺騙未經修改的瀏覽器對合法網站進行跨站請求的情況。如果使用者有合法網站的認證cookie，cookie將與請求一起被髮送。因此，惡意網站可以代表使用者在合法網站上進行交易，儘管它不能直接訪問認證cookie。

CORS進一步複雜化，因為某些形式的跨站請求一直被瀏覽器所允許，因此為了向後相容，必須保持預設啟用。對不同網站的GET請求是允許的，因為這一直是被允許的，例如嵌入其他域的影像。POST請求是允許的，但要注意不能檢查結果，因為你一直能夠從一個html表單中發起一個帖子到不同的網站。
 

這篇文章是因為我正在尋找將 Vue APP 驗證到 Drupal 後端的方法。Designkojo 的文章是最早出現在搜尋引擎頂部的文章之一。此外，這篇文章有魅力：描述得很好，簡潔。特別是對於初學者來說，所描述的方法易於實施。它表明：透過 API 金鑰進行身份驗證是 Web 應用程式的常用方式。這就是它變得危險的地方：尤其是沒有經驗的開發人員可能會上當，並認為這是透過 Web 應用程式向後端進行身份驗證的常用方法。
文章中介紹的設定：後端由 Drupal 提供。Drupal 從版本 8 開始在核心中整合了 JSON API，可以透過模組管理輕鬆啟用。有了這個，現在可以訪問所有實體（例如使用者、節點等）並透過 GET 請求讀取它們。
JSON API 基於 Drupal 系統中定義的許可權。因此，如果使用者對某個內容沒有讀取許可權，則該內容也無法透過 JSON API 載入。寫訪問也是如此：只有當訪問使用者具有適當的許可權時，才能建立、修改或刪除實體。
作者描述了他如何在客戶端 Vue 應用程式中訪問 Drupal 後端以建立內容。只有登入的使用者才能建立文章。因此，為了透過 JSON API 建立文章，他必須首先驗證自己。
有幾種方法可以向 Drupal 進行身份驗證。通常的方法是透過使用者名稱和密碼。這不僅可以直接透過前端實現，也可以透過 API 實現。此處 Drupal 在成功驗證後返回一個會話 ID，您可以將其快取並用於所有進一步的請求。
作者現在使用了另一種方式：他安裝了Key auth模組。這將為後端中的每個使用者建立一個 API 金鑰，可用於對 API 的身份驗證。為此，必須將引數“api-key”與鍵作為每次呼叫的值一起傳遞。這樣，使用者就會在 Drupal 中自動進行身份驗證，並擁有所有分配的許可權。文章中描述的“Key auth”模組只是使用者名稱和密碼的替代品。

在這裡他犯了一個危險的錯誤：他將來自 Drupal 後端的 API 金鑰整合到他的 Vue.js 應用程式中，以便能夠對 API 進行身份驗證並建立內容。Vue.js 應用程式在使用者瀏覽器的客戶端執行。這意味著原始碼是從伺服器直接傳送到瀏覽器的。現在，使用者可以完全訪問原始碼，還可以讀取其中包含的身份驗證金鑰。
 

CORS 設定確保只能從某個站點域名訪問後端？
沒有！沒有 CORS是在瀏覽器中的一種實現，旨在透過確保瀏覽器中的資源只允許訪問特定的端點來保護使用者免受惡意應用程式的侵害。

這種瀏覽器的實現可以在任何時候被繞過。首先，這取決於瀏覽器本身：如果CORS沒有被整合，或者沒有被幹淨地整合，那麼它將無法工作。伺服器傳送一個 CORS 標頭，由瀏覽器決定如何處理它。這不是一個安全要素，因為在這裡拒絕訪問不在伺服器的手中，而完全在瀏覽器的手中。
攻擊者可以透過 Web 應用程式的原始碼訪問 API 金鑰並使用它，例如透過 cURL 請求直接訪問後端的 API 資源。使用 cURL，沒有 CORS 生效，因此攻擊者可以直接訪問使用者的全部許可權。
API 金鑰是使用者名稱和密碼的替代品。沒有人會想到在 Web 應用程式的原始碼中儲存使用者名稱和密碼。
文章中描述的“Key auth”模組只是使用者名稱和密碼的替代品。

相關文章