Подтвердить что ты не робот

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

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

Ответ 2

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

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

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

Хорошим ресурсом для этого типа разработки является Do и Don'ts проверки подлинности клиента в Интернете

Ответ 3

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

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

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

  • Используйте временные метки, чтобы сделать пул nonce управляемым. Храните отметку времени в зашифрованном файле cookie за №1 выше. Выбросьте любые запросы, превышающие максимальное время отклика или сеанс для приложения (например, час).

  • Храните "разумно уникальный" цифровой отпечаток машины, делающий запрос с зашифрованными данными отметки времени. Это предотвратит еще один трюк, когда злоумышленник крадет файлы cookie клиентов, чтобы выполнить захват сеанса. Это гарантирует, что запрос вернется не только один раз, но и с машины (или достаточно близкая близость, чтобы сделать практически невозможным копирование злоумышленника), на который была отправлена ​​форма.

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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();
}

Ответ 10

Если вы принимаете только один ключ один раз (скажем, сделайте ключ GUID, а затем проверьте, когда он вернется), что предотвратит повторы. Конечно, если атакующий отвечает первым, тогда у вас есть новая проблема...

Ответ 11

Являются ли это WebForms или MVC? Если это MVC, вы можете использовать токен AntiForgery. Это похоже на аналогичный подход, который вы упоминаете, за исключением того, что он использует в основном GUID и устанавливает cookie с директивным значением для этого сообщения. Подробнее об этом см. Блог Стива Сандерсона: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Другое дело, считали ли вы проверку реферера на обратной передаче? Это не пуленепробиваемый, но может помочь.

Ответ 12

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