как уменьшить риски безопасности сессии asp.net - PullRequest
2 голосов
/ 22 декабря 2010

Я понимаю, что можно захватить сеанс asp.net, украдя файл cookie сеанса asp.net.Я думаю, что я думаю о краже куки, поскольку он передается по незащищенному Wi-Fi.

Кроме использования SSL, существуют ли стандартные способы защиты этой информации?Или предотвращение угона сессии?

Ответы [ 2 ]

1 голос
/ 22 декабря 2010

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

Вы видели запись в блоге Джеффа Этвуда по этому поводу, Взлом баночки с печеньем в Интернете ?Джефф больше фокусируется на проблемах с точки зрения пользователя , но в любом случае его стоит прочитать.Вот что он говорит, что люди могут сделать сегодня:

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

  1. Мы должны быть очень осторожныкак мы просматриваем в незашифрованных беспроводных сетях.

  2. Получите привычку получать доступ к вашей веб-почте через HTTPS.

  3. Лоббировать сайты, которые вы используете, чтобы предлагать просмотр HTTPS.

Это очень широкий совет, и есть целый ряд технических предостережений длявыше.Но это отправная точка для евангелизации рисков и ответственного использования открытых беспроводных сетей.

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

0 голосов
/ 22 декабря 2010

Нет простого решения этой проблемы, кроме запроса информации об аутентификации при каждом запросе страницы (что не практично и хуже с точки зрения безопасности в незашифрованной среде).

Для того, чтобыподдерживать состояние при использовании HTTP (который не имеет состояния), необходимо использовать что-то вроде cookie.Если этот файл cookie отправляется в незашифрованном виде, он может быть использован кем-то другим.

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

...