Как предотвратить повторные атаки? - PullRequest
16 голосов
/ 04 сентября 2008

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

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

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

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

Ответы [ 12 ]

13 голосов
/ 15 сентября 2008

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

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

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

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

13 голосов
/ 15 сентября 2008

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

11 голосов
/ 18 сентября 2012

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

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

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

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

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

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

4 голосов
/ 04 сентября 2008

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

2 голосов
/ 17 марта 2009

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

1 голос
/ 19 января 2010

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();
}
1 голос
/ 17 марта 2009

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

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

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

1 голос
/ 04 сентября 2008

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

1 голос
/ 04 сентября 2008

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

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

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

0 голосов
/ 27 февраля 2017

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...