Функция аутентификации 'Remember-me', всегда ли это означает 'небезопасный' сайт?
Я рассматриваю возможность реализации классического флажка 'remember-me' в моем веб-приложении, чтобы аутентифицированный пользователь мог "запомнить", как только он вернется на мой сайт.
Gmail, Facebook и другие имеют такую функцию, но я не слишком уверен, насколько она может быть безопасной.
Java-фреймворк, подобныйSpring Security , использует "подход на основе хеш-маркеров". Токен, который генерируется (используя имя пользователя, пароль, expirationTime и privateKey), является хранится в файлах Cookies клиента 'token=567whatever567'. Затем маркер повторно используется для повторной аутентификации пользователя при его следующем возвращении.
Меня беспокоит тот факт, что даже если процесс входа в систему происходил по https-соединению, при каждом последующем http-запросе файл cookie будет отправляться в сеть незашифрованным.
В принципе каждый может прочитать маркер и повторно использовать его для аутентификации.
Я пытаюсь посмотреть, как Gmail или Facebook реализуют это функциональность. Я вижу некоторые файлы Cookie, такие как ' presence=DJ267619445G09H0L15228675.....- в FB, другие-в Gmail.
Я не слишком уверен, что они используют какой-то другой трюк, чтобы защитить от кого-то, кто пытается выдать себя за другого пользователя.
Я попытаюсь выдать себя, используя что-то вроде cURL, чтобы увидеть, используют ли они только определенный маркер для запоминания пользователя.
Если это так, то мне кажется, что это серьезная проблема безопасности. Может быть, не facebook(мне все равно) , но с Gmail если вы не установите 'Use always https ', будет использоваться http-соединение, и оно будет отправлять ваши незашифрованные токены через интернет.
А ты как думаешь?
Я также заметил, что поля имени пользователя/пароля Facebook доступны по протоколу http (а не https). В связи с этим мне также интересно : все ли сайты, выставляющие поле username/password по http, небезопасны "по своей природе". Как только запрос отправляется по http, нет никакого "перенаправления на https", которое может исправить " учетные данные, видимые для мировая проблема.
Спасибо
Edit:
Мои опасения были вполне обоснованны http://codebutler.com/
Спасибо создателямFiresheep за то, что осветили проблему!!!
6 ответов:
Это не такая уж проблема, чтобы реализовать remember-me. То, что вам нужно сделать, это сохранить сеанс живым в течение длительного времени (и установить куки на длительный срок). Даже Gmail будет выходить из системы после определенного периода (я думаю, что это две недели или месяц). Тем не менее, вы должны понимать, что сохранение одной и той же сессии открытой дольше увеличивает возможность захвата в нее. В качестве контрмеры необходимо увеличить силу идентификатора сеанса. Идентификатор сеанса-это тот, который находится в файле cookie (или в URI обычно рассматривается в некоторых программах как " файл.php?PHPSESSID=1234...").
Ключ заключается в сохранении надежного идентификатора сеанса. Например, в Gmail у вас есть файл cookie GX со значением, подобным
DQAAAJoAAAA8mnjaAwgkS7y8Ws5MYCl-PAQLp9ZpMXpGKR47z4L9mlBH-4qEyApAtFbnLkzv1pPqxua1hOWMGiKYpBZr-h7Icyb-NUUg2ZW_nUFIymvw9KjmjSECYTowbCsDerkAxCzSDa83b5YC1mykPv1a9ji4znt6Fsna-AKgNTntvmUxeJ92ctsSlg9iGySEmXnisVyyJiQvI8jzbZqSpE_N2RKZПричина, по которой захват сеанса практически невозможен, заключается в том, что идентификатор сеанса настолько силен, и потому что сайт использует HTTPS везде. Никто не может угадать или иным образом получить идентификатор вашей сессии (таким образом, не может перехватить ваш сеанс). На беглый взгляд, идентификатор сеанса выше, кажется, имеет несколько ~1250-бит силы, 1*10^376 различных возможностей. Об этом никто не догадывается.
Очевидно, что всегда будут потенциальные способы все еще захватить сеанс. Например, уязвимости XSS открывают путь к получению ваших файлов cookie и, следовательно, идентификатора сеанса, но это никоим образом не является ошибкой ваших сеансов и не имеет ничего общего с "remember-me".
Меня беспокоит тот факт, что даже если логин процесс происходил под https-соединением, при каждом последующем http-запросе куки будут отправляться незашифрованными по сети.
Если вы установите флажок cookie secure в true, находясь в HTTPS, файл cookie никогда не будет отправлен при доступе к сайту через HTTP. Это необходимо сделать для сайтов только HTTPS.
Как правило, люди используют HTTPS только для страницы входа в систему, что неверно. Если кто-то действительно заботится, он должен использовать HTTPS по всей странице. Иначе невозможно предотвратить все Попытки захвата сессии.
Почему многие до сих пор используют HTTPS только для входа в систему? Вероятно, потому, что они не понимают, что находится в ставках, или потому, что это слишком тяжелый процессор, чтобы использовать HTTPS везде. Однако все же лучше использовать HTTPS для входа в систему, чем не использовать его нигде-потому что он шифрует учетные данные (таким образом, позже может быть украден только идентификатор сеанса, а не фактические учетные данные во время входа в систему).
Может быть, и не facebook(мне все равно), но с Gmail если вы не установите "использовать всегда https", будет использоваться http-соединение, и оно будет отправлять ваши незашифрованные токены через интернет. А ты как думаешь?
Я думаю, что значение по умолчанию должно быть HTTPS во всех случаях, если это возможно. Единственная реальная причина, почему не использовать HTTPS-это деньги (=производительность/оборудование).
Обычно это называется повторной атакой. Злоумышленник повторяет запрос, используя те же учетные данные (например, cookie), которые он украл у вас, и может выдать себя за вас. XSS-атака-это всего лишь вариант этого, но ее можно предотвратить (например, с помощью HTTPOnly).
Единственный способ ослабить большинство атак повтора-это https везде. Это должно держать подальше большинство любопытных глаз.
Существует множество методов профилактики.
Существуют также аппаратные устройства, которые сделайте лучшую работу, чем вы можете взломать в программном обеспечении, замедляя ваш сервер в процессе, и вы, вероятно, получите его неправильно. Специализированное оборудование может намного лучше отслеживать запросы в реальном времени и определять, что один и тот же маркер используется многими различными IP-адресами одновременно, и быстрее, чем один человек-оператор должен быть в состоянии запросить.
В ASP.NET 2.0+, при использовании проверки подлинности форм можно указать
requireSSL='true', чтобы указать, что браузеры должны отправлять только файл cookie проверки подлинности, когда HTTPS-соединение производится. Смотрите эту статью msdn для получения дополнительной информации о защите аутентификации форм.
Единственная причина не разрешить
remember me, Если вы являетесь банковским или подобным приложением. Если нет, просто следуйте нескольким простым правилам:
- Если у вас есть
remember me, Поставьте срок действия на печенье не более 30 дней в будущем и не сдвигайте значение. Заставить пользователя войти в систему раз в месяц не так уж и плохо.- любой чувствительный операции требуют пароля. При обновлении счетов, кредитных карт или реквизитов учетной записи всегда повторно запрашивайте пароль пользователя. Наиболее вероятная форма злоупотребления, как правило, через тот же компьютер, который использует человек, но это также гарантирует, что даже украденный файл cookie аутентификации на его собственном не может причинить слишком много вреда. Вы можете видеть мой баланс, но вы не можете ничего перенести.
Согласен с большинством комментариев, сделанных выше. Если вы беспокоитесь о безопасности, вы должны -
A) используйте https повсюду. Даже gmail недавно перешел на использование https по умолчанию-см. http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html
B) установите флажок secure в вашем сеансовом файле cookie, чтобы браузер не отправлял его по http-соединению.
C) исправьте XSS в вашем приложении. Если у вас есть проблемы с xss, ваша реализация ' remember я " всегда будет небезопасным. Смотрите шпаргалку OWASP XSS Prevention.
Включение IP-адреса в идентификатор сеанса не поможет. Это сделает функциональность "Запомни меня" в значительной степени бесполезной, и это не добавит много безопасности. Я точно знаю, что google не помещает IP-адреса в свой идентификатор сеанса.
Единственный способ сделать сайт полностью безопасным-это включить https везде. Вы правы, печенье можно понюхать, а затем использовать для подражания.
Существует несколько способов предотвращения захвата сеанса, таких как сохранение IP-адреса клиента, открывшего сеанс. Дополнительные данные должны храниться на стороне сервера для проверки сеансов, даже без функции автоматического входа в систему. Лучше использовать nonce для токена (или, по крайней мере, основывать его на несекретных данных), а не хэшированное имя пользователя и пароль, поскольку злоумышленник может смонтировать атаку, чтобы найти аутентификационную информацию, заданную хэшем. значение.
Если вы посмотрите на источник для форм входа Facebook, Gmail и, вероятно, других сайтов, то действие формы входа использует HTTPS, который затем перенаправляет на незащищенную страницу после успешного входа.
1 / когда пользователь проверяет "Запомнить меня": вы храните хэш каждой информации о его компьютере: IP, браузер, ОС, язык и т.д... и вы пишете этот хэш в его печенье с его идентификатором 2 / когда пользователь возвращается, вы вычисляете его новый хэш. Вы сравниваете это значение со значением в полученном файле cookie и значением в базе данных (для данного идентификатора). если все они равны, вы можете аутентифицировать пользователя.
Это ясно ?
Https ничего не может сделать, если у вас есть XSS-атака (лучший способ украсть печенье)