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

Question

Чтение этого вопроса

разные пользователи получают одинаковое значение cookie в aspxanonymous

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

Знаете ли вы, как проверка подлинности с помощью формы может гарантировать, что даже если файл cookie будет украден, хакер не сможет войти в систему, используя его?

Или вы знаете какой-нибудь другой механизм автоматической защиты?

Спасибо заранее.

Answer 1

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

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

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

1. requireSSL = true.Для этого необходимо, чтобы куки передавались только по SSL
2. slideExpiration = false.Если это правда, просроченный билет может быть повторно активирован.
3. cookieless = false.Не используйте сеансы без файлов cookie в среде, в которой вы пытаетесь обеспечить безопасность.
4. enableCrossAppRedirects = false.При значении false обработка файлов cookie в разных приложениях запрещена.
5. protection = all.Зашифровывает и хэширует файл cookie проверки подлинности с помощью ключа компьютера, указанного в machine.config или web.config.Эта функция не позволит кому-либо взломать свой собственный файл cookie, так как этот параметр указывает системе генерировать подпись файла cookie и при каждом запросе аутентификации сравнивать подпись с переданным файлом cookie.

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

Answer 2

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

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

Именно поэтому в дополнение к httpOnlyCookies вы захотите указать requireSSL="true"

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

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

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

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

Answer 3

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

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

Answer 4

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

Не не проверьте X-Forwarded-For или User-Agent, это тривиально для атакующего, чтобы изменить эти значения.

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

<httpCookies httpOnlyCookies="true"/>

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

Answer 5

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

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

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

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

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

FormsAuthentication.SetAuthCookie("UserName", false);

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

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

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

Answer 6

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