Как предотвратить повторные атаки?

Question

Это связано с другим вопросом, который я задал . Таким образом, у меня есть особый случай URL, когда при отправке формы на него я не могу полагаться на куки для аутентификации или для поддержки сеанса пользователя, но мне как-то нужно знать, кто они, и мне нужно чтобы знать, что они вошли в систему!

Я думаю, что нашел решение своей проблемы, но оно нуждается в уточнении. Вот что я думаю. Я создаю скрытое поле формы под названием «имя пользователя» и помещаю в него имя пользователя в зашифрованном виде. Затем, когда формы POSTs, даже если я не получаю куки от браузера, я знаю, что они вошли в систему, потому что я могу расшифровать скрытое поле формы и получить имя пользователя.

Главный недостаток безопасности, который я вижу, это повторные атаки. Как я могу помешать кому-то завладеть этой зашифрованной строкой и выполнить POSTing от имени этого пользователя? Я знаю, что могу использовать SSL, чтобы усложнить кражу этой строки, и, возможно, я могу регулярно поворачивать ключ шифрования, чтобы ограничить время, в течение которого строка подходит, но мне бы очень хотелось найти пуленепробиваемую решение. У кого-нибудь есть идеи? Предотвращает ли ASP.Net ViewState воспроизведение? Если да, то как они это делают?

Редактировать : Я надеюсь на решение, которое не требует ничего, хранящегося в базе данных. Состояние приложения будет нормальным, за исключением того, что оно не выдержит перезапуска IIS или вообще не будет работать в сценарии веб-фермы или сада. Сейчас я принимаю ответ Криса, потому что я не уверен, что это возможно сделать без базы данных. Но если кто-то придет с ответом, который не касается базы данных, я приму его!

Answer 1

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

{Ts, U, HMAC ({Ts, U}, Ks)}

Где Ts - метка времени, U - имя пользователя, а Ks - секретный ключ сервера. Пользователь отправляет это обратно на сервер, и сервер проверяет его, повторно вычисляя HMAC на предоставленных значениях. Если он действителен, вы знаете, когда он был выпущен, и можете игнорировать его, если он старше, скажем, 5 минут.

Хороший ресурс для этого типа разработки - Что нужно и чего не нужно делать для аутентификации клиентов в Интернете

Answer 2

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

Answer 3

Здесь есть несколько хороших ответов, и, в конечном итоге, ответ на них лежит:

1. Блочный шифр (с AES-256 +) и хеш (с SHA-2 +) - вся информация о состоянии / nonce, отправляемая клиенту. В противном случае хакеры просто манипулируют данными, просматривают их, изучают закономерности и обходят все остальное. Помните ... требуется только одно открытое окно.

2. Создание одноразового случайного и уникального одноразового номера для каждого запроса, который отправляется обратно вместе с запросом POST. Это делает две вещи: Это гарантирует, что ответ POST идет с запросом THAT. Это также позволяет отслеживать одноразовое использование заданного набора пар get / POST (предотвращая воспроизведение).

3. Используйте метки времени, чтобы сделать пул одноразовых номеров управляемым. Сохраните отметку времени в зашифрованном файле cookie для # 1 выше. Удалите все запросы старше максимального времени ответа или сеанса для приложения (например, час).

4. Сохраните «достаточно уникальный» цифровой отпечаток машины, выполняющей запрос, с зашифрованными данными отметки времени. Это предотвратит еще один трюк, при котором злоумышленник крадет клиентские куки-файлы для выполнения перехвата сеанса. Это обеспечит отправку запроса не только один раз, но и с компьютера (или достаточно близко, чтобы злоумышленник практически не смог скопировать), на который была отправлена ​​форма.

Существуют приложения на основе фильтров безопасности ASPNET и Java / J2EE, которые выполняют все вышеперечисленное с нулевым кодированием. Управление пулом nonce для больших систем (таких как биржевая компания, банк или защищенный сайт большого объема) не является тривиальным делом, если производительность критична. Рекомендую смотреть на эти продукты, а не пытаться программировать это для каждого веб-приложения.

Answer 4

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

Answer 5

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

Answer 6

ViewState включает в себя функции безопасности. См. эту статью о некоторых встроенных функциях безопасности в ASP.NET. Он выполняет проверку по отношению к серверу machineKey в файле machine.config на сервере, что обеспечивает правильность каждой обратной передачи.

Далее в статье вы также видите, что если вы хотите сохранить значения в ваших собственных скрытых полях, вы можете использовать класс LosFormatter для кодирования значения таким же образом, как ViewState использует для шифрования.

private string EncodeText(string text) {
  StringWriter writer = new StringWriter();
  LosFormatter formatter = new LosFormatter();
  formatter.Serialize(writer, text);
  return writer.ToString();
}

Answer 7

(Атаки воспроизведения могут легко сводиться к подделке IP / MAC, плюс вам приходится сталкиваться с динамическими IP-адресами)

Это не просто повтор, который вы преследуете здесь, в изоляции это бессмысленно. Просто используйте SSL и ничего не делайте вручную.

ASP.Net ViewState - беспорядок, избегайте его. В то время как PKI является тяжеловесным и раздутым, по крайней мере, он работает без изобретения ваших собственных «схем» безопасности. Так что, если бы я мог, я бы использовал это и всегда идти на взаимную аутентичность. Аутентификация только на сервере совершенно бесполезна.

Answer 8

Я новичок в некоторых аспектах веб-программирования, но я читал об этом на днях. Я считаю, что вам нужно использовать Nonce .

Answer 9

Можете ли вы использовать память или базу данных для поддержания любой информации о пользователе или запросе вообще?

Если это так, то при запросе формы я бы включил скрытое поле формы, содержимое которого представляет собой случайное число. Сохраните этот токен в контексте приложения или в каком-либо хранилище (база данных, плоский файл и т. Д.) При обработке запроса. Когда форма отправлена, проверьте контекст приложения или базу данных, чтобы увидеть, является ли это случайно сгенерированное число действительным (однако вы определяете допустимое - возможно, оно может истечь через X минут). Если это так, удалите этот токен из списка «разрешенных токенов».

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

Answer 10

Использовать https ... встроенная защита воспроизведения.