Идентификатор сеанса недостаточно случайный - ОБНОВЛЕНИЕ ASP.NET

ОБНОВЛЕНИЕ

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

@Vasile Bujac, поскольку ваш ответ был единственным и упомянул об использовании стандартного решения ASP.NET, я воспринял это как ответ, но спасибо всем за вашу помощь.

Мы используем сканер Retina от Acunetix на работе для сканирования безопасности наших приложений. Это говорит нам о том, что наши идентификаторы сеанса недостаточно случайны и слишком предсказуемы. Я не совсем уверен, как ASP.NET генерирует идентификатор сеанса по умолчанию (я все равно думал, что это GUID?), Но я пошел дальше и реализовал метод расширения класса SessionIDManager и переопределения методов CreateSessionID и Validate для использования Guid как объясняется в этой статье MSDN .

Хотя это делает его немного более случайным, он все же не дает «желаемого» эффекта, согласно Acunetix. Я даже добавил свойство refreshrateExpiredSessionId = "true" в web.config, и это не повлияло. У меня такое чувство, что мне может потребоваться преднамеренно вызвать Session.Abandon () , чтобы полностью очистить сеанс и получить новый идентификатор. Проблема в том, что я должен вызвать его прямо перед тем, как пользователь войдет в систему, поскольку это единственный надежный способ узнать, что пользователь начинает новый сеанс. Таким образом, я не мог ничего установить в сеансе, пока следующая страница не будет загружена так, как работает метод Abandon , и это будет означать промежуточную страницу, которая не очень идеальна, но поможет.

Кто-нибудь когда-нибудь сталкивался с этим или успешно реализовывал исправление?

Кроме того, просто для справки, мы не используем аутентификацию членства / форм, мы просто создаем новый пользовательский класс, когда кто-то входит в систему и сохраняет его в сеансе для дальнейшего использования.

Отчет Acunetix:

CWE-330 CAPEC-59 OWASP2007-A7

Описание: Токены сеанса, которые демонстрируют низкую энтропию («случайность»), часто подвержены атакам прогнозирования. . Небезопасные токены могут быть вызваны неадекватным генератором псевдослучайных чисел, значениями на основе времени, статическими значениями или значениями, основанными на атрибутах пользователя (имя пользователя или идентификатор пользователя). Это означает, что злоумышленник сможет угадать действительный токен сеанса после наблюдения за приложением в течение короткого периода времени и сбора созданных им токенов сеанса. Если злоумышленник определит допустимый токен сеанса для другого пользователя, то можно будет просмотреть, изменить или удалить данные произвольного пользователя без необходимости угадывать имя пользователя или пароль жертвы. Следовательно, возможность вывести действительные токены сеанса позволяет злоумышленнику обходить страницы входа в систему и устранять необходимость подбора учетных записей. Кроме того, статические токены могут позволить злоумышленнику нацеливаться на пользователей, даже если жертва в настоящее время не вошла в приложение. Это увеличивает пул жертв, на которые может нацеливаться злоумышленник.

Токены сеанса должны создаваться с помощью надежного генератора случайных чисел и собираться из большого пула чисел. Например, функции rand () операционной системы обычно бывает достаточно, если она может выдавать 32-битные значения, которые являются статистически однородным распределением. Плохие токены сеанса являются инкрементными, зависят от идентификатора учетной записи пользователя, используют только временные метки или имеют другую сильно детерминированную информацию. Другие методы защиты токенов сеанса - всегда передавать их через SSL, автоматически истекать токен через определенный период времени и явно истекать токен всякий раз, когда пользователь выходит из приложения.

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

• Убедитесь, что значения токенов имеют размер не менее 32 бита, особенно для приложений с большим количеством одновременных пользователей и большим количеством ежедневных запросов страниц.
• Битовый размер источника энтропии (случайные значения) более важен, чем битовый размер фактического токена сеанса. Например, хеш MD5 дает значение 128 бит. Однако каждый из хешей MD5 инкрементальных значений, метки времени или 8-битных случайных чисел небезопасен, поскольку источник случайных значений можно легко предсказать. Следовательно, размер 128 битов не является точной мерой токена сеанса. Минимальный размер источника энтропии составляет 32 бита, хотя более крупные пулы (48 или 64 бита) могут потребоваться для сайтов с более чем 10 000 одновременных пользователей в час.
• В большинстве случаев токены, генерируемые приложением (например, ASP.NET_SessionId, ASPSESSIONID, JSPSESSIONID, PHPSESSIONID), предоставляют достаточно большие случайные значения для предотвращения атак с предсказанием сеанса. Приложение должно использовать эти алгоритмы управления сеансом, если пользовательский механизм сеанса не был тщательно рассмотрен и протестирован.
• Отслеживайте атрибуты пользователя, связанные с токеном сеанса, с объектами на стороне сервера, чтобы предотвратить атаки, связанные с олицетворением пользователя. Если приложение не связывает строго маркер сеанса пользователя с информацией профиля этого пользователя, злоумышленник может просмотреть произвольную информацию, манипулируя значениями на стороне клиента. Например, если приложение устанавливает надежный токен сеанса, но выполняет SQL-запросы на основе cookie «UserId», то злоумышленнику нужно только изменить cookie «UserId», чтобы выдать себя за другого. Приложение было бы более защищенным, если бы оно связывало значение «UserId» с серверным объектом сеанса, поскольку злоумышленник не сможет изменить это значение.
• Срок действия маркеров сеанса истекает, когда пользователь выходит из приложения или после заранее определенного периода бездействия. Мы рекомендуем использовать 20-минутный тайм-аут для токена сеанса, хотя это во многом зависит от типа приложения и ожидаемого использования.