Сделать HTTP-запрос невоспроизводимым

У меня есть приложение, которое работает, например, на Google TV или Apple TV, которое отправляет HTTP-запросы на мою службу.

Теперь, если кто-то прослушивает этот запрос, он может воспроизвести его и таким образом выполнить атаку «Отказ в обслуживании» (DOS) в нашей службе.

Есть ли способ сделать каждый запрос уникальным, чтобы его нельзя было воспроизвести?

Я думал о том, чтобы отправить время, зашифрованное в запросе, и проверить разницу между временем сервера и временем отправки запроса, но я получаю слишком большие разницы во времени для сравнения.

Кто-нибудь имеет лучшую идею?

0
nl ja de
То, о чем вы говорите, это атака MITM. Используйте HTTPS, и это будет сделано настолько сложно, насколько это практически невозможно.
добавлено автор DaveRandom, источник
Хорошо, что обычным решением для этого было бы заставить сервер генерировать одноразовый ключ использования, который клиент может использовать, чтобы клиент затем отправил обратно на сервер, например. печенье. После того, как этот ключ используется, любые дальнейшие запросы, которые представляют этот ключ, будут отклонены. Именно то, как это реализовано, зависит от вашей архитектуры, но в сущности то, что вы смотрите, является вариацией темы аутентификации cookie.
добавлено автор DaveRandom, источник
Я бы не стал описывать это как атаку MITM (для меня это означает, что кто-то модифицирует существующий поток данных), это атака повтора. Существует множество способов защиты, использование cookie имеет дополнительные накладные расходы (и осложнения) по сравнению с отправкой одного токена использования через POST или GET
добавлено автор symcbean, источник
@Dave устройства, которые мы используем, не поддерживают https, поэтому мы должны найти другое решение, любые советы?
добавлено автор Johnny Zghaib, источник

1 ответы

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

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

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

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

1
добавлено
Спасибо Audrius, что именно то, что мне нужно, отлично работало.
добавлено автор Johnny Zghaib, источник
Кибербезопасность АСУ ТП: RUSCADASEC Community
Кибербезопасность АСУ ТП: RUSCADASEC Community
1 389 участник(ов)

Группа открытого независимого сообщества специалистов по кибербезопасности АСУ ТП / RUSCADASEC для интерактивного обмена информацией по теме Подробнее: www.ruscadasec.ru Наш канал для основных новостей и материалов @RUSCADASECnews

secinfosec
secinfosec
697 участник(ов)

Эта группа про информационную безопасность. Целевая аудитория: пентестеры, ресерчеры, ибшники всех мастей. Реклама, криминал, политика и прочая чушь карается родовыми проклятьями. Митапы: https://www.youtube.com/channel/UCagEjp1FmxY9gsVxi6_d4SQ

Linux Security
Linux Security
652 участник(ов)

Данная группа принципиально про безопасность и в частности про безопасность Linux. Прочие темы просим обсуждать в профильных чатах.

Chat Security / ИБач чат
Chat Security / ИБач чат
601 участник(ов)

Чат канала @ibach Обсуждение всего, что касается информационной безопасности Правила: https://t.me/chat_security/65