ю, что это URL-адрес защищенного токена, возможно, есть другое имя. Но я думаю, что вы все это знаете.

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

Вы берете секретный токен, объединяете его с ресурсом, который хотите защитить, и у него есть, и когда клиент запрашивает этот URL на одном из ваших серверов, хэш восстанавливается из информации, полученной из запроса, и сравнивается хэш , Если это то же самое, контент доставляется, иначе пользователь будет перенаправлен на ваш веб-сайт или что-то еще.

Вы также можете ввести временную метку в поле «Время жизни» по URL-адресу или включить IP-адрес пользователя, чтобы ограничить доставку его соединением.

Эта техника используется Amazon (S3 и Cloudfront), CDN уровня 3, Rapidshare и многими другими. Это также основная часть http-аутентификации дайджеста, хотя там и сделан шаг вперед с аннулированием ссылок и другими вещами.

Вот ссылка наAmazon документы если вы хотите узнать больше.

Теперь я обеспокоен этим методом: если один человек взломает один токен ваших ссылок, злоумышленник получит ваш простой текстовый токен и сам может подписать любой URL на ваше имя.

Или, что еще хуже, в случае amazon, доступ к вашим услугам в административных целях.

Конечно, здесь хэшированная строка обычно довольно длинная. И вы можете включить много вещей или даже заставить данные иметь минимальную длину, добавив некоторые ненужные данные в запрос. Maby некоторая псевдо-переменная в URL, который не используется, и заполнить его случайными данными.

Поэтому атаки методом грубой силы для взлома sha1 / md5 или любого другого хеша довольно сложны. Но протокол открыт, поэтому вам нужно только заполнить пробел, где находится секретный токен, и заполнить остальные данными, известными из запроса. И сегодня аппаратное обеспечение потрясающе и может рассчитывать md5s со скоростью, кратной десяткам мегабайт в секунду. Такого рода атака может распространяться на вычислительное облако, и вы не ограничены чем-то вроде «10 попыток в минуту сервером входа в систему или около того», что делает подходы хеширования обычно довольно безопасными. И теперь с Amazon EC2 вы даже можете арендовать оборудование на короткое время (бить их своим оружием, ха-ха!)

Так что ты думаешь? У моих опасений есть основания, или я параноик?

Тем не мение,

В настоящее время я разрабатываю облако объектного хранилища для особых нужд (интегрированное медиакодирование и специальные методы доставки, такие как потоковая передача и т. Д.)

Теперь level3 представил альтернативный подход для защиты URL токенов. В настоящее время это бета-версия и открыта только для клиентов, которые специально запрашивают ее. Они называют это «Проверка подлинности прокси».

В результате сервер доставки контента отправляет запрос HEAD серверу, указанному в ваших настройках (клиента), и имитирует запрос пользователя. Таким образом, передается тот же GET-путь и IP-адрес (как в x_forwarder). Вы отвечаете с помощью HTTP-кода состояния, который указывает серверу идти вперед с доставкой контента или нет.

Вы также можете внедрить в него некоторый процесс безопасного токена, а также можете наложить на него больше ограничений. Например, пусть URL запрашивается только 10 раз или около того.

Очевидно, что это связано с большими накладными расходами, потому что выполняются дополнительные запросы и вычисления, но я думаю, что это разумно, и я не вижу никаких предостережений с ним. Вы?