← Документация WAF / custom-rules / use-cases

Настройка аутентификации по токену

Аутентификация по токену позволяет ограничить доступ к документам, файлам и медиафайлам, предоставив его только выбранным пользователям без необходимости регистрации. Это помогает защитить платный или закрытый контент от воровства трафика и несанкционированного распространения.

Существует два варианта настройки аутентификации по токену: через Cloudflare Workers или через пользовательские правила.

См. следующие материалы Cloudflare Workers о двух разных вариантах реализации аутентификации по токену:

• Подпись запросов пример.
• Аутентификация с помощью заголовков шаблон.

Чтобы начать работу с Workers, см. Шаблоны.

Используйте язык Rules is_timed_hmac_valid_v0() Функция проверки HMAC для проверки токенов кода аутентификации сообщений на основе хеша (HMAC) в выражении пользовательского правила.

Чтобы проверить аутентификацию по токену, создать пользовательское правило с вызовом is_timed_hmac_valid_v0() функцию в выражении правила. Можно использовать такое действие, как Block.

В этом примере показано правило, которое блокирует любого посетителя, не прошедшего проверку HMAC-ключа для указанного имени хоста и пути URL. Для аутентификации по токену требуются следующие данные:

• Секретный ключ для генерации и проверки HMAC (например, mysecrettoken)
• Путь, который нужно аутентифицировать (например, downloads.example.com/images/cat.jpg)
• Имя параметра строки запроса, содержащего токен (например, verify)
• Время жизни токена в секундах (например, 3 часа = 10,800 секунд)

Рассмотрим следующий пример URL-адреса:

downloads.example.com/images/cat.jpg?verify=1484063787-9JQB8vP1z0yc5DEBnH6JGWM3mBmvIeMrnnxFi3WtJLE%3D

Где:

• /images/cat.jpg обозначает путь к ресурсу: сообщение HMAC для аутентификации.
• ?verify= является разделителем между путём к ресурсу и меткой времени выдачи HMAC-токена.
• 1484063787 обозначает метку времени выпуска токена в формате UNIX-времени в секундах.
• 9JQB8vP1z0yc5DEBnH6JGWM3mBmvIeMrnnxFi3WtJLE%3D представляет собой MAC-код в кодировке Base64.

Выражение для пользовательского правила будет похоже на следующее:

(http.host eq "downloads.example.com" and not is_timed_hmac_valid_v0("mysecrettoken", http.request.uri, 10800, http.request.timestamp.sec, 8))

Компоненты этого примера пользовательского правила (с использованием указанного выше примера URL) включают:

• Секретный ключ токена = mysecrettoken
• Время жизни токена = 10800 (10,800 секунд = 3 часа)
• http.request.uri = /images/cat.jpg?verify=1484063787-9JQB8vP1z0yc5DEBnH6JGWM3mBmvIeMrnnxFi3WtJLE%3D
• http.request.timestamp.sec = 1484071925 (например)
• Длина разделителя: len("?verify=") = 8

is_timed_hmac_valid_v0() функция сравнивает значение MAC, сформированное с помощью mysecrettoken секретный ключ на значение, закодированное в http.request.uri.

Если значения MAC совпадают и срок действия токена ещё не истёк, согласно следующей формуле:

http.request.timestamp.sec < (<TIMESTAMP_ISSUED> + 10800)

Тогда токен считается действительным, и is_timed_hmac_valid_v0() возвращает true.

Следующие примеры показывают, как можно генерировать токены на исходном сервере для пути, проверенного с помощью пользовательского правила, описанного в предыдущем разделе:

import hmac
import base64
import time
import urllib.parse
from hashlib import sha256

message = "/images/cat.jpg"
secret = "mysecrettoken"
separator = "verify"
timestamp = str(int(time.time()))
digest = hmac.new((secret).encode('utf8'), "{}{}".format(message, timestamp).encode('utf8'), sha256)
token = urllib.parse.quote_plus(base64.b64encode(digest.digest()))
print("{}={}-{}".format(separator, timestamp, token))

import hmac
import base64
import time
import urllib
from hashlib import sha256

message = "/images/cat.jpg"
secret = "mysecrettoken"
separator = "verify"
timestamp = str(int(time.time()))
digest = hmac.new(secret, message + timestamp, sha256)
param = urllib.urlencode({separator: '%s-%s' % (timestamp, base64.b64encode(digest.digest()))})
print(param)

<?php
$message = "/images/cat.jpg";
$secret = "mysecrettoken";
$separator = "verify";
$timestamp = time();
$token = urlencode(base64_encode(hash_hmac("sha256", $message . $timestamp, $secret, true)));
echo("{$separator}={$timestamp}-{$token}");

Это создаст параметр URL, например следующий:

verify=1484063787-9JQB8vP1z0yc5DEBnH6JGWM3mBmvIeMrnnxFi3WtJLE%3D

К защищаемому URL потребуется добавить этот параметр:

/images/cat.jpg?verify=1484063787-9JQB8vP1z0yc5DEBnH6JGWM3mBmvIeMrnnxFi3WtJLE%3D

Если у вас тарифный план Enterprise, вы можете проверить, правильно ли формируются URL-адреса на исходном сервере, выполнив следующее:

1. Задайте действие пользовательского правила Log.
2. Проверьте журналы выборки в Security Events.

Один и тот же секретный ключ можно использовать для защиты нескольких путей URI.

Это показано в предыдущем примере, где http.request.uri передаётся в качестве MessageMAC аргумент функции валидации.

С http.request.uri включает путь к ресурсу и это значение извлекается для каждого запроса, функция проверки сопоставляет все URI запросов с downloads.example.com с использованием того же секретного ключа.

Учтите, что, хотя для аутентификации нескольких путей можно использовать один и тот же секретный ключ, для каждого уникального сообщения, которое требуется аутентифицировать, необходимо сгенерировать отдельный токен HMAC.

Весь префикс пути URI фиксированной длины можно защитить одной подписью HMAC (при этом также будет использоваться один и тот же секрет). Для этого укажите префикс пути URI (вместо полного пути URI) и исходную строку запроса в качестве MessageMAC аргумент для is_timed_hmac_valid_v0() функцию.

Используйте substring() функцию, чтобы получить префикс из полного пути URI.

В следующем примере префикс пути URI, для которого требуется одна подпись HMAC, всегда имеет длину 51 символ (x является символом-заполнителем):

/case-studies/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/

В этом случае для каждого отдельного префикса пути URI длиной 51 символ потребуется своя подпись HMAC.

Если вы хотите блокировать запросы к файлам из этого примера, не прошедшим проверку HMAC, вы можете создать пользовательское правило, подобное следующему:

  (http.host eq "downloads.example.com" and starts_with(http.request.uri.path, "/case-studies") and not is_timed_hmac_valid_v0("mysecrettoken", concat(substring(http.request.uri.path, 0, 51), "?", http.request.uri.query), 10800, http.request.timestamp.sec, 1))

Примеры URI-путей допустимых входящих запросов:

/case-studies/12345678-90ab-4cde-f012-3456789abcde/foobar-report.pdf?1755877101-5WOroVcDINdl2%2BQZxZFHJcJ6l%2Fep4HGIrX3DtSXzWO0%3D
/case-studies/12345678-90ab-4cde-f012-3456789abcde/acme-corp.pdf?1755877101-5WOroVcDINdl2%2BQZxZFHJcJ6l%2Fep4HGIrX3DtSXzWO0%3D
/case-studies/768bf477-22d5-4545-857d-b155510119ff/another-company-report.pdf?1755878057-jeMS5S1F3MIgxvL61UmiX4vODiWtuLfcPV6q%2B0Y3Rig%3D

Первые два пути URI могут использовать одну и ту же подпись HMAC, поскольку у них общий префикс длиной 51 символ (/case-studies/12345678-90ab-4cde-f012-3456789abcde/) которое проверяется пользовательским правилом.

Третий путь URI требует другой подписи HMAC, так как префикс отличается.