Last update：2022-04-11 12:56:29
Hotlinking will not only infringe copyright, but also cause user erosion. It decreases the overall profit and increases bandwidth cost and server maintenance cost of our customers. Thus, hotlinking is an issue that needs to be addressed urgently for the market.
The anti-hotlinking feature rolled out by CDNetworks will recognize hotlinking requests with a certain rule and reject to provide service for these requests, preventing hotlinking and saving bandwidth and server operating cost for CDNetworks customers.
CDNetworks has rolled out a series of anti-hotlinking features, including:
|Anti-Hotlinking Feature||Feature Description|
|IP blacklist/whitelist Anti-hotlinking||To recognize the IP addresses of requests, only the matched IP addresses are allowed to access the service.|
|Cookie Anti-hotlinking||To recognize the value of Cookie header in HTTP requests, only HTTP requests with the matched Cookie header are allowed to access the service.|
|Referrer Anti-hotlinking||To recognize the value of referrer header in HTTP requests, only HTTP requests with the matched referrer header are allowed to access the service.|
|UA Header Anti-hotlinking||To recognize the value of User-Agent header in HTTP requests, only HTTP requests with the matched User-Agent header are allowed to access the service.|
|Customized Header Anti-hotlinking||To recognize other customized headers in HTTP requests as per customer requirement, only requests with the matched header are allowed to access the service.|
|Timestamp Anti-hotlinking||Encrypt URL with the timestamp and secret key negotiated with customers, and verify if the request time is valid.|
|Back-to-origin Authentication Anti-Hotlinking||Go back to origin to authenticate the information of each received quest, and comply with the authentication rules of origin servers.|
Customers can choose different Anti-Hotlinking features based on their own business types, and the comparison below will help.
|Basic Anti-Hotlinking||Allow or disallow requests from designated IP addresses/ webpages/ browsers/players, and requests with designated cookies||Easy implementation|
|Timestamp Anti-Hotlinking||Allow requests that have not expired||Good anti-hotlinking effect; Reject all requests that are expired|
|BtO Authentication||Anti-Hotlinking BtO authentication is required for each request; Applicable to global authentication scenarios||Good anti-hotlinking effect; Generate auth result on the basis of global (national/global) data analysis; Flexible scheme, can be defined freely; Authentication can be made based on information such as user account|
Basic Anti-hotlinking includes IP blacklist/whitelist, Cookie, Referrer, UA header and Customized Header Anti-Hotlinking.
Figure 1 Basic Anti-Hotlinking Working Process
(1) User sends a request to CDN PoPs;
(2) CDN PoP judges if the user information (such as IP, referrer, User-Agent and Cookie) meets the configuration requirements. Reject if it does not meet; otherwise, respond directly if there is cache locally. And fetch the corresponding resource from origin if there is no cache.
(3) Origin responds to the CDN PoP request.
(4) CDN PoP responds to the client request and cache the resource locally.
The feature of Basic Anti-Hotlinking can be configured through the following methods:
(1) Customers can self-configure the feature on the SI platform;
(2) The corresponding CSE can also configure the feature;
For the IP blacklist, CDNetworks support intelligent list which can prevent CC attack by restricting the access times of IP addresses in edge PoPs. After enabling this feature, CDNetworks cloud platform will mark the access times of IP addresses to restrict access, and intercept the access of an IP address when requests from the IP address to a domain name exceed the set threshold. The number of request interception times can be configured.
With the timestamp anti-hotlinking feature enabled, customers can control the time limitation of file access by setting a signature expiration time.
Timestamp anti-hotlinking is to give each request URL a “timeliness” of a certain amount of time. Through calculating the ciphertext, expiration time, file path and other information with the md5 algorithm on the CDN platform, CDNetworks can provide a unique value for all request URLs. By adding this value into the URL, CDN PoP can verify the request and identify if the request is legal. If a request does not have a matching md5 value, service will be denied. As ciphertext is private, it cannot be forged.
Here is how timestamp anti-hotlinking works:
A common verification method is to use the MD5 encryption algorithm: reach an agreement on the key and encryption rule with the customer; combine the specified parameters based on the rule and calculate the MD5 value, and add the calculated MD5 value into the URL. Since the ciphertext is confidential, the URL cannot be spoofed. When the URL with the timestamp and the MD5 encrypted string accesses the CDN PoP, the CDN PoP first judges whether the timestamp has expired. If yes, directly reject the request; otherwise, verify the MD5 encrypted string based on the algorithm agreed. The CDN PoP will consider the request as legitimate and provide service when the verification matches. Otherwise, the CDN PoP will consider the URL as spoofed, and the request as illegitimate, and refuse to provide service.
As shown in the following figure, a common encryption rule is to combine the key which has been agreed on with the customer, the timestamp carried by the URL, and the file path of the URL according to certain rules, and then calculate the corresponding MD5 value.
Figure 2 Timestamp Anti-hotlinking Principle
It applies when anti-hotlinking effect is highly stressed and time-sensitive URL is required, such as large file downloading and video online viewing.
Figure 3 Timestamp Anti-hotlinking Working Process
CDNetworks provides several timestamp types based on different situations of customers.
1) When the customer has an application
When a customer has an application, such as live broadcast or download customers, the terminal/application will calculate the value if we have negotiated with the customer. If a request does not have a matching md5 value, service will not be provided. As ciphertext is private, it cannot be forged. The URL encryption in timestamp anti-hotlinking is generated by the origin, and CDN only does verification.
The original URL is “http://www.example.com/test.jpg”;
The encrypted URL with timestamp will be:
Description of the parameters inside this URL:
CWSecret is a secret string.
CWSecret = md5 (URI + CWKey + CWTime)
URI = end user accessing URL’s path section – URI.
CWKey = Secret Key negotiated with customer.
CWTime = time stamp value in request URL, use UNIX time in hex format, in this example, 55d5a69c means 2015/8/20 18:6:20 GMT+8.
2) When the customer does not have an application
This is always used by customers without terminals.
Under this situation, the client will request the content first, and the origin site will provide the URL with the encrypted URL, and then the users can process the request.
3) When the customer has a content management system:
This is always used for the Media Acceleration customers who have the “content management server”.
Under this situation, the user will request the content URL, and the content management server will provide the URL with the encrypted URL, and then the users can process the request.
4) UTV (URL tag verification) Timestamp Anti-hotlinking is supported to improve verification efficiency
CDNetworks also supports the method of UTV timestamp anti-hotlinking, which reduces md5 value calculation verification times for application terminals of their 2nd and subsequent requests. The details are shown in the figure below.
Figure 4 Fundamental of UTV Timestamp Anti-hotlinking
CDNetworks CSE needs to confirm below information with the customer, before initiating a ticket on the PMS platform to the Operation and Maintenance team for configuration implementation.
CDN PoPs will conduct BtO authentication of relevant request information when receiving the request and decide whether or not to provide service based on the authentication result.
The characteristic of BTO Authentication Anti-Hotlinking is that the CDN PoP transfers each request to the authentication server of our customers first, then decides whether to provide service based on the authentication result. It is applicable to scenarios when the customer has a high requirement on anti-hotlinking. The authentication server and the content server of most customers are mutually independent.
Depends on customer’s architecture, we have 2 types of back to origin methods available for customers to choose: “Request and authenticate with same URL” and “Request and Authenticate with Different URLs”. Please refer to the section of Working Process for more details.
Figure 5 Request and Authenticate with Different URLs
(1) End user initiates the URL1 request, for example:
(2) CDN PoP extracts authentication parameter auth=xxx, rewrites and splices into authentication URL2, and sends authentication request to customer auth server, for example: http://auth.example.com/authorize?auth=xxxx
(3) Auth server will authenticate the legality of parameter auth=xxx and respond the result.
(4) If the auth succeeds, but CDN PoP does not cache the content requested, CDN PoP will fetch the content from origin. Request URL3: for example: http://cdn.example.com/test.dat? name1=value1&name2=value2
(4’) If authentication succeeds, and CDN PoP has cached content, directly respond it to user.
(4”) If authentication fails, CDN PoP will respond 403 Forbidden or 302 Redirect (redirect URL needs to be designated by customer) based on the policy configured by customer.
(5) Origin responds to CDN PoP with the content.
(6) CDN PoP will respond to end user with the content, and cache it locally.
Figure 6 Request and Authenticate with the Same URL
(1) End user initiates a URL request.
(2) CDN PoP conducts the transparent transmission BtO of the request.
(3) Origin authenticates request. If the request is legal and there is no update in file, origin responds 304 Not Modified, and if file has updated, respond 200 or 206 (if there exists range request). When request is illegal, respond error status code (403 by default, can be customized) or 302 redirect (the redirecting URL needs to be negotiated with the customer)
(4) CDN PoP responds file or CDN PoP rejects to respond (403) or respond 302 redirect to the designated page.