Некоторый хакер может украсть cookie веб-браузера от пользователя и войти в систему с тем именем на веб-сайте?
Чтение этого вопроса
различные пользователи получают то же значение cookie в aspxanonymous
и ищите решение, я начинаю думать, если для кого-то возможно действительно украсть cookie с некоторым путем и затем поместить его в его браузер, и вход в систему позволяет, говорят как администратор.
Вы знаете, как аутентификация формы может гарантировать, что, даже если cookie украден, хакер не добирается для использования его в фактическом входе в систему?
Есть ли какой-либо другой альтернативный автоматический защитный механизм?
Спасибо в усовершенствованном.
6 ответов
Можно ли украсть файл cookie и пройти аутентификацию в качестве администратора?
Да, возможно, если файл cookie аутентификации форм не зашифрован, кто-то может взломать их cookie, чтобы предоставить им повышенные привилегии, или, если SSL не требуется, скопировать чужой cookie. Однако есть шаги, которые можно предпринять для снижения этих рисков:
В элементе system.web / authentication / forms:
- requireSSL = true. Для этого необходимо, чтобы cookie передавался только через SSL
- slideExpiration = false. Когда истина, билет с истекшим сроком действия можно повторно активировать.
- cookieless = ложь. Не используйте сеансы без файлов cookie в среде, где вы пытаетесь обеспечить безопасность.
- enableCrossAppRedirects = false. Если установлено значение false, обработка файлов cookie в приложениях запрещена.
- защита = все. Шифрует и хэширует файл cookie Forms Auth, используя машинный ключ, указанный в machine.config или web.config.Эта функция помешает кому-либо взломать свой собственный файл cookie, поскольку этот параметр указывает системе генерировать подпись файла cookie и при каждом запросе аутентификации сравнивать подпись с переданным файлом cookie.
При желании вы можете добавить небольшую защиту, поместив в сеанс какой-либо аутентификационной информации, такой как хэш имени пользователя (никогда не вводите имя пользователя в виде обычного текста или его пароль). Это потребует от злоумышленника кражи как файла cookie сеанса, так и файла cookie Forms Auth.
Во многих случаях файлы cookie, используемые для аутентификации, совпадают с сеансом на сервере, поэтому невозможно просто взять cookie и «войти в систему», однако , вы можете прочитать о подделках межсайтовых запросов, которые позволяют злонамеренно использовать механизм для этого файла cookie:
Существует множество способов передачи идентификатора сеанса злоумышленнику. XSS - это наиболее часто используемая атака для перехвата идентификатора сеанса, и вам следует проверить наличие XSS-уязвимостей в вашем приложении. . Распространенный метод повышения мощности сеанса - проверка IP-адреса. Когда пользователь входит в систему, запишите IP-адрес. Проверяйте IP-адрес для каждого запроса, если IP-адрес изменяется, вероятно, сеанс был захвачен. Эта мера безопасности может предотвратить легитимные запросы, но это очень маловероятно.
Не не проверяйте X-Forwarded-For или User-Agent, это тривиально для злоумышленника, чтобы изменить эти значения.
Я также рекомендую включить httpOnlyCookies в вашем Интернете.config file:
<httpCookies httpOnlyCookies="true"/>
Это затрудняет злоумышленнику захват сеанса с помощью javascript, но это все еще возможно.
Я не знаю специфики рассматриваемого файла cookie, но, как правило, хранить в файле cookie пользователя и имя пользователя, и пароль - плохая практика. Обычно вы хотите хранить в файле cookie только имя пользователя вместе с другой не конфиденциальной информацией. Таким образом, пользователю предлагается ввести свой пароль только при входе в систему.
Я работаю над этим, и у меня появилась идея, я не уверен, что она на 100% безопасна, но это идея.
Моя идея заключается в том, что каждый пользователь должен пройти со страницы входа в систему.
Если кто-то украл cookie, он не пройдет страницу входа, а сразу попадет на остальные страницы. Он не может пройти страницу входа, потому что не знает настоящего пароля, так что если он пройдет, то все равно провалится.
Поэтому я помещаю дополнительное значение сессии, чтобы пользователь успешно прошел страницу входа. Теперь внутри каждой критической страницы я проверяю это дополнительное значение сессии, и если оно равно нулю, я выхожу из системы и снова запрашиваю пароль.
Теперь я не знаю, может быть, все это уже сделано микрософтом, нужно еще проверить.
Для проверки этой идеи я использую эту функцию, которая напрямую заставляет пользователя войти в систему.
FormsAuthentication.SetAuthCookie("UserName", false);
Моя вторая защита, которую я уже исправил и использую, заключается в том, что я проверяю разные ips и или разные cookie от одного и того же вошедшего пользователя. Я много думал об этом, много проверял (если он за прокси, если он из разных стран, что он ищет, сколько раз я его видел и т.д...), но вот общая идея.
Это видео показывает именно то, что я пытаюсь предотвратить. Используя трюк, который я описал здесь, вы не сможете просто установить только куки для входа.
Просто делюсь своими идеями...
Сценарий, в котором cookie может быть украден, происходит в общедоступной беспроводной среде. Хотя мы с вами никогда бы не стали работать в такой конфигурации, может быть невозможно помешать вашим клиентам сделать это.
Если злоумышленник знает, к какому защищенному сайту вы подключены, идея состоит в том, что ваш браузер может быть обманут и отправит сообщение на небезопасную версию того же URL-адреса. В этот момент ваш файл cookie будет скомпрометирован.
Вот почему в дополнение к httpOnlyCookies вы захотите указать requireSSL = "true"
<httpCookies httpOnlyCookies="true" requireSSL="true" />
Я не согласен с комментарием Ладьи, поскольку считаю его несправедливым;
@ Аристос, я обновил свой ответ. Но, честно говоря, если вы используете платформу разработки Microsoft, ваше приложение будет небезопасным по своей сути. - The Rook 22 минуты назад
Безопасность не возникает случайно и не происходит «сразу из коробки», по крайней мере, по моему опыту. Нет ничего безопасного, пока оно не разработано для этого, независимо от платформы или инструментов.