Anti-Hotlinking

1 Feature Intro

1.1 Brief Introduction

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.

1.2 Applicable Product Lines

• Content Acceleration
• Dynamic Web Acceleration
• Media Acceleration
• Media Acceleration Live Broadcast

2 Feature Detail

CDNetworks has rolled out a series of anti-hotlinking features, including:

• Basic Anti-hotlinking:
  IP Blacklist/Whitelist Anti-Hotlinking, Cookie Anti-Hotlinking, Referrer Anti-Hotlinking, UA Header Anti-Hotlinking and Customized Header Anti-Hotlinking;
• Timestamp Anti-Hotlinking
• Back-to-Origin Authentication Anti-Hotlinking

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.

Anti-Hotlinking	Application Scenarios	Advantages
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

2.1 Basic Anti-Hotlinking

Basic Anti-hotlinking includes IP blacklist/whitelist, Cookie, Referrer, UA header and Customized Header Anti-Hotlinking.

2.1.1 Application Scenarios

1. IP Blacklist/Whitelist Anti-Hotlinking applies to situations below:
   a) When some IP addresses have abnormal access actions, such as hotlinking and attacking;
   b) When the accelerated content has access IP address restrictions, such as only allow internal employees, or forbidden IP addresses outside the enterprise to access the content;
   c) When the accelerated content has access area restrictions, such as only allow users in London, or prohibit users from other regions to access the content.
2. Cookie Anti-Hotlinking can be applied when the accelerated content only allows access from requests with a specific Cookie.
3. Referer Anti-Hotlinking can be applied when the accelerated content only allows specific page visit, such as only allow users to access the resources by clicking the link on specific pages.
4. User-Agent anti-hotlinking can be applied to the following scenarios:
   a) When the accelerated content only allows to be accessed by specific browsers;
   b) When the accelerated domain name only allows to be accessed by specific clients. For example, User-Agent anti-hotlinking can be applied when a customer has its own client, which will send requests with specific User-Agent information.
5. Customized Header Anti-Hotlinking applies to customers who need to allow access from HTTP requests with customized headers.

2.1.2 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.

2.1.3 Instructions

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;

2.1.4 Notices

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.

2.2 Timestamp Anti-Hotlinking

2.2.1 Feature Description

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.

2.2.2 Application Scenarios

It applies when anti-hotlinking effect is highly stressed and time-sensitive URL is required, such as large file downloading and video online viewing.

2.2.3 Working Process

1. The user requests a content URL;
2. The customer’s origin or content management server generates a time-sensitive content URL with an anti-hotlinking string and responds to the user according to the agreed rules. For example:
   http://CDNetworks.cdn.com/test.mp4?wsSecret=c82151660097f7c341d6df8b037e82c7&wsTime=201710111042
3. The user utilizes the acquired URL to initiate a request to the CDN PoP.
4. The CDN PoP performs timestamp anti-hotlinking verification: judges whether the URL is expired. If yes, it will reject the request; otherwise, it will calculate the MD5 value according to the agreed rules and make a comparison. The PoP will reject the request when the comparison does not match, and provide service when the comparison matches. In addition, when the CDN PoP has no cache, it will return to origin to retrieve the content.
5. The video origin responds to the CDN PoP with the content.
6. The CDN PoP responds to the user with the content and caches it locally.

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.
For example:
The original URL is “http://www.example.com/test.jpg”;
The encrypted URL with timestamp will be:
(1)“http://www.example.com/test.jpg?CWSecret=c8ba17a8ba47749755ad8754f244108b&CWTime=55d5a69c”
(2)“http://www.example.com/c8ba17a8ba47749755ad8754f244108b/55d5a69c/test.jpg”
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.

1. Customers request with the encrypted URL to our edge PoPs.
2. PoP will identify the request; if passed, PoP will get the data from the origin site
3. Origin site will return the data to the CDN PoP;
4. After receiving the data, the PoP will feedback to customers with the hash value of the coming request:
   Px-time: xx (expiration time)
   px-hash=xxx (secret key +expiration time + URI path hash)
   Then, the client will request with this value in the header: “Cookie”
5. Client requests with the cookie provided by edge PoPs. And the PoPs will provide the service directly without implementing md5 calculation if cookie info is valid, but the md5 value will be verified if the cookie info has expired.

2.2.4 Instructions

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.

• CDNetworks supports two anti-hotlinking methods. For the first method, the encrypted string and timestamp are placed after the “?”, and for the other method, the encrypted string and timestamp are placed before the “?” and after the “host”. The former method is generally recommended, but it is necessary to confirm which method the customer will adopt.
• When the encrypted string and timestamp are placed after “?”, confirm the names of parameters carrying these two values.
• When the encrypted string and timestamp are placed before the “?” and after the “host”, confirm the location of the encrypted string and timestamp.
• Confirm the format of the timestamp. The default format is Unix timestamp: for example, 1486953720 represents 2017/02/13 10:42:00; and the decimal timestamp is shown in hexadecimal: for example, 1486953720 represents 58a11cf8.
• Confirm whether the timestamp carried in the user request URL is the URL generation time or the URL expiration time. Expiration time is generally recommended.
• Confirm the key involved in MD5 encryption, and specifying multiple keys is supported. When there are multiple ciphertexts, the CDN PoP will take one of the ciphertexts for MD5 verification each time. As long as the verification succeeds, the request is considered legitimate.
• Confirm the parameters related to MD5 encryption and the sequence of combination. Combination of “URI” + “Key” + “Time” is generally recommended, and the sequence of these three can be customized.
• Confirm the back-to-origin method: confirm whether the anti-hotlinking parameters is required in the URL when the CDN PoP returns to origin. If the customer needs to perform further timestamp verification, or if some parameters after “?” are needed for statistical analysis, then the parameters are needed. Otherwise parameters are not required.

2.3 Back-to-Origin Authentication Anti-Hotlinking

2.3.1 Feature Description

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.

2.3.2 Application Scenarios

1. As BTO authentication is needed for each request, BTO Authentication Anti-Hotlinking will increase the wait time on the user side. Thus, it is applicable to scenarios such as streaming and large file downloading, and not applicable to websites which have a large number of small files to be loaded.
2. It is also applicable to the scenario where the customer has a high security requirement on Anti-Hotlinking, such as copyrights protection.

2.3.3 Working Process

2.3.3.1 Request and authenticate with different URLs

(1) End user initiates the URL1 request, for example:
http://cdn.example.com/test.dat?auth=xxxx&name1=value1&name2=value2
(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.

2.3.3.2 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.

2.3.4 Notices

1. CDNetworks needs to confirm if there are headers of Last-Modified or Etag in origin server response because they may affect the cache.
2. Customers need to develop the authentication algorithm, build and manage an authentication platform.