Функция аутентификации «Запомнить меня», это всегда означает «незащищенный» веб-сайт? - PullRequest
11 голосов
/ 03 марта 2010

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

Gmail , Facebook и другие имеют такую ​​функцию, но я не совсем уверен, насколько она безопасна.

Java Framework, такой как Spring Security , использует «подход на основе хеширования». Генерируемый токен (с использованием имени пользователя, пароля, expirationTime и privateKey) хранится в куки-файлах клиента «token = 567whwhat567». Затем токен повторно используется для повторной аутентификации пользователя в следующий раз, когда он возвращается.

Меня беспокоит тот факт, что даже если процесс входа в систему происходил при подключении https, при каждом последующем http-запросе cookie будет отправляться в сети без шифрования.

В основном каждый может прочитать токен и использовать его для аутентификации.

Я пытаюсь посмотреть, как Gmail или Facebook реализуют эту функцию. Я вижу некоторые файлы cookie, такие как «присутствие = DJ267619445G09H0L15228675 .....» в FB, другие в Gmail.
Я не слишком уверен, используют ли они какой-то другой трюк для защиты от кого-то, кто пытается выдать себя за другого пользователя.

Я попытаюсь выдать себя за себя, используя что-то вроде cURL , чтобы увидеть, используют ли они только определенный токен для запоминания пользователя.
Если это так, это выглядит для меня большой проблемой безопасности. Может быть, не Facebook (мне все равно), но с Gmail, если вы не установили ' Всегда использовать https ', будет использоваться http-соединение, и оно будет отправлять ваши незашифрованные токены через Интернет.
Что ты думаешь?

Я также заметил, что поля имени пользователя и пароля Facebook открыты в http (не https). В связи с этим я также задаюсь вопросом: все ли сайты, выставляющие поле имени пользователя / пароля через http, небезопасны «по природе». После отправки запроса через http не существует «перенаправления на https», которое может решить проблему «учетные данные, видимые миру».

Спасибо

Редактировать
Мои опасения были обоснованы http://codebutler.com/
Спасибо создателям Firesheep за освещение проблемы !!!

Ответы [ 6 ]

7 голосов
/ 03 марта 2010

Это не такая проблема, чтобы реализовать запомнить меня. Что вам нужно сделать, это сохранить сеанс в течение длительного времени (и установить 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, куки никогда не будут отправляться при доступе к сайту через HTTP. Это необходимо сделать для HTTPS-сайтов.

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

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

Может быть, не Facebook (мне все равно), но в Gmail, если вы не установите «Всегда использовать https», будет использоваться http-соединение, и оно будет отправлять ваши незашифрованные токены через Интернет. Что ты думаешь?

Я думаю, что значение должно быть по умолчанию HTTPS во всех случаях, если это возможно. Единственная реальная причина, почему бы не использовать HTTPS, это деньги (= производительность / оборудование).

3 голосов
/ 04 марта 2010

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

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

Есть множество методов профилактики тоже.

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

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


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

  1. Если у вас есть remember me, поместите в файл cookie срок действия не позднее, чем через 30 дней и не сдвигайте значение. Заставлять пользователя входить в систему раз в месяц не так уж и плохо.
  2. Любые секретные операции требуют пароль. При обновлении счетов, кредитных карт или данных учетной записи всегда повторно запрашивайте пароль пользователя. Наиболее вероятной формой злоупотребления обычно является использование того же компьютера, который использует этот человек, но он также гарантирует, что даже украденный файл cookie для аутентификации сам по себе не может причинить слишком много вреда. Вы можете видеть мой баланс, но вы не можете ничего перевести.
2 голосов
/ 04 марта 2010

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

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

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

в) Исправьте XSS в вашем приложении. Если у вас есть проблемы с xss, ваша реализация «запомнить меня» всегда будет небезопасной. См. Шпаргалку OWASP XSS Prevention.

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

1 голос
/ 03 марта 2010

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

Это понятно?

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

1 голос
/ 03 марта 2010

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

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

1 голос
/ 03 марта 2010

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

...