Функция аутентификации «Запомнить меня», это всегда означает «незащищенный» веб-сайт?
Просто используйте HtmlHelper ActionLink и установите RouteValues и HtmlAttributes соответственно.
@Html.ActionLink(Reports.RunReport, "RunReport", new { controller = "Performance", reportView = Model.ReportView.ToString() }, new { target = "_blank" })
6 ответов
Реализовать запомнить меня - не такая уж проблема. Что вам нужно сделать, так это поддерживать сеанс в течение длительного времени (и установить длительность cookie). Даже Gmail выйдет из системы через определенный период (я думаю, это две недели или месяц). Однако вы должны понимать, что длительное поддержание одного и того же сеанса открытым увеличивает вероятность его взлома. В качестве контрмеры вам необходимо увеличить силу идентификатора сеанса. Идентификатор сеанса - это тот, который находится в файле cookie (или в URI, который в некоторых программах обычно обозначается как «file.php? PHPSESSID = 1234 ...»).
Ключ состоит в том, чтобы поддерживать надежный идентификатор сеанса. Например, в Gmail у вас есть файл cookie GX со значением, аналогичным
DQAAAJoAAAA8mnjaAwgkS7y8Ws5MYCl-PAQLp9ZpMXpGKR47z4L9mlBH-4qEyApAtFbnLkzv1pPqxua1hOWMGiKYpBZr-h7Icyb-NUUg2ZW_nUFIymvw9KjmjSECYTowbCsDerkAxCzSDa83b5YC1mykPv1a9ji4znt6Fsna-AKgNTntvmUxeJ92ctsSlg9iGySEmXnisVyyJiQvI8jzbZqSpE_N2RKZ
. Причина, по которой перехват сеанса практически невозможен, заключается в том, что идентификатор сеанса очень сильный, а также потому, что сайт везде использует HTTPS. Никто не может угадать или иным образом получить идентификатор вашего сеанса (следовательно, не может захватить ваш сеанс). На первый взгляд кажется, что указанный выше идентификатор сеанса имеет примерно ~ 1250 бит силы, 1 * 10 ^ 376 различных возможностей. Никто не может этого догадаться.
Очевидно, всегда будут потенциальные способы взломать сеанс. Например, уязвимости XSS открывают путь к получению ваших файлов cookie и, следовательно, идентификатора сеанса, но это никоим образом не является вашей ошибкой сеанса и не имеет ничего общего с «запомни меня».
Меня беспокоит тот факт, что даже если процесс входа в систему происходит при https-соединении, при каждом последующем http-запросе cookie будет отправляться в незашифрованном виде в сети.
Если вы установите для флага безопасности cookie значение true в HTTPS, cookie никогда не будет отправлен при доступе к сайту через HTTP. Это необходимо сделать для сайтов, поддерживающих только HTTPS.
В общем, кажется, что люди используют только HTTPS для страницы входа, что неверно. Если кому-то действительно интересно, он должен использовать HTTPS на всей странице. В противном случае предотвратить все попытки перехвата сеанса невозможно.
Почему многие до сих пор используют HTTPS только для входа в систему? Вероятно, потому что они не понимают, что поставлено на карту, или потому, что слишком загружен ЦП, чтобы везде использовать HTTPS. Однако все же лучше использовать HTTPS для входа в систему, чем не использовать его где-либо, потому что он шифрует учетные данные (таким образом, позже может быть украден только идентификатор сеанса, а не фактические учетные данные во время входа в систему).
Возможно, не в facebook (меня это не волнует), но с Gmail, если вы не установите "Всегда использовать https", будет использоваться http-соединение, и оно будет отправлять ваши незашифрованные токены через Интернет. Как вы думаете?
Я думаю, что значение по умолчанию должно быть HTTPS во всех случаях, если возможно. Единственная реальная причина, почему не использовать HTTPS, - это деньги (= производительность / оборудование).
1 / Когда пользователь проверяет «запомнить меня»: вы сохраняете хэш каждой информации о его компьютере: IP, браузер, ОС, язык и т. Д ... и записываете этот хеш в его файлы cookie с его идентификатором {{1 }} 2 / когда пользователь вернулся, вы вычисляете его новый хэш. Вы сравниваете это значение со значением в полученном файле cookie и значением в базе данных (для данного идентификатора). если все они равны, вы можете аутентифицировать пользователя.
Понятно?
Https ничего не может сделать, если у вас есть XSS-атака (лучший способ украсть cookie)
Обычно это называется атакой воспроизведения. Злоумышленник повторяет запрос, используя те же учетные данные (например, cookie), которые он украл у вас, и может выдать себя за вас. Атака XSS - это всего лишь разновидность этого, но ее можно предотвратить (например, с помощью HTTPOnly).
Единственный способ смягчить большинство атак повторного воспроизведения - это повсюду https. Это должно отпугнуть большинство посторонних глаз.
Существует множество методов предотвращения .
Есть также аппаратные устройства, которые работают лучше, чем вы можете взломать программное обеспечение, замедляя работу вашего сервера в процессе, и вы, вероятно, ошибетесь. Специализированное оборудование может намного лучше отслеживать запросы в реальном времени и определять, что один и тот же токен используется множеством разных IP-адресов одновременно, и быстрее, чем может запросить один оператор-человек.
В ASP.NET 2.0+ при использовании проверки подлинности с помощью форм можно указать requireSSL = 'true' , чтобы указать, что браузеры должны отправлять файл cookie проверки подлинности только при установке https-соединения. См. в этой статье msdn для получения дополнительной информации о защите проверки подлинности с помощью форм.
Единственная причина не разрешить запомнить меня - это банковское или подобное приложение. В противном случае просто следуйте нескольким простым правилам:
- Если у вас есть
запомнить меня, установите срок действия cookie максимум на 30 дней в будущем и не меняйте значение. Заставить пользователя входить в систему один раз в месяц не так уж и плохо. - Для любых конфиденциальных операций требуется пароль.При обновлении информации о выставлении счетов, кредитных картах или счетах всегда повторно запрашивают пароль пользователя. Наиболее вероятная форма злоупотребления, как правило, осуществляется через тот же компьютер, который использует человек, но это также гарантирует, что даже украденный файл cookie аутентификации сам по себе не может причинить слишком много вреда. Вы можете видеть мой баланс, но вы не можете ничего передать.
Есть несколько способов предотвращения перехвата сеанса , например, сохранение IP-адреса клиента, открывшего сеанс. Дополнительные данные должны храниться на стороне сервера для проверки сеансов, даже без функции автоматического входа в систему. Лучше использовать для токена одноразовый номер (или, по крайней мере, основывать его на несекретных данных), а не хешированное имя пользователя и пароль, поскольку злоумышленник может провести атаку, чтобы найти информацию аутентификации с хешированное значение.
Если вы посмотрите на источник форм входа в систему Facebook, Gmail и, возможно, других сайтов, действие формы входа в систему использует HTTPS, который затем перенаправляет на незащищенную страницу после успешного входа в систему.
Согласен с большинством комментариев, сделанных выше. Если вы беспокоитесь о безопасности, вам следует -
a) Использовать https везде. Даже gmail недавно перешел на использование https по умолчанию - см. http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html
b) Установить флаг secure в cookie сессии, чтобы браузер не отправлял его через http-соединение.
c) Исправьте XSS в вашем приложении. Если у вас есть проблемы с xss, ваша реализация "запомнить меня" всегда будет небезопасной. См. шпаргалку OWASP XSS Prevention.
Включение IP-адреса в идентификатор сессии НЕ поможет. Это сделает функциональность "запомнить меня" практически бесполезной, и это не добавит много безопасности. Я точно знаю, что google не включает IP-адреса в идентификатор сессии.
Единственный способ сделать полностью безопасный сайт - это включить https везде. Вы правы, cookies могут быть перехвачены и впоследствии использованы для выдачи себя за другого человека.