網站安全防護：CSRF 攻擊防禦與 CORS 設定

– 11 分鐘閱讀

在現今網路環境中，網站安全至關重要。本文將深入探討兩種關鍵的網站安全機制：跨站請求偽造（CSRF）的防禦以及跨來源資源分享（CORS）的設定。CSRF 攻擊利用使用者已驗證的身份，在使用者不知情的情況下執行惡意請求。防禦 CSRF 攻擊，可以透過 token 驗證、SameSite 屬性設定等方法來降低風險。另一方面，CORS 允許網頁從不同源請求資源，需要正確設定才能確保安全性。本文將詳細說明如何在 Django 中設定 CSRF 保護機制和 CORS，提升網站的安全性。

15.1 CSP 報告

CSP 報告是一種機制，允許瀏覽器在發現安全政策違規時向網站傳送報告。這些報告可以幫助網站所有者瞭解哪些內容違反了安全政策，並採取相應的措施。

{
  "csp-report": {
    "violated-directive": "img-src",
    "effective-directive": "img-src",
    "original-policy": "default-src 'self'; report-uri /csp_report/",
    "disposition": "enforce",
    "status-code": 0
  }
}

15.2 CSP 報告比例

CSP 報告比例是一個引數，允許您控制報告的比例。這個引數可以設定為一個介於 0 和 1 之間的浮點數，代表報告的比例。

CSP_REPORT_PERCENTAGE = 0.42

15.3 RateLimitedCSPMiddleware

RateLimitedCSPMiddleware 是一個中介軟體，允許您限制 CSP 報告的流量。這個中介軟體需要替換 CSPMiddleware。

MIDDLEWARE = [
    #...
    # 'csp.middleware.CSPMiddleware',
    #...
]

15.4 Content-Security-Policy-Report-Only

Content-Security-Policy-Report-Only 是一個報表模式，允許您佈署安全政策而不強制執行。這個模式需要設定 CSP_REPORT_ONLY 引數。

CSP_REPORT_ONLY = True

15.5 CSP Level 3

CSP Level 3 是 CSP 的最新版本，提供了更多的功能和改進。其中包括 upgrade-insecure-requests 和 block-all-mixed-content 等指令。

15.5.1 upgrade-insecure-requests

upgrade-insecure-requests 指令要求瀏覽器將 HTTP 請求升級為 HTTPS。這個指令需要設定 CSP_UPGRADE_INSECURE_REQUESTS 引數。

CSP_UPGRADE_INSECURE_REQUESTS = True

15.5.2 block-all-mixed-content

block-all-mixed-content 指令禁止瀏覽器載入混合內容（即 HTTP 內容在 HTTPS 頁面中）。這個指令需要設定 CSP_BLOCK_ALL_MIXED_CONTENT 引數。

CSP_BLOCK_ALL_MIXED_CONTENT = True

16.1 什麼是跨站請求偽造（CSRF）？

跨站請求偽造（Cross-Site Request Forgery，CSRF）是一種網路攻擊，目的是讓使用者在不知不覺的情況下執行惡意請求。這種攻擊通常是透過讓使用者點選惡意連結或提交表單，從而使得使用者的瀏覽器傳送請求到攻擊者的網站。

16.2 同源政策與CSRF

同源政策（Same-Origin Policy）是一種安全機制，限制了網頁可以存取的資源。根據同源政策，網頁只能存取同一網域名稱、同一協定、同一埠的資源。這意味著，如果一個網頁來自於不同的網域名稱、協定或埠，則它不能存取其他網頁的資源。

然而，CSRF攻擊可以繞過同源政策的限制。攻擊者可以建立一個惡意網頁，該網頁包含了一個表單或連結，當使用者點選時，會傳送請求到攻擊者的網站。由於使用者的瀏覽器已經登入了攻擊者的網站，因此攻擊者可以利用使用者的身份執行惡意請求。

16.3 防禦CSRF攻擊

防禦CSRF攻擊有幾種方法：

  1. Token-based驗證：在表單中加入一個token，該token由伺服器生成，並且每次請求都會驗證token的正確性。
  2. Header-based驗證：在請求的header中加入一個特定的header，例如X-CSRF-Token，伺服器會驗證該header的正確性。
  3. SameSite Cookie：設定Cookie的SameSite屬性為Strict或Lax，以限制Cookie的存取範圍。
  4. 雙重提交Cookie：在表單中加入一個Cookie，該Cookie由伺服器生成，並且每次請求都會驗證Cookie的正確性。

16.4 Django中的CSRF防禦

Django提供了一個內建的CSRF防禦機制，可以自動為表單加入token，並且驗證token的正確性。開發者可以使用csrf_token範本標籤來加入token，並且使用@csrf_protect裝飾器來保護檢視函式。

此外，Django還提供了一個SESSION_COOKIE_SAMESITE設定項，可以設定為Strict或Lax，以限制Cookie的存取範圍。

根據提供的內容，似乎是關於網站安全和 CSRF（Cross-Site Request Forgery）攻擊的防禦措施。以下是根據提供的內容重寫的技術文章：

CSRF 攻擊和 SameSite 屬性

CSRF 攻擊是一種常見的網站安全威脅，攻擊者可以透過欺騙使用者的瀏覽器傳送惡意請求到目標網站。為了防禦這種攻擊，網站可以使用 SameSite 屬性來限制 Cookie 的存取。

SameSite 屬性可以設定為三個值：None、Strict 和 Lax。這些值控制著 Cookie 何時可以被瀏覽器傳送給網站。預設情況下，SameSite 屬性設定為 Lax，這意味著 Cookie 只會在使用者直接存取網站時被傳送。

在 Django 中，可以使用 SESSION_COOKIE_SAMESITE 引數來設定 SameSite 屬性。這個引數可以設定為 None、Strict、Lax 或 False。其中，False 是不建議使用的，因為它會使網站變得不安全。

安全性考量

雖然 SameSite 屬性可以幫助防禦 CSRF 攻擊，但它並不是萬能的解決方案。網站還需要實施其他安全措施，例如使用 token 或雙重提交機制來驗證使用者請求。

此外，網站應該遵循 HTTP 協定的規範，使用安全的方法（如 POST、PUT、DELETE 等）來修改伺服器上的資料，而不是使用 GET 方法。這樣可以幫助防禦 CSRF 攻擊和其他型別的攻擊。

網站安全性與HTTP方法

網站安全性是一個非常重要的議題，尤其是在處理使用者資料和進行敏感操作時。其中一個關鍵因素是正確地使用HTTP方法，以確保使用者的請求被正確地處理。

HTTP方法

HTTP方法（HTTP Method）是用於向伺服器傳送請求的方式，常見的HTTP方法包括GET、POST、PUT、DELETE等。每個方法都有其特定的用途和限制。

  • GET：用於從伺服器檢索資料，不應該用於修改伺服器上的資料。
  • POST：用於向伺服器傳送資料，通常用於新增或修改資料。
  • PUT：用於修改伺服器上的現有資料。
  • DELETE：用於刪除伺服器上的資料。

安全性問題

如果網站沒有正確地實施HTTP方法的限制，可能會導致安全性問題。例如，如果一個網站允許使用GET方法修改資料，攻擊者就可以透過建構惡意的URL來修改資料。

解決方案

為瞭解決這個問題，可以使用以下幾種方法：

  1. 檢查HTTP方法：在伺服器端檢查請求的HTTP方法，如果不是預期的方法，則傳回錯誤。
  2. 使用CSRF保護：CSRF（Cross-Site Request Forgery）是一種攻擊方式，攻擊者可以透過建構惡意的請求來修改使用者的資料。可以使用CSRF保護機制來防止這種攻擊。
  3. 使用安全的HTTP方法：盡量使用安全的HTTP方法，如POST、PUT、DELETE等，避免使用GET方法修改資料。

Django實作

在Django中，可以使用require_http_methods裝飾器來限制HTTP方法。例如：

from django.http import HttpResponse
from django.views.decorators.http import require_http_methods

@require_http_methods(['POST'])
def group_membership_function(request):
    # 處理POST請求
    return HttpResponse('state change successful')

這樣就可以確保只有POST請求才能被處理。

Django 中的 CSRF 保護機制

Django 提供了強大的 CSRF（Cross-Site Request Forgery）保護機制，以防止惡意攻擊。以下是 Django 中的 CSRF 保護機制的重點：

1. CSRF Token

Django 會為每個使用者生成一個唯一的 CSRF Token，並將其儲存在使用者的 Session 中。當使用者提交表單時，Django 會驗證 CSRF Token 是否與 Session 中的 Token 相符。如果不相符，則會拒絕請求。

2. CSRF Middleware

Django 的 CSRF Middleware 會自動為所有表單新增 CSRF Token。當使用者提交表單時，Middleware 會驗證 CSRF Token 是否有效。如果無效，則會拒絕請求。

3. CSRF View Decorator

Django 提供了 @csrf_protect Decorator，可以用於保護特定的 View 函式。這個 Decorator 會驗證 CSRF Token 是否有效，如果無效，則會拒絕請求。

Django 會將 CSRF Token 儲存在使用者的 Cookie 中。當使用者提交表單時，Django 會從 Cookie 中讀取 CSRF Token，並驗證其是否與 Session 中的 Token 相符。

5. Referer Header

Django 會檢查 Referer Header，以確保請求來自合法的來源。如果 Referer Header 不合法，則會拒絕請求。

6. SECURE_REFERRER_POLICY

Django 提供了 SECURE_REFERRER_POLICY 設定，可以用於控制 Referer Header 的行為。

7. CSRF_TRUSTED_ORIGINS

Django 提供了 CSRF_TRUSTED_ORIGINS 設定，可以用於指定哪些來源是可信的。

CSRF攻擊防禦機制

CSRF（Cross-Site Request Forgery）是一種網路攻擊，攻擊者透過在使用者不知情的情況下傳送請求，來達到非法操作的目的。為了防禦CSRF攻擊，Django提供了多種機制。

16.5.2 其他非安全請求方法

當Django收到PUT、PATCH或DELETE請求時，會期待在cookie和請求頭中找到CSRF token。為了處理這些請求，需要進行額外的努力。以下JavaScript程式碼示範瞭如何從cookie中提取CSRF token並將其新增到請求頭中：

fetch('/resource/', {
  method: 'DELETE',
  headers: {
    'X-CSRFToken': extractToken()
  }
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('error', error));

CSRF Token 驗證

Django會從cookie和請求頭中提取CSRF token，並進行驗證。如果cookie和請求頭中的token不匹配，請求將被拒絕。

CSRF_COOKIE_HTTPONLY引數用於設定CSRF token cookie的HttpOnly屬性。如果設為True，則cookie將被隱藏於JavaScript，無法被存取。這意味著前面的JavaScript程式碼將無法工作。

預設設定

Django預設將CSRF_COOKIE_HTTPONLY設為False，而SESSION_COOKIE_HTTPONLY設為True。這是因為當攻擊者可以存取cookie時，CSRF攻擊已經不再是主要問題，因為攻擊者已經可以進行XSS攻擊。

使用Session儲存CSRF Token

Django也可以將CSRF token儲存在session中，而不是cookie。這可以透過設定CSRF_USE_SESSIONS為True來實作。如果使用此設定，則需要找到其他方式從HTML檔案中提取CSRF token，以便在AJAX請求中使用。

安全注意事項

無論使用何種方法傳送CSRF token，都應避免將其傳送到其他網站。應始終檢查cookie是否來自原始網站，以防止CSRF token被竊取並用於攻擊。

瀏覽器安全性：同源政策與跨來源資源分享

同源政策

同源政策（Same-Origin Policy, SOP）是一種安全機制，限制了網頁能夠存取哪些資源。根據這個政策，網頁只能存取與其來自相同的源（protocol、host、port）的資源。這意味著，如果一個網頁來自 http://example.com，它就不能存取 http://other-example.com 的資源。

跨來源資源分享（CORS）

跨來源資源分享（Cross-Origin Resource Sharing, CORS）是一種機制，允許網頁跨越不同來源存取資源。CORS透過在HTTP請求和回應中新增特定的標頭，來實作跨來源資源分享。

CORS的工作原理

當一個網頁傳送一個跨來源的請求時，瀏覽器會自動新增一個Origin標頭，指示請求的來源。伺服器可以透過檢查這個標頭，來確定是否允許跨來源存取。

如果伺服器允許跨來源存取，它會在回應中新增一些特定的標頭，例如Access-Control-Allow-Origin、Access-Control-Allow-Methods等。這些標頭指示瀏覽器，可以存取哪些資源和使用哪些方法。

Django-CORS-Headers

Django-CORS-Headers是一個Django的中介軟體，提供了一種簡單的方式來實作CORS。它可以自動新增CORS相關的標頭到回應中，讓你可以輕鬆地實作跨來源資源分享。

實作CORS

要實作CORS，你需要在你的Django專案中安裝Django-CORS-Headers中介軟體。然後，你需要在你的設定檔中新增一些組態，例如CORS_ALLOWED_ORIGINS、CORS_ALLOW_METHODS等。

INSTALLED_APPS = [
    #...
    'corsheaders',
    #...
]

MIDDLEWARE = [
    #...
    'corsheaders.middleware.CorsMiddleware',
    #...
]

CORS_ALLOWED_ORIGINS = [
    'http://example.com',
    'http://other-example.com',
]

CORS_ALLOW_METHODS = [
    'GET',
    'POST',
    'PUT',
    'DELETE',
]

CORS簡介

CORS（Cross-Origin Resource Sharing）是一種機制，允許網頁從不同的源（domain、protocol、port）請求資源。這是因為瀏覽器的同源政策（SOP）限制了網頁只能請求同源的資源。

CORS的工作原理

CORS是透過瀏覽器和伺服器之間的溝通實作的。當網頁請求一個不同源的資源時，瀏覽器會在請求中新增一個Origin頭，指明請求的源。伺服器收到請求後，會檢查Origin頭，如果允許請求的源，則會在回應中新增一個Access-Control-Allow-Origin頭，指明允許的源。

CORS的型別

CORS有兩種型別：簡單請求（Simple Request）和預檢請求（Preflighted Request）。

  • 簡單請求：如果請求方法是GET、HEAD或POST，且請求頭只有少數幾個，則為簡單請求。
  • 預檢請求：如果請求方法不是GET、HEAD或POST，或者請求頭超過了簡單請求的限制，則為預檢請求。

從系統安全架構的視角來看，本文深入探討了網站安全防護的關鍵機制，涵蓋了 CSP 報告機制、CSRF 防禦策略以及 CORS 跨域資源分享的實作方式。分析發現，有效利用 CSP 報告能幫助網站管理者及時發現安全漏洞並採取相應措施，但需注意報告比例的設定以避免過載。CSRF 防禦方面，Django 內建的 token 機制和 SameSite Cookie 屬性設定能有效降低攻擊風險，但也需要開發者正確理解和運用。至於 CORS，雖然能實作跨域資源分享，但也需謹慎組態允許的來源和方法，避免引入新的安全風險。技術的演進趨勢表明，瀏覽器安全機制將持續強化，未來可能出現更細緻的許可權控制和更智慧的威脅檢測技術。玄貓認為，網站安全是一個持續演進的過程，開發者應持續關注新的安全威脅和防禦技術，並將其整合到網站開發的每個環節，才能構建真正安全的網路環境。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。