Может ли какой-то хакер украсть файл cookie у пользователя и войти с этим именем на веб-сайт?

Ответ 1

Можно ли украсть файл cookie и аутентифицироваться как администратор?

Да, возможно, если файл cookie Forms Auth не зашифрован, кто-то может взломать их файл cookie, чтобы предоставить им повышенные привилегии или если SSL не требуется, скопируйте кого-то другого cookie человека. Тем не менее, вы можете предпринять шаги для снижения этих рисков:

В элементе system.web/authentication/forms:

• RequireSSL = верно. Это требует, чтобы файл cookie передавался только через SSL
• slidingExpiration = ложь. Когда это правда, истекший билет может быть реактивирован.
• Cookieless = ложь. Не используйте cookieless сеансы в среде, где вы пытаетесь обеспечить безопасность.
• enableCrossAppRedirects = ложь. Когда false, обработка файлов cookie через приложения не разрешена.
• Защита = все. Шифрует и хеширует файл cookie форм с помощью машинного ключа, указанного в файле machine.config или web.config. Эта функция помешает кому-то взломать свой собственный файл cookie, так как этот параметр сообщает системе генерировать подпись файла cookie и каждого запроса на аутентификацию, сравнивать подпись с переданным cookie.

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

Ответ 2

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

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

Чтобы в дополнение к httpOnlyCookies вам нужно указать requireSSL="true"

<httpCookies httpOnlyCookies="true" requireSSL="true" />

Я не согласен с комментарием в Rook, потому что я считаю это несправедливым;

@Aristos я обновил свой ответ. Но если честно, если вы используете платформу разработки Microsoft, ваше приложение будет по своей сути небезопасным. - Ладья 22 мин назад

Безопасность не происходит случайно, и это не происходит "прямо из коробки", по крайней мере, не в моем опыте. Ничто не защищено, пока оно не будет таким, независимо от платформы или инструментов.

Ответ 3

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

http://en.wikipedia.org/wiki/Cross-site_request_forgery

Ответ 4

Существует много способов, которыми идентификатор сеанса может быть пропущен злоумышленнику. XSS является наиболее часто используемой атакой для захвата идентификатора сеанса, и вы должны проверить уязвимости XSS в своем приложении., Общим методом повышения прочности сеанса является проверка IP-адреса. Когда пользователь входит в систему, запишите IP-адрес. Проверьте IP-адрес для каждого запроса, если IP-адрес изменит его, вероятно, на захваченный сеанс. Эта мера secuirty может предотвратить законные запросы, но это очень маловероятно.

Сделайте не проверку X-Forwarded-For или User-Agent, тривиальным для злоумышленника для изменения этих значений.

Я также рекомендую включить httpOnlyCookies в файле web.config:

<httpCookies httpOnlyCookies="true"/>

Это затрудняет атакующему захват сеанса с помощью javascript, но его все еще возможно.

Ответ 5

Я не знаю специфики рассматриваемого файла cookie, но, как правило, это неправильная практика хранения как имени пользователя, так и пароля в пользовательском cookie. Обычно вы хотите сохранить имя пользователя в файле cookie вместе с другой нечувствительной информацией. Таким образом, пользователю будет предложено предоставить свой пароль только при входе в систему.

Ответ 6

Я работаю над этим, и я придумываю идею, что я не уверен, что он на 100% безопасен, но есть идея.

Моя идея состоит в том, что каждый пользователь должен перейти со страницы входа.
Если кто-то украл файл cookie, он не прошел страницу входа в систему, а отправился прямо на остальные страницы. Он не может пройти страницу входа, потому что не знал действительно пароль, поэтому, если он он все равно терпит неудачу.

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

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

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

FormsAuthentication.SetAuthCookie("UserName", false);

Моя вторая безопасность, что у меня есть все готовое исправление и использование, заключается в том, что я проверяю наличие разных ips и/или разных файлов cookie у одного и того же зарегистрированного пользователя. Я много думал о том, что многие проверки (если есть за прокси, если они из разных стран, что искать, сколько раз я вижу его и т.д.), Но это общая идея.

Это видео точно показывает, что я пытаюсь предотвратить. Используя трюк, который я описал здесь, вы не можете просто установить только cookie для входа.

Просто поделитесь своими идеями...