Идентификатор сеанса недостаточно случайный - ASP.NET

Обновить

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

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

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

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

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

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

Отчет от Acunetix:

CWE-330 CAPEC-59 OWASP2007-A7

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

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

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

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

1 ответ:

Насколько я помню, ASP.NET генератор идентификаторов сеансов обеспечивает хорошую защиту от предсказания сеанса. Идентификатор сеанса состоит из 24 символов, использующих символы [a-z] и цифры [0-5] (всего 32 возможных символа, что составляет 2^5), что дает в общей сложности 2^(5*24) = 2^120 возможные значения. Однако вы можете реализовать SessionIDManager для добавления некоторой информации (например, user hostaddress, user-agent, маркер проверки с помощью алгоритма HMAC) для еще лучшей защиты-так, чтобы идентификатор сеанса приходил с другого IP-адреса. Адрес или другой браузер не прошли бы проверку. Если у вас реализована проверка подлинности с помощью форм, то в этом нет необходимости, поскольку билет проверки подлинности уже обеспечивает эти виды защиты.

Если вам нужен лучший идентификатор случайной сессии, вы можете использовать RandomNumberGenerator, такой как RNGCryptoServiceProvider в вашем SessionIDManager и заполнить кучу байтов (скажем, 32, что составляет 256 бит), а затем кодировать их с помощью Base64 

byte[] random = new byte[100];
//RNGCryptoServiceProvider is an implementation of a random number generator.
RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
rng.GetBytes(random); // The array is now filled with cryptographically strong random bytes.
return Convert.ToBase64String(random)

Однако в этой статье говорится, что максимальная длина вашего идентификатора сеанса составляет 80, поэтому вы должны переопределить метод Validate также для того, чтобы он работал.

8