Я знаю, что это URL-адрес защищенного токена, возможно, есть другое имя.Но я думаю, что вы все это знаете.
Это метод, который в основном применяется, если вы хотите ограничить доставку контента определенному клиенту, если вы заранее передали определенный URL.
Вы беретесекретный токен, скомпонуйте его с ресурсом, который вы хотите защитить, и, когда клиент запрашивает этот URL на одном из ваших серверов, хэш восстанавливается из информации, полученной из запроса, и сравнивается хэш.Если все то же самое, контент доставляется, иначе пользователь будет перенаправлен на ваш веб-сайт или что-то еще.
Вы также можете указать временную метку в значении, чтобы указать время для перехода по URL, или включитьПользователи IP-адреса, чтобы ограничить доставку его соединения.
Этот метод используется Amazon (S3 и Cloudfront), Level 3 CDN, Rapidshare и многие другие.Это также базовая часть http-дайджест-аутентификации, хотя там и сделан еще один шаг с аннулированием ссылок и другими вещами.
Вот ссылка на Документы Amazon , если вы хотите знать,подробнее.
Теперь меня беспокоит этот метод: если один человек взломает один токен ваших ссылок, злоумышленник получит ваш токен в виде обычного текста и сам может подписать любой URL на ваше имя.
Или, что еще хуже, в случае amazon, обращайтесь к вашим службам в административной области.
Конечно, хэшированная строка здесь обычно довольно длинная.И вы можете включить много вещей или даже заставить данные иметь минимальную длину, добавив некоторые ненужные данные в запрос.Добавьте в псевдопеременную некоторую псевдопеременную, которая не используется, и заполните ее случайными данными.
Поэтому атаки методом "грубой силы" с целью взломать sha1 / md5 или любой другой используемый вами хэш довольно сложны.Но протокол открыт, поэтому вам нужно только заполнить пробел, где находится секретный токен, и заполнить остальные данными, известными из запроса.И сегодня аппаратное обеспечение потрясающе и может рассчитывать md5s со скоростью, кратной десяткам мегабайт в секунду.Такого рода атака может распространяться на вычислительное облако, и вы не ограничены чем-то вроде «10 попыток в минуту сервером входа в систему или около того», что делает подходы хеширования обычно довольно безопасными.А теперь с amazon EC2 вы даже можете арендовать оборудование на короткое время (бить их своим оружием, ха-ха!)
Так что вы думаете?У меня есть основания для беспокойства или у меня паранойя?
Однако,
В настоящее время я проектирую облако хранилища объектов для особых нужд (интегрированное медиакодирование и специальные методы доставки, такие как потоковая передача и т. Д.).).
Теперь на level3 введен альтернативный подход к защите URL-адресов токенов.В настоящее время это бета-версия и открыта только для клиентов, которые специально запрашивают ее.Они называют это «Проверка подлинности прокси».
В результате сервер доставки контента отправляет запрос HEAD серверу, указанному в ваших настройках (клиента), и имитирует запрос пользователя.Таким образом, передается тот же GET-путь и IP-адрес (как в x_forwarder).Вы отвечаете HTTP-кодом состояния, который говорит серверу, что нужно идти навстречу с доставкой контента или нет.
Вы также можете ввести в этот процесс некоторый безопасный токен, а также можете наложить на него больше ограничений.Например, пусть URL запрашивается только 10 раз или около того.
Очевидно, что это связано с большими накладными расходами, поскольку выполняются дополнительные запросы и вычисления, но я думаю, что это разумно, и я не вижу никаких предостережений с ним.А ты?