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

Аутентификация - это процесс проверки того, кем вы себя называете. Когда вы вводите имя пользователя / пароль в Facebook / bank / и т. Д., Вы пытаетесь подтвердить свою личность - этот процесс называется аутентификацией. Все, что вы здесь делаете, это (пытаетесь) доказать, что вы тот же человек, который изначально подписался на службу XYZ. Существует множество статей о методах аутентификации (имя пользователя / пароль, OAuth, вход в социальные сети и т. Д.), Поэтому мы рассмотрим, что происходит после того, как вы выполнили этап аутентификации - управление сеансом.

Управление сеансом - это процесс отслеживания того, кем вы являетесь после аутентификации. По соображениям безопасности и практическим соображениям, как правило, не рекомендуется передавать свои учетные данные для аутентификации каждый раз, когда вы хотите получить доступ к защищенному ресурсу.

В качестве примера несколько лет назад мне довелось побывать в Пентагоне. Когда я приехал, стойка регистрации провела 30+ минут, проверяя (аутентифицируя), что я гражданин США и должен быть в туре. После этого мне выдали значок (жетон сеанса), который постоянно проверяли охранники, пока я перемещался в разные места в здании. Такая же практика применима к наиболее безопасным зданиям - больницам, эксклюзивным мероприятиям, чрезмерно обеспокоенным корпоративным офисам и т. Д.

Это та же песня / танец, которым следуют все веб-сайты, приложения и серверы, но что делает токен сеанса хорошим и почему имеет значение? Чтобы токены сеанса считались безопасными, они должны соответствовать нескольким принципам. Давайте посмотрим на основные части:

Бессмысленный контент

Токены сеанса НИКОГДА не должны содержать никакой идентифицируемой информации о пользователе, кроме самого токена. Вы ничего не получите от этой практики и как минимум выставите хлебные крошки для атаки, чтобы воссоздать ваш токен. Никогда не делай этого.

Энтропия и длина идентификатора

Энтропия - это просто причудливый способ сказать, что токен должен быть случайным…. Вроде действительно случайный. Когда вы входите в систему безопасности, есть разные уровни [случайности] (https://www.owasp.org/index.php/Insecure_Randomness). Дело в том, что токены сеанса не могут иметь отношения к какой-либо информации о пользователе, и их почти невозможно угадать. Вдобавок к случайности, если эти строки будут достаточно длинными с большим набором символов, это сделает их надежными.

Ключевая неизвестность

Когда мы храним эти токены в браузере или в заголовке, нет смысла называть, для чего они нужны. Не используйте очевидные ключи, такие как «SESSION_TOKEN», выберите что-то, что не подразумевает для злоумышленника, что именно здесь они должны сосредоточить свои усилия.

Эфемерность и ротация

Если вы придерживались пунктов выше, то ваши токены сеанса действительно бессмысленны вне связи, которую вы устанавливаете за кулисами с профилем пользователя. Срок действия этих токенов должен истекать, и их следует регулярно воссоздавать. У вашего приложения могут быть другие потребности, но обычно 1-2 недели - хороший срок жизни для токена сеанса.

Общие атаки

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

"Человек посередине"

Атака человек посередине - это когда злоумышленник нашел способ встать между вашими пользователями и вашим приложением. Самый надежный способ предотвратить это - потребовать, чтобы последняя версия TLS применялась для всех коммуникаций, но это все равно может происходить по разным причинам. Если у вас есть пользователь, который стал жертвой этой атаки, его токен сеанса будет утек. Агрессивная ротация токенов сеанса будет лучшей защитой, помимо исправления самой уязвимости MIM.

Подделка межсайтовых запросов и Межсайтовый скриптинг

Как и MIM-атака, CSRF позволяет злоумышленнику выдавать себя за одного из ваших пользователей и делать «аутентифицированные» запросы. XSS-атаки включают запуск вредоносного javascript в браузере, что также может привести к утечке ключей на стороне клиента. Опять же, ротация токенов сеанса будет вашей лучшей защитой, помимо исправления самих атак.

"Грубая сила"

Меньше всего вам нужно, чтобы злоумышленник имел возможность восстановить один из этих токенов или сделать вывод, как изменить один таким образом, чтобы получить более привилегированный доступ. Рекомендации по бессмысленному контенту и достаточной энтропии защищают от этой атаки.

Это не так уж и страшно

В зависимости от выбранного языка / фреймворка существует множество библиотек, которые предположительно правильно обрабатывают токены сеанса. Но в конечном итоге вы, как разработчик, должны предоставить приложение, отвечающее требованиям безопасности проекта, над которым вы работаете. Знание особенностей токенов сеанса и мотивов, стоящих за их функциями, поможет вам лучше оценить и реализовать лучшую безопасность для вашего приложения.

Первоначально опубликовано на medium.com 28 ноября 2017 г.