通過設定Referer黑白名單規則來避免網站被惡意盜刷 - CDN

Referer黑/白名單基於HTTP要求標頭中的Referer欄位，通過設定黑名單/白名單來控制訪問，防止資源被非法盜用。配置後，CDN會根據Referer資訊，允許或拒絕訪問請求。

重要

阿里雲CDN的Referer黑/白名單功能預設不啟用，即任何網站均可訪問您的資源。
Referer黑/白名單只是防止CDN流量盜刷的一種方式，更多防護方式參見防範流量盜刷最佳實務。
將網域名稱添加到Referer黑名單或白名單後，CDN會將該網域名稱的泛網域名稱加入規則名單。例如，填寫aliyundoc.com，最終生效的是*.aliyundoc.com，即所有子網域名稱都會生效。

Referer圖解

Referer是使用者從一個網站跳轉到另一個網站時，記錄的第一個網站的URL資訊，即表示當前頁面是通過哪個頁面跳轉過來的。具體由協議、網域名稱、路徑、查詢參數組成，如下圖所示。

說明

Referer本質上就是一個URL，即請求連結。
阿里雲支援僅網域名稱形式的Referer配置，通過勾選忽略Scheme實現。

使用情境

Referer黑/白名單主要用於保護網站的資源不被其他網站直接引用或盜用，常見的使用情境包括：

著作權保護：某些網站的內容受著作權保護，Referer黑/白名單可以限制只有授權網站訪問這些內容，保護著作權。
防止熱鏈盜用：Referer黑/白名單確保資源只能在特定網站上使用，防止其他網站直接引用，減少熱鏈盜用。
提高網站安全性：Referer黑/白名單只允許特定網站訪問資源，防止惡意盜鏈、惡意訪問或盜取敏感資訊。
控制流程量來源：Referer黑/白名單限制特定網站的流量訪問，有效控制流程量來源，提高網站穩定性和安全性。

綜上所述，您可以根據需求，在不同情境中使用Referer黑/白名單功能，保護資源、提高安全性和控制流程量。

工作原理

伺服器端檢查每個請求的Referer欄位，如果Referer欄位不是來自白名單配置，就拒絕提供服務，從而節省頻寬和伺服器資源。CDN的Referer請求規則如下：

如果瀏覽器攜帶的Referer與黑名單Referer匹配，或與白名單Referer不匹配，則CDN將拒絕該請求的訪問。
如果瀏覽器攜帶的Referer與白名單Referer匹配，則CDN將允許該請求的訪問。

注意事項

配置Referer黑/白名單後，黑名單請求仍可訪問CDN節點，但會被拒絕並返回403狀態代碼，CDN日誌中也會記錄該請求。
Referer黑/白名單功能基於HTTP要求標頭中的Referer欄位設定存取控制規則。黑名單請求被攔截時會產生少量流量費用，使用HTTPS協議訪問還會產生HTTPS請求數費用。
由於CDN流量盜刷來自公網訪問，所以Referer規則僅限於公網網域名稱匹配。

操作步驟

登入CDN控制台。
在左側導覽列，單擊域名管理。
在域名管理頁面，找到目標網域名稱，單擊操作列的管理。
在指定網域名稱的左側導覽列，單擊访问控制。
在Referer黑/白名單頁簽，單擊修改配置。
根據業務需求，填寫Referer配置項。
單擊確定，完成配置。

Referer配置項說明

參數		說明
Refer类型		黑名单攜帶黑名單Referer的請求均無法訪問當前資源。白名单只有攜帶白名單Referer的請求才能訪問當前資源。說明黑名單和白名單互斥，只能選擇一種。
规则		支援添加多個Referer名單，使用斷行符號符分隔。支援星號（）作為萬用字元，匹配所有子網域名稱。如`.example.com`匹配`example.com`的所有子網域名稱。支援萬用字元（）預設，匹配自身及其所有子網域名稱。如`example.com`匹配`example.com`和`.example.com`結果集。說明 Referer黑/白名單規則的總長度最長不超過60 KB。配置規則不需要填寫協議頭。
重新導向URL		請求被攔截後返回302+Location頭，該項為Location頭的值，必須以`http://`或者`https://`開頭，例如：`http://www.example.com`。
高級配置	允许通过浏览器地址栏直接访问资源URL	預設未勾選。勾選後，無論配置的是Referer黑名單還是白名單，系統不攔截空Referer請求，CDN節點允許使用者訪問當前資源。空Referer包括：使用者請求中不攜帶Referer頭。 Referer頭值為空白。
	精確匹配	預設未勾選。勾選後，不再支援萬用字元（*）預設。若未使用萬用字元，`example.com`僅匹配`example.com`。
	忽略Scheme	未勾選忽略Scheme時，要求標頭中Referer必須攜帶HTTP或HTTPS協議頭。勾選忽略Scheme後，要求標頭中Referer可不攜帶HTTP或HTTPS協議頭。
規則條件		規則條件能夠對使用者請求中攜帶的各種參數資訊進行識別，以此來決定某個配置是否對該請求生效。重要引用規則條件時，按所關聯規則條件的優先順序匹配，而非按功能自身的配置順序匹配。不使用：不使用規則條件。若需新增或編輯規則條件，請在規則引擎中進行管理。

Referer驗證

這裡使用curl命令測試，-e後面接referer值，-I後接CDN加速網域名稱。該命令結果返迴響應頭資訊。這裡以白名單為例進行驗證。

情境一：僅設定Referer規則

說明

該情境僅設定Referer規則為aliyun.com，重新導向URL、進階配置、規則條件均不配置。
將匹配攜帶形如http(s)://aliyun.com及其子網域名稱的請求，其他非白名單Referer將被拒絕。

攜帶主網域名稱的Referer訪問測試，命令curl -e http://aliyun.com -I CDN加速網域名稱。
```
[root@xxx ~]# curl -e http://aliyun.com -I http://referer.n          p
HTTP/1.1 200 OK
Server: Tengine
```
攜帶子網域名稱的Referer訪問測試，命令curl -e http://sub.aliyun.com -I CDN加速網域名稱。
```
[root@xxx ~]# curl -e http://sub.aliyun.com -I http://referer.xxx
HTTP/1.1 200 OK
Server: Tengine
```
攜帶其他網域名稱的Referer訪問測試，命令curl -e http://aIiyun.com -I CDN加速網域名稱。
```
[root@xxx ~]# curl -e http://aIiyun.com -I http://referer.xxx
HTTP/1.1 403 Forbidden
Server: Tengine
```

空Referer的測試，命令curl -e " " -I CDN加速網域名稱。

[root@ixxxxx ~]# curl -e " " -I http://referer.nxxxxx p
HTTP/1.1 403 Forbidden
Server: Tengine

僅網域名稱的Referer訪問測試，命令curl -e aliyun.com -I CDN加速網域名稱。

[root@i-xxx ~]# curl -e aliyun.com -I http://referer.mxxx
HTTP/1.1 403 Forbidden
Server: Tengine

情境二：設定Referer規則並勾選允许通过浏览器地址栏直接访问资源URL

說明

該情境設定Referer規則為aliyun.com並勾選允許通過瀏覽器地址欄直接存取資源URL。進階配置其他選項不勾選，重新導向URL、規則條件均不配置。
相比情境一中多匹配出空Referer的情形，即攜帶空Referer和直接存取也將被允許。

不攜帶Referer的訪問測試，命令curl -I CDN加速網域名稱。

[root@ixxxxxxxxxx ~]# curl -I http://referer.mxxxxxxxp
HTTP/1.1 200 OK
Server: Tengine

攜帶" "Referer的訪問測試，命令curl -e " " -I CDN加速網域名稱。

[root@ixxxxx7 ~]# curl -e " " -I http://referer.mxxxp
HTTP/1.1 200 OK
Server: Tengine

情境三：設定Referer規則並勾選忽略Scheme

說明

該情境設定Referer規則為aliyun.com並勾選忽略scheme。進階配置其他選項不勾選，重新導向URL、規則條件均不配置。
同情境一的情形，但允許出現不攜帶協議頭，如僅網域名稱aliyun.com的Referer請求。

不帶協議頭的Referer訪問測試，命令curl -e aliyun.com -I CDN加速網域名稱。

[root@i-xxx z ~]# curl -e aliyun.com -I http://referer.xxx
HTTP/1.1 200 OK
Server: Tengine

常見問題

請求中的Referer欄位不是應該預設內建HTTP或HTTPS協議頭部嗎，為什麼還會出現沒有帶上HTTP或HTTPS協議頭部的情況？

一般情況下，使用者請求中的Referer應該是帶有HTTP或HTTPS協議頭部的。然而，在某些情況下，可能會出現沒有帶上HTTP或HTTPS協議頭部的Referer的情況。

一種常見的情況是當使用者從一個不安全的網站（即未使用HTTP加密）跳轉到一個使用HTTPS協議的網站時，瀏覽器可能會根據安全性原則（如Referrer-Policy）修改或去除Referer欄位，以保護使用者資料的安全性。這種情況下，Referer欄位只會包含網域名稱部分，不包含協議頭部。

另外，某些瀏覽器或Proxy 伺服器可能會在特定情況下自動去除Referer欄位，例如在隱私保護模式下或通過匿名代理訪問網站時。

因此，在實際應用中，需要注意處理請求中Referer欄位可能沒有帶上HTTP或HTTPS協議頭部的情況，以確保正確判斷和使用Referer資訊。如果請求中Referer欄位沒有攜帶HTTP或HTTPS協議頭部，但又想匹配命中該請求，您需要勾選忽略Scheme選項。

為什麼會出現空Referer，對於此類請求應該怎麼處理？

空Referer（也稱為Referer頭為空白）是指在HTTP請求中缺失了Referer要求標頭部的情況。請求中的Referer頭通常包含完整的URI，其中包括協議（如 http 或 https）、主機名稱，可能還包括路徑和查詢字串等。空Referer可能出現的原因：

直接存取：使用者直接通過瀏覽器地址欄輸入網址、或通過書籤訪問、或開啟一個新的空白標籤頁時，都沒有來源網頁，因此Referer頭為空白。
使用者隱私：使用者或使用者使用的軟體（比如瀏覽器延伸或隱私模式）可能出於隱私保護考慮故意去除Referer頭。
安全性通訊協定：從HTTPS頁面跳轉到HTTP頁面的時候，為了安全起見，避免敏感資訊泄露，瀏覽器通常不會發送Referer頭。
用戶端策略：一些網站或應用程式可能出於安全考慮，通過設定<meta> 標籤或者HTTP頭（如Referrer-Policy）控制Referer的發送。
跨域請求：某些跨域請求可能因瀏覽器的安全性原則而不攜帶Referer頭。

對於帶有空Referer的請求，處理方式取決於具體應用情境和安全要求。以下是一些處理建議：

預設策略：如果您的服務不需要依賴Referer資訊來作出決策，那麼可以允許帶有空Referer的請求。
允許訪問：對於特定的URL或源，您可以勾選允许通过浏览器地址栏直接访问资源URL選項，只允許來自這些來源的請求，即使Referer為空白，CDN節點都將允許使用者訪問當前的資源。