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

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

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

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

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

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

Спасибо в усовершенствованном.

27
задан Joseph 24 October 2019 в 11:41
поделиться

6 ответов

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

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

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

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

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

26
ответ дан 28 November 2019 в 05:21
поделиться

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

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

3
ответ дан 18 July 2019 в 19:44
поделиться

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

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

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

<httpCookies httpOnlyCookies="true"/>

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

2
ответ дан 28 November 2019 в 05:21
поделиться

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

1
ответ дан 28 November 2019 в 05:21
поделиться

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

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

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

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

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

FormsAuthentication.SetAuthCookie("UserName", false);

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

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

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

1
ответ дан 28 November 2019 в 05:21
поделиться

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

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

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

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

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

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

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

13
ответ дан 28 November 2019 в 05:21
поделиться
Другие вопросы по тегам:

Похожие вопросы: