утентификация и управление сессиями включает в себя все аспекты обработки аутентификации пользователя и управления активными сессиями. Аутентификация – критически важный аспект этого процесса, но даже надежные механизмы аутентификации могут быть подорваны из-за недостатков в функциях управления учетными данными, включая смену пароля, забыли пароль, запомнить мой пароль, обновление учетной записи и другие связанные функции. Поскольку “проходящие” атаки вероятны для многих веб-приложений, все функции управления учетными записями должны требовать повторной аутентификации, даже если у пользователя действительный идентификатор сессии.
Аутентификация пользователя в Интернете обычно включает в себя использование идентификатора пользователя и пароля. Существуют более надежные методы аутентификации, такие как программные и аппаратные криптографические токены или биометрия, но такие механизмы слишком дороги для большинства веб-приложений. Широкий спектр недостатков управления учетными записями и сессиями может привести к компрометации учетных записей пользователя или системного администратора. Команды разработчиков часто недооценивают сложность создания схемы аутентификации и управления сессиями, которая адекватно защищает учетные данные на всех этапах сайта. Веб-приложения должны устанавливать сессии для отслеживания потока запросов от каждого пользователя. HTTP не предоставляет этой возможности, поэтому веб-приложения должны создавать ее самостоятельно. Часто среда веб-приложения предоставляет возможность сессии, но многие разработчики предпочитают создавать свои собственные токены сессии. В любом случае, если токены сессии не защищены должным образом, злоумышленник может захватить активную сессию и принять на себя личность пользователя. Создание схемы для создания сильных токенов сессии и их защиты на протяжении всего их жизненного цикла оказалось недостижимым для многих разработчиков. Если все учетные данные для аутентификации и идентификаторы сессии не защищены с помощью SSL в любое время и защищены от раскрытия из-за других недостатков, таких как межсайтовый скриптинг, злоумышленник может захватить сессию пользователя и принять на себя его личность.
Решение
Тщательное и правильное использование пользовательских или готовых механизмов аутентификации и управления сессиями должно значительно уменьшить вероятность проблемы в этой области. Определение и документирование политики вашего сайта в отношении безопасного управления учетными данными пользователей – хороший первый шаг. Обеспечение того, чтобы ваша реализация последовательно соблюдала эту политику, является ключом к наличию безопасного и надежного механизма аутентификации и управления сессиями. Некоторые критически важные области включают:
• Сила пароля – пароли должны иметь ограничения, которые требуют минимального размера и сложности для пароля. Сложность обычно требует использования минимальных комбинаций алфавитных, числовых и/или неалфавитных символов в пароле пользователя (например, по крайней мере один из каждого). Пользователям следует требовать периодически менять свой пароль. Пользователей следует предотвращать повторное использование предыдущих паролей.
• Использование пароля – пользователи должны быть ограничены определенным количеством попыток входа за единицу времени, и повторные неудачные попытки входа должны быть зарегистрированы. Пароли, предоставленные при неудачных попытках входа, не должны записываться, так как это может раскрыть пароль пользователя тому, кто может получить доступ к этому журналу. Система не должна указывать, было ли это имя пользователя или пароль, которые были неправильными, если попытка входа не удалась. Пользователи должны быть проинформированы о дате/времени их последнего успешного входа и количестве неудачных попыток доступа к их учетной записи с того времени.
• Контроль изменения пароля – должен использоваться единый механизм изменения пароля, где бы пользователи не пытались изменить пароль, независимо от ситуации. Пользователям всегда следует требовать предоставлять как свой старый, так и новый пароль при смене пароля (как и всю информацию об учетной записи). Если забытые пароли отправляются пользователям по электронной почте, система должна требовать, чтобы пользователь повторно прошел аутентификацию, когда пользователь меняет свой адрес электронной почты, иначе злоумышленник, который временно имеет доступ к их сессии (например, подойдя к их компьютеру, пока они вошли в систему), может просто изменить свой адрес электронной почты и запросить отправку “забытого” пароля на него.
• Хранение паролей – все пароли должны храниться в хешированной или зашифрованной форме, чтобы защитить их от раскрытия, независимо от того, где они хранятся. Предпочтительнее хранить в хешированной форме, так как она не обратима. Шифрование следует использовать, когда требуется исходный текст пароля, например, при использовании пароля для входа в другую систему. Пароли никогда не должны быть зашиты в исходный код. Ключи дешифрования должны быть хорошо защищены, чтобы гарантировать, что они не могут быть захвачены и использованы для дешифрования файла паролей.
• Защита учетных данных при передаче – единственная эффективная техника заключается в шифровании всей транзакции входа с использованием чего-то вроде SSL. Простые преобразования пароля, такие как его хеширование на клиенте перед передачей, предоставляют мало защиты, так как хешированная версия может просто быть перехвачена и передана заново, даже если фактический пароль в исходном тексте может быть неизвестен.
• Защита идентификатора сессии – идеально, если вся сессия пользователя защищена через SSL. Если это сделано, то идентификатор сессии (например, куки сессии) не может быть захвачен из сети, что является наибольшим риском раскрытия для идентификатора сессии. Если SSL не является жизнеспособным по причинам производительности или другим причинам, то идентификаторы сессии сами по себе должны быть защищены другими способами. Во-первых, они никогда не должны включаться в URL, так как они могут быть сохранены в кеше браузера, отправлены в заголовке реферера или случайно переадресованы “другу”. Идентификаторы сессии должны быть длинными, сложными, случайными числами, которые нельзя легко угадать. Идентификаторы сессии также могут часто меняться во время сессии, чтобы уменьшить, как долго действителен идентификатор сессии. Идентификаторы сессии должны меняться при переключении на SSL, аутентификации или других крупных переходах. Идентификаторы сессии, выбранные пользователем, никогда не должны приниматься.
• Списки учетных записей – системы должны быть разработаны так, чтобы не позволять пользователям получать доступ к списку имен учетных записей на сайте. Если списки пользователей должны быть представлены, рекомендуется использовать некую форму псевдонима (экранное имя), которое соответствует фактической учетной записи, вместо этого. Таким образом, псевдоним не может быть использован во время попытки входа или какой-либо другой хакерской атаки, направленной на учетную запись пользователя.
• Кэширование в браузере – данные аутентификации и сессии никогда не должны передаваться как часть GET, всегда следует использовать POST. Страницы аутентификации должны быть помечены всеми видами тега “no cache”, чтобы предотвратить использование кнопки “назад” в браузере пользователя для возврата на страницу входа и повторной отправки ранее введенных учетных данных. Многие браузеры теперь поддерживают флаг AUTOCOMPLETE=OFF, чтобы предотвратить сохранение учетных данных в кэше автозаполнения.
• Доверительные отношения – архитектура вашего сайта должна избегать неявного доверия между компонентами, когда это возможно. Каждый компонент должен аутентифицировать себя перед любым другим компонентом, с которым он взаимодействует, если нет веской причины этого не делать (например, производительность или отсутствие рабочего механизма). Если требуются доверительные отношения, должны быть введены сильные процедурные и архитектурные механизмы, чтобы гарантировать, что такое доверие не может быть злоупотреблено по мере развития архитектуры сайта со временем.
Для комплексного сканирования уязвимостей и защиты рассмотрите возможность партнерства с надежным решением, таким как INFRA (www.infrascan.net). INFRA предоставляет передовые услуги по сканированию безопасности с check.website и мониторингу для идентификации всех уязвимостей, обеспечивая надежность ваших веб-приложений.