Функция аутентификации "Remember-me", всегда ли это означает "Unsecure" Website?

Ответ 1

Это не такая проблема, чтобы реализовать помню-меня. Что вам нужно сделать, так это долгое время поддерживать сеанс (и установить длительность файла cookie). Даже Gmail выйдет из системы после определенного периода (я думаю, это две недели или месяц). Тем не менее, вам нужно понять, что сохранение того же сеанса, который открывается дольше, увеличивает вероятность его захвата. В качестве меры противодействия вам необходимо увеличить силу вашего идентификатора сеанса. Идентификатор сеанса - это тот, который находится в файле cookie (или в URI, который обычно рассматривается в некотором программном обеспечении как "file.php? PHPSESSID = 1234..." ).

Ключ должен поддерживать сильный идентификатор сеанса. Например, в Gmail у вас есть файл cookie GX со значением, похожим на

DQAAAJoAAAA8mnjaAwgkS7y8Ws5MYCl-PAQLp9ZpMXpGKR47z4L9mlBH-4qEyApAtFbnLkzv1pPqxua1hOWMGiKYpBZr-h7Icyb-NUUg2ZW_nUFIymvw9KjmjSECYTowbCsDerkAxCzSDa83b5YC1mykPv1a9ji4znt6Fsna-AKgNTntvmUxeJ92ctsSlg9iGySEmXnisVyyJiQvI8jzbZqSpE_N2RKZ

Причина, по которой Session Hijacking практически невозможна, потому что идентификатор сеанса настолько силен, и потому, что сайт использует 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 - деньги (= производительность/аппаратное обеспечение).

Ответ 2

Обычно это называется повторной атакой. Злоумышленник повторяет запрос с использованием тех же учетных данных (например, cookie), которые он украл у вас, и может выдать себя за вас. Атака XSS является лишь вариацией этого, но может быть предотвращена (например, с использованием HTTPOnly).

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

Есть множество методов предотвращения.

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

В ASP.NET 2.0+ при использовании проверки подлинности с помощью форм вы можете указать requireSSL='true', чтобы указать, что браузеры должны отправлять cookie аутентификации только при подключении https. См. эту статью msdn для получения дополнительной информации о защите аутентификации форм.

Единственная причина не допускать remember me заключается в том, что вы являетесь банковским или аналогичным приложением. Если вы этого не сделаете, просто следуйте нескольким простым правилам:

• Если у вас remember me, по истечении 30 дней в cookie по истечении 30 дней и не сдвиньте значение. Принуждение пользователя к регистрации один раз в месяц не так уж плохо.
• Для любых чувствительных операций требуется пароль. При обновлении биллинга, кредитных карт или реквизитов аккаунта всегда запрашивается пароль пользователя. Наиболее вероятной формой злоупотребления обычно является тот же компьютер, который используется человеком, но он также гарантирует, что даже украденный файл cookie подлинности сам по себе не может нанести слишком большого вреда. Вы можете видеть мой баланс, но вы ничего не можете передать.

Ответ 3

Согласитесь с большинством комментариев, сделанных выше. Если вас беспокоит безопасность, вы должны -

a) Используйте https повсюду. Даже gmail недавно переключился на использование https по умолчанию - см. http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html

b) Установите безопасный флаг в своем cookie сеанса, чтобы браузер не мог отправить его по http-соединению.

c) Исправьте XSS в своем приложении. Если у вас проблемы с xss, ваша реализация "запомнить меня" всегда будет небезопасной. См. Обходной лист защиты OWASP XSS.

Включение IP-адреса в идентификатор сеанса НЕ поможет. Выполнение этого приведет к тому, что функция "запомнить меня" практически бесполезна, и это не добавит много безопасности. Я точно знаю, что Google не помещает IP-адреса в свой идентификатор сеанса.

Ответ 4

Единственный способ сделать абсолютно безопасный сайт - включить https везде. Вы правы, печенье можно обнюхивать, а затем использовать для выдачи себя.

Ответ 5

Существует несколько способов предотвращения захвата сеанса, например, сохранение IP-адреса клиента, который открыл сеанс. Дополнительные данные должны храниться на стороне сервера для проверки сеансов, даже без автоматической регистрации. Лучше использовать nonce для токена (или, по крайней мере, основывать его на несекретных данных), а не на хэшированном имени пользователя и пароле, так как злоумышленник мог бы смонтировать атаку, чтобы найти информацию об аутентификации, учитывая хеш-значение.

Если вы посмотрите на источник для форм входа в Facebook, Gmail и, возможно, в другие сайты, в действии формы входа используется HTTPS, который затем перенаправляется на незащищенную страницу после успешного входа в систему.

Ответ 6

1/Когда пользователь проверяет "запомнить меня": вы храните хэш каждой информации о своем компьютере: IP, браузер, ОС, язык и т.д.... и вы пишете этот хэш в своих файлах cookie с его идентификатором 2/когда пользователь вернулся, вы вычисляете его новый хеш. Вы сравниваете это значение со значением в полученном cookie и значением в базе данных (для данного идентификатора). если они все равны, вы можете аутентифицировать пользователя.

Ясно ли это?

Https ничего не мог сделать, если у вас есть атака XSS (лучший способ украсть файл cookie)